Change security best practice to unique origin per publication #1518
Conversation
…n per publication
mattgarrish
requested review from
iherman,
bduga,
lrosenthol,
dauwhe,
shiestyle and
wareid
epub33/rs/index.html
Outdated
|
|
||
| <!-- | ||
| After each working draft is published: | ||
| - change the link/text in the section heading to refer to the published draft (use the dated URL) | ||
| - move all changes down to the next section | ||
| --> | ||
|
|
||
| <ul> | ||
| <li>19-Feb-2021: Updated the scripting security recommendations so that the text discusses assigning |
There was a problem hiding this comment.
Maybe "recommends" rather than "discusses"? Not sure of the ideal way to mention a non-normative change.
There was a problem hiding this comment.
That's okay. W3C specs include a reference to RFC 8174, which makes it formal that non-capitalized uses of 2119 keywords only have their plain English meaning. I've been meaning to give the docs a once over to undo some of the more egregious uses of "might" and "need"... :)
epub33/rs/index.html
Outdated
| Adopting this approach will isolate documents from each other and from other Internet | ||
| domains, thereby limiting access to external URLs, cookies, DOM storage, etc.</p> | ||
| <p>Reading Systems need to behave as if a unique origin were allocated to each <a>EPUB | ||
| Publication</a>. Adopting this approach will isolate publications from each other, |
There was a problem hiding this comment.
I think it is worth putting a reference to the 'formal' origin (ie, to https://url.spec.whatwg.org/#origin) emphasize the Web Security aspect. This can be as simple as making the word an active link or a formal reference to the URL spec (probably the best is to do both).
epub33/rs/index.html
Outdated
| Adopting this approach will isolate documents from each other and from other Internet | ||
| domains, thereby limiting access to external URLs, cookies, DOM storage, etc.</p> | ||
| <p>Reading Systems need to behave as if a unique origin were allocated to each <a>EPUB | ||
| Publication</a>. Adopting this approach will isolate publications from each other, |
There was a problem hiding this comment.
I wonder whether 'must' is not a better term. I know this is not a normative section, ie, a MUST is not an option, but the usage of the word 'must' may give more emphasis.
There was a problem hiding this comment.
Yes, no reason not to start fixing some of these now.
rewrite scripting security to use non-rfc lowercase wording
…to fix/issue-1156
Yes, but I'm thinking of doing that in a separate PR. I want to look at the authoring document and ensure it still makes sense. It looks like not all the reading system requirements were reflected in the prose, like which contexts we recommend scripting support in and which are only optional. |
|
I just realized... we may want to add a link from §11 to §4.4.2. Or merge §4.4.2 to §11? I am tempted to go with the latter, but I am not sure what was the rationale for §4.4.2 originally. |
This PR updates the security section so that it discusses assigning a unique origin to each publication rather than assigning a unique domain per content document.
Let me know if the new note captures the issues that were raised on the 2021-02-18 telecon relating to how web-based reading systems cannot always enforce this kind of restriction and/or if there's anything else missing or that needs fixing.
Fixes #1156
Fixes #873