Re: [w3c/manifest] Allow setting an HTTP request for server side PWA detection (#954)

> I’m may look to define one here for "installed" and a second over in App Info for "installation source."

One rule we kept with Client Hints is to not expose values that are not also exposed through JS (to maintain the parity with them exposing already-exposed data, but not beyond that). Are those values currently web exposed?

> 1. Do we need to specify whether a CH should be available in Critical-CH or is that open to all CHs?

Any CH can be a critical one AFAIUI. /cc @amtunlimited & @davidben who are leading that Critical CH work.



> 2\. Do you think it would make sense for these two to follow the "Sec-" approach used for UA-related hints?

That's the recommended approach in the [RFC](https://tools.ietf.org/html/rfc8942#section-4.2).



> 3\. Do all CHs automatically accrue to the privacy budget work (or similar) or do we need to specify that they should be considered as potential fingerprinting vectors so implementors know to include them in whatever mechanisms they use to control for that?

I'm no expert on the privacy budget or other mechanisms employed by browsers to limit/monitor active fingerprinting. I suspect that all active entropy-exposing surfaces contribute to the overall exposed entropy, and hence are monitored/controlled by those efforts.
I would expect the Client Hints you plan to expose to be controlled in exactly the same way that the equivalent DOM APIs are.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/954#issuecomment-799669002

Received on Monday, 15 March 2021 18:53:20 UTC