151–156 of 156 posts
Earlier quoted context omitted.
What if they use IPs instead of domain names?
Then you write router-level firewall rules for the IPs you know are safe to fully block. You can do that selectively so you don’t break other devices. I already do this for local DNS circumvention, which is probably a lot more common than hardcoded IPs.
Earlier quoted context omitted.
How would they know? The point of returning “standard” values, is that you are indistinguishable from any number of legitimate users.
They start blocking any fingerprint that looks like you're hiding it. Similar to sites blocking known Tor exit nodes and proxies.
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…
The Accept-Language header predates Google by many years, see https://www.rfc-editor.org/rfc/rfc1945#appendix-D.2.4
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.
Earlier quoted context omitted.
The Accept-Language header predates Google by many years, see https://www.rfc-editor.org/rfc/rfc1945#appendix-D.2.4
I 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…
Do any of the mobile-friendly alternative HN front-ends support commenting without giving up your creds?
Earlier quoted context omitted.
I 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…
Sorry, mis-click threading issue on mobile. I meant the reply to this thread: https://news.ycombinator.com/item?id=42480099 Do any of the mobile-friendly alternative HN front-ends support commenting without giving up your creds?
Earlier quoted context omitted.
I 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…
Sorry, mis-click threading issue on mobile. I meant the reply to this thread: https://news.ycombinator.com/item?id=42480099 Do any of the mobile-friendly alternative HN front-ends support commenting without giving up your creds?