Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reject Google's malicious [WEI] Web Environment Integrity infiltration from upstream Chromium #2432

Closed
1 task
Ultrabenosaurus opened this issue Jul 26, 2023 · 7 comments · Fixed by #2445
Closed
1 task

Comments

@Ultrabenosaurus
Copy link

Ultrabenosaurus commented Jul 26, 2023

Description

Reject Google's malicious [WEI] Web Environment Integrity infiltration from upstream Chromium

Who's implementing?

  • I'm willing to implement this feature myself

The problem

The upstream Chromium project has been hijacked by Google to implement their preferred method of locking the entire Internet up in DRM, via "Web Environment Integrity". Their proposal was quietly released via an employee's personal git account which was subsequently locked to prevent discussion, and the implementation was very quickly accepted into the Chromium codebase: chromium/chromium@6f47a22.

This is an intentional, shady, and outright malicious bypass of the W3C or any pretence of following and supporting open web standards and a direct attack on the fundamental freedoms, privacy, and security of all web users. By infiltrating the Chromium project like this, rather than trialling it in their own Chrome browser, Google are intentionally seeking to infect the vast majority of Internet users' devices without most of them even knowing, even if they intentionally boycott Google over this attack. If WEI is implemented in web browsers, all users will be held hostage by companies to only use approved devices in approved ways to access approved websites, being tracked and exploited while doing so.

This is blatantly and intentionally malicious behaviour from Google and the complicit Chromium contributors.

Possible solutions

Do not accept WEI implementations from the Chromium project.

Alternatives

There is no real compromise as Google are pushing ahead with their WEI implementation into Chromium without regard for users, standards, or feedback. They will not compromise so the only solution is to completely reject their goals and code.

Additional context

No response

@jstkdng
Copy link
Member

jstkdng commented Jul 26, 2023

it looks fairly easy to disable (for now), but that'd also mean that pages that decide to use that API will stop working. Unless the results are spoofed somehow.

@Ultrabenosaurus
Copy link
Author

pages that decide to use that API will stop working. Unless the results are spoofed somehow.

I mean, that's kind of the point. Do not accept the future Google wants for the web, where they decide who is allowed to view which pages. Protest the only way they'll notice: market share. If enough people aren't using the browsers and viewing the websites that implement this, one would hope WEI will die.

@r7l
Copy link

r7l commented Jul 26, 2023

Yes please, keep this out of ungoogled-chromium.

@underdogest
Copy link

underdogest commented Jul 27, 2023

Right now it looks like chromium itself is only proxying the attestation to the OS.

My guess is that on android it will use the google safetynet rootkit with that encrypted and obfuscated binary blob that executes in the background, extracting the private key from there is complicated and tedious. It's really cancerous, some lowlifes spend their day making up new obfuscations and using the code paths itself as bits in a shared key, very tedious to extract the actual key from there. On the flip-side checking validity of a safetynet attestation requires querying google's servers (costs money).

Linux based OS will probably never implement it and will be locked out of all cloudflare hijacked websites in the near future.

Windows might implement it in an easy to reverse library in the near future.

If websites decide to accept a privacy-preserving attestation (non-personal private key inside a binary delivered to all users) it will be trivial to spoof, you only need to extract one key from any OS and use it inside ungoogled chromium.

If websites decide to only accept a personal attestation (per-OS-installation private key somewhere on the OS or TPM), the spoofed ones will be easy to block. I fear in the further future windows and mac will use some kind of certificate issued by microsoft and apple to every registered user, so websites will see a unique identity that is signed by a trusted vendor.

Make no mistake: this IS the precursor to a "login with your real name to access the internet" system.

@jstkdng
Copy link
Member

jstkdng commented Jul 27, 2023

Linux based OS will probably never implement it and will be locked out of all cloudflare hijacked websites in the near future.

good, fuck cloudflare

Make no mistake: this IS the precursor to a "login with your real name to access the internet" system.

indeed, it's all so tiresome. If google thinks it can walk over the W3C without consequences then, it's indeed over. Firefox might even implement this for some bs reason like "stop trolls from targeting protected groups" or smth whilst holding a large bag of google money.

And why are they spamming the github commit, they don't care, it is just a mirror lmao.

@quantumpacket
Copy link

If google thinks it can walk over the W3C without consequences then, it's indeed over.

The W3C is basically a subsidiary of Google at this point. The "anti fraud" community group this was created under, out of the 189 members 62 are from Google, and even the chair is a Google employee. There is only 1 W3C member in the entire group. Even more troubling is the other chair is from Brave Software.

@pglpm
Copy link

pglpm commented Jul 30, 2023

And why are they spamming the github commit, they don't care, it is just a mirror lmao.

It's just a "gesture", a way of protesting. In my opinion every little helps, no matter how insignificant. (Sure there's the danger that insignificant actions steal focus from significant ones, but I don't think that's the case here.)

@networkException networkException linked a pull request Aug 5, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants