This was intended to be a short FUSS on how to set the browser language to a certain language permanently instead of having to select it on various pages that the user browses, it then turned in to a "computer engineering" FUSS snippet when it was determined that Google is violating HTTP protocol by not respecting the RFCs and user's preferrences, then the FUSS was promoted to the computer security FUSS page when we found a way to work around the issue but hell, might as well also explain how to work around uncompliant websites, so we finally turned it into a self-standing article within the "computer security" category of the website.

Google services, for example, discriminate against the English language severely and that is probably due to Google generally being seen as an US company where English is the default. For example, setting the Accept-Language header to English (en) and making a request from a non-English speaking country will make Google completely ignore the Accept-Language header and Google websites will offer the content based on the language that the Google website (erroneously) infers from the origin of the connection.

We would argue that this practice is flawed and discriminatory, even if one would consider apologetics along the lines of serving a more diverse audience, because in a world with international treaties and hence the ensuing mobility, there is no guarantee that the Internet connection point of a user also determines their language. Politics aside, we would even consider this an issue with some implications to matters such as general safety, or to use the neologism "physical security", considering that if some user is lost in a jurisdiction unknown to them, and iff. they gain access to a terminal they might not even comprehend the language of a public service like Google.

With the unification of the European Community, one idea that was suggested concerning business is for companies to create products that would vary in each separate jurisdiction, as a way to enhance diversity. However, the practice turned out to be bad for business, generally because people did not want a local variation of a product but they wanted that exact product that they saw or knew about from different sources of fame. Businesses quickly adapted and stopped going down that path and started offering the exact same product everywhere. In principle, even though the measures were predicted to have a good outcome, the practice turned out to be highly racist by following the principle of positive discrimination.

