Google is prototyping a DRM system for websites in Chromium
Google is prototyping a DRM system for websites in Chromium
Sometimes you have to ask the question whether something should be done at all, and trusted computing is certainly one of those cases where the answer is obviously a big fat NO. So please reconside...
the API is called Web Environment Integrity, and it’s a way to kill ad blockers first and a Google ecosystem lock-in mechanism second, with no other practical use case I can find
This is why every full-stack engineer who celebrates the chromium browser dominance because they don’t have to worry about css and js browser compatibility should be slapped. The I/O conference is the biggest ad disguised as a “we care about the web” community event of them all.
if anyone hasn’t read it yet, the goals and non-goals sections of the “explainer” are a joke that mostly contradict the rest of the document, and seem like a late addition to muddy the waters in online discussions when they realized how unpopular this idea would be. the entire thing gives me crypto whitepaper vibes in that it’s an intentionally dishonest representation of a technology nobody but google wants
also, the actual spec isn’t even a first draft, almost like other browser vendors supporting or even understanding this thing is an unlisted non-goal. it’s much worse if they do though: implementing this thing requires your browser to keep a connection to a google-approved attester, which will receive a live feed of the requests leaving your browser; ie, it’ll have your live browsing history. for some reason (by design), when the explainer talks about cross-site tracking, it only talks about methods to prevent the web server from doing it, other than this paragraph of nonsense:
User agents will not provide any browsing information to attesters when requesting a token. We are researching an issuer-attester split that prevents the attester from tracking users at scale, while allowing for a limited number of attestations to be inspected for debugging—with transparency reporting and auditability.
only a couple of paragraphs before this, the doc describes what the attester receives and signs as a “content binding”, which… seems to be a set of browsing information for the page you’re on
e: oh yeah, that’s one of the only places they mention the concept of a token issuer at all. they don’t actually describe what it is, and I can’t figure out the value of splitting it from the attester if the token has to contain your browsing data — either way, both systems get a copy of it
They are doing their best to make Chrome actual malware.
I couldn’t read past the example scenarios in the introduction. I read “bad actors” and it’s enough to know that they are avoiding thinking, or at least talking, about the realities of what they are making.
the authors of this paper need never to work in tech ever again
all four of the authors are software engineers
to paraphrase many of the issues on this repo, they need to not
Are they just copying the stuff Microsoft did back in the 90s to kill Netscape navigator? Someone should set up a website called Chrome is Evil à la Internet Explorer Is Evil.
Did setting up that website actually help?
so I was pretty young at the time, but that site was one of my motivating factors in trying pre-Firefox Mozilla for the first time
No idea. But it was funny.