HTTP header fields

[martinthomson]

Mozilla reviewed this internally and concluded that the HTTP header fields aren't valuable.

This assumes that feature policy has a narrower purpose than described, which is to manage the delegation of permissions. We think that any application of feature policy to security is a poor fit in light of the window.open() escape.

[clelland]

I've updated the issue about the window.open() problem in #173 (new PR in #259)

[clelland]

There are at least three cases that I know of where the header field is useful or necessary -- I just want to make sure that Mozilla has considered all of them.

1. For the 'undesirable behaviour / features' use case in Define the scope of feature policy #252 -- that covers features which a site would most likely be interested in disabling for themselves, which can't be done for top-level documents which aren't being framed by another containing document. (I understand that Mozilla does not necessarily support this use case at all, but I'm listing it for completeness)

2. To sandbox or restrict permissions at the top-level -- Iframe sandboxing can be self-applied through headers, via Content-Security-Policy. This is useful for pages where the operator of the web server really doesn't trust the content, and could be used by Feature Policy for finer-grained control than sandboxing.

3. To support policies in workers -- I'm working on adding support for FP in worker contexts, and those (especially service workers) can't really be considered subresources of the pages which create them. In order to avoid races, it makes sense for workers to define their own policies, through an HTTP-level mechanism. (This is immediately useful for the 'usb' feature, and will be needed for Client Hints (Feature Proposal: Client Hints delegation #129) as well.)