EPUB 3 Working Group Telco — Minutes

Date: 2022-06-09

See also the Agenda and the IRC Log

Attendees

Present: Masakazu Kitahara, Ben Schroeter, Wendy Reid, Matthew Chan, Toshiaki Koike, Dave Cramer, Matt Garrish, Brady Duga, Shinya Takami (高見真也)

Regrets:

Guests:

Chair: Dave Cramer

Scribe(s): Matthew Chan

Content:

Wendy Reid: hello++.

Dave Cramer: in our last meeting we discussed the paper written by EU security researcher who were looking at security issues in various RS.
… wendyreid invited them to guest at our meeting last week.
… interesting discussing ensued, with some recommendations. Today we try to work thru some of those issues..

1. Disallowing File URLs.

See github issue epub-specs#2324.

See github pull request epub-specs#2329.

Dave Cramer: I can’t think of good reason to have these, but a lot of good reasons to prohibit them.

Brady Duga: yes, sounds good. File URLs seem to be interoperable. What file would you load from an epub?.

Ben Schroeter: most common thing i’ve seen is youtube videos, but those aren’t file URLs, right?.

Brady Duga: depends on how the epub is created. Could be a link to youtube, or link to external resource that plays in your epub, but neither of those are file URLs.

Dave Cramer: file URL goes against idea that epub should be self contained, you don’t want epub author to look at your files in your local machine.

Ben Schroeter: when Play gets file URL what happens?.

Brady Duga: probably gets stripped on the server, but probably gets intercepted and rejected. We might try to open it in the browser, but then the browser would probably reject it.
… there are also a lot of origin issues with file URLs.

Dave Cramer: I propose we forbid file URLs.

Brady Duga: there’s already a PR open for that.

Proposed resolution: Remove file URLs, merge PR 2329 and close issue 2324. (Wendy Reid)

Ben Schroeter: +1.

Dave Cramer: +1.

Brady Duga: +1.

Masakazu Kitahara: +1.

Wendy Reid: +1.

Matthew Chan: +1.

Matt Garrish: +1.

Ben Schroeter: +1.

Toshiaki Koike: +1.

Resolution #1: Remove file URLs, merge PR 2329 and close issue 2324.

2. Recommendation to frequently update reading system engines.

See github issue epub-specs#2323.

Dave Cramer: recommend RS should update their distributed devices and apps regularly.
… not sure if this will change behaviour of RS vendors.

Wendy Reid: i like the spirit of this recommendations, but it doesn’t seem testable or enforceable. Also not sure if it will happen, as updating these things is more fraught than necessary.

Brady Duga: it might be out of your control. Google has a browser based version, so if user updates their browser, then RS is updated. Android update will update the browser..
… Google can’t make Apple update embedded hardware.
… recommendation won’t change that.

Matt Garrish: this is kind of like a recommendation that RS vendor who abandon support should pull their app from circulation.

Ben Schroeter: similarly, we could also recommend that users update their browsers too.

Dave Cramer: yeah, and HTML spec doesn’t recommend that users update browser.

Wendy Reid: I think this came up specifically in reference to kindle software using old webkit, similarly difficult to update on old Linux devices.

Dave Cramer: I think there are RS where even if they wanted to update some components it is not possible, codebase is too old, original devs are gone.

Brady Duga: I know people who update webview and it’s really really hard to do it without breaking things.

Dave Cramer: another factor is that you have the ability to mitigate some of these issues in different ways.
… given that these are complicated systems, its not just the rendering engine that controls user experience.
… not seeing a lot of appetite for this.

Proposed resolution: Close issue 2323 as won’t fix. (Wendy Reid)

Dave Cramer: +1.

Ben Schroeter: +1.

Wendy Reid: +1.

Matthew Chan: +1.

Matt Garrish: +1.

Toshiaki Koike: +1.

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

Masakazu Kitahara: +1.

Brady Duga: +1.

Resolution #2: Close issue 2323 as won’t fix.

3. Adding malicious symbolic links to an EPUB application.

See github issue epub-specs#2322.

Dave Cramer: symbolic link outside the epub pointing to local fs, should we discuss this in threat model and/or explicitly disallow.
… not sure how this would be done in practice.

Brady Duga: there is a parameter to include symlink in zip.

Dave Cramer: yes, -y.
… but i didn’t get a chance to try this.
… should we add the idea to the threat model?.

Wendy Reid: i think so.

Brady Duga: this one is more obscure, easy for people not to think of this. So maybe just a notice to watch out for this, and similar threats of files referencing other files.
… and this wouldn’t be a MUST or a SHOULD?.

Matt Garrish: could it be a MUST though? “RS must not preserve symbolic link when unpacking” something like that.

Brady Duga: it depends on the fs, the OS… not sure how I would tell people not to do this, and I don’t want to limit this to the way you would do it using zip.

Dave Cramer: and if you have a really bad RS that allows scripting, and the script asks the local fs to do stuff.

Ben Schroeter: is epubcheck looking into this issue?.

Matt Garrish: romain is looking into whether epubcheck could detect such symlinks.

Proposed resolution: Add symbolic links to the threat model, investigate whether EPUBCheck can detect symlinks. (Wendy Reid)

Brady Duga: +1.

Wendy Reid: +1.

Ben Schroeter: +1.

Matt Garrish: +1.

Matthew Chan: +1.

Dave Cramer: +1.

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

Toshiaki Koike: +1.

Masakazu Kitahara: +1.

Resolution #3: Add symbolic links to the threat model, investigate whether EPUBCheck can detect symlinks.

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.

5. AOB?.

Dave Cramer: okay, then thanks everyone. We’ll see you all soon!.

6. Resolutions