- From: Yoav Weiss via GitHub <sysbot+gh@w3.org>
- Date: Thu, 05 Sep 2019 13:54:04 +0000
- To: public-css-archive@w3.org
> @dbaron I am not convinced about the active vs passive distinction: it can very easily become a "best practice", possibly propagated by some popular framework, to always ask, and then the distinction goes away. @frivoal Browsers are [determined](https://github.com/bslassey/privacy-budget) to make sure the distinction between passive and active fingerprinting is very clear for developers, and that any blurring of the distinction will have practical implications. Those practical implications should apply to both JS entropy sources as well as the Client Hints one. @grorg > This gives pixel-tracking and other non-JS fingerprinting techniques even more data. That is not accurate: * For pixel-tracking, cross-origin requests will not get hints, unless the 1P is actively delegating the hints to the pixel-tracking host. * The idea behind Client Hints data exposure is to treat it similarly to JS exposure, as an active fingerprinting vector. So it should not be considered a "non-JS" technique. As a result, when JS is disabled, CH are also not emitted. * Any use of MQ in CSS should also be considered an active fingerprinting vector, as it can e.g. trigger network requests, which don't require JS to be abused by the server. > * It will make some caching more difficult. If the user preference changes, the caching code now needs to know what things to redownload. Vary headers solve that problem. Variants will enable solving it with better granularity in the future, but since we're talking about exposing a single bit here, I doubt they matter for this discussion. -- GitHub Notification of comment by yoavweiss Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4162#issuecomment-528375796 using your GitHub account
Received on Thursday, 5 September 2019 13:54:09 UTC