Should a RS require user consent to use scripting?

[iherman]

This came up at the discussion with @GJFR at the EPUB meeting: should we advise Reading Systems (e.g., in §15.3) to ask for user's consent before accepting a publication that uses scripting?

[iherman]

cc @bduga

[mattgarrish]

#2297 has this:

Reading systems that allow users to load untrustworthy EPUB publications (e.g., unsigned EPUB publications through the process of "sideloading") SHOULD treat such content as insecure (e.g., prompt users to allow scripting and network access).

If a book comes straight from the vendor's store to the RS, do we want to worry users every time or do we trust that vendors are vetting their content?

[bduga]

If a book comes straight from the vendor's store to the RS, do we want to worry users every time or do we trust that vendors are vetting their content?

I'm not really sure. Vetting scripts is hard, and I expect it would be entirely possible for bad actors to insert malicious code into some epubs without the epub creator being aware of it. That said, do we want to become the "accept all cookies" of the publishing world? We could add a comment along the lines of "Even content that comes directly from a known party could contain malicious code and Reading Systems MAY want to allow users to treat such content as untrusted, for example by allowing users to disable scripts and network access. Whether such controls are provided is left to the Reading System implementor, as is their specific design (e.g. allowing per-source controls, global settings, etc)."

[mattgarrish]

That said, do we want to become the "accept all cookies" of the publishing world?

Ya, that also worries me, but I actually read the request here to warn the user after they've paid for the book as they download it to their reading system. That strikes me as a strange time to inject the warning. It seems like a warning you should get before purchasing, but then we're really going far afield from epub content or reading systems.

I'd be fine with recommending that reading systems allow scripting to be disabled for all/individual publications. We already recommend that for network access, and scripting seems like the lesser of the two evils. I can disable scripting in my browser, so why not for publications?

[iherman]

I'd be fine with recommending that reading systems allow scripting to be disabled for all/individual publications. We already recommend that for network access, and scripting seems like the lesser of the two evils. I can disable scripting in my browser, so why not for publications?

I would be fine with that, but this would really work if I, as a user, knew that there is scripting in the publication in the first place.

I wonder whether it is realistic to say that RS-s might consider giving a visual clue when a publication includes scripting (just like my mac has a small light on the menubar if there is a recording going on). That, plus the possibility to turn scripting off, might be enough, and that avoids the "accept all cookies" effect...

[mattgarrish]

I wonder whether it is realistic to say that RS-s might consider giving a visual clue when a publication includes scripting

That's probably more reasonable than an alert every time a book is loaded into a reading system, but on the flip side we're getting into the UI which we've generally avoided doing.

[GJFR]

I like the option to disable scripting for all publications. But indeed, most users won't be aware of scripting, unless there's an explicit indication.

Another option would be to disable scripting by default, so the user is required to explicitly enable it through the RS's settings if they want to. To me, this especially makes sense because the majority of publications do not seem to embed scripts (please correct me if I’m wrong!).

Consequently, EPUB creators wanting to embed scripts, could just still do so and additionally include <noscript> tags, indicating to the user that this publication requires scripting. E.g.:

<noscript>
This publication employs scripts, please enable scripting in your reading application
or use an application that supports scripts.
</noscript>

Other than the somewhat increased user friction, there's still a downside from a security perspective as well. Once a user enables scripting because of one publication requiring it, all other publications loaded afterwards will be able to silently execute scripts, unless the user disables scripting again.

[iherman]

Consequently, EPUB creators wanting to embed scripts, could just still do so and additionally include <noscript> tags, indicating to the user that this publication requires scripting. E.g.:

<noscript>
This publication employs scripts, please enable scripting in your reading application
or use an application that supports scripts.
</noscript>

Alas! That won't work. AFAIK, <noscript> works in HTML only, it does not work in XHTML, and EPUB relies on XHTML...

[mattgarrish]

To me, this especially makes sense because the majority of publications do not seem to embed scripts (please correct me if I’m wrong!).

I believe this depends on the type of publishing. For trade fiction, no, but for educational material scripting is more common. Maybe some of the vendors here have general numbers on how much scripting there is in the content they distribute.

AFAIK, <noscript> works in HTML only

Yes, it not only doesn't work but isn't valid in XHTML.

The answer doesn't have to be never to warn users, but the requirement should allow flexibility for reading systems to adapt their interfaces to user preferences. If I'm not worried about scripting and don't care about warnings, maybe there's an "accept all" option that disables the warning.

Going over this discussion so far, and just mulling the problem generally, it seems like there are a number of recommendations that could be needed:

• Reading systems SHOULD provide users a method of specifying a global preference for enabling scripting in newly loaded EPUB publications.
• If a reading system does not provide users a method of specifying a global preference, it SHOULD alert users to enable scripting each time a scripted EPUB publication is loaded.
• Reading systems SHOULD allow users to enable/disable scripting for individual EPUB publications without affecting other EPUB publications in the reading system.
• Reading systems SHOULD allow users to enable/disable scripting at any time while reading an EPUB publication.
• Reading systems SHOULD provide users a method of discovering which of their EPUB publications contain scripted content (e.g., a visual marker in a bookshelf or a field in the publication metadata).

Not suggesting we have to implement all of the above, but getting consent and making sure users know what is going on is a multi-faceted problem.

[iherman]

The issue was discussed in a meeting on 2022-06-09

List of resolutions:

• Resolution No. 4: Close issue 2321, no change to current statement on network activity.

View the transcript

4. Should a RS require user consent to use scripting?.

See github issue epub-specs#2321.

Wendy Reid: mixed feelings. Yes we should be asking for user consent if the script is taking info out of the epub, but i've seen more epubs that use js innocuously to animate things, and I don't want to scare users.

Dave Cramer: we use it in cookbooks to make a timer in the corner.
… i don't think a blanket consent is warranted.
… we already rely on HTML-like things, and things like geolocation already recommend user consent. So we are covered for those.

Brady Duga: what about tracking external media on every page? No scripting is involved, but no consent there?.

Matt Garrish: the network activity part of it is the more dangerous thing.
… the question of how to attain consent while not blasting users with notifications is a difficult question.

Dave Cramer: it leads to the web situation where 100x a day you get a cookies pop-up.
… i don't really want to perpetuate that model.

Wendy Reid: it is worth having something about this, because it is a true threat.
… something like "RS should warn a user when something is going to activate network activity".
… this is more rare.
… and we could keep the wording of the recommendation loose enough so that RS can decide whether it is a blanket consent, or epub by epub.

Dave Cramer: what do we have on network activity right now?.

Wendy Reid: nothing specific.

Ben Schroeter: how would you word it so that your average user would really understand what they are consenting to? "Network activity"? I wouldn't expect people to understand.

Matt Garrish: https://w3c.github.io/epub-specs/epub33/rs/#sec-epub-rs-network-access says:

"If reading system developers allow network access, it is RECOMMENDED both that they
notify users when network activity occurs; and
let users block access to the network (e.g., disable network access for the reading system globally or for a particular EPUB publication)."

Wendy Reid: like the MacOS approach: "always load links from this source" sort of thing.
… not usual pattern to the average user.

Brady Duga: but a Zoom link, for example, is the user clicking on a link. What if the user just turns a page and a video auto-plays?.
… I think the user should get a prompt if the video is remote.
… user is not expecting turning a page could communicate to another party.

Wendy Reid: we have recommendation re. consent to network access.

Dave Cramer: going stricter than what we have could be hard.

Proposed resolution: Close issue 2321, no change to current statement on network activity. (Wendy Reid)

Dave Cramer: +1.

Wendy Reid: +1.

Ben Schroeter: +1.

Shinya Takami (高見真也): +1.

Brady Duga: +1.

Toshiaki Koike: +1.

Matt Garrish: +1.

Masakazu Kitahara: +1.

Resolution #4: Close issue 2321, no change to current statement on network activity.

Brady Duga: it's not that user consent to scripting goes too far, it's that the real threat is network activity.