blog.jse.li/posts/chrome-7
This applies to many of the ongoing attempts at anti-fingerprinting across browsers. Performance testing can bypass many of the attempts at hiding information about the hardware and OS too. It can also be quite reliable. Talked about this a few days ago.
Conversation
If JavaScript is enabled, adversaries are able to fingerprint many details about the OS, hardware and browser configuration without that information being directly exposed. Privacy and security mitigations need threat models and clear goals as often points out.
1
4
18
Most of the browser privacy features that I see being implemented across browsers (Firefox, Chrome, Brave, Safari) are little more than privacy theatre with unclear end goals. If they want to hide that Incognito is being used, they should state that and publish a design document.
1
3
A nice example is Safari hiding WEBGL_debug_renderer_info to supposedly mitigate hardware fingerprinting distinguishing between Apple devices. I don't see how that's actually supposed to work. This applies to a huge portion of the privacy mitigations in browsers and extensions.
1
3
Instead of aiming to provide fundamental privacy improvements, browsers are primarily shipping mitigations for specific code being used in the wild. They target the lowest common denominator of tracking. Safari at least has some actual substance with Chromium starting to copy it.
Mitigations should not simply be aiming to make adversaries rewrite their code and cope with minor annoyances and barriers. They should have clear threat models / goals, aiming to provide some fundamental improvement that can actually be quantified and explained in documentation.
2
6
12
It's completely acceptable to work towards an end goal with an incomplete approach implemented as part of iterating towards that. I don't think it's acceptable when it's not presented that way. Documentation is crucial, including to set end user expectations for privacy/security.
5