Priority: -- → P3
Whiteboard: [domsecurity-backlog1] → [domsecurity-backlog1][parity-chrome]
FWIW, we decided on a public position of "worth prototyping" in https://github.com/mozilla/standards-positions/issues/24.
Created attachment 8971280 [details] [diff] [review] bug_1390801_implement_feature_policy.patch Adding a WIP patch which allows to: * parse HTTP response header and creates an object representation for featurePolicy * allows to query whether a feature is allowed or not; that API is available through C++ and also provides the necessary WebIDL bindings so one could query |document.policy.allowsFeature("camera");| * added testcase which verifies those parts are working This patch does not include: * Actually preffing off the requested feature for the context Also there a bunch of cornercases that need to be sorted out: * What happens if an http header ships a feature policy which contradicts with the value in the frame 'allows' attribute * what happens if two http feature policies are sent (first one wins?) * upper/lowercase checks
I thought the idea was that it could reuse the CSP parser? Did you look at that?
(In reply to Anne (:annevk) from comment #3) > I thought the idea was that it could reuse the CSP parser? Did you look at > that? CSP Parser is a massive and complex piece of software. In contrast, a feature policy only has to do 4 string comparisions once tokenized and that's it. I think it would make sense that CSP and Feature Policy share the same tokenizer, but the actual parsing should happen separately. I would change my mind if feature policy all of a sudden would accept wildcards like *.example.com, but I hope we don't go down that route. The way it is right now, the feature policy parser can just rely on NS_NewURI() which does all the URI parsing for us.
I guess I'm mostly concerned about the tokenizer, then. I just don't want to end up in a situation where they diverge and we're stuck with two.
(In reply to Anne (:annevk) from comment #5) > I guess I'm mostly concerned about the tokenizer, then. I just don't want to > end up in a situation where they diverge and we're stuck with two. FWIW, I filed Bug 1458504 to factor out the tokenizer.
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Whiteboard: [domsecurity-backlog1][parity-chrome] → [domsecurity-backlog1]
You need to log in before you can comment on or make changes to this bug.