Status

()

Core
DOM: Security
P3
normal
11 months ago
6 days ago

People

(Reporter: ckerschb, Unassigned)

Tracking

(Blocks: 2 bugs, {dev-doc-needed, parity-chrome})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [domsecurity-backlog1])

Attachments

(1 attachment)

(Reporter)

Updated

11 months ago
Priority: -- → P3
Whiteboard: [domsecurity-backlog1]

Updated

5 months ago
Whiteboard: [domsecurity-backlog1] → [domsecurity-backlog1][parity-chrome]

Updated

4 months ago
Blocks: 1442689

Comment 1

4 months ago
FWIW, we decided on a public position of "worth prototyping" in https://github.com/mozilla/standards-positions/issues/24.
(Reporter)

Comment 2

3 months ago
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

Comment 3

3 months ago
I thought the idea was that it could reuse the CSP parser? Did you look at that?
(Reporter)

Comment 4

3 months ago
(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.

Comment 5

3 months ago
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.
(Reporter)

Updated

3 months ago
Depends on: 1458504
(Reporter)

Comment 6

3 months ago
(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.)
Keywords: parity-chrome
Whiteboard: [domsecurity-backlog1][parity-chrome] → [domsecurity-backlog1]
Keywords: dev-doc-needed
You need to log in before you can comment on or make changes to this bug.