explainers-by-googlers / reduce-accept-language

This repository hosts explainer for reducing passive fingerprinting in the Accept-Language header.
Creative Commons Attribution 4.0 International
16 stars 0 forks source link

Security by design VS fingerprinting as a preference #8

Closed andrerferreira closed 1 year ago

andrerferreira commented 1 year ago

If the goal is to have increased anonymity by default then the proposal should advance with the addition of a checkbox field in the browser preferences which would be not checked by default.

This allows power users, not concerned with fingerprinting to continue to use Accept-Language as it was designed, rather than having to change its design.

Give (power) users choice and protect those that do not understand the risk a safe default.

andrerferreira commented 1 year ago

Wanted to add a bit more and offer my particular use case:

I live in the European Union, we have many languages here.

I’m also currently an emigrant in a country whose language is my 4th strongest (Spanish). My preferred language is not the browser or the system language which I use out of habit, but my native Portuguese, followed by Brithish English and French. If none of those are present, then I can read in Spanish (in Italian too if I have to).

So I'm never happy when I'm redirected to a website page whose language is based on my location, nor am I happy to read something in English (my system's language) when Portuguese was available.


Although I'm aware that Safari has already implemented "something" similar to the reduction proposal, their approach offers a depersonalisation that diminishes my individuality by using only 1 language.

Yet, having a degree in Cyber security allows me to understand that some users would benefit from anonymity.

So please, allow choice.

Tanych commented 1 year ago

thanks for your suggestion, we will definitely take consideration your case before we land this feature.

andrerferreira commented 1 year ago

I was just reading the proposal at https://docs.google.com/document/d/1RkPDf7DNtcOj4KXeW8wNCuYfto-drnGYST_NvZe3GoY/edit and I think I'm a bit more enlighten regarding the differences of this proposal to that of Safari, as I understand it at the moment as I've found no documentation from them.

There's indeed waste in the accept-language header after the 1st negotiation, I understand the implementation results in reduced bandwidth along with smaller log entries at the cost of a slower initial negotiation and the enforcement of the new server side headers.

Websites will no longer be able to offer personalised content based on the preference languages, but if indeed, as per your study, it doesn't happen much, it's potentially a good improvement.

I think I was initially mistaken. The user language preferences are kept, just not sent, as such the change respects users choices and that concern is invalid.

andrerferreira commented 1 year ago

By the way, it's great to see someone addressing the “Security concerns” in RFC 4647 Matching of Language Tags and RFC 5646 Tags for identifying Languages, both more recently being BCP 47. Just wondering if people are going to be happy with the extra request... I already have a redirect from HTTP to HTTPS :)