The original idea was to note down a quality of life improvement by leveraging RFC 3282 that describes the usage of Accept-Language and then to use a browser add-on like HeaderEditor to mangle all requests to any and all websites in order to force the Accept-Language to en (ISO 639, from RFC 3066 such that all webservers will know that the English language is preferred and regardless where the user might find themselves on the planet geographically all websites would respond in English.

To our amazement, Accept-Language to en just does not work for important Google services like Google maps and Google serves its content depending on the country of origin of the request. In other words, if you find yourself in the middle of the Sahara desert but are just that lucky to squeeze some battery power out of a phone to be able to reach Google, you will be disappointed and wasting precious time looking for ways to switch the pages into English (or any other language that you know, for that matter) because more than likely the pages will be served up in Arabic.

Ironically enough, RFC 3066 that cites ISO 639 for the language codes also states that compositions between the language and the region (as per ISO 3166) are acceptable values for the Accept-`Language header. This leads to possible grammatical compositions such as en-US instead of just the ISO 639 language code en.

The following experimental results by sending requests to Google servers with mangled Accept-Language haders can be summarized:

• Accept-Language: en, as mentioned, this will fail and Google will just set the language to the official country language meaning that Google services discriminate against international English speakers,
• Accept-Language: en-US, this fails as well, meaning that the American-English dialect is discriminated against,
• Accept-Language: en-CA, this passes,
• Accept-Language: en-GB, this works,
• Accept-Language: en-WAS (roughly, the language used on this wiki) seems to fail, which was more or less expected given that WAS is neither an ISO 639 nor an ISO 3166 compliant regional code

This allows us to conclude that international English as well as American English are the languages that are discriminated against but that other valid English-speaking regions such as Canada or Great Britain will make the server respond correctly in English. Having found that out, it is now possible to still use this technique and to force Google services to respond compliantly to the standards simply by setting the preferred language to some regional variation of English - if you can live with an occasional word such as "scrumptious" instead of "cool" when going through expected Google service labels.

There exist security exploits that latch onto language difference yet most of them pertain to byte-level exploits where the actual character set of the language is important yet not the language itself. The former exploits range from buffer overflow exceptions to minor issues such as the lack of implementation of various languages that would provide the opportunity for a code injection.

However, for this report alone, we're more concerned with the political and physical ramifications, no doubt being biased by our constant unavoidable usage of Google services. First, the initially mentioned "physical security" regarding Google services for a user stranded in an emergency scenario still stands and Google's decision to break RFC 3282 seems arbitrary. Or, to borrow from that self-important sounding yet important RFC 2119, RFC 3282 states that the Accept-Language is a forward-declared preference for a language, which means that a server SHOULD offer the content in the order of preference set by Accept-Language yet it is not REQUIRED for the server to do so such that the server's preference to ignore RFC 3282-compliant values such as en or en-US is arbitrary. One could argue politically that Google does this as a sort of voluntary discrimination of the people working for the company to the hopeful effect of positively discriminating against different jurisdictions but even from a social point of view that seems nothing too consistent or would come across as virtue signalling.

One of the other consequences is the breaking of principles of globalization (ironically, because politically speaking, even according to the implied sense of Google's choices, English speakers have the privilege), something more pertinent to computer engineering that would suggest that services should offer content in the local language of the user. However, the local language is set by the operating system, and then consequently, the language is set by the browser when the said "services" consist in webpages.

In terms of networking, due to how TCP/IP is designed, it should be mentioned that the origin of a network connection is meaningless - whilst every endpoint has an IP address, the actual "meaning" behind that IP address is fully arbitrary. It's like saying that "money has no value because it's just paper" - which is partially true because paper has little value (and deliberately so, for purposes out of the scope of this allegory) yet it is the users of the currency and the transactions itself that gives them meaning. With that said, the specification tacitly implies that the TCP/IP networking model is not designed to accommodate nor account for geography such that any "decisions" based on the source of a connection is just an arbitrary assumption taken in the context of the protocol. Even if IP-address ranges are owned and they can be looked up, just because, say, a a large IP address block is owned by a company in South Africa, it does not mean that that a connection to and from addresses within that range is a connection to and from the country itself.

Anthropomorphizing TCP/IP just because it is widely-used does not grant the protocol any additional properties than the ones written at design time or curated over the years. It's like, say, banning the entirety of China, just because there are "many hacks coming from China" - which is true, but it is also likely that there are way more "smart fridges" in China than citizens of Finland, with many of those smart fridges requesting and releasing IP addresses in real time. Some things just cannot be politicized unless you're willing to create very strange and unsolvable paradoxes that will work to your and everyone elses detriment in the long run.

One upcoming mitigation that has been in the works for a very long while is IPv6, which should broaden the range of addresses to the point that every thing could have its own dedicated address that would be stable under geographic variation, but that is out of the scope of this page and comes along with many other gotchas that would have to be mentioned separately.

So, you've gotten a brand new laptop, it's definitely in English, either because you like English or because you are from an English-speaking language, and you're a vlogger that opens up the laptop in Morocco in the middle of the Sahara desert with your GSM connection in order to look up something on Google, yet you are met with strange Arabic characters that make you wonder why they appear on your screen like that given that everything else on your screen is in English (mind you, this applies to speakers of any other languages as well, y'all will get Arabic characters in this scenario, even if you're Chinese!). . .

It is possible to switch the browser language to a regional variation of English and it will work just the same as using hacker tools that can inject headers or rewrite requests. For example, on Firefox, clicking the hamburger icon (vertical lines) and selecting "Settings" will open up the Firefox settings. Recently, it is possible to avoid going through the maze of settings and just searching for "language" should offer the option to set the browser language as the first result.

Now, just add, say, "Canadian English" to the list and move it right to the top. Or, if your operating system is French or you are French and prefer to see Google services in French, then select "French" and move it all the way up to the top.

With the preferred language to the top, the dialog can be closed by confirming the choices. After that, opening up a site such as maps.google.com should properly greet you in your language regardless where you are to be found geographically.

The word proper is used because doing this any other way around, especially if your operating system is in your own language and ending up with a different language on your screen, just because you're, say, visiting some place temporarily, is the wrong way to do it.

Globalization, and conveniently the type that pertains to computers, is specifically designed to respect user-choice and should not rely on some centrally inferred decision of a data controller like Google. In some ways, this is a good example of "globalization done wrong" or interpreted wrongly, where, politically speaking, "globalization" is now somehow misunderstood as some way to put power in the hands of grand "conglomerates" like Google or Meta, when, in fact, "globalization" was meant to empower diverse cultural sub-divisions, explicitly in spite of large data controllers.

At this rate, why not just drop all languages and just leave it in English? At least, if I am German, then I might just as well get used to English rather than having to put up with various languages filling my screen when I am traveling because then English won't change when I move from one country to the other. This is particularly funny in geographic areas like Europe where moving from one country to the other consists in a one-hour drive so if a passenger is browsing at the same time, they'll be offered Google web search in all the possible language except the one that they prefer. Arguably, if you are German and you do have the operating system in German, then the browser would also be in German and Google will respect that choice (just like respecting French, from the previous example) but the principle of varying the content language by picking the network connection origin over the specification of the protocol itself still stands. Similarly, if I am Spanish and I like my computer in English, then why punish me for my choices and spam me again with all the possible languages?

Even large companies can get things wrong with international standards typically being open for everyone to consult and contest - hence the acronym Request For Comments R.F.C. that define and also refine over time all these standards, which is why one should not violate protocols, no matter how large your company thinks it is, because doing so creates a bunch of confusion around some points that might have been well-established over time by very many people.