Repository navigation
Interactivity #1875
Description
From the PING review:
What is the model of interactivity? How should users know or control with whom they are interacting?
Is integrity or authenticity provided? How does the reader know who authored an EPUB, and confirm that it wasn't altered?
Do digital signatures as defined in the spec provide integrity or authenticity of a book? To what extent does that match guarantees of the web model (a known origin, no mixed content, confidentiality of communication contents). Would ongoing work on signed exchanges be helpful?
Do EPUBs allow entry of user-generated text? Does that text remain local? How does a user distinguish between interactivity that is provided by the reading system and interactivity that is provided by the book itself? When are they communicating with which piece of software? Annotations -- including highlights, margin notes, answers to in-book surveys, etc. -- can reveal very sensitive information that a reader might not wish to disclose to anyone else.
Do reading systems distinguish chrome in a way that provides security to the end user? Do ebooks typically display at full screen? Can they mimic websites and phish users? Our Web privacy guidance typically includes questions about "native UI" to cover cases like these: if there is no distinction between the UI provided by the user agent and the UI of the browseable content itself, then an interactive web site (or ebook) can effectively pretend to be a different site, and phish user credentials, for example. This would be a particular concern if EPUB reading functionality was provided by a web browser and users became accustomed to clicking links in ebooks to continue browsing elsewhere.
Activity
iherman commentedon Oct 27, 2021
The issue was discussed in a meeting on 2021-10-26
View the transcript
1.3. interactivity
See github issue #1875.
Wendy Reid: next is interactivity.
… you had a question about RS and full screen reading.
… full screen reading tends to be an option.
… user-generated text tends to be in annotations, or specific text fields put in by the author.
… but epub doesn't really do local storage.
… and then there is other interactivity that we've touched upon, e.g. some RS lock scripting.
Ivan Herman: re. the annotation system, that is 100% outside purview of the spec.
… implementation of that is down to the RS.
… it would be nice to have a standard annotation system, but today that doesn't exist.
… we can and should put something into RS spec about annotation related privacy concerns.
… but the normative standards should probably not change, since we don't talk about this.
Matt Garrish: there is a spec for annotations, but not sure that it's widely implemented.
… but even that was only about interchange, not about what happens within each RS.
Nick Doty: i think the point of interactivity is that it might not always be obvious who you're interacting with.
… i'm assuming that when i highlight something in my book, that i'm interacting with the RS, but could I also be interacting with the publisher?
… for forms inside books, does that get shared or not?
… the web has historically not been very transparent about this, but there's an opportunity here to be better.
Dave Cramer: on the web we have the idea of origin and first party. When you choose to go to a website, you've given first party defacto permission to collect some info.
… with epub there is a separation between the content creator and the UA.
… if I buy from Kobo, I interact with Kobo but the content is from publisher.
… as far as I know all the data goes back to the retailer, but the publisher knows nothing.
… so in terms of user expectations, a user might have a baseline expectation of greater privacy in ebook than in open web, but not sure that is really the case now.
Nick Doty: but there is an expectation of interoperability, that a book from one retailer can be readable in multiple different UAs.
Nick Doty: there should be some privacy properties that user can rely upon, no matter where they take the book.
Rick Johnson: we used to always need to explain that epub is 2 things, a file format, but also a thing in the supply chain used to ferry around data.
Wendy Reid: remote resources is something we've talked a lot about in the wg, but perhaps we won't get into that now for time.
iherman commentedon Apr 8, 2022
The issue was discussed in a meeting on 2022-04-08
List of resolutions:
View the transcript
1. Close Privacy & Security Issues.
Dave Cramer: the TAG has reappeared of making a couple comments, I am making a PR to mention that when using web APIs, which have the most dramatic privacy and security implications (geolocations, push notifications) then you should get user consent.
See github issue epub-specs#1959.
Dave Cramer: we have several issues where there was never much discussion in the issue (#1959 for example).
… I think the PR i mentioned earlier would serve to close this issue.
… agree/disagree?
Ivan Herman: we had a lot of discussion with PING, good discussions, after which we made extensive additions to answer the issues they raised.
… and we contacted them several times to get their acknowledgement. So at this point we consider these issues closed..
… they have the right to reopen issues if they like.
… Amy from TAG has closed the issue of epub review on the TAG repo, so that is an indication of how they feel.
Gregorio Pellegrino: so is this passed? it is okay?
See github issue epub-specs#1872.
Ivan Herman: yes, it is okay.
Dave Cramer: risk of exposure and finger printability.
… this was raised before we clarified the threat model, can we close this now?
See github issue epub-specs#1873.
Dave Cramer: obfuscation, which we've discussed extensively, followed by updates to the spec docs.
See github issue epub-specs#1875.
See github issue epub-specs#1876.
Dave Cramer: interactivity, which we've addressed as best we can given that it's ambiguous.
… self-contained packages, this is a case where its appropriate to close because epub is clear that it is largely self-contained, subject to exceptions enumerated in the spec. Not dramatically impacting privacy.
See github issue epub-specs#1957.
Dave Cramer: we enumerated the threat model, which deals with #1957.
See github issue epub-specs#1958.
Dave Cramer: permission prompts, we're dealing with this, strengthened text.
See github issue epub-specs#1959.
Dave Cramer: broad user expectations issues, which is covered by the other changes we've made.
Dave Cramer: I think the spec is now much more informative/clear about some of these issues, so thanks everyone.
npdoty commentedon May 10, 2022
user-generated content is noted in the non-normative privacy considerations, which is an improvement.
I think we need to describe the privacy threat of users not having an understanding of when they're interacting with the content (and potentially having that shared with the content author) and when they're interacting with the reading system, so it's understood with whom the reader is communicating when highlighting or making margin notes.
mattgarrish commentedon Jun 22, 2022
We have a normative recommendation to alert users when network activity is occurring now, so doesn't this address the issue of the content trying to phone home any information about the user's activity without their awareness?
npdoty commentedon Jul 1, 2022
I don't know that network activity indicators are an effective way to address that distinction: network activity is after the fact, might not happen in that particular moment, and may not be clearly related to the interaction that the user has (it could be about loading the next page or video, say).
mattgarrish commentedon Jul 1, 2022
It's not really clear to me how a distinction can be made, though. All the reading system knows is that at some point a script might try to connect to a source outside the publication to send/receive some data. For what purpose is beyond it.
I'm not aware of publishers trying to emulate reading system functionality like storing bookmarks and annotations, as it's not trivial to do and probably highly insecure. But other than disclosing data collection policies, seeking consent, and providing options to delete stored data, all of which we also recommend, what else can be done here?
When the experience of doing these things doesn't match users' expectations of the reading system, they're going to know something strange is going on.
And we also recommend to allow users to block all network activity (this is separate from core reading system networking needs), so they don't have to wait until the reading system alerts them with a direct prompt or they see a network icon flashing to take action.