EPUB 3 Working Group Telco — Minutes

Date: 2022-06-17

See also the Agenda and the IRC Log

Attendees

Present: Dave Cramer, Zheng Xu (徐征), Masakazu Kitahara, Toshiaki Koike, Matthew Chan, Wendy Reid, Ivan Herman, Matt Garrish, Brady Duga, Avneesh Singh, Aimee Ubbink, Charles LaPierre, Jen Goulden

Regrets:

Guests:

Chair: Dave Cramer

Scribe(s): Matthew Chan

Content:

Wendy Reid: present_.

1. Malicious Symbolic Links in EPUB.

See github issue epub-specs#2322.

Dave Cramer: this was raised as possible security issue as a way to create links to the local fs. Because these things are OS dependent, we have been working on how to define this requirement, and how stringent to be. Also investigating how epubcheck can help.

Dave Cramer: See proposal in a comment to close the issue.

Brady Duga: the SHOULD NOT is a little weird because the purpose of SHOULD is that ‘we don’t think you should do this, but there are exceptional cases where it might make sense’.
… we’re using it to me ‘we’re not sure how to express this so we’ll just say SHOULD NOT’.

Matt Garrish: why not make it make it a MUST NOT and accept that epubcheck can’t catch everything?.

Brady Duga: problem with a MUST is that we are trying to define behaviour over an undefined concept, so it’s hard to put normative statements around that.

Ivan Herman: agreed. I’ve tried to find language to fit this, but I couldn’t..
… I would love to say ‘MUST NOT’ but not sure how to define the prohibited behaviour.
… and I agree that using SHOULD NOT is vague for the same reasons.

Brady Duga: this isn’t a real problem, there aren’t a lot of epubs with symlinks in it. If you do put symlink it, your epub will probably break on most RS..
… real risk here is that someone finds out that there is a key secret file in a RS, and they make an epub with a symlink to the file, and then exfiltrate the data.
… we just want to make sure RS devs know that this is a threat.
… in practice, people aren’t doing this.

Dave Cramer: and we’re already catching some of this. I tested this in an epub, and epubcheck threw an error.
… so even if we can’t define these things, they don’t match the signature of the things we do allow.

Matt Garrish: you could set the symlink as a data file to prevent it from being checked, but if someone is up to no good there isn’t a guaranteed way to find it.

Dave Cramer: i could see it being done accidentally, like if you had an alias on your desktop and accidentally put it in your epub.
… i’m also okay with doing this even if we don’t have an iron clad definition of what it is.

Proposed resolution: proceed as described in https://github.com/w3c/epub-specs/issues/2322#issuecomment-1157847432 and then close the issue. (Ivan Herman)

Dave Cramer: +1.

Wendy Reid: +1.

Ivan Herman: +1.

Brady Duga: +1.

Masakazu Kitahara: +1.

Matthew Chan: +1.

Zheng Xu (徐征): +1.

Toshiaki Koike: +1.

Charles LaPierre: +1.

Resolution #1: proceed as described in https://github.com/w3c/epub-specs/issues/2322#issuecomment-1157847432 and then close the issue.

2. Consider security implications of URI schemes.

See github issue epub-specs#2320.

Dave Cramer: not sure what to do here because having a mailto: link is a pretty ordinary thing.
… but the fact that these can be abused is a problem.

Ivan Herman: we might be getting into the same problem as with symlinks if we try to be precise about it.
… we found some, like file: that we definitely want to avoid, but not sure how to make a general statement about this.
… other than maybe ‘be careful about which URI schemes you use’.
… for example, you don’t want to open up the discussion about bitcoin here.

Matt Garrish: we made the change a few weeks back that remote resources should be referenced by HTTPS, for other URI schemes, they will probably spawn some other app (dialing app, mail client).
… not sure this is our problem to solve, feels like we are going a little far afield.
… new schemes come up all the time.

Brady Duga: i think we’ve already fixed this. 1. URI schemes that are used internally - resolved with banning file: and HTTPS, 2. URI scheme that goes to another app.
… you may not recognize that a link is of this 2nd type.
… but we’ve added a suggestion that links external to the epub trigger notification to user.

Ivan Herman: not sure that that 2nd part is in the spec yet.

Brady Duga: okay, then let’s recommend a ‘hey, you’re leaving our secure space now’ to external links.
… that would solve this problem.
… most apps are good about this. They won’t automatically take an action when they open..

Dave Cramer: i think informing user and getting consent is key here, not worrying about technical details.

Matt Garrish: I don’t recall this being in the spec.

Ivan Herman: yes, we discussed this in a prior meeting.

Matt Garrish: but not in the security section currently.

Ivan Herman: is this going to be a SHOULD or a MUST?.

Brady Duga: SHOULD. Preserves the ability for user consent to be subject to a global allow.

Proposed resolution: Recommend the user SHOULD be given notification about links and their destination as part of RS recommendations, close issue 2320. (Wendy Reid)

Dave Cramer: +1.

Charles LaPierre: +1.

Toshiaki Koike: +1.

Wendy Reid: +1.

Matt Garrish: +1.

Brady Duga: +1.

Matthew Chan: +1.

Aimee Ubbink: +1.

Zheng Xu (徐征): +1.

Ivan Herman: +1.

Masakazu Kitahara: +1.

Resolution #2: Recommend the user SHOULD be given notification about links and their destination as part of RS recommendations, close issue 2320.

Ivan Herman: mgarrish can you find where we want to put this?.

3. Reading system requirement to resolve property datatype values.

See github issue epub-specs#2317.

Wendy Reid: i attempted to write some tests about the property datatype values.
… these can appear in 2 places: OPF and content documents themselves.
… applies to any of the vocab, e.g. dc.
… the way it is currently worded in spec, we are expecting RS to resolve those prefixes to URLs.
… e.g. a11y would resolve to an expanded URL that takes you to a fragment.
… ‘RS must resolve this to a URL’.
… but how to tell if RS is doing this in a test? Also, are RS really doing this? Because RS just needs to tell what kind of property it is.

Ivan Herman: it is clearly something that is sneaking into the spec from the RDFa world.
… which says that every property that you use must be identifiable by an URI.
… what these prefixes do is to abbreviate those URIs.
… I tried testing by saying that if RS really did this, then I would be able to use the full URI wherever I would use the prefixed version, and the behaviour would be the same.
… and all RS I tried failed on this test.
… so we have functionality here that is already heading towards under-implemented path unless we change it.
… essentially the whole prefix mechanism becomes unnecessary.
… i don’t think the package document is suitable for RDFa anyway.
… maybe content document might be RDFa-able.

Matt Garrish: the package document was supposed to be RDFa-lite.
… so RDFa was an underpinning, but my understanding was that we were never requiring RS to process as RDFa.
… so if you wanted to treat them as just tokens, you could.
… to me i don’t know if this requirement for RDFa processing should be a SHOULD or even a MAY.
… what we do have is the way that you should do the processing if you wanted to do that.
… I think we should make that distinction clear.

Ivan Herman: okay, so the operative thing is to make that clarification.

Matt Garrish: we’ve never had a statement that you must expand all data types. But somehow we say that you must support the mechanisms.

Ivan Herman: there are a number of places in the spec where we say “if there is no prefix, then use this URL”.
… those statements would have to be clarified or changed then.
… so we wouldn’t just be changing the vocab section.

Matt Garrish: i’d have to review the spec.

Wendy Reid: https://w3c.github.io/epub-specs/epub33/rs/#sec-vocab-assoc.

Matt Garrish: it should be like everything else in the spec i,e. ‘if you are doing it, then here are the mechanisms’.

Wendy Reid: i think all the MUSTs are there, but they are all MUSTs.
… these are all meant to be testable, and i have yet to find a way to test them.
… so maybe we don’t have an action today, other than giving mgarrish time to review?.

4. Changed the RS section on i18n.

See github pull request epub-specs#2330.

Ivan Herman: this is a general problem. In the RS spec, we have a general statement of the sort ‘RS MUST treat HTML or CSS etc. as conforming to those other specs’.
… and we decided that all our testing concentrates on those things that epub spec adds.
… but there are some statements in i18n section (e.g. xml-lang, dir) where we are creating tests for features specified in HTML.
… the PR changes i18n section so that only the additional features are subject to normative statements.
… similarly, there is another issue. Daniel, who is now running our tests on Thorium, says that we should not put the acid test in the test suite since it will fail all the time.
… there we make a general statement that RS should implement CSS, but then later we say that RS MUST implement CSS in such and such a way.
… these latter normative statements are really superseded by other specs.
… I would propose to allow merging this PR about the changes to i18n now, and then review the rest of the spec to see how pervasive this sort of issue is in other sections.

Proposed resolution: Merge PR 2330, review remainder of specification for similar issues. (Wendy Reid)

Dave Cramer: +1.

Wendy Reid: +1.

Toshiaki Koike: +1.

Matt Garrish: +1.

Charles LaPierre: +1.

Matthew Chan: +1.

Brady Duga: +1.

Masakazu Kitahara: +1.

Zheng Xu (徐征): +1.

Ivan Herman: +1.

Resolution #3: Merge PR 2330, review remainder of specification for similar issues.

Ivan Herman: if we find additional similar things, then we should come up with a PR with all those changes. e.g. Including the one about the acid test.

5. AOB?.

Ivan Herman: the Thorium team is probably the first to systemically go through the tests.
… out of the 100s we currently have, they have 30-40 with which they have problems.
… they will raise issues for those where they have problems.
… there are some features that Thorium just does not implement.
… the other thing is that I have reached out to the Chinese team. Tried to get our Chinese colleagues to reach out to Xiaomi to see if they will participate in our tests.
… also we are still missing test from the test suite.
… we need more test contributors!.
… e.g. how would you make a general test on disallowing file: URLs?.
… if you can find a general way to do that, I would be grateful.

Dave Cramer: okay, thank you everyone for being here.
… we will see everyone next time.

6. Resolutions