Interaction with Permission-Policy for non-subresource requests?

[englehardt]

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.

[yoavweiss]

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]

Thanks for bringing this up! Addressing on that PR and also https://chromium-review.googlesource.com/c/chromium/src/+/3583274

[miketaylr]

In #106 (comment) @englehardt wrote:

Permissions Policy doesn't remove low entropy hints from a top-level document request.

@englehardt can you describe in more detail what you're observing?

[arichiv]

Good catch! Fix here @englehardt: https://chromium-review.googlesource.com/c/chromium/src/+/3586379

[englehardt]

@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]

@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]

For clarity: example.com could respond with Permissions-Policy: ch-ua=(), ch-ua-mobile=(), ch-ua-platform=().

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]

@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]

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]

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.