How do you allow EPUBs in CORS / CSP / iframe origin policy?

[dlazin]

In the WG discussion for #1061, I mentioned that one consideration is how the developer maintaining an external iframed resource could specify a CORS header that lets EPUBs (or one specific EPUB, or one specific reading system) to load the resource, while blocking some other origins.

The same basic question applies to Content Security Policy and the obsolete X-Frame-Options header: since an EPUB isn't a real webpage, it doesn't have an URL, so how does the developer maintaining an external service specify an EPUB "address" (origin) in a CORS/CSP/X-Frame-Origins directive?

Links on the topic:
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

[dlazin]

Related, as discussed in today's face-to-face:
#1374

[iherman]

The issue was discussed in a meeting on 2021-10-29

List of resolutions:

• Resolution No. 1: Merge PR Recommend that path-absolute-URL strings not be used to reference resources #1725.

View the transcript

2.3. "IRI of the Package Document": what is this exactly? (issue epub-specs#1374)

See github issue epub-specs#1374.

Dave Cramer: See more detailed explanation.

Romain Deltour: I may summarize.
… the big problem is defining how to resolve relative URLs in an EPUB.
… most of the URLs we use are relative URLs.
… but an URL object is something which is parsed from an URL string.
… to make it absolute.
… it is done by the parsing algorith.
… I make an example.

parse("doc.xhtml", "https://example.org") == "https://example.org/doc.xhtml".

Romain Deltour: for using this algorith we have to now the base URL (https://example.org).
… the problem is that our spec doesn't define what is the URL of the EPUB (because it may be used in different locations: online, offline, ecc.).

Romain Deltour: e.g., http://example.org/publisher/mobydick.epub#/EPUB/package.opf.

Romain Deltour: I'm going to show other examples.

parse("doc.xhtml", "http://example.org/publisher/mobydick.epub#/EPUB/package.opf") == "http://example.org/publisher/doc.xhtml".

parse("../../doc.xhtml", "http://example.org/publisher/mobydick.epub#/EPUB/package.opf") == "http://example.org/doc.xhtml" // ⚠️ OUTSIDE OF CONTAINER.

Romain Deltour: in this case I'm going outside of the EPUB.

parse("/doc.html", "http://example.org/publisher/mobydick.epub#/EPUB/package.opf") == "http://example.org/doc.xhtml" // ⚠️ OUTSIDE OF CONTAINER.

Romain Deltour: that's why I think we should define which is the base URL, also for security issues.
… the solution should be unambiguious.
… the resulting URL should not go outside the container.
… resolving two relative URLs in two different EPUBs they should not resolve in the same absolute URL.
… the URL of the EPUB should not share the same origin.
… these are the 4 objectives of the ideal solution.

Ivan Herman: I remember that one solution may be to consider an EPUB as a localhost (with a unique port).
… so the localhost:port is what represents the root for the EPUB.
… but if the RS works in a streaming way, it may not work (because the EPUB is not decompressed).
… and if it goes out of the EPUB, the user gets a 404.

Romain Deltour: yes, there are different approches. One is to use domains, another is to use a custom protocol scheme:.

parse("/", "epub:/") == "epub:/".

parse("../../doc.xhtml", "epub:/EPUB/package.opf") == "epub:/doc.xhtml".

Romain Deltour: I don't know which one is better.
… from a RS point of view.

Ivan Herman: I think defining a URI scheme for that is not a good idea.

Romain Deltour: I don't think we'll come with a solution that will be used by the end user.

Brady Duga: I think there are 4 cases: local URLs, online URLs, jar URLs.
… I think is the last URL the problem.
… isn't it?

Romain Deltour: yes, but also referencing to resources outside the package.

Brady Duga: do we need to tell people how to display URLs inside on EPUBs (using fragments)?.
… I would propose to remove it.

Romain Deltour: somewhat related, a gist from @annevk about ZIP URLs (from 8 years ago): https://gist.github.com/annevk/6174119.

Hadrien Gardeur: referencing everything outside the archive is problematic specially for the content document.
… I don't think we should get to a specific resolution here, because the RSs have different solutions.

Romain Deltour: removing that paragraph about the URL of the package document won't work.
… we need to tell people how to build them.

Romain Deltour: at a minimium, we should base everything on the assumption that there is a url for the root of the container.
… and we leave it for the reading system to define.
… I'm not sure that will work.
… and we are back to the discussion that the RS spec should say something.

See github issue epub-specs#1843.

Dan Lazin: there is another issue: #1843.
… about URIs for EPUBs.
… how do specify epub in cors/iframe policy?.
… I don't know how this is managed today.
… you need some way to say, hi, I am aware of this epub can it can iframe my content.

Romain Deltour: this might not answer entirely.
… RS spec says, for scripting, reading system must associate a unique origin to the script.
… a similar mechanism could be used to answer that issue about CORS/CSP.

Dan Lazin: is it a predicable url?.

Romain Deltour: this scripting mechanism is only about an origin--could be an opaque origin, doesn't have to be a url.
… opaque origin serializes to null.

Ivan Herman: where do we go from here?.

Dave Cramer: do we ask for help?.

Ivan Herman: we have tried and failed before.
… we have been discussing these things.
… if we come up with a concrete proposal.
… and then check whether that solution is acceptable to the TAG or whoever.
… my knowledge is not good enough to write a proposal.

Romain Deltour: I was supposed to come up with a proposal.
… I can write a summary of issue with possible approaches "paths" to solutions.
… I don't know enough about URLs and security to know all the plusses and minuses.

Ivan Herman: we can't go to CR with this stuff open.
… it's unfortunate that Tess is not around any more, we might ask the TAG.
… and the TAG takes time.
… we have time pressure.

Dave Cramer: could we talk to ping?.

Romain Deltour: could we liase with Anne at WhatWG?.

Ivan Herman: I worry about that.

Tzviya Siegman: talking to Tess would be good.

Ivan Herman: if we have a proposal that romain can put together.
… my first option would be to involve Tess.

Romain Deltour: I can summarize the problem statement.

Laurent Le Meur: tests will take time.
… why don't we just say that path-absolute URLs are illegal.
… and just update epubcheck?.
… to post an error if there's a slash at the beginning of URL.

Romain Deltour: path-absolute URLs are a red herring. the issue is with any relative URL really..

Laurence Zaysser: could we have a fifth objective, easy to move to web publication?.

Romain Deltour: it's about any relative urls. Just dealing with path-relative won't solve the issue.

See github pull request epub-specs#1725.

Matt Garrish: we have 1725 PR, which forbids path-absolute URLs. Is there any reason we shouldn't merge that?.
… should we close that? Or integrate it because it deals with part of the question?.

Wendy Reid: have we exhausted this?.

Ivan Herman: to answer matt, that one can go in.

Romain Deltour: +1.

Ivan Herman: using root-relative IRIs is a bad idea for something like epub, where the root url is unclear.

Proposed resolution: Merge PR #1725. (Wendy Reid)

Romain Deltour: +1.

Ben Schroeter: +1.

Ivan Herman: +1.

Gregorio Pellegrino: +1.

Matt Garrish: +1.

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

Dave Cramer: +1.

Brady Duga: +1.

Matthew Chan: +1.

Tzviya Siegman: +1.

John Roque: +1.

Bill Kasdorf: +1.

Wendy Reid: +1.

Toshiaki Koike: +1.

Laurent Le Meur: +1.

Charles LaPierre: +1.

Hadrien Gardeur: +1.

Dan Lazin: +1.

Resolution #1: Merge PR #1725.

[dlazin]

I will write a note for the Security sections of the specs.

[iherman]

The issue was discussed in a meeting on 2022-02-25

• no resolutions were taken

View the transcript

3. How do you allow EPUBs in CORS / CSP / iframe origin policy? (issue epub-specs#1843)

See github issue epub-specs#1843.

Dave Cramer: this is issue about external iframe resources, and CORS headers about having this in epub.

Dan Lazin: we were talking a few months ago about whether external resources are good idea, and how there are legit cases for them..
… say you are an educational publisher, and you have a demo that you want to embed, but only in your website and your epubs.
… normally you do this by setting X-frame or CSP in your server.
… not sure how you would do this in epub, since it doesn't have URL.
… the internal browser core may have a URL that it uses to refer to the epub, but as an RS developer, I don't know what that is.

Ivan Herman: i played with this URL area in the spec in Nov, and your supposition is correct.
… an epub document has its own fancy URL which is different from one RS to another.
… there is no way a 3rd party setting up a website could refer to it in a security policy.
… we don't define what the root URL of the package is, we only define it in a behavioural way.
… earlier today I saw in Apple Books and Thorium that some of them use URLs that are non-standard, etc..
… simply put, you can't do it. And not sure how you would do it..

Dan Lazin: might be okay for us not to implement it, but it might not be our call whether we implement it or not.
… security horizontal review might take issue with it.
… should we note this in our security document?.

Matt Garrish: it's not that it's not supported, but as you say, you can't rely on it or it might work.
… it's the same with any web scenario where you can't set the header.

Brady Duga: the way you describe CORS is almost like a DRM mechanism, but it's more like, a script is only allow to request resources from a place that would allow that origin.
… this is only for scripting and a few other places.
… we support CORS, but it might not work. You can use wildcards to set the origins.
… we haven't created a security hole, it's more like our security is very restrictive/tight.

Ivan Herman: +1 for Brady's formulation.

Dan Lazin: so I would have to allow my server to be iframed by anyone, can't limit to only my own books.
… say you had a sign-in page that i wanted to control iframing of, I couldn't do that.

Ivan Herman: only change I can see is to explicitly add this to the security document somewhere.
… it's otherwise an unsolvable problem.

Dan Lazin: duga's point about wildcards means there might be a solution.
… could we for example say that epub origins must always have epub: protocol?.

Ivan Herman: we'd have to define the protocol, and no current RS uses it.

Dan Lazin: at a future point, if we could create some limits on the epub origin that are easily wildcardable, we could make CORS/CSP work in epub.

Ivan Herman: we can think about this in epub 4.

Dave Cramer: not sure what solution we can implement in 3.3.

Dan Lazin: i propose that we add something about this in the security note.

Ivan Herman: dlazin, you should....

Dave Cramer: okay, good bye for now, thank you for all the interesting discussion!.

---