3 ms·
Every browser information leak that can contribute to fingerprinting needs to be plainly considered a security vulnerability in need of fixing/mitigation, perio
by mindslight 2y ago
Every browser information leak that can contribute to fingerprinting needs to be plainly considered a security vulnerability in need of fixing/mitigation, period. This class of vulnerabilities has continued to get a huge pass, only being taken seriously by projects like TOR browser and then still only the convenient fixes getting backported.
I do realize this is a tall ask, as many of these vulnerabilities arise from standards promulgated by the surveillance industry itself (chiefly Google, of course), and so are not easily mitigated. For example font lists and ask-to-use-microphone are straightforward to fix for general web browsing, whereas the fix for browser viewport size requires some kind of thoughtful design that subsumes the old model.
In general I'd say that browsers (or at least their operating modes) need to start differentiating into different things for the open [season] web versus app runtimes, so that vulnerability mitigations can be stronger for the open [season] web and sidestep complaints that it disrupts legitimate apps. Of course the two modes need to be indistinguishable by websites, lest every two-bit xitter-summarizing "news" site insists that it's some special snowflake needing app functionality to run its surveillance code.
Also since I'm apparently writing my Christmas list, we desperately need widespread privacy laws in the US. If you want a "value add" feature of your product to be shoving ads in people's faces, fine - people at least get immediate and actionable feedback from that. But persistent tracking supported by pervasive surveillance is completely at odds with individual liberty. And taking away the largest consumer surveillance market would mean much less being invested in new ways to attack users.
- tatersolid 2y agoThe Accept-Language header predates Google by many years, see https://www.rfc-editor.org/rfc/rfc1945#appendix-D.2.4 https://www.rfc-editor.org/rfc/rfc1945#appendix-D.2.4
- mindslight 2y agoI certainly did not mean to imply that every browser fingerprinting vulnerability is due to Google née Doubleclick. What did I say to make you think so? And from a technical perspective, Accept-language doesn't seem terribly hard to mitigate - exactly one language at a time, and UI that allows a user to easily change to another, as if it's part of the logical URL. It's all the javascript APIs, especially the graphics ones with their loads of weakly-defined behavior, that are especially pernicious.
- tatersolid 2y agoSorry, mis-click threading issue on mobile. I meant the reply to this thread: https://news.ycombinator.com/item?id=42480099 https://news.ycombinator.com/item?id=42480099 Do any of the mobile-friendly alternative HN front-ends support commenting without giving up your creds?
- fragmede 2y agoOn mobile, the one I use has a share button that lets you open the comment in a browser.
- fragmede 2y agoOn mobile, the one I use has a share button that lets you open the comment in a browser and not have to login to the apo, though you miss some customizations like notification on comment replies.