-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interaction with Permission-Policy for non-subresource requests? #105
Comments
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? |
Thanks for bringing this up! Addressing on that PR and also https://chromium-review.googlesource.com/c/chromium/src/+/3583274 |
In #106 (comment) @englehardt wrote:
@englehardt can you describe in more detail what you're observing? |
@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 |
@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. |
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. |
@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. |
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. 🤷 🤷♂️ 🤷♀️ |
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. |
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.
The text was updated successfully, but these errors were encountered: