-
Notifications
You must be signed in to change notification settings - Fork 154
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor cop-editing nit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A great proposal and write-up, thanks @clelland!
|
||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about same-origin iframes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a pretty great initial sketch!
``` | ||
|
||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Add a first draft of an explainer for document policies