EPUB 3 Working Group Telco — Minutes

Date: 2022-05-26

See also the Agenda and the IRC Log

Attendees

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

Regrets:

Guests:

Chair: Dave Cramer

Scribe(s): Matthew Chan

Content:

Dave Cramer: welcome all to this post-CR meeting.
… this means that our highest priority is testing.
… but we also have some issues around privacy and security.
… which we will discuss today.

1. Security and Privacy issues.

1.1. Making statements normative.

See github pull request epub-specs#2297.

Dave Cramer: one of the key elements of the feedback was that most of our security and privacy section was non-normative, and Nick thought it should be.
… this PR makes that change so that many of the things we discussed non-normative have become normative, but still SHOULD.
… reading through this PR, it seems to be a better statement of our values and the importance of privacy and security.

Matt Garrish: this also addresses concern re. unsigned epubs and whether RS can trust such epubs.
… not sure how to phrase, because unsigned doesn’t necessarily mean untrustworthy.
… language now gives a lot of leeway to RS.
… can’t necessarily be enforced, but still good practice that we are now throwing our weight behind.

Dave Cramer: still significant progress versus previous versions of epub on this.

Wendy Reid: we can’t merge anything right now because we have it set so that it auto publishes after a merge.
… we need to figure out if we need a new snapshot.

Proposed resolution: Approve PR 2297. (Wendy Reid)

Dave Cramer: +1.

Matt Garrish: +1.

Matthew Chan: +1.

Dan Lazin: +1.

Toshiaki Koike: +1.

Wendy Reid: +1.

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

Brady Duga: +1.

Masakazu Kitahara: +1.

Resolution #1: Approve PR 2297.

1.2. External Resources should be loaded securely.

See github issue epub-specs#2263.

See github pull request epub-specs#2299.

Dave Cramer: this issue comes with this PR.
… this is around remote resources, and recommended that they be served over HTTPS.
… avoiding person in the middle and other such network attacks.

Dan Lazin: my only concern is the PR itself is not super clear in its language.
… “RS may not load resources”.
… what we mean is there is a chance RS may not load.
… I’ll do a pass.

Dave Cramer: this is SHOULD level, so would we test whether a remote resource is served via HTTP, and that would result in a warning from epubcheck?.

Matt Garrish: yes, that is what I would expect.

Dave Cramer: this could affect existing content, but I expect it would be rare.

Matt Garrish: generally the direction of the web is HTTPS too.
… this will cause some warnings, but security outweighs. We should move in the direction of the web.

Dave Cramer: using backwards compatibility as reason not to fix security issue isn’t where we want to be.

Proposed resolution: Approve PR 2299, close issue 2265. (Wendy Reid)

Brady Duga: +1.

Wendy Reid: +1.

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

Matthew Chan: +1.

Masakazu Kitahara: +1.

Dan Lazin: +1.

Dave Cramer: +1.

Toshiaki Koike: +1.

Matt Garrish: +1.

Resolution #2: Approve PR 2299, close issue 2265.

1.3. Authenticity and Integrity checks.

See github issue epub-specs#2265.

Dave Cramer: we did add a section about this in the previously approved PR 2297.
… XML signatures does support signing of the epub.
… so there is a mechanism for this, but i’m not aware of an epub RS that supports signing or that would alert end user/do something else if faced with signed epub where signature is invalid.

Brady Duga: an attacker could just re-sign the epub with their own signature. RS can’t know what signature should be.

Dave Cramer: so should we just note that we have a signature capability, but given the nature of epub it is tough to ascertain a chain of trust even though it is possible on the web?.

Brady Duga: the PR itself looks fine.
… do we have to resolve all issues, right? And the raiser must be happy with resolution? This is part of CR transition?.

Wendy Reid: yes.
… we can close the issue, and then make sure that PR gets an okay from security and privacy reviewers.

1.4. Review of issues in “Reading Between the Lines”.

See github issue epub-specs#2266.

Dave Cramer: See (academic) paper on EPUB Security.

Dave Cramer: this is a paywalled academic paper, link is to the author’s own website.
… they tested close to 100 epub RS, with some automated tests of security issues (e.g. scripting). Concluded with a few recommendations on how to change the spec.
… I’ve looked at it briefly.
… we were talking earlier about remote resources, but it seems that we allow use of local resources, which may be a significant security hole.
… it also mentioned that half of RS that supported javascript supported geolocation, etc..
… they say it wasn’t mentioned in spec, but it should be covered by our recommendation for soliciting user consent.
… I think several of us need to review issues raised in it.

Wendy Reid: mgarrish gave good summary of points in issue.
… authors make some suggestions around the support of javascript and that the spec should specify no access to local file system.
… but we’ve always strayed from explicitly telling RS how to build an RS.
… their points are valid, and the RSs featured should take those issues up.
… rather than changes that should be made in the spec itself.

Dan Lazin: should we invite them to give us a presentation and some recommendations?.

Dave Cramer: I like the idea of having a dialog with them. They seem interested and knowledgeable.

Wendy Reid: I also like the idea.

Dave Cramer: good topic for next chairs call.

Brady Duga: +1.
… also re access to file system, does that mean you can’t access the epub? Difficult not to be overly broad in prohibitions.

Matt Garrish: this is why I didn’t try to write a PR to answer this one.
… their main point of contention is file: URLs right?.
… we can block those in authoring without breaking epub.
… trickier on RS side.
… we talk in theory about how file: URLs could be used, but does anyone even do this in reality?.

Dave Cramer: <xi:include href=file:://usr/passwd>.

Matt Garrish: if there was a way to block that I personally wouldn’t take issue, but the language would be tricky from RS perspective.

Wendy Reid: I’ve found the authors of the paper online.

Dave Cramer: that’s a great way forward on this issue.
… we could probably learn from each other.

1.5. Persistent storage security.

See github pull request epub-specs#2301.

See github issue epub-specs#2264.

Dave Cramer: about unrelated documents.

Matt Garrish: this is about two requirements that were still in the spec, but which are no longer applicable.
… i.e., language around each document being treated as its own domain.
… if you absolutely need to use persistent storage, then we recommend you encrypt instead of storing as plaintext.

Dave Cramer: a lot of people have done proofs of concept of drafting epubs that can read data from local storage created by a different epub.

Matt Garrish: not sure if javascript encrypting is trivial to break or not, but at least we are saying to pay attention to this.
… we also recommend just not storing sensitive data in the first place, if you don’t have to.

Proposed resolution: Approve PR 2301, close issue 2264. (Wendy Reid)

Dave Cramer: +1.

Matt Garrish: +1.

Brady Duga: +1.

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

Wendy Reid: +1.

Dan Lazin: +1.

Toshiaki Koike: +1.

Matthew Chan: +1.

Masakazu Kitahara: +1.

Resolution #3: Approve PR 2301, close issue 2264.

2. Testing.

2.1. Standardize formatting of mol-navigation.

See github pull request epub-tests#148.

Dan Lazin: this is a discussion of a comment in the PR.
… this was a test for MO, and this was a test for a MUST within the MO section (which is a SHOULD).
… Ivan has created a way to filter should tests, so that, for example, a tester could say “i’m not worried about the ‘should’ tests”.
… but in order for us to determine whether the spec is implementable, the MUST_s within the should sections are still important.
… we need to have 2 independent implementations of these _MUST-s too.
… so what is the purpose of marking some tests as should, and based on the answer to same, how do we treat MUST-s in SHOULD sections?.

Dave Cramer: do we have this problem on a higher level? If we allow possibility of audio only RS, then anything related to visual only is not required.

Dan Lazin: that’s the opposite of this, because those tests would not be marked as SHOULD-s, and could not be accidentally filtered out.

Dave Cramer: so in some sense we may need to leave it up to the RS dev, e.g. if the RS in question doesn’t support MO.

Matt Garrish: so we’re concerned about how to handle filtering? Can Ivan just fix this in the filtering script?.

Dan Lazin: I think its what is the purpose of marking a test as a should test? Are we telling RS tester not to worry about this? Or are we telling Director not to worry about this?.
… I think purpose of our tests is CR. So I would think we do NOT mark such tests as should tests.
… maybe we should defer this until Ivan is here, this isn’t urgent.

Brady Duga: yes, fine to defer. But it seems these tests are going to be marked as MUST-s because they ARE MUST-s..
… otherwise they would just be SHOULD in the spec.

Wendy Reid: I would be more worried about this if it wasn’t in a feature like MO that is already fairly well supported.
… could some of the more technical features of MO be at risk? Sure. But the core feature of MO I’m not worried about.

Dan Lazin: hearing duga’s reply, and no disagreements, I’m tending towards not flagging them as should tests. I don’t think Ivan feels strongly, but we can follow up with him next meeting.

Wendy Reid: I’ll wait for the PR for us to resolve.

3. AOB?.

Brady Duga: don’t accidentally sign up for the wrong TPAC conference!.

Wendy Reid: there’s a name conflict. 2 conferences named TPAC in Vancouver at the same time.

Dan Lazin: within a few days W3C will link us to a block of discount TPAC hotels.

Dave Cramer: the information is forthcoming.
… okay, that wraps us up, thanks everyone!.

4. Resolutions