Repository navigation
Interaction with Permission-Policy for non-subresource requests? #105
Description
In Request processing the hints in the hintSet are checked against permission policy only if the request is a subresource request. Are hints expected to be checked against Permission Policy when the request is a non-subresource request (e.g., a request who's destination is iframe)? I would expect requests for embedded iframes to also check against Permission Policy and that's what I've observed when testing in Chrome.
It's possible I'm just misunderstanding the fetch definition of non-subresource request. What I've observed in testing matches my intuitive understanding of a "subresource" request as an embedded request and a non-subresource request as a top-level document request. But fetch's definition seems more narrow than that.
Activity
yoavweiss commentedon Apr 12, 2022
I think you're right and the "if request is a subresource request" part doesn't match Chromium's implementation and seems spurious.
@arichiv - thoughts? Is this part WPT tested?
arichiv commentedon Apr 12, 2022
Thanks for bringing this up! Addressing on that PR and also https://chromium-review.googlesource.com/c/chromium/src/+/3583274
miketaylr commentedon Apr 14, 2022
In #106 (comment) @englehardt wrote:
@englehardt can you describe in more detail what you're observing?
arichiv commentedon Apr 14, 2022
Good catch! Fix here @englehardt: https://chromium-review.googlesource.com/c/chromium/src/+/3586379
englehardt commentedon Apr 15, 2022
@arichiv Got it thanks! I wasn't sure if the spec was incorrect or the implementation :) This resolves it.
@miketaylr For clarity: example.com could respond with
Permissions-Policy: ch-ua=(), ch-ua-mobile=(), ch-ua-platform=(). This prevented those three low entropy hints from being added to requests for resources embedded within example.com (including first-party resources) but did not affect the client hints headers on the top-level request to example.com. With @arichiv's fix it looks like all requests (including the top-level) will not have the headers.arichiv commentedon Apr 15, 2022
@yoavweiss reminded me that permissions policies aren't cached, so we actually don't expect to see enforcement on the first request sent to a site in any case. I'll add a note to the spec about that to clarify.
miketaylr commentedon Apr 15, 2022
Thanks @englehardt. Is there any use case for this, or are you just doing exploratory testing? I'm undecided if this is an actual useful thing to do... since the UA string will reveal the same info as the low-entropy UA hints.
englehardt commentedon Apr 15, 2022
@miketaylr I was wondering whether, if a website wanted to, they could prevent any device information from being sent to themselves. I was thinking long-term, if the web platform was able to freeze and deprecate the User-Agent header. But I don't see an immediate use case for the reasons you stated.
miketaylr commentedon Apr 15, 2022
Thanks - I can see that being theoretically interesting, to be able claim as a site that no device identifiers are stored, at least at the network level. But maybe a new permissions policy would be the way to go, to turn off all (most?) headers. 🤷 🤷♂️ 🤷♀️
englehardt commentedon Apr 15, 2022
Right that's a good point. Even if one were able to turn off client hints and the UA was frozen, other headers will reveal coarser information that will vary between vendors and browser versions.