Re: [w3ctag/design-reviews] Feature Policy: Document Policies (#408)

Thanks for taking a look -- I'll see if I can update the explainer. Some of the more formal bits can probably be removed now, since they're covered in the actual spec text.

To answer the questions here in advance of that:

1. There are three headers and an attribute, which work together like this:
* Document-Policy: Response header which sets the policy for the document it is delivered with.
* Require-Document-Policy: Response header which sets a *minimum* policy for *any* embedded content.
* <iframe policy>: attribute which sets a minimum policy for any content loaded into that frame.
* Sec-Required-Document-Policy: Request header, which details the minimum policy required for the document being requested.

Essentially, if there is a minimum policy required (in most cases there won't be, unless `Require-Document-Policy` or <iframe policy> has been used) then it is advertised to the server with the `Sec-Required-Document-Policy` header. If the document in the response doesn't meet that requirement, then it will not be loaded.

2. The spec has been updated since I filed this request (I'll update the issue with the link there) There are still a couple of sections needing to be fleshed out, but the algorithms and structures are all there, I believe.

3. "Guardrails" is an informal term we've been using to talk about controls that make it easier for developers to succeed, to create performant sites, either by removing poorly-performing APIs, or letting them know through reporting when they're doing something that is likely to be slow. I'll see if I can rewrite that, either to explain it or to use clearer terms.

4. The 'requires-acknowledgment' flag is part of definition the feature itself, and not something that is up to a developer to control. We would define that flag for a feature based on whether or not it is safe to impose the policy on a subframe without requiring the subframe to explicitly set it in its own Document-Policy header.

    As a couple of examples:
    - If we define a document policy feature to disable `document.write`, that could have unintended consequences on pages which aren't aware that it could be disabled, potentially introducing security bugs on a previously-safe page. So that policy would require acknowledgment. You could set it on your own document, but you can't impose it on another one without its consent.
    - If we define a policy that requires images to have declared sizes, to improve layout speed, that would likely not cause any drastic consequences to a page that wasn't aware of the policy (other than maybe making it look worse). We could probably safely impose that policy without needing the embedded page to acknowledge it explicitly.
   - Also, iframe sandboxing already defines a number of similar features that can be disabled, that don't require acknowledgment, and this has generally been okay. If we want to use Document Policy to explain sandboxing, then those features should be implemented in a way that doesn't require acknowledgment.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/408#issuecomment-591013926