Create document-policy-explainer.md #328
Conversation
Add a first draft of an explainer for document policies
Fixing review issues
|
@annevk, do you want to take a look, and see if this is a good starting point for discussion? @ojanvafai @foolip @jpchase @triblondon FYI as well |
|
In deeper nesting section's last line: GET / HTTP/1.1
Host: c.example.com
Sec-Required-Document-Policy: image-compression;bpp=2(Note that in the last example, the stricter requirements imposed by the top-level document subsume the requirements on the nested frame, so the combined threshold value is still 'bpp=4'.) I suppose the bpp=4 should be bpp=2 to match what happens in the example. |
|
|
||
| All existing sandbox features can be defined as document policies as well. The | ||
| iframe `sandbox` attribute will disable all of them by default, but they can be | ||
| turned back on either with the `policy` attribute or the `sandbox` attribute. |
There was a problem hiding this comment.
What would it look like to turn sandbox flag back off with the policy attribute? Would it be <iframe sandbox policy="forms">, as an equivalent to <iframe sandbox="allow-forms">?
There was a problem hiding this comment.
I think that would be the syntax, if we can do it. I'm worried about the compat implications of allowing both <iframs sandbox="allow-forms"> and <iframe sandbox policy="forms"> though.
There was a problem hiding this comment.
Do you mean the risk of people adopting <iframe sandbox policy="forms"> before it works in all browsers, and ending up not having the behavior they want in some browsers? There's also the potential confusion of having two equivalent ways to express two things. What's the strongest argument for having this new form? Tradeoffs :)
|
|
||
| In documents generated from `data:` URLs, and in iframe srcdoc documents, where | ||
| the parent document controls the content of the child explicitly, and there is | ||
| no HTTP network transfer, the acknowledgment will simply be implied. |
There was a problem hiding this comment.
That's a possibility -- does it open up any new kinds of attacks, where being able to affect the policy on an iframe and not requiring it to consent enables things you couldn't do otherwise?
There was a problem hiding this comment.
I'm not to sure if there are plausible attacks here, but it does seem like the same argument as for data: and srcdoc applies: the same origin controls both things.
This all reminds me of the decision to not require <iframe allow="fullscreen"> for the same-origin case, although it's just analogous and risks might be different.
Fixing minor issues (Thanks @huchenlei, @sideshowbarker, @foolip)
| ``` | ||
|
|
||
| None of these result in a `Sec-Required-Feature-Policy` header, as all of the | ||
| existing sandbox features are safelisted. |
There was a problem hiding this comment.
I think we should leave this as an open issue as surfacing existing sandboxing features seems quite valuable and gives servers more control over potential attacks. (In that case there would not have to be matching response header, but that seems okay, quite similar to CORS.) Also, this should be Sec-Required-Document-Policy.
There was a problem hiding this comment.
Thanks for catching the name :)
I was looking to maintain some kind of parity between the items which are advertised in that header and the policies which you must declare in order to be loaded. I wonder if we'd need some different syntax to denote policies which will be enforced, but which you don't get to refuse?
Leaving an open issue seems like the right thing here, agreed.
Fix typo in header name in sandbox example.
clelland
added
the
document-policy
Add a first draft of an explainer for document policies