Why do you think Chrome bothers with this extra headers. Anti-spoofing, bot detection, integrity or something else?
The purpose here is surely to detect sophisticated spoofing by non-user-browser software, like crawlers and robots. Robots are in fact required by the net's Geneva Convention equivalent to identify themselves and respect limitations, but obviously many don't.
I have a hard time understanding robot detection as an issue of "user freedom" or "browser competition".
The big one is that running a browser other than Chrome (or Safari) could come to mean endless captchas, degrading the experience. "Chrome doesn't have as many captchas" is a pretty good hook.
I don't know what you mean by "the market".
What I do know is that if I try to go to a site with my favourite browser and a site blocks me because it's so poorly engineered it thinks I am a bot just because I'm not using Chrome, then it's pretty obvious that it's not detecting bots.
Also worth noting: it might surprise you that there browser automation frameworks. Some of them, such as Selenium, support Chrome.
You can add an exception in Firefox's settings to allow third-party cookies for CAPTCHAs. Google's reCAPTCHA cookie is set by "recaptcha.net", and CloudFlare's CAPTCHA has exactly the same problem, whose domain is "challenges.cloudflare.com".
If the cookies aren't set and passed back, then they can't know that you've solved it, so you get another one.
Maybe my experience is atypical but it seems to me this is a reCAPTCHA problem, not a Mozilla one. It’s Google’s problem. I imagine they can solve this but simply don’t want to.
Maybe I’m wrong but again, i encounter more issues with their “anti bot” methods than any other by a massive margin.
It's already a pretty degraded experience.
In the name of robot detection, you can lock down device, require device attestation, prevent users from running non-standard devices/OS/software, prevent them from accessing websites (CloudFlare dislikes non-chrome browser and hates non-standard browsers, ReCaptcha blocks you out if you're not on Chrome-like/Safari/Firefox). Web Environment Integrity[1] is also a good example of where robot detection ends up affecting the end user.
It's quite hard to figure out what this is for, because the mechanism is so incredibly weak. Either it was implemented by some total idiots who did not bother talking at all to the thousands of people with counter-abuse experience that work at Google, or it is meant for some incredibly specific case where they think the copyright string actually provides a deterrent.
(If I had to guess, it's about protecting server APIs only meant for use by the Chrome browser, not about protecting any kind of interactive services used directly by end-users.)
In this case, you would need to reproduce a message that explicitly states that it's Google's copyright, and that you don't have the right to copy it ("All rights reserved."). Doing that might then give Google the legal evidence it needs to sue you.
In other words, a legal deterrence rather than a technical one.
Bot detection. It's a menace to literally everyone. Not to piss anyone off, but if you haven't dealt with it, you don't have anything of value to scrape or get access to.
What leads you to believe that bit developers are unable to set a request header?
They managed fine to set Chrome's user agent. Why do you think something like X-Browser-Validation is off limits?
That presumably gives Google the legal ammunition it needs to sue you if you do it.
To me, it seems likely that the spec is for a legally defensible User-Agent header.
It's not off-limits technically. But do you think it'll remain this simple going forward? I doubt that.
1. Do I understand it correctly and the validation header is individual for each installation?
2. Is this header only in Google Chrome or also in Chromium?
I'm not sure how you got that impression. It's generated from fixed constants.
https://github.com/dsekz/chrome-x-browser-validation-header?...
If it's only in the closed-source Chrome, then it seems it's intended to help Google's servers distinguish between Google's own products and others.
But I've never seen a Google site which worked less-well in Chromium than in Chrome, so I'm somewhat skeptical of this. Perhaps there are exceptions
I wonder if "x-browser-copyright" is an attempt at trying to use the legal system to stifle competition and further their monopoly. If so, have they not heard of Sega v. Accolade ?
I'm a bit amused that they're using SHA-1. Why not MD5, CRC32, or (as the dumb security scanners would recommend) even SHA256?
They don't have to own the servers and the pipes if they own all the clients, sources of revenue, distribution platforms and financial transaction systems.
> The vast majority of email.
Not even close, less than a third in reality
I agree that google should be cut down, but if done then other tech giant should be too, otherwise we're just trading one master for another
Remember that email involves at least two parties. It doesn’t matter if I use a non-Google provider, I still have to follow all of Google’s email rules, or email will be useless to me because I wouldn’t be able to send mail to Gmail or Google Workspace users.
In a practical sense, Google have very direct control over almost all email.
When we started like 15 years ago, the emails of the students and TA were evenly split in 30% Gmail, 30% Yahoo!, 30% Hotmail and 10% others (very aproxímate numbers).
Now the students have like 80% Gmail, 10% Live/Outlook/Hotmail and 10% others/Yahoo. Some of the TA are much older, so perhaps "only" 50% use Gmail.
The difference is huge. I blame the mandatory gmail account for the cell phone.
Anyway, we had weird problems with Live/Outlook/Hotmail and Yahoo because they classified some of our emails as spam. Gmail usually works better.
Anyway^2, everyone is using WhatsApp, so it doesn't matter.
Anyway, I got asked to provide a "real" email address by support at my mobile provider.
I gave them a yahoo email.
At work, 70% of the messages are by WhatsApp. We have like 10 buildings distributed in a 3 million person city, like 3 miles away from each other. So there is a lot of global coordination (mostly by WA). Also inside each building each subgroup of TA (like Algebra+Monday-Thursday+Morning) has one WA group, and the students have an unofficial WA per course.
We even have a WA group for the "HOA" of my home. (It's an apartment.) People can't maintain a mailing list or use CC correctly, but can use WA.
And there is another WA for the parents in each course of my children in primary school. Everything is discussed there, in particular invitations to birthday parties. Also, the school has like 3 official methods to send info (that is very confusing), but someone kindly repost all the info in the WA group.
Also, WA has a few aventajes: [1]
* If someone sends a message, they get angry if you don't reply in less than 5 minutes.
* If you realize something a Saturday at 11:30 pm, you can't send a WA about that, because the other person will think you expect them to get out of bed/party to reply.
* You can't mark a message as unread to reply it later or in a few days.
* It's even more centralized than email
[1] /s
According to this definition https://www.merriam-webster.com/dictionary/majority : "c : the greater quantity or share" that also seems to be a possible meaning in English
In US English, when speaking with the mathematical precision, majority means absolute majority (more than half) and plurality means relative majority (more than anyone else). British English does also have the term relative majority like in French, though I don’t know if this is used in mathematics.
But like most other dictionaries in both English and French (with some exceptions like l’Académie Française’s dictionary), Merriam-Webster tries to describe how language is actually used in the real world and not some theoretical idea of how it should be used.
Therefore, since “majority” is often used to mean either absolute or relative majority when speaking in a less precise context than mathematics, a general-purpose dictionary like this one lists both meanings. A mathematical dictionary from the US (again I don’t know about the British equivalent) would list just the absolute meaning.
I have seen nitpicking on whether the word majority is the right word for a relative majority, but only seen plurality offered as an alternative by American English speakers who are also students of the American political system.
I would almost never expect anyone to say "the plurality of cars sold are Toyotas", for example.
They don't own all sources of revenue. Even on their major media platform they get siphoned off by companies like patreon. It is all a charade and not everyone is enamoured by that.
A ton. They got shares in a bunch of submarine cables, their properties (YouTube, Maps, Google Search) make up a wide share of Internet traffic, they are via Google Search the chief traffic source for most if not all websites, they own a large CDN as well as one of the three dominant hyperscalers...
My first thought was the Nintendo logo used for Gameboy game attestation.
I wonder what a court would make of the copyright header. What original work is copyright being claimed for here? The HTTP request? If I used Chrome to POST this comment, would Google be claiming copyright over the POST request?
I can only assume it's the flawed logic that it's "reasonably secure, but shorter than sha256". Flawed because SHA1 is broken, and SHA256 is faster on most hardware, and you can just truncate your SHA256 output if you really want it to be shorter.
There are a lot of applications for which collision resistance is irrelevant and for which the use of SHA-1 is fine, for instance in some random number generators.
On the CPUs where I have tested this (with hardware instructions for both hashes, e.g. some Ryzen and some Aarch64), SHA-1 is faster than SHA-256, though the difference is not great.
In this case, collision resistance appears irrelevant. There is no point in finding other strings that will produce the same validation hash. The correct input strings can be obtained by reverse engineering anyway, which has been done by the author. Here the hash was used just for slight obfuscation.
You're right that collision resistance doesn't really matter here, but there's a fair chance SHA1 will end up deprecated or removed from whatever cryptography library you're using for it, at some point in the future.
SO many things also already standardize on SHA1 (or even weaker hashes) as a (non-security) anti-collision hash for either sharding storage sets (host, folder, etc) or just as already well profiled hash key algos.
MD5 (and SHA1) is already absent or deprecated in many cryptography libraries, e.g. https://cryptography.io/en/latest/hazmat/primitives/cryptogr...
Every time someone uses MD5 or SHA1 for something that isn't legacy-backcompat, they further delay their deprecation/removal unnecessarily.
Though in contrast to that, sometimes the criteria is just that a given number of bits aren't useful, so the output of a different hash is truncated to the desired size.
Maybe part of the driving criteria os compatibility with E.G. the oldest supported Android version? Or maybe some version of Windows seen in legacy devices in poor countries? There might be good reasons beyond just 'header is new, everything must be state of the art'.
Sometimes something that looks wrong is bad even if it’s technically acceptable.
There probably(?) isn't any serious vulnerability in using SHA-1 for an integrity identifier that is based on a hard-coded "API key", but I think algorithm hygiene is always a good thing. You don't want to train your engineers to use broken algorithms like SHA-1, "because it might be ok, idk".
Evaluating anything in parallel is a different compromise between the time and the power needed to perform a computation, i.e. with an N-way parallel evaluation you hope to reduce the time by almost N times, while increasing the power by a similar factor and not increasing much the energy required to do the computation.
The time to compute a hash is not always the most important, especially when the hash computation can be overlapped with other data processing. In mobile and embedded applications the energy can be more important. In that case using the hardware instructions for SHA-256 or SHA-1 can provide energy savings over hashes like Blake2/3.
So the best choice for a hash function can be affected by many factors, it is preferable not to choose automatically the same function regardless of the circumstances.
Nowadays SHA-256 is widely supported in hardware and still secure enough for any application with an 128-bit security target, so it is OK as a default choice, but it may be not the best choice in many cases.
My mind went here immediately as well, but some details are subtly different. For example being a remote service instead of a locally-executed copy of software, Google could argue that they are materially relying on such representation to provide any service at all. Or that without access to the service's code, someone cannot prove this string is required in order to interoperate. It also wouldn't be the first time the current Supreme Court took advantage of slightly differing details as an excuse to reject longstanding precedent in favor of fascism.
They might be trying to do this in the US given the political climate, but then again, the current administration is decidedly unfriendly towards Big Tech in general.
My suspicion is that what they're trying to do here is similar to e.g. the "Readium LCP" DRM for ebooks (previously discussed at [1]): A "secret key" and a "proprietary algorithm" might possibly bring this into DMCA scope in a way that using only a copyrighted string might not.
You could already do that with the user agent string. What this does is distinguishes between chrome and something else pretending to be chrome. Like say a firefox user who is spoofing a chrome user agent on a site that blocks, or reduces functionality for the firefox user agent.
Like people spoofing the Chrome UA in Firefox to avoid artificial performance degradation inflicted by Google on their websites...
If they only look at this header, then legitimate users using non-chrome browsers will get treated as bots.
If the these headers are only used for chrome user agents, then it would be easy to bypass by using headless chromium with a user agent that spoofs firefox or safari.
Indeed, even for those who require a round of mental gymnastics before they concede that monopolies are, like, "bad" or whatever, GP points out precisely how this would constitute "consumer harm".
I wonder if this is header is not connected in some way to that feature.
The same policies also offer the ability to force-install an official Google "Endpoint Verification" chrome extension which validates browser/OS integrity using Enterprise Chrome Extension APIs ("chrome.enterprise") [0] only available in force-installed enterprise extensions.
FWIW, in my years of managing enterprise chrome deployments, I haven't come across the feature to force people to use Chrome (there are a lot of settings, maybe I've missed this one). But, there definitely is the ability to prevent users from mixing their work and non-work gmail accounts in the same chrome profile.
[0] https://developer.chrome.com/docs/extensions/reference/api/e...
Edit: Okay, maybe one hole in my logic is the first-sign in experience. When signing into google for the first time in a new chrome browser, the force-installed extension wouldn't be there yet. Although Google could hypothetically still allow the login initially, but then abort/cancel the sign in process as part of the login flow if the extension doesn't sync and install (indicating non-chrome use).
I don’t see why any of that can’t rely on a chrome extension implementation using the privileged APIs to verify OS, Browser, etc. Struggling to understand why they need special headers for any of this functionality.
Our hard work
by these words guarded
please don't steal
(c) Apple Computer Inc
not if they make it dynamic somehow (e.g. include current day in hash). Then with MV3 changes that prevent dynamic header manipulation there is no way for an extension to spoof it.
That's an odd possibility.
Ironically, Google just fought with Oracle a case around similar concepts.
Or is it exclusive to the closed-source Chrome codebase?
Sadly nobody can do anything about it, so far. We'll yet need to see the outcome of the antitrust trial.
> to push their own agenda and shape the whole Internet the way they want
Which version of chrome is the first to implement these headers?
What are the potential effects of these headers on chromium forks, e.g. ungoogled chromium?
You would have to maintain the code to generate character-perfect strings (or maybe just keep a very large library of the current most popular ones) and also make sure you have the up to date API key salt values (which they probably going to start rotating regularly), which–as I said before–wouldn't be impossible, just prohibitively irritating to maintain for comparatively little benefit.
And besides, it won't be too long before people just start spoofing the hash too, probably shorter than getting the generator up and running