“Should request be allowed to use feature” algorithm #220
Conversation
index.bs
Outdated
| <h3 id="should-request-be-allowed-to-use-feature">Should <var>request</var> be allowed to use <var>feature</var>?</h3> | ||
| <p>Given a feature (<var>feature</var>) and a <a for="/">request</a> (<var>request</var>), this algorithm returns <code>true</code> if the request should be allowed to use <var>feature</var>, and <code>false</code> otherwise.</p> | ||
| <ol> | ||
| <li>Set |global object| to |request|’s <a for="request">client</a>’s <a for="environment settings object">global object</a>.</li> |
There was a problem hiding this comment.
Hmm, I'd love to get @annevk to sanity check this..
Given that we're talking about passed in "request", shouldn't we use use request's attribute directly, as defined by Fetch? E.g. Fetch#client or Fetch#request-window?
There was a problem hiding this comment.
Depends what you want to happen in non-window contexts like workers.
There was a problem hiding this comment.
As mentioned below, there's not a good way to set feature policies in non-document contexts yet (work on that front is happening in #207); until there is, I don't think I can know where to check for set policies, here.
index.bs
Outdated
| <li>If |global object| is a {{Document}}, set |document| to |global object|.</li> | ||
| <li>If |global object| is a {{Window}}, set |document| to |global object|’s <a>associated `Document`</a>.</li> | ||
| <li>If |document| is null, return <code>false</code>. | ||
| <div class="issue">How can we enable secure use of policy-controlled features within requests initiated by clients that do not have documents? e.g., from within {{WorkerGlobalScope}}s or {{WorkletGlobalScope}}s, i.e., within Service Workers?</div> |
There was a problem hiding this comment.
ServiceWorker's client has an associated origin, we should be checking against that?
@jakearchibald any guidance? :)
There was a problem hiding this comment.
The CSP model would probably work well here. https://www.w3.org/TR/CSP3/#html-integration
Documents and worker globals have the CSP list. Requests are blocked before reaching the service worker if they fail the document's CSP. However, the service worker may also have its own CSP which blocks additional requests.
CSP also checks responses. I don't know if that's desirable here.
There was a problem hiding this comment.
Workers having their own Feature Policy is being figured out here: #207. Until that's resolved, I think we can/should just return false in Worker contexts.
index.bs
Outdated
| <h3 id="should-request-be-allowed-to-use-feature">Should <var>request</var> be allowed to use <var>feature</var>?</h3> | ||
| <p>Given a feature (<var>feature</var>) and a <a for="/">request</a> (<var>request</var>), this algorithm returns <code>true</code> if the request should be allowed to use <var>feature</var>, and <code>false</code> otherwise.</p> | ||
| <ol> | ||
| <li>Set |global object| to |request|’s <a for="request">client</a>’s <a for="environment settings object">global object</a>.</li> |
There was a problem hiding this comment.
A request's client may be null, so this spec has to deal with that.
There was a problem hiding this comment.
In what contexts? If there’s no other way to get an origin in those contexts, I guess we'll return false.
…should-request-be-allowed
…should-request-be-allowed
… in no-window contexts.
…should-request-be-allowed
|
This looks good, thanks for the ping @yoavweiss |
This PR is part of an attempt to address #129 – using Feature Policy to let authors opt-into sending specific Client Hints to specific origins.
The overall, basic idea is: