Skip to content
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.

Sign up for GitHub

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

HTML <meta>-delivery #313

Open
wants to merge 8 commits into
base: main
Choose a base branch
from
Open

HTML <meta>-delivery #313

Changes from 2 commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
31b087c
First stab at <meta>-delivery
eeeps May 16, 2019
11a4465
Merge branch 'master' of https://github.com/wicg/feature-policy into …
eeeps May 16, 2019
fa92356
Merge branch 'master' of https://github.com/wicg/feature-policy into …
eeeps May 30, 2019
f79b1a8
Add "Merge a new declared policy into document’s existing Feature Pol…
eeeps May 30, 2019
24495e4
Tweaks
eeeps May 31, 2019
aba86ca
Revert "Add "Merge a new declared policy into document’s existing Fea…
eeeps May 31, 2019
4dcdb5b
Add "Merge two declared policies" algorithm.
eeeps May 31, 2019
e3cc937
Oops
eeeps May 31, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
51 changes: 50 additions & 1 deletion index.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -231,7 +231,7 @@ spec:reporting; urlPrefix: https://w3c.github.io/reporting/
<section>
<h3 id="header-policies">Header policies</h3>
<p>A <dfn>header policy</dfn> is a list of <a>policy directives</a>
delivered via an HTTP header with a document. This forms the document's
delivered via an HTTP header with a document, or a . This forms the document's
<a>feature policy</a>'s <a>declared policy</a>.</p>
</section>
<section>
Expand Down Expand Up @@ -427,6 +427,55 @@ spec:reporting; urlPrefix: https://w3c.github.io/reporting/
</div>
</section>
</section>
<section>
<h3 id="meta-element">
The `<meta>` element
</h3>

A {{Document}} may deliver a policy via one or more HTML <{meta}> elements
whose <{meta/http-equiv}> attributes are an <a>ASCII case-insensitive</a>
match for the string "`Feature-Policy`". For example:

<div class="example">
<pre highlight="html">
&lt;meta http-equiv="Feature-Policy" content="fullscreen 'none'; geolocation 'none'"&gt;
</pre>
</div>

Implementation details can be found in HTML's <a>Feature Policy state</a>
`http-equiv` processing instructions [[!HTML]].

Authors are <em>strongly encouraged</em> to place <{meta}> elements as early
Copy link
Contributor

@Malvoz Malvoz May 19, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it important to mention that the <meta charset> should be set before <meta http-equiv>s? I asked the same thing in w3c/webappsec-csp#387.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question, and thanks for the heads up. I'll plan to monitor the conversation there and copy any changes over.

in the document as possible, because policies in <{meta}> elements are not
applied to content which precedes them.

<div class="example">

For example, a script tag that preceded a &lt;meta&gt;-delivered policy
directive of `sync-xhr ‘none’` would still be able to call
`XMLHttpRequest.open()`.

<pre highlight="html">
&lt;script&gt;
var req = new XMLHttpRequest();
req.open("GET", "/api/security_check.json", false);
req.send();
&lt;/script&gt;

&lt;meta http-equiv="Feature-Policy" content="sync-xhr ‘none"&gt;
</pre>

In the above, the call to req.open will succeed, because the policy
disabling sync-xhr occurs after it, in the markup.

</div>

Note: A policy specified via a <{meta}> element will be enforced along with any other policies active, regardless of where they're specified. However, once a specific Feature Policy directive has been set by way of an HTTP header or <{meta}> element, that directive cannot be further updated or changed.
<!--TODO this is first wins. do we want last wins? -->
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How multiple Feature-Policy headers should be combined is the subject of #148. I don't think this PR should change anything other than adding text to say that using <meta> for Feature Policy is allowed, and each such <meta> is interpreted as though a separate Feature-Policy header field were appended to the HTTP response header. Then the text that resolves #148 can explain how multiple 'Feature-Policy' header fields are combined together.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that's possible as they are parsed independently. If you start a quoted string in one and end inside a <meta> that should not work.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point :)

A <meta> element would have to be parsed and merged separately from the response headers.

That's also necessary because it would be encountered after create a new browsing context has already initialized the document's policy (unless we specify that it interacts with the preload scanner somehow, but I think there is legitimate hesitancy to adding more dependencies on that).

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and each such <meta> is interpreted as though a separate Feature-Policy header field were appended to the HTTP response header.

I don't think that's possible as they are parsed independently.

I think you're probably interpreting me too literally. I just meant that each <meta http-equiv=Feature-Policy> should be interpreted the same as if it were a HTTP header.

More generally, it seems bad that CSP and Feature-Policy as specifying so many details for <meta http-equiv>; it seems like HTML5 itself should provide more infrastructure for these specs to reuse.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, for starters there's disagreement on whether we should add more <meta http-equiv>. I don't think it's a good idea as it makes all these policies dynamic and there's usually subtly different processing models across browsers leading to issues.

Then, the value-space is different, headers contain bytes, attribute values contain strings. Then, headers can be parsed as a single-block (and ideally combined, then parsed), elements are typically parsed case-by-case.

There are some reusable bits there, but all of it requires quite a bit of care.

And then, for consistency across <meta http-equiv>, it's unclear to what extent that exists today, but if someone were to invest time in that maybe some abstraction is feasible as you suggest.


Note: Modifications to the <{meta/content}> attribute of a <{meta}> element after the element has been parsed will be ignored.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about adding a new <meta http-equiv='Feature-Policy'> header to the DOM using script? This is done regularly with CSP to tighten the policy after the initial scripts have loaded.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This language doesn't say anything about what happens when new elements are inserted. As I plan to re-use as much of the specific HTML processing step language from CSP as possible, I expect that the behavior will be similar.

Because FP is more about client side behavior, and less about loading/blocking resources, I don't expect that pattern to be as common here, as it is with CSP.

That said, if we do expect it to be a common pattern, it may merit a mention in this high-level-guideline-y, non-normative bit of text.

Thoughts?

</section>
</section>
<section>
<h2 id="introspection">Policy Introspection from Scripts</h2>
Expand Down