This is pretty much the inevitable end-game of the web, in no small part funded by ad-based business models (as the analog gap pretty much destroys most attempts to use this stuff to do copy protection) and enabled by developers who have insisted we shove as much difficult-to-implement functionality (by which I am talking about CSS complex stuff, not powerful-but-easy-to-code APIs for OS-level access) into the browser as possible.
The result: there is now effectively one dominating web browser run by an ad company who nigh unto controls the spec for the web itself and who is finally putting its foot down to decide that we are all going to be forced to either used fully-locked down devices or to prove that we are using some locked-down component of our otherwise unlocked device to see anyone's content, and they get to frame it as fighting for the user in the spec draft as users have a "need" to prove their authenticity to websites to get their free stuff.
(BTW, Brave is in the same boat: they are also an ad company--despite building ad blocking stuff themselves--and their product managers routinely discuss and even quote Brendan Eich talking about this same kind of "run the browser inside of trusted computing" as their long-term solution for preventing people blocking their ads. The vicious irony: the very tech they want to use to protect them is what will be used to protect the status quo from them! The entire premise of monetizing with ads is eventually either self-defeating or the problem itself.)
> who is finally putting their foot down and deciding that we are all going to be forced to either used fully-locked down devices
The person who wrote the proposal[0] is from Google. All the authors of the proposal are from Google[1].
I've been thinking carefully about this comment, but I really don't know what to say. It's absolutely heartbreaking watching something I really care about die by a thousand cuts; how do we protest this? Google will just strong-arm their implementation through Chromium and, when banks, Netflix & co. start using it, they've effectively cornered other engines into implementing it.
This isn't new to them. They did it with FLoC, which most people were opposed to[2]. The most they did was FLoC was deprecate it and re-release it under a different name.
The saving grace here might be that Firefox won't implement the proposal.
You do not and you cannot. It was written in stone once Chrome dominated the browser market. What Chrome (Google) wants, Chrome (Google) gets. Despite all the good engineering Google wants to sell ads, that's all there is to it. And the result is this proposal.
> The saving grace here might be that Firefox won't implement the proposal.
It's irrelevant and we are an irrelevant minority. Unless people switch to FF in droves the web is Chrome. And they won't because at the end of the day people just want to get home from their shitty jobs and stream a show. As long as that works everything else is a non-issue.
We could at least get everyone here to use Firefox. There's really no excuse for a technically minded person to still be using Chrome for their day to day browsing.
If you do eventually run into a poorly crafted webpage that doesn't work on Firefox you have the wherewithal to decide if you are simply not going to use that site or hop over to chrome just this once.
But the important thing is checking in automatically as a Firefox user in the logs of every other site online. Push Firefox marketshare up and at least some places will be hesitant to write off Firefox as irrelevant.
> We could at least get everyone here to use Firefox.
That would accomplish nothing.
> But the important thing is checking in automatically as a Firefox user in the logs of every other site online.
No, that's not important. HN users are a tiny minority compared to the billions of people that use the web daily.
I'm sorry, there's no easy way to say this: Firefox is never coming back. The web of old is never coming back. It's over. Even if this particular proposal gets defeated somehow, a future similar proposal will make it through. There is nothing you or I can do about it. Google is more powerful than most governments, and they are vastly more powerful than any random group of like-minded people who get together on the Internet in the belief that they can accomplish something.
A defeatist attitude like this certainly predicts the future... If you're playing by the rules. And the rules were set by Google, so it's in your best interest to break them by actively harming Google. Restrictions in choice happen because people don't oppose the narrowing enough to make the corporations lose money. This might be one of the few times where targeted malware could be beneficial if it destroys Google's services and makes them too much of a risk to use. If somebody puts a latent trigger into a Javascript library that's widely used like Node.js that makes Chromium and only Chromium break then that would start a cascade effect of Chromium locking itself up more and more until it's impossible to use. You could even make cookie bombs, where you have two cookies, and when one expires before the other it triggers the surviving poisoned cookie to ruin Chrome's functionality by poisoning the browser agent. Google wouldn't be able to trust anything they didn't make themselves. You can force Google to barricade themselves in until it's impossible to reach them, and have them do it so fast that updating systems for developers and users would be too much of a pain to constantly keep up with. The downside is once you use a tactic like this then it's not just Google that wouldn't trust anything they didn't make themselves.
Firefox came into the mainstream because of power-user recommendations and the browser ballots.
It should be illegal for a significan platform (say 10mln users) to make its own browser, or any really, the unquestioned default. Users should be prompted on first use, giving a randomly ordered selection of any capable browser. If users can just click through it the choice should be random.
This is the only way to maintain healthy competition and ensure independent yet functional standards. Otherwise incentives will continue to centralize power.
You're describing the old Firefox before they became Google's controlled opposition. Since 2011 all they have done is continuously stripped out every useful power user feature in a bid to turn into a shitty copy of Chrome; the last straw was gutting their powerful XUL/XPCOM extension system in favor of Chrome's far limited web extensions because muh security (and since then there's been more, not less cross browser malware). Today you can't even write your own extension for use on the main build thanks to forced extension signing (which ended up disabling everyone's extensions a few years ago due to an invalid certificate).
And that's before all their unethical tracking, in browser advertising and privacy violation over the years, that requires various 'hardening' about:config changes out of the box, or the erosion of configurable features with almost every release. Mozilla are woke hypocrites today, financially dependent on Google while claiming to be privacy champions and squandering their money on multiple other projects instead of focusing on Firefox.
The only browser that continues to be the old Firefox in spirit - the one that upended Microsoft's IE monopoly - is its hard fork, Pale Moon (which gets derided as oLd aNd iNSeCuRe by Mozilla fanboys). Doesn't need any 'hardening' because it doesn't snoop on you to begin with, and the latest versions have massively improved web compatibility while retaining support for the original powerful XUL extension system.
It may well be too late, given Google has absolute control over web standards and their policy of introducing draft features in Chrome and then making them part of the standard. Unless an anti-trust case is brought against them which explicitly mentions their browser engine and standards monopoly, and correctly points out that every other browser today is just a skin around Chrome while Firefox is controlled opposition. Every case against them seems to obsess on the search engine monopoly.
>Firefox came into the mainstream because of power-user recommendations and the browser ballots.
But it was a completely different situation.
- There was a huge influx of new internet users who were all asking their techy friends which browser to use. This is not the case now. People mostly stick with what they know.
- FF was the better product for pretty much all use cases. If this proposal does go through, this will not be the case. It's nice that FF can block ads, but it's ultimately useless if the average user won't be able to access Netflix/Youtube/Facebook/their bank account. It will be an objectively worse browser.
Browsers are increasing in importance even today, not decreasing.
And as I said, the sustainable solution is browser ballots back by the force of law. It's worked where it's been tried.
Anti-trust based solely on narrow definitions of consumer harm on the other hand, serve only the capital owners. And they'll leverage and co-opt any and every popular and useful innovation: open source, community contributions, open standards, patterns light or dark, etc.
See that's where I disagree. Rich governments like the EU or the US can and do have power to push regulations if they wanted to. Pretending we the people (in a broad sense), i.e. the state, have no power whatsoever to control the terms under which these companies operate within the state, is defeatist.
Bringing up "We, the people" here is ridiculous, regardless of the "sense". We have zero power. Zero. Protests, revolts, riots ... all make no difference anymore and making a cross on a piece of paper once every couple years, aka voting, doesn't give us power. Anyone believing that is a fool.
It certainly allows us to avoid the worst of 2 evils in any case and nudge the ship of state away from obvious rocks where extremist positions cause politicians to lose elections. Furthermore many states have a means for individuals to directly make law on matters that directly concern enough sufficient voters.
Sounds like defeatism. By writing such comments you only help Google and make people resign from doing anything. Good job...
It won't be easy, but it is not impossible to change the world. There are many, many intelligent people around. We just need to work together to achieve our goals.
BTW EU has shown, multiple times, that it is powerful enough to impose regulations on tech giants like Google, Facebook or Apple.
(3) has enough coherence to actually do something about it
It's not obvious to me that any of these apply. The EU is pushing -- in fits and starts -- towards self-reliance in its computing infrastructure, but at a slow pace.
Of these, number 1 is probably the most doubtful. The EU, however boring that line of thinking is, is still quite bureaucratic, and it's doubtful that measures to control this, might not be a priority of bureaucrats. After all, the regs I mention later are in the name of "less e-waste" (which is good, but besides the point). So something like "control web DRM" might not be as blatant and easily solved (your point No.3).
For number 2, the EU's new regulations above more easily replacable batteries, mandatory USB-C ports and such, in my eyes prove -- though not doubtlessly -- that they do care about walled gardens in tech.
Number 3 though, again, as I've alluded to before, doubtful. But possible in my eyes. Urgency is another thing you've mentioned, and -- let's say it again -- bureaucrats are not particularly known for solving a problem in the right time.
NB: don't misenterpret my use of 'bureaucrat[ic]' as a negative comment, it is just a fact, however boring.
I use Vivaldi (not chrome itself but another Chromium browser) because I want PWA support on my Linux machine so I can have an app for outlook with notifications and Chromium browsers make that far more convenient than Firefox.
Essentially this doesn’t work because every email client I tried can’t handle the specific way my work email account does authorization and the login always fails. They also blocked POP/IMAP so that’s not an option either. No one else in a team of software engineers figured out a better way to access email so for now this is the best option
It is extremely disingenuous to claim the only browser to still refuse to block third party cookies by default, because it helps their ad partners, is "more secure".
The only way in which Chrome is more secure at anything appears to be securely forcing you to view ads via this API. And a shocking amount of malware fails to work when you use a running environment that 95% of society are not using.
So as someone who deals with enterprise software: Network effects.
Where I work, we treat Chrome as the malware it is: It's banned both by technical measures and security policy. We deploy Firefox, and begrudgingly deal with Edge when people insist on a Chromium-based browser. (At least Microsoft added some modicum of privacy settings here.)
Here's what I've learned over the past several years: Web developers are lazy. We're commonly told such and such app or service "only works on Chrome" or they'll "only support on Chrome". When we call for support, half the time we'll get told it's because we're not on Chrome, and I have to actually prove to them on an isolated machine that the issue occurs on Chrome so they'll shut the heck up and do their job. "Oh, I found an issue on our server" after I spent two hours trying to convince them their app works fine on Firefox.
In most cases, things "not working on Firefox" entails exempting a site from the popup blocker. In 2023, troubleshooting alternative browsers is usually... roughly that easy. But blaming your web browser is easy and lets them shift blame, so that's what they do.
But enterprise software companies have completely turned Chrome into the modern Internet Explorer: The only browser they'll even deal with. And since a lot of people buy Google's marketing that they know security and aren't completely clueless how security works (they are), people have by and large given in and installed Chrome.
I was there too. People always say this, but just because a thing changed once does not mean it will happen again. In this case, the population scale alone has changed by over an order of magnitude.
Just doing some quick searching - the first numbers that come up when you search for "how many people used the internet in the year 2000" are on the order of 350 million or so. Comparatively, now, in 2023, Reddit alone has some 450 million users. It would seem right now that Tiktok has about three times the number of active users than there were total Internet users 23 years ago.
Additionally, there are literally hundreds of billions of dollars now resting on Chrome remaining the dominant browser.
Short of government intervention (or absolutely monumental fuckup on Google's part somehow), Chrome is here to stay.
Yes. The solution is very simple: uninstall Chrome and Chromium.
We are the people with the most influence on the tech. We are prescriptors. We are legion.
– Yes but Chrome is a tad faster and I have my bookmarks and my favorites extension and blablablabla…
— Then you are the root cause of the problem. If you are not ready to sacrifice an ounce of comfort to save the web, then you are the one killing the web.
Simple: install Firefox. Now.
(oh, and, by the way, also removes google analytics and all google trackers from the websites under your control. That’s surprizingly easy to do and a huge blow in Google monopoly. There are plenty of alternatives)
Please explain what you mean. It sounds like you have an important point that can only be found if people sit and carefully read several pages. Important points deserve to be stated more plainly.
The entire point of this spec is that your alternative browser wouldn't be able to attest to its "integrity" unless it was exactly as locked down as the other ones. If you have some kind of rebuttal to the shared context we all otherwise have, maybe you should be the one forced to state it more plainly.
> The solution is very simple: uninstall Chrome and Chromium.
No. Firefox, beyond being slower, also keeps constantly displaying ads… for itself. Want to open a new tab? “Big Browser cares about your privacy, read how!” I just want to open a new tab!!! I’m working! Restarting? “Discover what’s new with Firefox”, “Hohoho, we care about your privacy, LOOK HOW MUCH WE CARE! ALSO WE HAVE NO ADS!” Worse, they suggest to solve privacy that I use Mozilla VPN. VPNs don’t solve privacy. Also, it’s a paid ad for a paid product.
Mozilla had also a staunch political slant, going as far as firing a CEO for a donation he made to the opposing group years ago. There is nothing neutral here, if you are not a leftist, it’s dangerous to use or even give your participation to that ecosystem.
Mozilla has failed to become the no-ads, better-ethics, privacy-aware navigator (pun intended). They keep performing worse actions than Google all the time.
There isn't a moral dimension attached to loving the right kind of people and gay and straight people are equally moral in pursuing relationships with significant others. On the other hand there is a moral dimension to trying to take away our fellow citizens rights. The CEO as the face of the org became unsuitable to his role when he acted publicly and objectively immorally in support of those who would gut the rights of his fellows
He wasn't on the wrong side of a political issue he was on the wrong side of decency and morality. This ought not to be a leftist position nor should we fear that the tyranny of excessive concern for others may be imposed upon us. Should we decide to use Firefox for evil as it were the privacy both endorsed and adhered to by Mozilla precludes them discovering it let alone stopping us.
The position of user of Firefox and public face of Firefox are inherently different positions and come with different reasonable expectations but I think you knew that.
> it’s dangerous to use or even give your participation to that ecosystem.
Please describe precisely the threat model you fill most applicable
> keeps constantly displaying ads
For a definition of constantly redefined to mean rarely when a new major version comes out.
> They keep performing worse actions than Google all the time.
The context here is that google tracks everything you do and regularly shares it with the government including under terms that are obviously abusive of user privacy and including to repressive governments, are in the middle of attempting to destroy ad blocking by pushing locked down environments in the name of security. A move likely to have massive implications that will be impossible to manage or control in repressive dictatorships even if Google themselves do nothing to directly assist with mass surveillance in Orwellian states. Merely building general purpose tools virtually guarantees bad usage by repressive regimes. By contrast Mozilla has? Tried to pimp their VPN to you as part of their new version notification...
It really sounds like the Brenden Eich debacle has colored your perception of the situation and perhaps you need to step back and evaluate the situation objectively.
Brendan Eich getting fired was like watching the original internet get murdered by progressives. Everything since then has been about how I thought that would go.
A guy gave a $3100 dollars to a political cause of his choice that was on the ballot, and people with this ideology drove him out of the company he founded that fought very hard for internet freedoms.
Since then, Mozilla/Firefox has largely become irrelevant and absolutely no longer has the same privacy concerns and respects.
He donated money in opposition of a law he didn't want to pass. He didn't take anyone's rights away.
I surely do mean exactly that particular Waterfox. I've had my fair share of concerns back in the day when System1 acqui(hi)red Waterfox, but I haven't seen any suspicious behaviour whatsoever so I'm pretty confident it's fine for the time being.
Of course, if you know a better browser (that is not Chromium-based), I'll be happy to hear your suggestions!
>I was there too. People always say this, but just because a thing changed once does not mean it will happen again.
The problem is that the web standards have now grown so much that it is impossible to write a complete new web browser from scratch. Firefox is not coming back, because Mozilla seems to prioritize other things than code quality and the actual usability of their software.
And yes, I know that the SerenityOS developers are trying to do it, but while some very advanced things work "good enough" in their browser so that Twitter and Discord's web client works to some extent, the more basic things are so broken that their browser cannot even render basic HTML 3.2 sites properly.
Google's end goal is probably to "deprecate" HTTP 1.x and force everyone into using their own replacement for the protocol. Their protocol is going to be like the thing they call "HTTP2", an insanely complex protocol that is impossible to implement by a small developer team. In the end their own protocol becomes a "rolling release" protocol that only works with Google's own app, at which point they can completely stop releasing RFCs for it.
I was there too, in the 1.0 days, and still am. But these days are gone, Firefox is not coming back. Back then Firefox was immensely better than IE. As long as the other alternatives are just as good, there is no reason for the mythical "average user" to change over. Why bother if you can do everything in Chrome? We may understand the differences, ideological or technical, but good luck explaining that out there. There's a massive disconnect between user and technology and as a result people will live in the perfectly curated technological bubble that's been served to them.
the adblock "endgame" will be a self-hosted DNS system that blocks requests to ad-server urls (or return benign responses).
Then the game will switch to encrypted proxied traffic that you cannot block.
Then the adblocking software will switch to the GPU layer, and use machine learning and AI to wipe the region of memory in the GPU containing the ads (and replace it with something benign).
Then the next logical step from likes of google is a fully trusted computing environment - aka, you as an end user no longer control your own machine.
The browser... or the javascript running in it, served from the primary domain you are browsing will just do DNS over HTTP from within the browser, completely avoiding your dns filter
It was fun while it lasted though, finally news sites that could be read on an average German mobile data connection.
For the uninitiated: Germany's mobile phone network has been ridiculously expensive and unreliable for decades. Everyone else in Europe has done it better, because no one else thought they could extort 60 billion euros from the providers for RF spectrum licenses - we're still paying for that blatant debt-shifting today.
There's a degree of saying no and opting out and controlling your own shit that you can do.
Some, like owning a phone and getting tracked to many degrees is inevitable but others, like software on a computer, is quite easy to think about.
You don't need to be a majority to go a different path. Linux users everywhere know this. We never needed the "year of the Linux desktop".
There's usually ways around the designated box. Obviously, get ready to be called names for not bowing down to authority... But you can ignore them and move on.
Whatever happened to legislation? I bet most people here would have said the same about Apple's App Store monopoly on iOS, and yet the EU passed the DMA and the matter was closed.
There's no reason why the same can't happen here. The defeatism attitude helps with nothing and is part of the reason why this happens in the first place.
EU passing the DMA is literally the specific reason why google is unstoppable. They finally cracked the last significant holdout against chrome/chromium market dominance, now there is nobody left to oppose them in the browser market.
Chrome/Chromium is already above 75% marketshare and the EU doesn’t care, and is taking moves that will actively increase consolidation and monopoly control.
We’re literally in the thread where we’re talking about the anti-consumer moves that are resulting from that consolidation. This is what it looks like when Google flexes that monopoly control and tells you how it’s going to be. EU doesn’t seem to care.
> Chrome/Chromium is already above 75% marketshare and the EU doesn’t care, and is taking moves that will actively increase consolidation and monopoly control.
It took roughly 15 years for the EU to react to Apple's practices, and they have been anticompetitive from day one.
Chrome has caused no competitive damage to consumers or competitors (yet), give it time.
You can by not using Google products.
Change the search for ddg or kagi. Change your email for proton.
Use Dropbox instead. Remove Chrome, live with iceweasel or Firefox.
It is not like you'll be loosing much. This is the time to change, while we still have other players in the market.
No, you can't - not until you get a significant part of the world's population to join your protest.
The point is that if chrome implements this, netflix, amazon, facebook etc might decide they'll use this feature and only permit browsers who implement this to use this site.
Even if the only browser that does so is chrome, that's fine because chrome's market share is big enough that they can ignore the rest.
Have fun using Firefox if half of the web locks you out or treats you like a second class citizen.
It may not be that easy as now that stuff like banks and government services have embrance it. If they or your work/school apps need it, you are screwed
I'm already using a separate device for "official" stuff. It's a fully Google/Microsoft managed phone that runs my professional life (work profile, LinkedIn, etc.) and accesses government and some financial services. It mostly sits in a drawer outside work hours and don't use it to browse or talk to anyone outside of work. It has SimpleX installed so it can send anything I need (eg. financial statements) to my personal phone, without even needing to store my personal phone number.
My personal phone, and my personal laptop and PC, run open source OSes and are as privacy-focused as I can make thrm. They're the ones I use to browse and talk to people, both on public and private platforms. They're the ones that have my photos, my books, my passwords, my movies and my music. (I don't use streaming services, except for YouTube via Newpipe.)
I do make sure that I always have at least one bank account with a bank that doesn't require SafetyNet or similar, and can therefore be accessed without needing the "official" phone. So far, all but one of my financial service providers work fine from my personal devices.
I think the dual-device approach will quickly become the only realistic one for individuals who want privacy in their computer use (which will remain a minority). I will even say that, although Google is doing this purely for the sake of ads and profits, it is not unreasonable to expect citizens to have an "official" online presence in the form of a highly standardised Internet client, without prejudicing their ability to use other ones. In the same way that you have an official residential address, without prejudicing your ability to have other mailboxes or live on the road.
> netflix, amazon, facebook etc might ... lock you out
Is this supposed to be a bad thing? It's almost made to sound like surviving without them would be tantamount to starving, but frankly we might be better served without them.
I see Facebook locking you out (no great loss there) but I'm less convinced about Amazon or Netflix. They're not advertising-based businesses, so are not suffering with bots-consuming-ads problem.
Put another way, my site is unappealing to bots, and frankly I don't care about bot traffic, because I don't have ads. So I don't feel the need to support this server-side.
Equally Amazon makes money selling goods, not ads. They don't need to know if its human or bot, they just need a credit card. [1] Netflix is subscription based, again doesn't care if its a "trusted device" or not. They want you make sure their content is available not blocked because my TV is "untrusted".
Sure, you'll end up using Chrome to use Google properties. But I don't really see the incentive for the non-ad-based Web to bother implementing this.
[1] it won't move the needle for fraud, fraud is easily done via trusted devices.
>Equally Amazon makes money selling goods, not ads.
Amazon is one of the biggest ad networks on earth. They made $40bn from advertising last year using all the personal data they get from their paying customers.
>Netflix is subscription based, again doesn't care if its a "trusted device" or not.
Oh but they do care very much. Netflix requires DRM in desktop browsers and its own app on mobile platforms. And they launched and ad based plan recently.
It's a mistake to believe that advertising is the main problem and direct payments are the solution. Making a payment takes away more privacy than advertising alone ever could and hands personal data to payment schemes and banks on top of everything.
> they'll use this feature and only permit browsers who implement this to use this site
we as tech early adopters and "leaders" in this space, we need to be telling family and friends to complain to those sites about such required support. If enough people complain to amazon that they don't want to use this google branded browser, i think there will be some pushback and the companies would be hesitant to drop support for firefox.
>The point is that if chrome implements this, netflix, amazon, facebook etc might decide they'll use this feature and only permit browsers who implement this to use this site.
Works for me. I don't need those sites/services. If they want to be actively hostile to me, I can vote with my feet/wallet.
I can't (nor do I wish to) control what other people do. Just what I do.
As it stands now, I block the bulk of scripts/ads/trackers/other spyware on my devices, and those who don't like that are free to block me from accessing their sites.
Maybe I'm missing something important here, but I don't need anything from Alphabet, Netflix, Meta or any other rapacious corporation. They can do what they like, and I will do the same.
>Have fun using Firefox if half of the web locks you out or treats you like a second class citizen.
If the above folks are who you consider "half the web" then, at least for me, nothing of value would be lost, as I don't use that garbage anyway.
You can move away now or wait until they lock you out (and thereby lock you out of all you OAuth sites) with no recourse. The endless cries for help in /r/GMail/ says it all.
OAuth sites will let you change your OAuth provider or even better switch to a local account on their site and use a password manager so you don't tie everything to an OAuth provider unless the site will accept a self hosted one.
What's the harm in giving some sketchy site a unique, random password only used with that site? (In contrast to letting them have your Google profile and all that comes with it)
The need to retain one unique random password per site (as opposed to having one extremely secure Gmail password with two factor authentication attached to it).
It's the old twin airplane principal from the hacker's dictionary: the virtue of putting all your eggs in one basket if the basket is built very well.
Something to consider when you save your passwords in Google, you can "forget" and reset your Google account password and all your passwords are still there. Compare that to a proper password manager where if you forget the master password (assuming sufficient complexity) nobody is getting those passwords back ever. So Google has full access to your passwords whenever it feels like it.
As the other commenter said, there's zero risk giving a dodgy site a randomly generated password used only for that site, the randomly generated password gives them no information or pathway to any other web site.
I doubt Apple will be our savior here. Apple is in a great position to implement this spec: their secure enclave and the systems they've developed around it are practically the state of the art. Also Apple is in bed w/ traditional media. (Apple News, Apple TV, iTunes, etc.) Microsoft has been doing the same[1] for years w/ Pluton on the Xbox to protect their IP. Google has been doing this on Android using, dm-verity, SafetyNet, et al. Nintendo employs similar protections on the Switch with moderate success. (After the bootrom of the initial HAC-001 was patched on the production floor the only real option to attack a modern Switch is physically glitching the console.)
I suppose Apple may object on the grounds of being a "privacy focused" company, but I'll believe that when I see it. I'm not gonna sit here holding my breath for these megacorps to do the right thing.
> I doubt Apple will be our savior here. Apple is in a great position to implement this spec: their secure enclave and the systems they've developed around it are practically the state of the art.
You are probably right, but there is one self-interested reason why Apple might resist implementing this - Apple doesn’t like the web competing with apps, and this is basically giving the web a capability that right now only apps (effectively) have.
Perhaps you haven’t been paying attention but macOS Sonoma—currently in beta, shipping this fall—has the best web app support we’ve seen in a mainstream operating system.
You can put a web app on the Dock using the Finder’s “Save to Dock” command for virtually any website or web app.
Not only do you get service workers, push notification, web app manifest support, etc. web apps have first class support in the Finder, Spotlight, Spaces, Mission Control, etc. [1].
Screenshotting Apple TV+ works fine for me on desktop Chrome, even with hardware acceleration enabled. I don't recall doing anything to circumvent normal behavior (not really in the habit of screenshotting things I'm watching).
You only have to look at how they're (still) restricting PWAs to see they also have their own goals to preserve their walled garden and market share (as they should, it's a publicly listed company, but it's not the same as an open source alternative)
Yeah: the company that is all about locking down user devices and relishes in providing a DRM-ridden platform for developers to maintain complete control over their users is totally going to be against implementing this specification :/. I mean... it's possible? but any hope there is fully predicated on their hatred of Google and their distaste for the web.
If my goal is to try to avoid vendors locking down what I can do with my computer, I don't think switching from Linux to MacOS is going to be an improvement.
Doesn't Apple have some leverage here? They may not control the overall browser market but they mostly control the smartphone market (or at least the profitable segment of that market) and lots of those users prefer to use Safari.
I'm aware Apple implemented similar tech a while ago, but I have infinitely less confidence that Google would use it responsibly.
And lot of people here squeal like stuck pigs if you suggest anything other than the Chrome monopoly. HM is a constant barrage of demanding that legislators force the Chrome monopoly to be extended to iOS devices!
I mean Firefox caved to support EME. This isn't the early days of the web anymore either, the enthusiasts are a small minority of global web traffic that this will probably succeed even with a large scale boycott.
I still remember the controversy surrounding EME, a LOT of people came out against it (including the EFF[0]); despite that, they still triumphed on[1].
DRM should be inconvenient and expensive. There have always been ways to implement DRM security theater for the comfort of content providers in board rooms.
The media ecosystem is not going to be enhanced by making DRM more restrictive. Netflix could completely deactivate all DRM today, and it would change nothing.
Apple completely abandoned their "FairPlay" iTunes music DRM because it became evident that it was not needed.
Apple in no way abandoned FairPlay. Every file on Apple Music, and iTunes Match is protected with it. And those greatly outnumber transactional sales through the iTunes store, by an order of magnitude. The customer picked the DRMed version, every time.
Good. DRM should be external to the browser, not integrated into it.
DRM is mostly security theater anyway. Until a few years ago, the Spotify client just left unencrypted mp3s cached locally. And they stopped DRMing music over a decade ago. People are willing to pay a reasonable price for first party content.
If a company insist on DRM, then they should be on their own.
If we make it too easy, then they will just use it everywhere.
Yes, but that is fairly recent! Did anyone even notice? For years, you could siphon every song you listened to and save it locally. But did it affect anything? I did it for a little while, but then found it wasn't worth the trouble.
If done correctly, TPMs on every computer would be preloaded with signing keys (probably microsoft). The web browerser would then ask the TPM to sign the Platform Configuration Registers, which are a hash of a challenge nonce, the system firmware/kernel/configuration/etc. This signature is then sent (along with a description of the system configuration) to an external attester. This external attester validates that:
A) the claimed configuration is "secure" (trusted kernel, bootloader, browser, etc) and
B) The TPM's signature attests to the configuration.
The validator then generates its own signed message that can be sent to the server.
In practice, I think this is logistically unworkable in todays computing environment. But with enough big players pushing for it, I don't see anything fundamentally impossible.
Sites will just stop trusting that as an attester.
Anyone can write their own EME plug in that writes the files to disk. But it won't have the keys of any trusted module, because the reason sites trust them is because they don't do that. So it won't get accepted by anyone. Same here.
Of course, but if Google did that it would allow Firefox to complain about Google's abuse of monopoly power. I'm not sure that is a path they'd risk going through.
So what if Netflix doesn't work?? That is the choice of Netflix. Big content will always want more control. Firefox will never be able to keep up. They will just do a mediocre job of working against their users.
Microsoft and Real Player pushed hard for an integrated ActiveX based DRM ecosystem over a decade ago. I'm so glad that Mozilla flatly refused to entertain such idiocy. I sure wish that Mozilla still existed.
Mozilla is now just a "pick me" [1] organization to big content. They should own being a browser that caters to users, not platforms. Because they will end up with nothing.
1) You cannot all of a sudden provision content differently to a user who has an unapproved device with their preferred accessibility stack and/or hardware.
2) Even if attestation does not involve tracking, effectively forcing children into an ecosystem that tracks them can be deemed unlawful by the FTC. Providers cannot foreclose all means of access to content that are not in a tracking ecosystem, because it violates the rights of children.
The proposal is probably legally negligent because it does not exercise the ordinary standard of care expected of senior technologists. Providing a tool that affects hundreds of million of children and people with disabilities is not a joke.
The person who wrote the proposal[0] is from Google. All the authors of the proposal are from Google[1].
It astounds me that people would actually associate their real identities with stuff like this publicly.
how do we protest this?
The same way we protest politicians doing things against our desires? We know exactly who the perpetrators are, so perhaps we should all give them a piece of our mind. I absolutely don't condone violence, but exercising our right to free speech is always a good idea.
Probably the privacy angle is best. Given that this uses an "attester’s public key", this enables to uniquely identify a given device repeatedly over time with no margin for error. It's essentially "perfect fingerprinting".
There's also the option that devices don't use a per-device key. If all the devices from a vendor use the same keypair, then this would be broken by just extracting the key from a single device (AFAIK, in the US this would likely not be legal to use).
> The saving grace here might be that Firefox won't implement the proposal.
As others have said, FF doesn't have a lot of leverage left to influence those type of decisions, but Safari might. Not sure what their position is on this proposal.
The one pager has a section on stakeholder feedback [0], but doesn't name them for some reason.
Looking at it in terms of leverage and market-share is a huge mistake that Mozilla keeps making. Mozilla doesn't have a platform like Google does. What exactly is Mozilla even competing for? Popularity?
They should hunker down and make the best browser they can, implementing their best web. It worked 20 years ago, and in many ways the circumstances are the same. We have tech monopolies proposing ludicrous "content security" mechanisms. Where would Mozilla have been if they tried making some sort of half baked "less evil" form of Microsoft Janus DRM[1]?
People are going to get sick of how intrusive DRM is becoming, and there should be an alternative waiting for them.
Every person who has content they thought they purchased "expire" and be erased from their device, or who can no longer use their expensive projector after the latest mandatory update.
I evangelized heavily for Firefox in the 1.x days. People were sick of IE6, and were glad to have Firefox. I worked at a computer store and probably converted 100+ people.
Mozilla and Wikimedia both have a reputation for wasting money by trying to branch out beyond their main product. Wikimedia is totally overfunded so wasting money doesn't threaten their survival but they've also been criticized for begging for donations that they don't need. Personally I don't see a reason to combine them.
Wikimedia is much much less shady than Mozilla in a bunch of ways. Some people might take issue with the way they spend their money, or the tactics they use to raise money, but I don't think I would consider them shady.
Full disclosure: I was employed as a software release engineer at the Wikimedia Foundation from 2015 through 2022.
> FF doesn't have a lot of leverage left to influence those type of decisions
FF didn't have leverage in 2005 but we're still somehow living in a post-IE world. Leverage and market share aren't a concern, community support is all that's needed. The issue is that Mozilla Corp have been rapidly burning community bridges at pace of late, topped off by the fact that 2005 Mozilla wasn't dependent on Microsoft for their income.
It scares me when people talk about forcing apple to allow non WebKit browsers on iOS. iOS is the only thing stopping chrome from actually winning the browser war.
The proposal for Chrome, you don't, because there's no stopping it. See DRM, Secure Boot, all the rest of the shitshow pursuing "trusted environment". It'll never happen, but CEOs won't accept reality.
You can, however, embrace the rest: eg. keep serving your own content on http (along with https), gopher for retro compatibility, and because they are less prone to break.
Keep using your current device for browsing, and whatever refuses to serve you either leave it for good or keep a spare chromebook for all the "services" you can't avoid to use, like banking.
I don't have a better route. It's a bit like streaming: if I want resolution above 480p, I use a Chromecast with Android TV.
> if I want resolution above 480p, I use a Chromecast with Android TV.
I am one who specifically does not want a resolution above 480p. Unfortunately, some TV services had decided to remove that feature and now it wastes disk space due to the higher resolution. I also want to be able to use an external caption decoder and recorder (in my case, the same device does both), so will use the composite video and not HDMI (which doesn't have captions).
Steven J. Searle wrote: "The sad fact of the matter is that people play politics with standards to gain commercial advantage, and the result is that end users suffer the consequences. This is the case with character encoding for computer systems, and it is even more the case with HDTV."
> keep serving your own content on http (along with https), gopher for retro compatibility, and because they are less prone to break.
Yes, it is reasonable. I think that "HTTPS only" is (mostly) no good, but having both is good. HSTS is no good.
Generally agree but I don't think Secure Boot falls in this category unless the keys are locked in firmware (and in that case the firmware is the problem). Root passwords aren't evil either just because they can be withdrawn from the user.
Vote with your clicks. Google doesn't want me to install an ad-blocker on my phone, so I'm not browsing the ad-infested websites. And for the current integrity checks: If a site wants me to solve a captcha just to view it, I close the tab and never visit the domain again. In fact, I already close the tab when I see Cloudflare checking my browser. Let the corporate web die.
I'm doing this again, but here's my shameless plug for the article I wrote 1 year ago now, "Remote Attestation Is Coming Back," which warned that this was coming to the web and had quite a discussion about that idea at the time:
It was just one example, but Netflix is trash in web browsers anyway. Firefox should say no to all of this - it doesn't feel like it now, but saying no could birth alternative services that don't operate in such a manner.
Not technology related exactly, but until recent events I thought Reddit would survive and be untouchable. Now I'm wondering why I didn't join the fediverse sooner. There are rough spots but it will surpass centralized solutions.
We are at a turning point and should say no to all garbage. They need us more than we need them.
> It's absolutely heartbreaking watching something I really care about die by a thousand cuts; how do we protest this?
Death by a thousand cuts can also happen in the other direction. Even if we do not have a single decisive way to oppose this disastrous proposal, we can fight it in as many ways and on as many avenues as possible. Spreading the word about it widely is an important first step, so that those best placed to oppose it know that they should act.
As long as online advertising is a primary source of revenue for many companies, the internet is going to increasingly have less degrees of freedoms.
Probably the only solution is to bring harsh legislation against the very existence of online advertising. I don't know what that legislation would actually look like and how it can be done ethically.. but the alternative is probably worse.
Brave is an advertising company, but we’re quite different from Google and others in this space. Brave's ad notifications are opt-in and engineered in such a way to protect and preserve user privacy. I'm not sure where you saw Brave engineers talking about ways to prevent users from blocking our ads—we don’t try to prevent users from blocking Brave Ads.
If you wish not to see Brave’s ad notifications, you can easily avoid them (by not opting-in in the first place, or by throttling/disabling-entirely). There are no special hoops to hop through, or technical incantations to utter. We believe digital advertising is better when it is built on user-first principles and consent.
If a user opts-in to Brave’s ad notifications, their device proceeds to routinely download-and-maintain a regional catalog of available inventory. The user's device then evaluates the catalog entries for relevance. User data is NOT sent off-device in Brave’s model. If a relevant ad entry is found, it is then displayed to the user in such a time and manner for minimal distraction. When an ad notification is shown, the user receives 70% of the associated ad revenue for their attention (no clicks required).
Again, if the user wishes to not see ad notifications, they can simply choose not to opt-in to viewing them. If the user wishes to not see the occasional sponsored image on the New Tab Page, they can turn those off from the New Tab Page itself with 2 clicks ( Customize › Show Sponsored Images). Importantly, the user is always in control. They decide whether ads will be displayed, and to what degree (e.g., the user can set a limit on ad notifications per hour).
Brave isn't interested in coercing users to view advertisements.
For now.
Remote attestation will devalue non-attested advertising. Once your stream of revenue dries up due to devaluation, that's when the executives will have a choice to make.
While the 'Web Environment Integrity API Proposal' is portrayed as a measure to enhance web security and prevent fraud, it poses potential threats to competition, especially for open-source browsers like ours. It may seem to protect the ad business model, but what it could lead to is the monopoly of Google Chrome, curbing the emergence of new competitors.
We are an open-source browser developer and these concerns deeply resonate with us. We understand the paradox Alphabet faces, yet we firmly believe the solution isn't about exerting "DRM" level control over a ubiquitous means of access.
We're committed to standing up for the future of the web. We don't just see ourselves as a browser company but as advocates for an open, fair, and free web. We invite you to join us in this endeavor. Visit https://github.com/dosyago/BrowserBoxPro today. Stand with us for an open, free, and fair web.
> and enabled by developers who have insisted we shove as much difficult-to-implement functionality (by which I am talking about CSS complex stuff, not powerful-but-easy-to-code APIs for OS-level access)
Interesting that fixing "how to center a div" is considered harmful, but WebSerialPort is actually very good?
> The result: there is now effectively one dominating web browser run by an ad company who nigh unto controls the spec for the web itself
I don't think this this reality. Google proposes a bunch of APIs that goes nowhere because the other browser vendors consider them harmful. Google's previous attempts at trying to drive more adtech into the browser have failed due to a lack of support from other browser vendors.
I think "who drives the web specs" is probably in the best situation possible. It's largely Google, Mozilla, and Apple who all have slightly different interests in what makes a good web platform, and the web ends up better for it.
> Interesting that fixing "how to center a div" is considered harmful, but WebSerialPort is actually very good?
It is certainly "interesting", but "true" nonetheless: one determined person--think Fabrice Ballard if you want an example--is in a great position to throw together a web browser and even implement ALL of the crazy API wrapper specs, but when if they aren't you simply don't need most of them to browse any given website.
But, as it stands, my only a-few-year-old copy of Safari can barely even browse the web anymore as it is missing some new corner case of CSS or web components or whatever and I just get blank screens a lot; the result: people have burned years of large teams into trying to maintain implementations of HTML/CSS and have given up.
The web should really just be a handful of really core specs for getting platform access--which of course have innovated over the years so you'd have all of canvas, WebGL 1/2, and WebGPU, which would take SOME effort but isn't like, INSANE--and then all of the layout should be done end-to-end in libraries.
The world NEEDED to be like this to prevent us from ending up with only a handful of web browsers that can only be maintained by giant companies: it needs to be sufficiently easy to build a web browser that we would end up with a ton of small implementations that would be difficult to move as a unit, forcing progressive enhancement as a permanent norm.
How are you measuring this? Like, I would expect someone to want to ship e.g. WPF or something into the browser as their UI toolkit. Why would this fit in 5 MB?
So... you prefer the end result we got, with there being only ~1.75 browsers in existence--and only 1 that truly matters to developers--where ~1.66 of them are owned by companies that would prefer to implement this specification? :(
I think, given your history, is that what you’re looking for is apps but distributed on the web. However I believe there is also a market for app clips of sorts that are meant to be more lightweight and have some default APIs available to them, for cases where people don’t actually want the overhead of apps.
It's important to note that a browser that implements something like this is simply not a User Agent, in the most clear way - it's just not there to serve the User, it's there to serve the website. When you consider this, it's clear that this goes against the core principals of the WWW, making this an Anti-WWW feature, or better put, a regression.
Hopefully this will not be implemented, but still it's a good wake up call for those who still think that Chrome is more than an ads-delivery app with some browser functionality.
Yeah this is really the endgame. I think the issue is systemic though, this is more than just ad money. Bots and automatability of the web was always an anomaly and a flaw, as the web was and is always designed for humans. Strict human verification was always a need. One can say we did achieve this with 2FA and such, but what is technology all about? Convenience. If it's more convenient, people will prefer remote assertion every day of the week: https://gabrielsieben.tech/2022/07/29/remote-assertion-is-co...
It is systemic, but I think you underestimate how deeply the adtech money and everything surrounding it is embedded in our mindset. It's essentially the Goodhart's Law taken to the extreme, where every single new iteration of the system brings in new middlemen, new misaligned incentives, then putting those middlemen between the person providing a service and the person who'd like to pay for it.
Here's an exercise: try to draw a diagram of all parties required to display a video ad on your page. I suggest starting with the OpenRTB and VAST specs. It's creepy.
The biggest shame here is that most people are convinced that we need advertising because otherwise people would not pay for content.
> we shove as much difficult-to-implement functionality (by which I am talking about CSS complex stuff, not powerful-but-easy-to-code APIs for OS-level access) into the browser as possible.
"powerful-but-easy-to-code APIs for OS-level access" are actual hard-to-implement-right functionality that is often pushed to browsers with very little discussion or considerations.
But the chance of a web page actually needing that functionality to render at all is rare for hopefully-obvious reasons. The status quo is that progressive enhancement is dead: a few-year old copy of Safari can now simply not browse much of the web anymore because it is missing some corner case of CSS or web components or whatever: I often am stuck at loading spinners or are simply thrown into a blank page... the best case is a client-side rendered 500 error on many pages.
It was critical for the web to be easy to implement the core of for a small team or even a single concerted god-tier developer--imagine Fabrice Ballard--and the current spec has failed so hard at this that even tech megacorps have thrown in the towel. People get upset about WebUSB... but that's not the API surface that is causing us issues. If I had to single-handedly implement all of canvas/WebGL/WebGPU and JavaScript/WebAssembly I could pull it off (noting I used to be a video game engine developer).
> But the chance of a web page actually needing that functionality to render at all is rare for hopefully-obvious reasons.
The chance of a page using something has no bearing on how dificault something is to implement.
> People get upset about WebUSB... but that's not the API surface that is causing us issues.
It's one of the hundreds of APIs, and yes, it causes issues, too. Because it also needs to be implemented, and it also adds to the complexity of the web browser.
No: it doesn't need to be implemented unless you actually want to do something with USB. Random websites aren't not working because you don't support USB. My iPhone doesn't support WebUSB even if I updated its firmware.
It feels like this cannot fly in the EU already though. And if they someone found a way around the regulatory, there will be amendments to shoot it down.
The entire premise of 'people want expensive to make websites, but don't want to pay for them' is already a bit flawed. I do pay for youtube to not see ads, I wish I could pay Google (and Meta) to not serve me ads on any site including Google search, they have ads on. That would make life a lot nicer. And I personally know no-one who would not sign up for that. But that doesn't happen, I guess because ads make more (not from me, but he)?
To begin with, pretty much every government employee in the world has some proprietary software developed within the country for security reasons. Old, even obsolete machines. Out of date software, unlicensed/unregistered software, etc, etc. Much of this is also true of banks.
This means if this is put in place as in the spec, it will affect banks and governments negatively. And as powerful as Google is, I don't think it will win over governments + banks.
But again, all the above could be nonsense, and Google will gatekeep the web. It found itself as the loser in the AI race, and it knows pursuing AI during the ongoing arguments on privacy and who owns the data AI is being trained on - the next best thing is to own the playground where the AI trains. That may not be an entirely bad thing either; sad, perhaps, but as this goes on, and browsing becomes a pain, maybe this will result in people just spending less time online? That's a good outcome in my books.
Yeah: it isn't shocking and can be quickly found using Google (as I just did now). (I have provided some extra links but am only quoting Brendan Eich as you seemed particularly interested in him saying the words himself rather than his team.)
> 1/ native C++/Rust code, no JS tags on page that have zero integrity. That means ability to use SGX/TrustZone to check integrity and develop private user score from all sensor inputs in the enclave; ...
> We already have to deal w/ fraud. That is inherent in any system with users and revenue shares or grants. We do it better via C++ and (under way) SGX or TrustZone integrity checking + OS sensor APIs, vs today’s antifraud scripts that are routinely fooled.
> What Brave offers that's far better than today's joke of an antifraud system for ads is as follows: 1/ integrity-checked open source native code, which cannot be fooled by other JS on page; ... (1) requires SGX or ARM equivalent, widespread on mobile.
They are also building an SDK and talk about using this tech to ensure the ads presented by their SDK in someone else's app are legitimate.
> Part of the roadmap (details in update) is a BAT SDK. Obviously it would be open source, but more: we would require Secure Remote Attestation (Intel SGX broken but ARM TrustZone as used by Trustonic may be ok) to prove integrity of the SDK code in app.
Again: the very tech they are excited about to make their ad-based business model work against people cheating and blocking their ads is the same tech that Google is going to use to make their ad-based business model work against Brave cheating and blocking their ads ;P.
You asked for sources, they gave you sources and now you complain about when those statements were made?
4 to 5 years isn't even that long for these kind of plans, but at the very least offer a good faith counter argument and state your case instead of vaguely begging the question and doing some hand waving about the age of the statements.
What's strange to me is that the main author of the spec -- Ben Wiser -- seems to be against closed, wall-garden paradigms as he has written in a blog post "I just spent £700 to have my own app on my iPhone" [1]. In the post, he laments the state of the App Store monopoly on iOS and ponders returning to Android for the app installation freedom.
How can he reconciliate these views with this spec, which he is the main author of? Surely Ben sees the parallels?
He writes: "Apple’s strategy with this is obvious, and it clearly works, but it still greatly upsets me that I couldn’t just build an app with my linux laptop. If I want the app to persist for longer than a month, and to make it easy for friends to install, I had to pay $99 for a developer account. Come on Apple, I know you want people to use the app story but this is just a little cruel. I basically have to pay $99 a year now just to keep using my little app."
I think it's very easy to treat people in such a binary manner. I get it.
What this guy's doing is shameful, but I've seen dozens of otherwise lovely people, working for charities, spending much more time on socially-important and useful work than 90% of the crowd here... and the same people would push barely legal (if not illegal) targeting on masses of people, arguing to push cigarette ads in markets that still allow it. Advertising is cancer and the current model is not sustainable.
What I'm (poorly) trying to say is: be angry, let everyone know that you're angry, make more people angry, but remember that focusing on this guy is a distraction from a bigger systemic issue and it actually helps organisations like Alphabet.
> I've seen dozens of otherwise lovely people, working for charities, spending much more time on socially-important and useful work than 90% of the crowd here
As if you personally know 90% of the people here? And how many of those 10% would never ever push advertising on anyone, would you guess?
It's moot anyway, you cannot compensate for a lie by giving someone a lot of cake, even all the cake in the world. It's apples and oranges.
> Advertising is cancer and the current model is not sustainable.
"Advertising" is just a shorthand for the concrete actions concrete individuals engage in. There is no "model" outside of hundreds of decisions people make every day. It's like blaming "capitalism" and pretending people just play the "game" as if that existed outside of those actions. For any person you could name, I can find you someone in the same situation who refused to do the evil thing.
Speaking as someone who worked in adtech and managed to spend almost a year getting paid to build an adblocker:
I can tell you that the machine is so big and the responsibilities diluted to such extent that no one really feels like they're making a morally dubious decision, it just sort of happens on its own, magically.
The intent may genuinely be to help decrease bot activities versus human activities.
Even the ad example is about not charging advertisers for bot views, which is a huge problem right now.
The problem is that a tool can often be used for evil as easily as for good, and the more the standard was used to block ad blockers over simply filtering out User Agent spoofing bots, the more this tool ends up evil.
And even if the limited scope in the proposal was the true intent, there's nothing preventing scope creep.
Though reading over it all, I do think the assumption of motivations in most of the comments here are misaligned. This does seem to be primarily focused on the issue of growth in bot activity and making it harder on bots to act as if human to servers.
Still, the spirit of who controls the client is very much at stake, and the comments here are ostensibly right that this is a measure that should not happen.
(And frankly, given the bubbling attitudes about enshittification coupled with the coming lowered barrier of entry for competition against software firms and content production, I think this is very much the kind of thing that may backfire horribly if forced though.)
This is meant to be a Play Integrity API proxy for the web.
Now, I'm not opposed to having a locked down device when performing actions like using a bank app.
However, Google is abusing this, because they force their adware and spyware into that device, so I can't have a secure, locked down Android device without that.
Ironically my bank app allows me to bypass the jailbreak detection screen at my own risk, but Mario Kart Tour and a parking app won’t and expect me to factory reset my device to use them (and Mario Kart doesn’t even tell you and just crashes)
> How can he reconciliate these views with this spec, which he is the main author of? Surely Ben sees the parallels?
It's easy: he works for Google. Every single public-ish web developer and/or devrel from Google will spend inordinate amounts of time lambasting Apple, writing eaassays on how Apple cripples the web etc.
While Google has broken the web so badly that Apple would need several decades to come anywhere close.
Note: the moment they leave Google, they may slightly change their tune and criticise Google a bit. For an example, see Alex Russel of web components when he went to work at Microsoft after spending a decade making sure that web browsers are turly unimplementable: https://infrequently.org/2021/07/hobsons-browser/
Why isn't it a response to the question above asked? The question above seems to be saying that this API will be used to create walled gardens; the linked part of the design is about how to prevent the API from being used to create walled gardens.
It doesn’t have very concrete answers. It’s really more of a couple of ie thoughts, with an exhortation for people to provide ideas on how to fix this. For example:
> Attesters will be required to offer their service under the same conditions to any browser who wishes to use it and meets certain baseline requirements.
What prevents this set of baseline requirements from being e.g. “the device is backed by a TPM from these four vendors”?
> Although a holdback would prevent the attestation signal from being used for per-request enforcement decisions, there remains immense value for measurement in aggregate populations. However, a holdback also has significant drawbacks.
“So, like, here’s a vague idea on how we might prevent this. However this idea has significant problems.” Not a very convincing argument?
> If the community thinks it's important for the attestation to include the platform identity of the application
“If we assume that we can’t actually solve this…”
Basically there’s not much in the way of answers there. Generally when you put out proposals with a history of significant pushback I’d expect the likely feedback to be addressed in more depth than this.
(I guess since we’re doing disclaimers I also work at Google but not on this.)
I doubt it. As explained by GitHub user tbrandirali, the stated goals seem to be inherently contradictory. Quoting in part:
"This internal contradiction is further demonstrated by the fact that the proposed solution to prevent misuse by websites - holdbacks - is to simply sabotage the functionality of the system itself, by making attestation probabilistic. This is not a workable solution to the problem: if the holdback rate of requests is low enough, the denial of service to legitimate users will simply be a cost of business that websites will accept; if instead it is high enough, websites will not use this system as it does not provide meaningful enough information, even for analytics purposes, due to the high uncertainty. There is no goldilocks zone where this system is useful but not open to abuse by implementer websites. You're either implementing a feature that can - and most likely will - be used by websites to exclude unattested clients, or you're implementing a useless feature."
Why wouldn't a 10% holdback work? Would a company consider it "simply a cost of business" to block 10% of people at random? That's going to cause a huge amount of support load and probably a lot of negative press. 90% of data will still be good for analytics.
Pretty much the entire premise in the title of his blog post is false for dramatic effect and you wonder how this man could stoop so low as to be duplicitous?
The underhanded way this is being proposed is really something else. It's hosted on a non-google github to provide distance, it's worded in a way that makes it seem like this is something that benefits users, when it's the absolute opposite of that. It subverts the whole concept of a user agent. This is a huge threat to our industry and we cannot allow this to happen.
It's not a "threat to" the industry... It literally _comes from_ the industry... Unless the tech industry is willing to lose one of its biggest sources of revenue, this is exactly what the industry wants...
Add "integrity" to the list of adjectives used for obfuscating the rise of authoritarian dystopia...
It all started with "trusted computing", where "trusted" means "not under the owner's control". Then they tried to spin it as a "security" thing with TPMs, and created the impression that those speaking out against them were either malicious actors or insane conspiracy theorists.
Now it is actually happening. They want to control exactly what hardware and software you use, and they're doing it by ostracisation, which makes this even more sinister: you're still technically allowed to use software and hardware of your choosing, but you'll be blocked from participating.
I still remember when Intel was forced to revert adding a unique serial number to its processors because of widespread outrage, so it is possible for the public to make a difference; they just need to be educated about the coming dystopia and agitated enough to care and act upon it.
Perhaps we can start by spreading instructions on how to disable TPMs and "secure" boot along with all the advantages that come with doing so (custom drivers, running whatever OS you want, hardware you actually own, etc.) Of course the corporate-owned "security" lobby is going to start screaming that it's "insecure", but we need to make it clear that this is not the "security" we want because it is inherently hostile to freedom.
"Those who give up freedom for security deserve neither."
This would be the method of last resort. I think secure boot as a technology actually has security advantages, if you can freely set the keys. That was what the tech was advertised as to console the critics, but if course it would run counter to the goal of controlling hardware if this was actually implemented consistently. I think regulation to force vendors to provide this option (and in a frictionless, actually usable manner) could do a lot here.
Second is more focus on nag screens, "nudges" and other deliberately degraded UX. I.e. with the Surface tablets, you're technically able to disable secure boot, however you'll then be greeted with an ugly bright red boot screen every time you turn the device on. This stuff can have significant psychological impact, especially for "casual" users.
Whether you like it or not (and I certainly don't), you've gotta sort of admire the sheer vision of a fifteen-year project to build a browser so good it comes to monopolize the industry, all because you've had the foresight to realize that monopoly will be crucial to securing your position as the adtech hegemon. An underrated masterpiece of evil genius.
And tech people fell for it hook, line, and sinker.
It's completely and utterly irrelevant that Chromium is open source, because the web is a protocol, and having the source for an implementation of the protocol doesn't matter in the least when you don't control the protocol. You can't just fork Chromium and remove a feature, because websites expect the feature, and your browser won't work on them. You can't just fork Chromium and add a feature, because websites don't care about your tiny fork and won't use your feature. You can't fork Chromium, you have to fork the entire web.
That's exactly what we need to do. More specifically, we need to decouple the app web from the document web. Most of the value of the web to society lies in text, images, and video, in that order. We need a version of the web refocused around basic content with a spec simple enough for a small team to implement a browser for. A subset of HTML/CSS is probably the only way to succeed, since sites would need to work with current browsers. I think a few HTML tags + flexbox + fonts + colors would get you pretty far.
> You can't just fork Chromium and remove a feature, because websites expect the feature, and your browser won't work on them. You can't just fork Chromium and add a feature, because websites don't care about your tiny fork and won't use your feature. You can't fork Chromium, you have to fork the entire web.
In some cases you can (although it may be difficult, because the code might be difficult too and maintaining with merging changes can make it difficult too).
You can remove features you don't want, possibly adding fake features in its place or those that access other features, e.g. the microphone access to instead access a file, etc.
You can add features that most people don't use even if you do use them. It can also be implemented in ways that are backward-compatible. Also, some features that are added are not features that the web pages will need to know anything about, because they are user features instead.
Nevertheless, some things cannot easily be forked in this way. For example, adding a "Interpreter" header to add support for additional file formats and make it compatible even with browsers that do not support it, cannot be made compatible unless you add a request header to specify its availability too I suppose, and then just complicates it.
Of course you can. Microsoft's Edge and Brave already add proprietary features like AI and reader mode, tab groups, video calling, crypto wallet etc.
Brave could add a custom CSS or HTML feature. Hell that was the status quo we came from ten years ago when each vendor had their own feature flags and implementation for WebRTC and proprietary video codecs, etc.
Brave already explicitly removes ads and blocks all kinds of things websites expect to work on Chrome.
I think you missed the point of the comment you’re replying to. Without market share, the custom feature will never be respected by the web. At best if web developers don’t have to do any work for it you might get something that you can maintain for a while.
In fact, Edge is a perfect example of "nobody caring about your tiny fork": No matter what Microsoft tried, the internet no longer cared about Trident and IE/Edge. The only way Microsoft could regain some semblance of existing was to turn IE/Edge into Chrome and play the internet game as Google dictates.
Nowadays Edge has some superfluous features that differentiate it from Chrome, but they are still superfluous. Underneath it's still Chrome, because the internet demands Chrome.
Still bummed they didn't go with gecko.
(I know chromium is the superior engine, but Microsoft could've pushed gecko development to new highs for sure)
And I believe this strategy was how Sundar Pichai became CEO of Google. He oversaw the chrome project in the early days and its incredible success catapulted him up the management ladder at Google.
I wouldn't necessarily view it as malice from the beginning. It's entirely likely that early Chrome was really trying to solve usability problems in hosting complex applications like GMail. A goal that was attempted throughout history, as seen from the days of ActiveX, Java Web Applets, Flash, etc.
But capitalism does what it does best, and will happily take advantage of (and try to prolong) a natural monopoly situation even if the origins were genuine.
In fact this is why there are regulations around "utilities". They are also an area where a natural monopoly is the optimal, so they shouldn't be treated as a free market.
(Food for thought: Perhaps the Internet infrastructure should be a utility too? Browser makers could be forced to be non-profit, which would mean companies need to divest themselves of the "Internet business" if they want to do "business _over_ the Internet")
> I wouldn't necessarily view it as malice from the beginning. It's entirely likely that early Chrome was really trying to solve usability problems in hosting complex applications like GMail. A goal that was attempted throughout history, as seen from the days of ActiveX, Java Web Applets, Flash, etc.
I would say that the actual goal early Chrome was really trying to solve, was to prevent the browser monopoly of the day from being used against Google. It's similar to how Valve invested on Steam OS, as insurance in case Microsoft used its operating system monopoly to degrade the Steam experience relative to Microsoft's application store.
That's a fair take. Which kind of begs the question: How much innovation in tech is actually just people getting around limitations imposed by monopoly/high influence players?
The literal attempt to censor web usage of Linux and BSD desktops, other FOSS clients, custom Android ROMs, etc with an open reasoning "to sell you ads".
Yeah I mean the first of their examples is literally:
> Users like visiting websites that are expensive to create and maintain, but they often want or need to do it without paying directly. These websites fund themselves with ads, but the advertisers can only afford to pay for humans to see the ads, rather than robots. This creates a need for human users to prove to websites that they're human, sometimes through tasks like challenges or logins.
I find it quite cute that they start with "users" as if it's a user demand but in the next sentence switch to "advertisers" --- the real target population.
Why stop there. Let's see who is behind the problem they're solving with item 2:
Some examples of scenarios where users depend on client trust include:
1. Users like visiting websites that are expensive to create and maintain, but they often want or need to do it without paying directly. These websites fund themselves with ads, but the advertisers can only afford to pay for humans to see the ads, rather than robots. This creates a need for human users to prove to websites that they're human, sometimes through tasks like challenges or logins.
2. Users want to know they are interacting with real people on social websites but bad actors often want to promote posts with fake engagement (for example, to promote products, or make a news story seem more important). Websites can only show users what content is popular with real people if websites are able to know the difference between a trusted and untrusted environment.
Not written in item two: And the people paying to promote the posts funding these sites want to know the promotions are landing on real consumers' screens.
It’s not impossible that google people who work there long enough are under a corporate delusion that users need something ads related that is aligned with business model of their paycheck issuer. They may sincerely believe it’s the only way forward, because otherwise it’s ruined for everyone.
As someone who lived in a city fully controlled by organized crime, I can tell you that eventually some people become fanboys of gang-law and start to unironically teach everyone how it’s better and more moral than actual law.
I'm worried about this too, as we run a company that invests heavily in developing browsing technology that is powered by these browsers (like chromium) but liberates them in various ways (such as running headless in the cloud, and then having users connect to it remotely), or running in a "semi automated". Both of these things would possibly be flagged by these attestation guards, and would not be environments that "preserve the integrity of the ad business model and the dominant browser market". If you want to get involved in doing something about it, come and check out our open source browser work at: https://github.com/dosyago/BrowserBoxPro and get involved
I mean, to be fair, that's their entire modus operandi.
You don't berate a kitchen for serving food, why would you look at any Google contraption from HTTP/3 to Chrome as anything but a vehicle for selling ads and/or mining data?
Google are clearly trying to add levels of indirection here to pretend it’s some kind of standards forming, instead of a dictatorship. There’s nothing “to be fair” about.
The largest subsection of the document is spent discussing how to prevent specifically this situation, and this is called out explicitly as a non-goal.
They didn't try hard enough. That section concludes "Established browsers would need to only use attesters that respond quickly and fairly to new browsers' requests to be trusted," so in the end, Chrome's monopoly lets it call all the shots.
It's the ad-tech sector of the web declaring a secession from the internet, for ads can't live under the law of the open web. The new AdWeb is going to look like appstores: websites will need to pay to the adweb owners, and users will need to use smartphones or locked down browsers. As for the open web, it will stay and continue evolving free from money making concerns.
Good luck getting online banking to work outside Chrome and Edge.
If you call their support line to say something isn't working, they'll ask if you're using Chrome or Edge. If you aren't, they'll tell you to just use Chrome or Edge.
It's time to break Google up. They're the AT&T and Standard Oil of our generation. Make Ads, YouTube, Search, Cloud, Chrome, etc. all independent companies. Demand that antitrust regulators do their damn jobs for a change.
* The US would never kill its golden calf except as a last resort.
* The US standard for antitrust is consumer harm. Google implementing a thing that other companies have been asking for, any company can join and send their own attestation signals, and then those other companies in unrelated markets use the thing to maybe not support unapproved stacks which could reasonably include Android/Chrome won't fall on Google.
Google Cloud becomes a VC driven organization that slowly eats margin dirt against it's competitors until insolvency. There was no way for it to recover enough resources from the mothership before being split out.
Search trundles along ok, assuming it took search ads and a ton of core infra with it, but it never makes enough money to ship a decent product extension. It hopefully removes some products it can no longer afford margin on, which have long produced distorted results (albeit with good intention). It suffers slow brain drain, and users end up using multiple search engines for every search again because no one has good search quality. The monopoly breaks, but so does this part of the internet, bolstering apps and information sites ecosystems positions. Wikipedia is the only real winner we want in this space.
Display Ads goes like it just discovered faster than light travel, no longer held down by the ol ball and chain that is the entire rest of the company. They go much darker as they no longer have tons of goodwill organizing from the rest of the company, and increasingly join the bad actors. In 20 years they eventually join lexis level evil in terms of multi-directional user sharing.
YouTube heads off into the stratosphere along with Display Ads. They try to maintain a better public face, but having to spin up their own ad market solutions drops ad quality even further, margins suffer, but their position remains ossified and they slowly recover. They start to get a bit more agile, no longer disrupted every other year by some mandate from the mothership, they're better able to keep up with new markets and more rapidly crush new competition.
Workspace decays very slowly. All the AI stuff halts and gets ripped out as there's no one there to work on it. The drive product has to scramble to figure out how to rebuild without all the internal commodity infrastructure support. GMail gets unstable for a while due to the weight of the infrastructures sitting on many fewer shoulders. Global instability results of the rapid de-distribution of the system as the production infrastructure was sliced apart in a rush to meet forced division. The economy takes a big dive as a result, as half the world loses email access regularly, bills don't get paid, etc.
Photos spins out into its own thing, and dies rapidly, as selling the odd photo frame here and there just can't meet margin.
Chrome tries to get funding from Microsoft, eventually it gets purchased wholesale, but the core team gets ripped up and largely discarded. Who knows how the OSS products fare, it depends on the executives in Microsoft who win this purchase. Eventually the main product gets shuttered, with Edge being the only replacement.
The telco products all shutter immediately, with no recourse. Same with R&D.
AI tries to split out into it's own thing, but fails to find a business and suffers constant reputation problems. After 10y of trying it eventually shuts, the acquiring company however immediately spins up multiple successful products and makes a big dent in the now well established market.
Android spins out into its own organization. The first decade the heat of internal politics in new found vacuums crushes them, eventually they find footing and head back to their open core roots, get scrappy and do some new things. Along the way their size fluctuates as the market forks and fractures as it does, but Android manages to hold its position as the western center of its universe.
Chromecast, ChromeOS, Nest all suffer badly having no core ecosystem to ship anymore. They attempt to buddy up with Android which pushes them around trying to androidify everything, but resulting in poor UX and/or poor margins across the board. Eventually the all but ChromeOS shutter, and ChromeOS business also closes, but leaves behind an OSS gift that a core group of passionate individuals try to limp forward as best they can with the new Microsoft Edge overlords.
Users find their data fractures across a dozen companies, with poor SSO integrations. Security mistakes abound, lots of people are affected. Online crime goes through the roof, it feels like the 90s again, but on a much much larger scale. Lots of people lose their accounts, and are affected by service outages and the ongoing economic effects from those. ISPs jump at the chance to step in, and lots of users start trying to use alternative email services again. They experience poor discoverability, lots more security problems, and constant space pressure. Vultures make off like bandits, and amazon, apple, microsoft, and cloudflare are the biggest winners in the fallout.
> The economy takes a big dive as a result, as half the world loses email access regularly, bills don't get paid, etc.
Now you have me excited for this possibility. Doubly so if people stock up on ingredients for high explosives first. Take what you can while the taking is good: no room for repo men. Year 0 now.
> feels like the 90s again
I can't wait.
> amazon, apple, microsoft, and cloudflare are the biggest winners in the fallout
Sadly, that's true. Google's remains can only be cannibalized by companies that are already Google-sized.
I mean, is any of this supposed to sound bad, because it sounds like a more-unhinged version of the internet of old and I am here for it!
Add some internet chaos to go along with all the climate, finance and real-world chaos we’ve got going on in our lives already. Who knows what kinds of interesting and innovative ideas and technologies would bloom in this environment!
> Vultures make off like bandits, and amazon, apple, microsoft, and cloudflare are the biggest winners in the fallout.
In this world, Amazon et al get the same treatment. As for "vultures make off like bandits", welcome to market-based economics, these companies can compete if they don't want to die, and if they can't compete, then let them die.
counterargument: let's say the us gets in a real war with china, a massive conglomerate like google would probably make massive contributions to cyber/technological warfare that the individual pieces would have a hard time doing
i agree they should be broken up, but it might be the wrong time for it.
Google can intercept nuclear ICBMs? Because if they can't, nothing they do would really matter in a real war against China.
(And saying that actually "it would probably not escalate that far in a real war because... It just won't! " might be a common argument these days amongst war mongering lunatics to make war with China or Russia sound less batshit insane, but it's not an actual argument. It's just run of the mill "this time it's different!" cope that has been said before every blood bath. )
Can you give us an example of wartime contributions that require expertise across the verticals of browser vendor, advertisement marketplace, a remote home video/audio monitoring vendor, an OS vendor, and a productivity software vendor? How does integrating those verticals help in an attack or defense scenario any better than having those separated?
By the HN guidelines this is a repost, but it would be a mistake IMO to delete it. This would mark the end of the open web, but for whatever reason this issue has never really bubbled to the surface here before. It feels like something is different this time.
The chess pieces for the end-to-end unblockable ad machine are in place.
You'll have the cynically named "Privacy sandbox" that builds tracking directly into the browser. You curtail ad blockers by capping browser extensions. And then you allow access only to "attested" clients. Inescapable tracking and unblockable ads. And you'll get to see ever more of them over time.
If this isn't evil enough in itself, the way Google presents these initiatives in grossly misleading ways makes my blood boil.
Fuck "Be as evil as possible" Google. Absolutely pathetic company. I'm so done with them.
I see one more dangerous development imposed by this move: limiting access to web content for rival search engines. I'm sure that Google Robot will pass all "high security standards" and web integrity checks, while others won't be able to do so.
I think "don't use Chrome" is really not the best way to fight this - instead, make it known. Get out to as many people as possible that this thing exists, spread awareness, explain the consequences, make a stink.
Google is absolutely in a position to implement this and I figure a good number of sites would immediately join. However, the image of "tech" is tarnished enough already and the general population is more aware of the importance of having control about their online experience.
So I'm kinda optimistic that more public awareness of this might lead to a larger backlash and might make Google think twice in continuing this, lest risking a PR disaster.
This is the most disgusting thing I have ever read. My blood is boiling to the point where I genuinely don't see a bright future.
Ben Wiser (Google), Borbala Benko (Google), Philipp Pfeiffenberger (Google), and Sergey Kataev (Google) have got to be the most repugnant people on the planet for pretending this is anything but a scheme to destroy all privacy and freedom on the web all so fucking Google can sell more ads.
I am not a hopeful romantic, but the EU has been investing on vendor neutral web-browsers like Nyxt [0] and the UR Browser [1] through the Horizon Europe program. I doubt that legislators (at least in the EU) will view this as a positive development, assuming EU legislators know what they are doing. On the other hand, lobbying by big tech is still very much a threat.
The big problem with many of the alternative browsers like the ones you mentioned is that they are powered by the Blink engine (it's one of the 2 options for nyxt). The overwhelming market-share of Blink and the institutional monopoly on its development is the biggest driver for introduction of anti-features like these. WEI for example, is being prototyped in it [1]. These anti-features make it into every browser that uses Blink. While some browsers like UR-browser and Brave disable many of these features, they still lend credibility to the blink engine.
We need to promote alternative web engines like Servo and libweb and browsers based on them. Many of these engines need a major push to be competent enough for daily use. Gecko is also fine - but building a new browser with it is said to be hard.
I assume you are referring to the UR-browser. Despite being closed source, it seems to have better privacy policy compared to Chromium. By using chromium or many of its derivatives, you are automatically lending credibility and subjecting yourself to anti-user features like these. Chromium is one of those software that I consider as open source, but not free/libre. It absolutely doesn't respect users' interests. The usual argument of "but it's open source, modify it" isn't practical either, because the code base is too massive and complicated.
Despite all that, I would recommend only FOSS browsers with good privacy policy - because they exist.
This proposal is attempted theft. The web does not belong to Google, it belongs to everybody. Who are they to suggest that users with “non-attestable” (read: not controlled by Google) user agents or operating systems should be excluded or punished?
If Google wants a war, let’s give them one. Tell everyone who will listen. Give Google hell.
Oh by "Web Environment" you mean "my machine" lol!
I already got caught by this kind of thing - a https://github.com/nativefier/nativefier app wrapping Youtube Music doesn't work, because Google detects somehow that you are not using a trusted browser and refuses to serve.
This is sort of moving in the "zero trust" (as in let's use ML etc. to detect if we trust something. username/password is not enough), which I fear because it will break a bunch of stuff for genuine users and make things less reliable.
> Users often depend on websites trusting the client environment they run in.
is already a lie. Users don't depend on websites trusting the client environment. Users expect the client to limit the way in which they have to trust websites.
Sure website owners would love to be able to trust user input, but that has little to do with the interest of the users.
If something starts with that kind of framing already you certainly know that this is not going to benefit the user.
Proposals like this demonstrate the utter failure of our ethics education in computer science.
In a field facing increasingly harder ethical questions every day, it’s important to start empowering our engineers to say “no” to ethically bankrupt things like this.
I don't think any amount of ethics education will matter in the end in the face of the incentive structure that appeared in the industry.
Strong cultural norms (e.g. hacker culture) might help for a while. But incentive structures eternally erode opposition.
It could make it easier for developers to band together and try to collectively veto things like this. But corporations with money can always buy the expertise of people, have them undermine the community, create their own parallel communities and influence public opinion and legislators.
FAANG salaries supercharge people's cognitive dissonance. They will find ways to excuse, minimize and ignore their contribution to the current situation.
Even HackerNews developed a sub-subculture of people that were constantly going on threads and calling remote attestation worries as "FUD".
It's unclear how to preserve cultural norms that stand in the way of market dominance. The only thing I can think of is having competing interests in the market. But whenever these align -- hell breaks loose.
You might be disappointed. Ethics training can't force people with different political viewpoints to conform to yours; in fact it gives them better tools to explain their views.
I hate to say it, but if you used Chrome to read this, then you're part of the problem.
Awful stuff like this wouldn't stand a chance if Google didn't have such a monopoly position.
For the sake of the open internet, please switch to a different browser. IMO, Firefox is best, but even something chromium based is probably fine. Just not Google Chrome.
I am not optimistic that the de-facto end of general computation can be prevented, or that there will even be noteworthy opposition.
There are so many powerful interests that stand to gain from preventing e.g. ad-blocking and content capture.
Thanks to Windows 11 requiring TPM, it is just a matter of time until hardware support for remote attestation is ubiquitous even on desktop computers.
Meanwhile, our (including myself) attention is (perhaps justifiably to some extent) on the latest news about $EXISTENTIAL_THREAT and how $THE_OTHER_SIDE did $EVIL_THING fed to us by the algorithm.
Organizations that used to effectively fight threats to freedom like this (FSF, pirate parties, CCC, EFF, etc) have lost a lot of their support/influence and clarity of purpose over the last decade.
>The attestation is a low entropy description of the device the web page is running on.
>The attester will then sign a token containing the attestation and content binding (referred to as the payload) with a private key.
>The attester then returns the token and signature to the web page.
>The attester’s public key is available to everyone to request.
I'm assuming "attester" here means "hardware authenticator." How is the attestation low entropy if it's presumably signed by a key that is unique & resident to my device? There is nothing higher entropy than a signature w/ "my" private key. That is literally saying "I [the single universal holder of the corresponding private key] signed this attestation." These days that key is realistically burned into my device at manufacturing time, and generally even if I can enroll keys on "my" device (big if), there is a very limited number of keyslots on hardware authenticators. Certainly not enough slots to present a random throwaway identity to each webpage.
I don't understand how you can have public/private key crypto as the basis for attestation and also have privacy? The two seem mutually exclusive. Is the private key supposed to be shared among a large cohort? (Which seems rather unwise, as it would make the blast radius of a compromised key disastrously huge.)
> I'm assuming "attester" here means "hardware authenticator." How is the attestation low entropy if it's presumably signed by a key that is unique & resident to my device?
From what I understood, the "attester" is a remote server, which signs the attestation with its own key, after somehow verifying that the browser and operating system and drivers and machine is not running any code that this remote server does not completely trust. That key can be used at most to identify the remote server, which is supposedly shared by a wide number of devices.
Yes, this means that your browser depends on having a working connection to that remote server for every attestation it makes, and that if that remote server colludes with the web page (or is compromised), it can leak your identity.
Also, there probably will be per-device keys, it's just that they are only used in the communication between the attester and the device, and not exposed to the web page.
So you're at the complete mercy of the attester (and of whatever deals it made with the sites) but the sites technically can't use the token to track you. Privacy!!!
The WEI spec talks at length about how ads provide revenue for the web publisher. In that context, I'm pretty sure that the 'environment' they're talking about must ensure that the ads are shown. This would mean that the attester has to invasively check the browser/app to ensure that no ad blocker is running. That would mean that the attester is most likely a proprietary application running on the user's device.
Maybe your device sends a signed attestation to the OS vendor and they generate a more generic attestation (basically "this is a legit Chrome browser running on Android but I won't tell you anything else").
There's some quite complex cryptographic machinery called Direct Anonymous Attestation that would make this possible. I don't know if they plan on using this though.
> Attesters will be required to offer their service under the same conditions to any browser who wishes to use it and meets certain baseline requirements. This leads to any browser running on the given OS platform having the same access to the technology, but we still have the risks that 1) some websites might exclude some operating systems, and 2) if the platform identity of the application that requested the attestation is included, some websites might exclude some browsers.
I feel this is the bit that's going to be hand waved away for the sake of convenience.
I also wonder what those certain baseline requirements are going to be? Weird that they're left ambiguous.
It's probably nothing to worry about. We have a ton of precedent with Widevine that "it's okay, we'll license to anyone who meets requirements" wouldn't ever be abused[0]. It's fine, you just meet the baseline requirements that aren't spelled out yet and that might be subject to change and that certainly won't include headless or highly scriptable or experimental browsers. Nothing to worry about.
I fully expect the attestors to be platform vendors - Google, Apple, MS.
It’ll be cryptographic chain-of-trust based, with it sending a fingerprint, probably encrypted/signed with a per device key stored in something like a TPM, to the attestor, who will say if the fingerprint is valid or not.
They’ll inevitably only attest to the state of apps running under this full chain - so full secure boot, no unsigned drivers, only signed/approved apps - probably with a requirement to be installed via the platform’s App Store.
No one will be attesting for Linux because there’s no chain of trust and no control over what runs.
It’s a recipe for eliminating user choice and freedoms.
The current spec has a holdback mechanism. It actually gets implemented, I don’t expect that holdback mechanism to actually be part of the final implementation - because it makes the whole idea useless.
It's unbelievably frustrating to see Google saying "oh, we wouldn't abuse this, trust us, you just have to meet the requirements (that we conveniently haven't specified)" -- frustrating because we know what attestation and chain-of-trust looks like for Google and it's already abused today, and there's zero reason to believe this is going to be different.
Telling us that they're not going to abuse us or limit user freedom while they're actively holding back user freedom. But we're supposed to just not look at that. There are so many examples of Google abusing gatekeeper status, we went through this with Widevine. But even if we ignore all the past abuses (not that Widevine is a past abuse, as far as I know it's still not available today in a generally accessible form for new browsers) -- even if we ignore all of that we still have Play Integrity on Android today, currently, that is currently being abused.
We're supposed to not only ignore the past, we're also supposed to ignore the present and to ignore Google's current attestation policies on Android and just assume that Google still has good intentions here.
This isn't extreme enough. If they're going to put out a very controversial proposal like this, they may as well go all in. The push back against this is going to fizzle out, and it will be shoved through regardless of anyones opinions.
Governments will love this due to protection and security it provides among other things. I wish I could say I was surprised, but Google has continued to fail to deliver even when they try for a power-grab play like this.
Feature requests:
- Add a distributed bad-actors list similar to DNS.
- Start the process of introducing this functionality at the hardware level.
- Require photo personal identification to prove humanity.
The only way around the dystopia this will lead to is to constantly and relentlessly shame and harass all those involved in helping create it. The scolding in the issue tracker of that wretched "project" shall flow like a river, until the spirits of those pursuing it breaks and it is disbanded.
And once the corporate hydra has regrown its head, repeat. Hopefully, enough practise makes those fighting the dystopia effective enough to one day topple over sponsoring and enabling organisations as a whole, instead of only their little initiatives leading down that path.
I commented similarly elsewhere (https://news.ycombinator.com/item?id=36815276) but shoutout to all the people during the Web Video DRM debate who said that DRM wasn't going to be proposed for HTML or Javascript.
How can the “attesters” verify the integrity of the user agent? Sure the attestation is signed, but why can’t we mess with the data sent to the attester and just nullify the entire point of the proposal? The “browser acceptance criteria” in the spec, that would presumably contain this info, is just “TODO”. Thanks Google for conveniently omitting that key detail.
Also interesting that its implied in the explainer that attesters are just HTTP endpoint dealing with “billion-qps” traffic. Again, point above, but also how can we trust any attester to not use the (completely unobfuscated) information the user agent is sending them?
I guarantee that big websites will host their own attesters, only allow use of their attester, and require attestation for every request, allowing them to fingerprint every single user.
You don't send any data to the attester. It runs locally on your device, or rather is part of its core functionality. Building a chain of trust from the TPM hardware module, validating secure boot is enabled, validating the kernel and drivers have not been tampered with, eventually validating the browser has not been tampered with.
You can't run your own attester - these are implemented by the companies who provide the hardware, such as Microsoft or Apple.
Not without exploits. This is a cryptographically signed chain of trust from hardware to booloader to kernel to the OS to Chrome. If any of these are tampered with the signature will not validate and they won't load. If you try to run an unsigned version the layer above you will refuse to sign the attestation. The only solution is finding exploits in the chain. If at any point you get unsigned code running or manage to get a signature outside of the signed environment then you can "spoof" the attestation. But while it is a big stack it is explicitly designed to prevent this exact issue, so it won't be easy and it will be quickly patched.
This is the same setup as SafetyNet on Android. SafetyNet can be worked around right now for "Basic Integrity" but this works by making your device claim to be an older device. Newer devices support hardware backed attestation for which there is no general work around. You can be sure that this proposal will be using hardware-backed attestation from the start.
> I’m giving everyone a heads up that I’m limiting comments to contributors over the weekend so that I can try to take a breath away from GitHub. I will reopen them after the weekend
Does it disturb anyone else that this is (a) in a personal namespace & (b) reason given for closing discourse being a single individual's need to disconnect from work at the weekend, when that person is employed by a large corp to maintain this spec which they are implementing in their product?
Surely Google as an org, if they're behind this, or at least a standards bodies own org namespace should both own this project, and also decision making around discourse, with any individual employees being free to leave the project un-answered outside of working hours?
This isn't some open source passion project someone's doing in their off time...
First I wanted to say client trust is one of the two things I‘d really like to see improved from a security standpoint but I think it‘s the wrong way around. Browsers should establish if they feel they operate in a trustworthy enough environment and decide to not work at all if they don‘t. Having the website initiate this check is a bit strange to me. (The other thing being more MitM and DNS Hijacking protection)
It's an Orwellian name, but makes a certain amount of sense. That's the most effective kind of Orwellian name.
Even still, I think that it is wrong to give something a convenient name that espouses some virtue. They should have chosen something like Web Environment Verification API.
I think it's spyware, and I don't like it. It reminds me of the Stripe API, where you have to run some JavaScript on your site that snoops on your interactions and reports stuff to Stripe that it uses to detect fraud. https://news.ycombinator.com/item?id=22937303
They've probably delusioned themselves that this is not evil. They are saving the internet from small businesses going under because their ads are being blocked!
The idea behind this proposal is what I feared the moment remote attestation(-ability) started to gain traction on clients.
Google will arguably kill legacy SafetyNet (which is circumventable, as it's not rooted in hardware) soon. Microsoft pushes extremly hard for remote attestation-ability by requiring TPMs. Very soon only an insignificant number of client devices will not be able to perform remote attestation by the major vendors based on hardware trust modules.
Soon there will be a Plaza Web, for which you'll need an approved device for, like a Chromecast with Google TV, and the Old Web of communities, enthusiasts, and the like.
I highly doubt it, but I wonder if this will be the straw that breaks the camels back where general perception of Google flips to where they are viewed in the same circle as Comcast or EA.
Google is heading in that direction and their velocity is accelerating.
This isn't just Google. The whole hardware industry is moving towards the Digital Lockdown. This idea has been around, at least, since the early 2000s, but the people who were talking about it, of course, got shouted down as conspiracy theorists.
And as far too often, the "conspiracy theorists" were right, but nobody cares about ever thinking about that, because nobody seems to be actually able to think about things anymore, unless the thoughts are breast-fed.
We're heading towards a reality, where copypasting from a website is going to cost you money if the license requires you to do so. Looking at it, considering the status quo of technology, almost everything required for a "trusted" environment is already present in consumer-hardware.
We have hypervisors, virtualization, containerization. Encryption/Decryption of data in RAM/CPU in real-time is coming eventually. Blockchain technology makes verification of digital ownership secure and easy. AI will make it stupidly easy for corporations to make sure that everyone complies and I will be everywhere within the next few years.
A glimpse of this reality can be seen in NovaQuark's "Dual Universe", where everything is behind DRM. A "metaverse" company for a reason, I guess.
The empire strikes again being driven by the insatiable greed. Just wait till its minions will fill up this thread with classical astroturfing and comments in vain of "We were waiting for this feature since forever!" and "It's for better security". I can also easily see how they massively downvote everyone who disagrees with the righteous direction of The Corporation. This is so Orwellian 1984.
HTTP/3, HTTP/2, many useless JS API are pushed by Google.
Is there any real alternative to the multimedia Web? Or do We need to make one now?
What we need:
- hypertext, links
- raster and vector images
- videos
- responsive layout system of said hypertext (cassowary)
- programs that can control the page content fully
At DOSYAGO, we're definitely concerned about this. We see concerns of Alphabet’s Web Environment Integrity API Proposal, we see a potential threat to the very democracy of the web. The danger isn't merely about preserving the ad business model, but the potential for market monopolization by Google Chrome. Yet, the beauty of open source presents us with hope and solutions.
As creators of a competing open-source browser, we're stirred by this. We're concerned about the future integrity of browsing - whether run remotely, headlessly, or semi-automated, we see all these threatened by such attestations. But we believe in the power of the collective, and the spirit of innovation that thrives in the open-source community.
The conundrum is real for Alphabet, but leveraging control over such a global, ubiquitous means of access cannot be the answer. However, we don't advocate a future where Google cannot derive value from its creations. The economic balance may be hard to find, but technically, solutions will emerge. We're committed to standing up for the future of the web, because we believe in its open, democratic potential.
Now, more than ever, we need you to join us in safeguarding the web's future. Come, contribute, and be part of the change. Visit https://github.com/dosyago/BrowserBoxPro today. Stand up for an open, fair, and free web.
> ... This creates a need for human users to prove to websites that they're human, sometimes through tasks like challenges or logins.
No I do not? This sounds incredibly condescending as a user – I don't need to prove anything.
Their example of Play Integrity API is alarming because that essentially means either use this OS and this browser which has been verified only by us or we will not allow you to use the internet (SafetyNet vibes)
I’m hoping to get back to everyone as soon as possible. I hope you can all appreciate that I’m a human being and this has been a lot!
In the mean time, I wanted to repost my last comment on the GitHub issue thread [1]:
Hey all, we plan to respond to your feedback but I want to be thorough which will take time and it’s the end of a Friday for me. We wanted to give a quick TL;DR:
- This is an early proposal that is subject to change based on feedback.
- The primary goal is to combat user tracking by giving websites a way to maintain anti-abuse protections for their sites without resorting to invasive fingerprinting.
- It’s also an explicit goal to ensure that user agents can browse the web without this proposal [2]
- The proposal doesn’t involve detecting or blocking extensions, so ad-blockers and accessibility tools are out of scope.
- This is not DRM - WEI does not lock down content
- I’m giving everyone a heads up that I’m limiting comments to contributors over the weekend so that I can try to take a breath away from GitHub. I will reopen them after the weekend
> This is not DRM - WEI does not lock down content
Right, but there is a severe risk that you give the means to block non-mainstream clients, be it browsers, operating systems or devices, correct?
Yes, it's nice to know you may want to allow user agents to browse the web without WEI and I'm sure you have best intentions, but we are already in a world where banks and even stuff like Zoom just look at the user agent string and say "Ah, I don't know this browser, please install Chrome or Edge!". Why shouldn't they just similarly halt in the future if the WEI API does not exist? I (and the browser vendor) can spoof a user agent, but you can't spoof attestation, i.e. cannot fix it if websites don't allow my browser based on the (missing) WEI API. So, how will you prevent this?
How can you make sure that users of e.g. Asahi Linux will be able to use the web in the future? Who will attestate their browser based on what? How will e.g. Gentoo users use the web with their build-from-source browser and OS? Will e.g. Netflix continue to work reliably on a user agent without WEI (but with Widevine) - and will the holdback population (if holdback is implemented at all - no offense intended, but you didn't sound too confident about this on the blink-dev mailing list, tbh) be large and significant enough for them to not just say "eh, can't verify, use the app please or wait a bit"?
> It’s also an explicit goal to ensure that user agents can browse the web without this proposal
How, in an information theory sense, can you stop website operators from using this attestation information to block subsets of users? The "holdback" mentioned in your reference link seems like an optional thing, as if we're concerned about good faith actors rather than the opposite.
It would be nice if the spec included examples of how a hypothetical bad actor couldn't abuse the spec to block non-attestors. i.e. How do we stop "this website only works in Chrome on Windows" but for attestation? Right now, it's trivial to "fix" because we can lie about our environment (it's likely just reading our User-Agent) and it's unlikely that the website will actually not work in other OS/browser contexts.
Some websites really do only work in certain contexts, but I think critics' concern is what happens when the website would work perfectly fine, but it refuses to. I think this is largely the same concerns people have with mobile app permissions, but those can be gatekeeped by mobile app stores who can enforce political goals such as "You can't ask for permissions you don't need and refuse to work when you don't get them", websites have no such constraints.
What's to stop websites from blocking random users now? Nothing, really. But we don't have to bypass any cryptographic attestations in order to try to work around those blocks. This spec seeks to stop that.
It's complex and nuanced, all about altering probabilities of various bad things and TBH work still needs to be done to prove a useful middle ground even exists.
But one thing I can say for sure is there's no way I'm approving Chrome adding a feature which makes it possible for websites to be viewed only in Chrome. Nobody wants that and it's listed as an explicit anti-goal of the feature. Chrome couldn't have existed in the first place without masquerading as Safari, who masqueraded as Netscape etc.., this is something we're all very aware of and committed to in Chrome as its core to the openness of the web.
I suspect you didn’t just forget. It would look good to at least explain why you’re not following through on this, as it’s now Thursday in parts of the world.
In much the same vein as something clearly profoundly hurt you and you want to ruin the web out of spite, I root for global warming because it will destroy all the infrastructure on which you wish to take a giant dump.
> giving websites a way to maintain anti-abuse protections for their sites without resorting to invasive fingerprinting.
What prevents a website from using invasive fingerprinting _AND_ WEI together? I strongly suspect websites will end up using both WEI and invasive fingerprinting because:
1. Websites will want to use invasive fingerprinting on old browsers and it would work within browsers that deliberately don't implement WEI.
2. Websites will want to get as much invasive fingerprinting information as they can get their hands on.
3. It is another layer of fingerprinting in the likely event that WEI is ineffective due to TPM exploits[1], operating system/driver exploits, web browser exploits, determined actors using rooms of computer display recording devices and robotic arm mouse movers, etc. Invasive fingerprinting further increases the cost and complexity to actors the website is trying to block.
> This is not DRM - WEI does not lock down content
It is absolutely 100% DRM. Your proposal states that devices would need to attest their configuration to the website. The website can then block the user because it doesn't want to show the news article to a Linux device where the user can block annoying pop-up ad videos, copy and paste the text or save the web page. The website can instead only allow devices which are factory-configured to block copy+paste, block saving web pages, block screenshots, etc. It's still DRM even with the proposed holdback mechanism because in the best case, a user will still be blocked 9/10 times (or whatever the holdback mechanism is set to). The more likely scenario is a website owner will just refuse to serve content until the client has attested itself. "The requested page can not be provided due to an unexpected problem. Try again in a few minutes."
There are so many flaws with the scheme as currently proposed I feel I could write for days:
Will websites be expected to block and ban users of AMD-SP now that it is broken[1]? Or will whoever conducts ad fraud just buy all the AMD-SP devices they can get their hands on?
As another author replied, are Gentoo users that compile their web browsers and operating systems from scratch just ignored, and the proposal pretends it won't impact these users?
How does the proposal allow users with specialist accessibility software to browse the web without being blocked for being a minority group that is not economically worth website owner's time to support? What prevents abuse of said specialist accessibility software for other purposes?
How would a new start-up developing a competing browser or phone from scratch, and are very much unknown and in a minority position, be able to convince millions of website owners to unblock/allow their new browser or phone? Cloudflare's Friendly Bots program refuses to respond to open source projects, so why would Cloudflare as an implementer of WEI care about new start-ups or small open source software projects?
This is a level or two below where my knowledge of the browser trails off, so I'll ask generally: how would this interact with things like the WebKit Content Blocker API?
Step 1: Sites require a "secure" (read proprietary) browser like "Google Chrome", "Microsoft Edge", "Safari" or refuse to operate.
Step 2: "Secure" browsers change the behavior of their implementation of the Content Blocker API so an industry-accepted "secure" site lile Google Ads can opt-out of being blocked ("You wouldn't want a misconfigured content blocker to accidentally break a verified secure site right?")
Step 3: ???
(Force the users into a take it or leave it choice for whether they want to be part of the internet or not)
I don't understand how the Apple that introduced their Content Blocker APIs would choose to invest into this API to kneecap their own content blockers?
They wouldn't have to. Unless you use an iDevice you're not using an Apple made browser. (The content blocker API is WebKit so it's used across multiple browsers)
As for revenue from Apple users, they already want to have control over that and would be more than happy if Google and co voluntarily stopped serving their users so they can make ad money off of them on their own terms.
Most likely all extensions and content blockers would be disabled for DRMed sites. Or maybe they'd be enabled but the browser would tell the site you have a blocker enabled and the site would refuse to load.
Either Apple will make their devices refuse to sign the attestation if you're using it, or Google will remove Apple from its list of trusted attesters.
Or (most likely) they will negotiate how to split the money. Maybe through some kind of safe advertising consortium.
Apple is just fine with collecting user data on platforms so long as they're the only ones doing it. Apple even runs its own ad network over its own app store.
If you ask anyone who works in advertising they always say Apple has by far the "worst" targeting options. They display ads in the App Store but the data they use to track is usually not very great.
There's been some wishy claims maybe perhaps users-scripting & debugging will be left intact, that the intent here is about other levels.
But there's basically no real actual meat to this specification. It's abstract: it doesn't really say what Web Environment Integrity is, it's up to the browser to determine, and the rules could keep getting more and more and more specific at the browsers leisure.
What a weird dystopian world we find ourselves in. And, sadly, the despair in the comments reflecting utter defeat is very troubling. Times like this make me really miss the 90s, when the tech culture embraced open source and always found a way to outsmart the "googles" of that day. It is certainly a different time these days, however the game being played has always been the same. I wish people would completely re-envision the internet. Because, in reality, google has only captured one protocol. The web is much bigger than you all think. If you build it they will come sounds like a good philosophical statement to end this with.
Okay, the proposal is what it is but it doesn’t explain how the attestation is generated. So this would look into the underlying OS and decide if my computer is a real computer? And when it has doubts it displays some pictures and asks me which ones show bicycles?
This already exists on Android in the form of "SafetyNet", which apps can use to detect if they are running on a device that isn't "secure", like a device with a custom ROM or a rooted device
Can someone explain to me what's so fundamentally bad with this proposal?
My understanding is that websites can essentially confirm whether the user is likely to be a human because he/she accesses the website from a certified device.
Won't this mean there is less need for Captchas, logins and pay walls?
The doc also mentions that this will remove the need for some use-cases of fingerprinting.
I imagine from a user perspective this will be an improvement.
I could imagine governments getting behind this, there are a few proposed laws that require age verification, like the online safety bill in the UK. You could easily see them adding age verification on top of this proposal.
Would moving control of web standards under governmental control help? The FTC and similar government orgs can take ownership and enforce standards, labeling browsers commercial utility.
I don't care if the web is relevant if it's not the web anymore. Ruining a platform to keep it relevant isn't in my interest as a user.
If we shoot this down and every bank requires me to download a mobile app, then fine. What this is proposing is basically to turn websites into mobile apps: device controlled, unmodifiable, broken on any non-approved hardware. If that's going to be the case regardless, I'd rather just download the app, at least that would be more honest about what's actually going on, and at least I'd still be able to use my adblocker when I browse the web.
> That's already true of the web without this API. It doesn't change anything in regards to that.
I fully disagree, I don't see how anyone could credibly make this claim. The web is open and customizable and neutral in a way that native platforms are not. Part of that is full device and OS neutrality where customizations and forks of browser engines do not generally[0] signal untrustworthiness to website operators. And true neutrality for the OS and hardware and browser is incompatible with this kind of full-stack attestation.
[0]: with the exception of a few minor features like web video DRM, which... surprise. It's almost like DRM is bad for the web, and it's almost like all of the licensing and access guarantees given by Google and Microsoft were nonsense and didn't prevent web video DRM from being a giant problem.
----
> Please read the proposal. It has nothing to do with preventing adblocking or detecting people with adblockers.
I have read the proposal all the way through, and I fully disagree, regardless of the "we don't want to restrict things" asides the authors have added. It is impossible to give website operators tools that can prevent automated actions in a browser that can not also be used to prevent accessibility APIs. There is no way to guarantee to a website operator that they are in a "trusted" environment where their code is not being manipulated while still allowing an extension to manipulate that code. And adblockers are only one category of extension that would be hampered by those restrictions, but they would be hampered.
There is a zero percent chance that detecting bot traffic for advertisers will not turn into adblocking/automation restrictions over time, and for Google employees to say that this will not happen means nothing given Google's history around adblockers. We are far, far past the point where Google deserves the benefit of the doubt on this. Chromium devs have been spending that goodwill for years, and they've run out.
Chromium is already less effective at adblocking than Firefox is today, and Manifest V3 is still set to make adblocking worse -- despite employee claims that these efforts were not intended to harm adblockers. Surprise, adblockers still got harmed. And this is a trend; at this point it is not goodwill or good faith to assume that Chrome proposals are neutral towards adblocking, it is burying one's head in the sand.
This proposal has a clear end point and the most charitable thing I can say about the people behind it is that maybe they're not malicious, maybe they're just hopelessly naive. Maybe they're not trying to harm the web, maybe they've just never actually thought about the industry they're in or what the motivations are of the companies in that industry.
----
I'll add to this that "people just don't understand, please read the proposal" is not a new response to Google controversies. It gets pulled out literally every time that Google makes a controversial decision: FLOC, web audio, Manifest V3, Web DRM, the list goes on and on. It is deflection; a suggestion that people pointing out criticisms must just not be informed because otherwise they wouldn't have those criticisms. It's not that Google ever does anything bad, it's just bad at communicating or people are jumping to conclusions.
We're not jumping to conclusions, the first thing I did when learning about this was read through the entire proposal. We understand the proposal, the proposal is just bad.
>I don't see how anyone could credibly make this claim
>device controlled
A website is limited in what it can do by the browser it runs in.
>unmodifiable
Since responses are generated server side you can not modify what they send you.
>broken on nonaproved hardware
There are existing sites which don't support Linux or don't support mobile devices.
>true neutrality of OS and hardware is incompatible with attestation
Attestation doesn't mean that HTML now renders differently. The User Agent string already allows servers to block OSs.
>There is a zero percent chance that detecting bot traffic for advertisers will not turn into adblocking/automation restrictions over time
Sites can already detect adblocking without attestation. There is no evidence that the precense of an adblocker will be a signal to whether an environment is trustworthy. That is not the purpose of the API.
>given Google's history around adblockers
They have worked to support ad blocker extentions and they have provided a platform to ad blocker extentions. They have banned a malicous adblocker which also committed clickfraud. They have had some anti adblock experiments on YouTube such as limiting the resolution.
>We are far, far past the point where Google deserves the benefit of the doubt on this
I disagree.
>Chromium is already less effective at adblocking than Firefox is today
It works fine for me.
>Manifest V3 is still set to make adblocking worse
No, it won't. You just have to use a different API.
>despite employee claims that these efforts were not intended to harm adblockers
They care about improving the experience of the entire chrome user base. Getting rid of poorly designed APIs is a part of making Chrome better for everyone.
>We're not jumping to conclusions
Yes. You are. Google is trying to make the web more private and secure from the current state the web is in. Look at the reponse to FLOC. Despite increasing user's privacy many people forgot upset because they greedily want the web to cater to only them and not to people who rely on advertising. Similarly with Web DRM people panicked because they didn't want DRM because they only care about themselves and do not care about people who want their content to be protected. There is a theme where people get outraged because they don't understand that there are more people who use the web and have different needs than just them.
Giving people the option to protect their content or the option to use attestation as a signal doesn't prevent some idealized open web from existing. Sites that would like extra security can opt into it.
> Since responses are generated server side you can not modify what they send you.
You cannot modify what they send you, but you can and should modify the data received within your own computer, so that the program can receive and deal with modified data.
However, it ought to be possible to do so without needing to decrypt and encrypt it. The web browser should be able to use insecure proxies even for secure protocols so that you do not need to encrypt it twice (the communication with the server will still be encrypted).
Conflating serverside generated code to native app restrictions is nonsensical, they are not the same thing. Conflating device control to browser restrictions is also nonsensical given that the whole point of the web is that sites are browser neutral, and (again with exception of user-hostile features like DRM) browser forks are largely undetectable. Building a website that reliably blocks Linux is hard, borderline impossible. Even blocking scrapers is a losing battle, with a bit of work Headless Chromium is virtually undetectable (which of course it is, because if it was easy to detect headless browsers nobody would be arguing that "trusted" environments were necessary to stop scrapers and headless access). The user agent string is user controlled and I can easily set it to anything I'd like. A user agent string is not even remotely comparable to attestation. The web is not the way that HTML renders, the web is the platform, not just HTML.
> Sites can already detect adblocking without attestation. There is no evidence that the precense of an adblocker will be a signal to whether an environment is trustworthy. That is not the purpose of the API.
Sites can't reliably detect adblocking without lots of work, there's not an easy API for that. And there is a ton of evidence that attestation will be used for DRM and to prevent adblocking, look at native apps on mobile platforms that support attestation. Native apps like Netflix already refuse to run on rooted devices. Their reason for that is to lock down possible circumvention of the client or redirection of the video stream. It's a content decision made to block users from altering the client/content (ie, exactly what adblockers do).
Attestation for native applications has never been a rare thing that only banks used. And also, heck banks, banks don't need attestation. I should be able to load my banking app on a rooted Android device. Banks are not an excuse to take away that ability away from me.
What the "purpose" of the API is doesn't really matter. How it will be used matters. Device attestation is regularly abused on Android devices, there is no evidence that this will be different. But like I said, maybe the people proposing it don't have bad intentions, maybe they're just naive. Either way the outcome is going to be the same.
> No, it won't. You just have to use a different API.
uBlock Origin already objectively runs worse on Chrome than Firefox. Gorhill has stated numerous times that Manifest V3 will make this worse. Also I'm familiar with Manifest V3's API differences between Firefox/Chrome's implementation, and I agree with him, Chrome's Manifest V3 API is worse for adblockers.
This is denialism, Manifest V3 makes adblockers less effective.
> Look at the reponse to FLOC. Despite increasing user's privacy many people forgot upset because they greedily want the web to cater to only them and not to people who rely on advertising
And there it is, makes me feel like clarifying the above points was a waste of time. Objection to this is greedy because we've forgotten about the people who rely on advertising.
I mean, come on. You can't even consistently keep up the charade of arguing that this isn't about adblockers for two comments before accidentally slipping into arguments that the advertisers are the real victims. When you write that sentence, you have to on some level realize that it's not going to make people trust the proposal more.
> Similarly with Web DRM people panicked because they didn't want DRM because they only care about themselves and do not care about people who want their content to be protected.
This sentence is also just a great way to convince people you're sincere when you argue that a proposal isn't meant to lock down devices or introduce HTML-level DRM -- no notes. ;)
----
I will give you this: If for some inexplicable reason you've come out of Web DRM, and Manifest V3, and FLOC, and Topics, and Web Audio changes, and a lack of mobile extension support, and AMP, and First-Party Sets, and the Conversion Measurement API, and on and on -- and somehow you believe those proposals were all good and worked out great and nobody had anything to complain about, then I buy that you would probably also look at this proposal and wonder why people were getting worked up.
The issue is that I have no idea how on earth anyone paying attention to the direction of the web could come to the conclusion that those proposals didn't have problems. But if somehow you've magically been able to do that, then I understand why the pushback to this proposal probably seems weird to you.
>Conflating serverside generated code to native app restrictions is nonsensical, they are not the same thing
You did it first. Attestation has nothing to do with extentions.
>Building a website that reliably blocks Linux is hard, borderline impossible
With attestation doesn't reveal what OS you are using, so it owned still be impossible to reliably block Linux.
>And there is a ton of evidence that attestation will be used for DRM and to prevent adblocking
Please share it.
>It's a content decision made to block users from altering the client/content (ie, exactly what adblockers do).
The difference is that web browsers allow extentions, but the Netflix app doesn't.
>uBlock Origin already objectively runs worse on Chrome than Firefox
I use it just fine on Chrome and do not see any ads.
>Chrome's Manifest V3 API is worse for adblockers.
It has the same API for blocking ads. The API for blocking network requests is what changed.
>You can't even consistently keep up the charade of arguing that this isn't about adblockers for two comments before accidentally slipping into arguments that the advertisers are the real victims.
FLOC is about trying to get advertisers to stop invading people's privacy. You shouldn't be surprised that advertisers are a stakeholder when talking about FLOC. Advertisers are as important stakeholder in the web in general. In regards to attestation there are more stakeholders than just users and advertisers since security is important to almost any type of service on the internet.
>I have no idea how on earth anyone paying attention to the direction of the web could come to the conclusion that those proposals didn't have problems
The direction is not going away from web extentions and I don't see anything going after adblock extentions.
>Conflating serverside generated code to native app restrictions is nonsensical, they are not the same thing > You did it first. Attestation has nothing to do with extentions.
First of all, extensions are not serverside code, so... no, that doesn't make any sense. Second of all, attestation has a lot to do with extensions because extensions are based on browser functionality, and attestation impacts which software you can run. In this case, attestation means websites can check to see if you're running modified or forked browsers that might allow for broader extension APIs.
And attestation has even more to do with extensions when extended to websites than it normally would because if the point of this is to established "trusted" environments, then arbitrary extension access to a web page means the environment is not trusted. If you allow arbitrary extension access, you can't provide guarantees about whether someone is human or not -- extension APIs allow for automation and scraping and ad fraud. And blocking that behavior is explicitly one of the use-cases listed in this proposal for the integrity API.
If this doesn't block extensions, then it's not a useful proposal for blocking bots. Quite literally every single use-case that this proposal lists are impossible if extensions are not restricted. Blocking ad fraud, blocking bots, blocking malware from a banking site, and blocking cheating in web games -- all of that requires blocking extensions. A "trusted environment" the way the proposal describes it can not have arbitrary extension access because extensions can do all of that stuff; from posting automated content to fraudulently clicking on ads to cheating at online games to stealing your bank password.
> With attestation doesn't reveal what OS you are using, so it owned still be impossible to reliably block Linux.
Do you genuinely think that an Open Linux environment is going to support attestation? We're having a hard enough time getting Passkey to support Linux, there is zero chance that Arch Linux becomes a trusted attestation provider for the Web Environment Integrity API.
And if it did, this whole proposal would be useless, because I'd be able to use Headless Chromium on Arch Linux and just have Arch Linux say that my computing environment was secure. There is no definition of "trusted computing environment" for a website provider that doesn't involve blocking access to arbitrary user-controlled code execution at the OS and browser level.
Because if you couldn't block that access, you wouldn't have any security guarantees. The entire premise falls apart if fully user-controlled environments are supported. It would be a useless proposal.
> And there is a ton of evidence that attestation will be used for DRM and to prevent adblocking > Please share it.
> FLOC is [another long explanation of why advertisers are the victim and FLOC is actually making the web more private]
I have to say again, I don't know if you expect this to sway anyone reading these comments, but it's not going to. No one is going to read that paragraph and think, "you know what, this person probably does care about adblockers and probably is really committed to making sure they're not harmed."
>attestation means websites can check to see if you're running modified or forked browsers that might allow for broader extension APIs.
It does not tell you what browser the user is using. Websites can not block a specific browser.
>Blocking ad fraud, blocking bots, blocking malware from a banking site, and blocking cheating in web games -- all of that requires blocking extensions
How does this affect browser modifications and extensions?
Web Environment Integrity attests the legitimacy of the underlying hardware and software stack, it does not restrict the indicated application’s functionality: E.g. if the browser allows extensions, the user may use extensions; if a browser is modified, the modified browser can still request Web Environment Integrity attestation.
It's about reducing the rate of those things.
>Do you genuinely think that an Open Linux environment is going to support attestation?
When Linux distributions start to actually care about security yes I do see plenty.
>Play Integrity
Play Integrity covers both attesting to if the system is in a secure state and if the app you are running is from the play store. This proposal only has an equivalent for the former.
>this is also not very difficult to look up
Chrome has worked on CNAME stuff since that was written and most of it does not really matter to most people.
>another long explanation of why advertisers are the victim and FLOC is actually making the web more private
Advertisers aren't the victim in this situation. It's the users who are losing privacy due to cross site tracking.
> It does not tell you what browser the user is using. Websites can not block a specific browser.
This is unbelievably silly. It's like saying that Play Integrity doesn't tell you if the user is running LineageOS, so it doesn't mean that apps can block LineageOS. This is not a serious argument.
> It's about reducing the rate of those things.
Again, this is incredibly silly. There is zero evidence this will reduce the rate of those things. Extensions are very likely the most common vector for this.
And if you genuinely can't see a clear path in this proposal where website operators will say, "we can block Headless Chromium, but people are still getting their bank passwords stolen by malicious extensions, lock the extensions down too" -- then, I don't know, it must be nice to be able to somehow trust corporations that much despite the entire history of how advertisers and corporations have interacted with the web standards process.
Regardless, blocking Headless Chromium on its own is a restriction of user autonomy and a restriction of user freedom. That is still blocking me from using a specific browser. And if your argument is that scriptable browsers aren't going to be blocked, then this entire proposal is a waste of time. This proposal will affect extensions for obvious reasons, but even if it didn't it would still be a problem.
> When Linux distributions start to actually care about security yes I do see plenty.
:) Come on. Linux security is not the reason it would be blocked in these situations, user agency to run headless browsers like Headless Chromium is the reason it would be blocked.
You're trying to shift this conversation to be about security, but security is only one of four use-cases proposed, and three of them are about preventing the user from doing actions that the website owner considers harmful. This is not primarily a security proposal, it is a proposal about blocking off user capabilities that website authors would rather the user not have.
That is the reason why attestation won't be coming to Linux: because Arch Linux won't lock me out of my own system and prevent me from running software that I choose.
Of course, it does not escape my notice that you haven't provided an argument for why Linux won't be blocked, you've provided an excuse for why Linux should be blocked. What you're telling me is "yes, your device won't support attestation and you won't be able to use your bank website on that device, but that's Linux's fault. And maybe eventually Linux will support attestation in the future."
Okay, it's nice to know I'll only be locked out using the OS I prefer for an ambiguous amount of time until it caves and meets an unspecified standard of security at some unspecified point in the future. But I'm still going to be blocked from Linux. And you've moved from "this doesn't block an OS" to "it does block an OS and that's actually a good thing to do."
> Play Integrity covers both attesting to if the system is in a secure state and if the app you are running is from the play store. This proposal only has an equivalent for the former.
Luckily the former is the part I care about and is the primary part that is abused. Rooting an Android device is the part we're talking about and the part this has implications for. You started out this conversation by asking me to read the proposal. Let me extend the same request to you: please do some research on this.
Also, please don't make claims that aren't substantiated about how attestation will work. This proposal does not specify that attestation on Android wouldn't use the Play Integrity API. It is extremely likely that Google would use the same underlying system and that Android would refuse to provide attestation for apps that aren't from the Play Store.
Nothing in this proposal preempts them from doing that, there is no reason to trust you when you say that sideloaded apps will be able to pass attestation. The proposal specifically does not lay out what attestation requirements will be.
> Chrome has worked on CNAME stuff since that was written and most of it does not really matter to most people.
"Chrome works on CNAME stuff": where? The API isn't supported, what are you talking about :)
And if a nearly 20% reduction in adblocking capability doesn't matter to you, great! But don't pretend that it doesn't exist. Chrome objectively has a worse adblocking experience than Firefox. Manifest V3 will make that experience worse.
Maybe you don't care about that, which is fine for you, but "this won't affect adblocking" and "meh, what adblocking you'll have will be good enough, stop caring so much about adblocking" are very different arguments.
> It's the users who are losing privacy due to cross site tracking.
FLOC would not have stopped cross site tracking or improved user privacy. None of the proposals Google made about restricting cross site tracking needed FLOC (Firefox and Safari were able to block cross site cookies just fine without FLOC).
In addition, it's not really even accurate to say that Google is clamping down on cross site tracking; in fact First Party Sets exposes mechanisms to treat cross site cookies as if they are first party.
Chrome was last to the table on blocking common cross site tracking techniques, specifically because they refused to implement industry wide defenses until they had another user targeting solution implemented. Chrome very literally delayed user privacy improvements until they could make sure that advertisers were taken care of. They were the last browser to add those improvements because they were worried about advertisers more than users. And they immediately proposed specification changes that weakened the user protections that other browsers had already launched.
>It's like saying that Play Integrity doesn't tell you if the user is running LineageOS, so it doesn't mean that apps can block LineageOS. This is not a serious argument.
But, it's true. Since LineageOS doesn't break Android's security model they could work with phone manufacters / Google to allow LineageOS to be trusted. Then apps would not be able to tell via play integrity that it could be lineageos since it looks like any other trusted device.
>There is zero evidence this will reduce the rate of those things.
I think this is fair criticism of the proposal. If it's not effective in practice then sites won't invest time in using it since it's a pointless API.
>Regardless, blocking Headless Chromium on its own is a restriction of user autonomy and a restriction of user freedom.
This API is not about blocking headless chromium.
>but people are still getting their bank passwords stolen by malicious extensions, lock the extensions down too
Protecting against that is unrelated to this proposal.
>:) Come on. Linux security is not the reason it would be blocked in these situations
Considering most Linux users are 1 curl | bash away from installing malware that can easily pivot to root and install a kernel module to hide itself. It's related.
>and three of them are about preventing the user from doing actions that the website owner considers harmful.
Can you quote that section. I don't see it.
>it is a proposal about blocking off user capabilities that website authors would rather the user not have.
Except this proposal doesn't block any user capabilities. It simply adds a way for sites to check if the user has a secure environment.
>That is the reason why attestation won't be coming to Linux: because Arch Linux won't lock me out of my own system and prevent me from running software that I choose.
Arch could simply have in their settings app a toggle that allows you to disable trusted mode to allow you to install kernels or whatever you built yourself. Similar to how motherboards let you disable secure boot.
>it does not escape my notice that you haven't provided an argument for why Linux won't be blocked
Firstly, this proposal isn't about blocking people. Secondly, their will be many Android bsed Linux distros that will be considered secure. For the Debians and Archs of the world they will need to work with others and prove they can provide a trusted environment. I believe this is possible and I think something similar happened in relation to secureboot.
>"it does block an OS and that's actually a good thing to do."
I never said that it was a good thing to do.
>Rooting an Android device is the part we're talking about and the part this has implications for.
Rooting breaks the android security model and provides by definition an untrusted environment. Android apps may not want to deal with supporting devices that don't support the security features an Android operating system is supposed to provide.
>It is extremely likely that Google would use the same underlying system and that Android would refuse to provide attestation for apps that aren't from the Play Store.
The Play Integrity API works with apps not from the store.
>
danShumway 26 minutes ago | parent | context | flag | on: Web Environment Integrity API Proposal
> It does not tell you what browser the user is using. Websites can not block a specific browser.
This is unbelievably silly. It's like saying that Play Integrity doesn't tell you if the user is running LineageOS, so it doesn't mean that apps can block LineageOS. This is not a serious argument.
> It's about reducing the rate of those things.
Again, this is incredibly silly. There is zero evidence this will reduce the rate of those things. Extensions are very likely the most common vector for this.
And if you genuinely can't see a clear path in this proposal where website operators will say, "we can block Headless Chromium, but people are still getting their bank passwords stolen by malicious extensions, lock the extensions down too" -- then, I don't know, it must be nice to be able to somehow trust corporations that much despite the entire history of how advertisers and corporations have interacted with the web standards process.
Regardless, blocking Headless Chromium on its own is a restriction of user autonomy and a restriction of user freedom. That is still blocking me from using a specific browser. And if your argument is that scriptable browsers aren't going to be blocked, then this entire proposal is a waste of time.
This proposal will affect extensions for obvious reasons, but even if it didn't it would still be a problem.
> When Linux distributions start to actually care about security yes I do see plenty.
:) Come on. Linux security is not the reason it would be blocked in these situations, user agency to run headless browsers like Headless Chromium is the reason it would be blocked.
You're trying to shift this conversation to be about security, but security is only one of four use-cases proposed, and three of them are about preventing the user from doing actions that the website owner considers harmful. This is not primarily a security proposal, it is a proposal about blocking off user capabilities that website authors would rather the user not have.
That is the reason why attestation won't be coming to Linux: because Arch Linux won't lock me out of my own system and prevent me from running software that I choose.
Of course, it does not escape my notice that you haven't provided an argument for why Linux won't be blocked, you've provided an excuse for why Linux should be blocked. What you're telling me is "yes, your device won't support attestation and you won't be able to use your bank website on that device, but that's Linux's fault. And maybe eventually Linux will support attestation in the future."
Okay, it's nice to know I'll only be locked out using the OS I prefer for an ambiguous amount of time until it caves and meets an unspecified standard of security at some unspecified point in the future. But I'm still going to be blocked from Linux. And you've moved from "this doesn't block an OS" to "it does block an OS and that's actually a good thing to do."
> Play Integrity covers both attesting to if the system is in a secure state and if the app you are running is from the play store. This proposal only has an equivalent for the former.
Luckily the former is the part I care about and is the primary part that is abused. Rooting an Android device is the part we're talking about and the part this has implications for. You started out this conversation by asking me to read the proposal. Let me extend the same request to you: please do some research on this.
Also, please don't make claims that aren't substantiated about how attestation will work. This proposal does not specify that attestation on Android wouldn't use the Play Integrity API. It is extremely likely that Google would use the same underlying system and that Android would refuse to provide attestation for apps that aren't from the Play Store.
Nothing in this proposal preempts them from doing that, there is no reason to trust you when you say that sideloaded apps will be able to pass attestation. The proposal specifically does not lay out what attestation requirements will be.
> Chrome has worked on CNAME stuff since that was written and most of it does not really matter to most people.
Chrome now handles CNAME aliases internally: https://bugs.chromium.org/p/chromium/issues/detail?id=1151047.
We also now plan to support this for extensions as part of declarativeNetRequest API.
The linked issue shows CNAME support being added to at least Chrome's built in adblocker.
>FLOC would not have stopped cross site tracking or improved user privacy
Yes, but the plan was that after FLOC cross site cookies would not be sent. The whole point is to provide an alternative to people using cross site cookies before it gets removed.
I apologize for an off-topic request, but if it's not past the edit window could you go over your comment and clean up the references/formatting? I think you may have had some errors copying and pasting quotes from my comment to reply and may have pasted more of my comment than you intended; this is very difficult to follow.
---
> But, it's true. Since LineageOS doesn't break Android's security model they could work with phone manufacters / Google to allow LineageOS to be trusted.
There is no evidence that Google would do this. And you're talking about a hypothetical; the fact is that LineageOS is currently blocked. That is what is factually true right now. Saying that it could theoretically be trusted in the future doesn't mean that the Integrity API doesn't block it today.
It doesn't mean that attestation won't block OSes right now. You can't deny that currently the Play Integrity API blocks Android ROMs.
> This API is not about blocking headless chromium. [...] Protecting against that [(password theft)] is unrelated to this proposal.
So first off, this is opinion you, there is nothing in the proposal that indicates that scriptable browsers would be allowed and nothing that references Headless Chromium. You are assuming that Headless Chromium wouldn't be blocked, but I would love to see any statement from Google supporting that assumption.
But more importantly, you're basically saying this proposal blocks nothing at all. Think about what you're saying, this is a proposal that supposedly prevents bots and ad fraud and you're going to allow Headless Chromium? You're like one comment away from telling me, "well, the proposal isn't about guaranteeing OS integrity."
> Considering most Linux users are 1 curl | bash away from installing malware that can easily pivot to root and install a kernel module to hide itself. It's related.
No, this is very transparently an excuse. Out of the reasons for this proposal (as specified in the proposal), kernel level malware is relevant to basically zero of them. Kernel level malware is not the reason why Netflix doesn't run on a rooted Android device. Kernel level malware is not something that matters for blocking web scrapers or bots. Kernel level malware is not the vector through which ad fraud happens. Quite frankly, kernel level malware is not the biggest concern when thinking about bank account theft of phishing attacks.
The reason Linux is blocked is because Linux does not impose computing restrictions on the user.
> [...] This creates a need for human users to prove to websites that they're human, sometimes through tasks like challenges or logins. [...] Websites can only show users what content is popular with real people if websites are able to know the difference between a trusted and untrusted environment. [...] Users playing a game on a website want to know whether other players are using software that enforces the game's rules. [...] Users sometimes get tricked into installing malicious software that imitates software like their banking apps, to steal from those users.
Of those 4 proposals, only the last one (banking security) is directly related to user security, the other 3 are site policies (ad fraud/scraping, blocking bots, blocking game modifications).
> Except this proposal doesn't block any user capabilities. It simply adds a way for sites to check if the user has a secure environment.
This is borderline disingenuous. Giving website authors the ability to arbitrarily block "untrusted" environments (and specifically telling them that the purpose is to allow blocking capabilities in untrusted environments) is the same as blocking user capabilities.
It's especially absurd to deny given that mainline companies like Google will be in charge of determining what environments count as "secure" and what environments will be supported for attestation, so not only is it an API that is designed to allow websites to block clients, it is also very much going to be Google's decision whether or not a given user capability is compatible with a "trusted" environment.
----
> Arch could simply have in their settings app a toggle that allows you to disable trusted mode to allow you to install kernels or whatever you built yourself. Similar to how motherboards let you disable secure boot.
At which point it would be blocked from attestation, hence blocking user freedoms.
Also, custom-built kernels and custom user software are not side-things I can toggle on and off, my setup depends on those things. You can't go into user settings from the desktop in Arch and just turn off the kernel; if I'm using custom drivers for a monitor or input device, I can't just turn those off.
What you are saying is "your OS won't be blocked, you'll just boot into a different OS or different OS-mode without any of your custom kernels or drivers." But take a step back and think about that: the OS is blocked. And the solution you're giving me is to boot into a different OS based on a different kernel that I don't control that doesn't have my custom-compiled drivers and that might not even support my hardware. This is really silly, it's like saying that Apple Pay is fully supported on Android, you just have to boot into an iPhone.
> Rooting breaks the android security model and provides by definition an untrusted environment. Android apps may not want to deal with supporting devices that don't support the security features an Android operating system is supposed to provide.
Like I said, this is about blocking my ability to root my device. It is a reduction in user autonomy under the excuse that user autonomy to root my device makes my device untrusted.
Quite frankly, it should not be an app's choice to decide whether or not to run on a rooted device. It's none of their business whether or not my phone is rooted.
> The Play Integrity API works with apps not from the store.
Technically true in the sense that I believe Aurora spoofs Play Integrity APIs and device checks, but I'm not sure of the full details there, and in any case that's a circumvention of Google's policies, not something that Google explicitly allows. I'm not sure I understand what you mean here?
The currently inactive issue that hasn't been updated for over a year? That's not exactly strong evidence. Let me know when the Chromium team starts working on it and merges it.
In the meantime, it is objectively true that Chrome currently has worse adblocking capabilities (particularly around CNAME cloaking) than Firefox and that it has had worse adblocking capabilities for multiple years. This is not an API that is available for extensions to use.
And the way that CNAME cloaking has played out in Chrome -- given that they are trailing behind other browsers by years does not suggest that any of the other issues with Manifest V3 are going to be better handled. The overwhelming trend here (and what this issue shows) is that Chrome is going to lag behind other browsers on adblocking.
I'm having a hard time figuring out how you're looking at an arguably orphaned issue and seeing that as evidence that the Chromium team cares about adblocking APIs or that they can be trusted to make sure that adblocking capabilities aren't broken.
> Yes, but the plan was that after FLOC cross site cookies would not be sent. The whole point is to provide an alternative to people using cross site cookies before it gets removed.
Right, that's what I said. It was for advertisers, not for users.
Firefox and Safari removed cross site cookies without supplying an alternative just fine, that was a user-focused change. Chrome refused to make a user-focused change until after it introduced a spec (FLOC, later Topics) purely for the benefit of advertisers. In addition, it introduced other specs (Same Site Sets) that weakened those same protections.
>but if it's not past the edit window could you go over your comment and clean up the references/formatting?
Sorry, it's past the window.
>There is no evidence that Google would do this.
There are many OEMs who have gotten their OS approved for it. LineageOS could go through the same process like everyone else to get it approved.
>the fact is that LineageOS is currently blocked. That is what is factually true right now.
That is true, and hopefully things like this proposal will incentivize LineageOS to pursue getting their OS approved.
>So first off, this is opinion you
The current proposal is focused on the OS you are using and not on blocking certain browsers. There is a section "Attester-level acceptable browser policy" saying that if there is demand that could change. Technically with the current proposal an attester could be designed to be more strict in what they will attest to. There could an attestor a website could trust that just enforces OS security and different one which is restricted to some subset of browsers.
>But more importantly, you're basically saying this proposal blocks nothing at all.
The proposal is ambiguous on what is considered a secured environment, but it seems that they are mostly concerned about OS security. Even if it does not perfectly blocks thing it could still be useful. Imagine if there was a way to check if a user has antivirus installed and has ran a recent scan. This signal would be correlated with users who have malware installed.
>Think about what you're saying, this is a proposal that supposedly prevents bots and ad fraud and you're going to allow Headless Chromium?
The proposal does not say that it prevents those things. It says that it can help with preventing those things.
>Kernel level malware is not the reason why Netflix doesn't run on a rooted Android device.
Correct. It is likely more motivated in that rooted Android devices do not adhere to the android security model and not secure to show L3 content on.
>Kernel level malware is not something that matters for blocking web scrapers or bots.
It does matter. BOTH kernel level and user level malware can scrape websites and act as bots.
>Quite frankly, kernel level malware is not the biggest concern when thinking about bank account theft of phishing attacks.
Then a future proposal can try and address the bigger concerns.
>The reason Linux is blocked is because Linux does not impose computing restrictions on the user.
It is clear that Android, which is built upon Linux, will have support for attestation. And again there is no blocking going on. Blocking users is not the goal of the proposal.
>Of those 4 proposals, only the last one (banking security) is directly related to user security, the other 3 are site policies (ad fraud/scraping, blocking bots, blocking game modifications).
Malware on a user's machine can do the last 3.
>This is borderline disingenuous. Giving website authors the ability to arbitrarily block "untrusted" environments (and specifically telling them that the purpose is to allow blocking capabilities in untrusted environments) is the same as blocking user capabilities.
Be upset at sites that do that then.
>It's especially absurd to deny given that mainline companies like Google will be in charge of determining what environments count as "secure" and what environments will be supported for attestation, so not only is it an API that is designed to allow websites to block clients, it is also very much going to be Google's decision whether or not a given user capability is compatible with a "trusted" environment.
Anyone can become an attester.
>Also, custom-built kernels and custom user software are not side-things I can toggle on and off, my setup depends on those things. You can't go into user settings from the desktop in Arch and just turn off the kernel; if I'm using custom drivers for a monitor or input device, I can't just turn those off.
In that case I would recommend you to have Arch sign those drivers.
>What you are saying is "your OS won't be blocked, you'll just boot into a different OS or different OS-mode without any of your custom kernels or drivers.
You wouldn't have to boot into a different OS. The current state of the web is what you would experience. People using a secure environment will have benefits like seeing less captchas.
>Like I said, this is about blocking my ability to root my device
Attestation has nothing to do with preventing people from rooting their device. You still have the same autonomy to root your device.
>Quite frankly, it should not be an app's choice to decide whether or not to run on a rooted device. It's none of their business whether or not my phone is rooted.
Considering rooted devices might negatively impact their business it is their business. Apps were checking for root before attestation existed. If your device is rooted you are able to remove any checks to the app itself that are blocking you from using it on a rooted device.
>Technically true in the sense that I believe Aurora spoofs Play Integrity APIs and device checks, but I'm not sure of the full details there, and in any case that's a circumvention of Google's policies, not something that Google explicitly allows. I'm not sure I understand what you mean here?
I am not talking about spoofing. For example ReVanced is a modded YouTube app that is not in the play store. If you use ReVanced and google attempted attestation they would be able to see that your device is secure, but see that the APK is not from the play store.
>I'm having a hard time figuring out how you're looking at an arguably orphaned issue and seeing that as evidence that the Chromium team cares about adblocking APIs or that they can be trusted to make sure that adblocking capabilities aren't broken.
Priorities change, but you can clearly see that it was being worked on and it did get to the point where it works for Chrome's adblocker. Since chromium is open source anyone could go ahead and finish the implementation, but it doesn't seem like many people see it as a high priority compared to other things which could be worked on.
>Firefox and Safari removed cross site cookies without supplying an alternative just fine
They have less market share so they do not have to be as responsible with changes they make. Google on the other hand could kill many businesses, break people's sites, and cause a large amount of harm if they make big changes like that without finding someway to let people transition to a suitable alternative.
>In addition, it introduced other specs (Same Site Sets) that weakened those same protections.
Chrome doesn't want to break people's sites. People have invested a lot of money in building sites and it is not trivial to just rearchitect them to work.
> That is true, and hopefully things like this proposal will incentivize LineageOS to pursue getting their OS approved.
If Google is in charge of deciding which OSes get approved, then this is about blocking OSes. I'm sorry. You can not in one breath argue that this isn't about blocking anyone and in the next breath argue that everyone needs to get their OS approved by Google.
> The current proposal is focused on the OS you are using and not on blocking certain browsers.
The current proposal does not describe attestation requirements, you're reading into this document something that is never specified. In fact, the current proposal explicitly calls out browser blocking as a possibility and calls that an unsolved problem: "Attesters will be required to offer their service under the same conditions to any browser who wishes to use it and meets certain baseline requirements. This leads to any browser running on the given OS platform having the same access to the technology, but we still have the risks that 1) some websites might exclude some operating systems, and 2) if the platform identity of the application that requested the attestation is included, some websites might exclude some browsers."
The proposal does not offer a concrete plan for preventing either scenario, it throws out a few ideas and then says, "we'll have to see." The proposal also does not at any point state that browsers will not be blocked. It states that any browser that "meets requirements" should be allowed. It does not specify what those requirements are, and there's no evidence offered in the document that a browser like Headless Chromium would qualify for them.
> And again there is no blocking going on.
We keep dancing around this, it's false. It's false given even the assumptions you've brought up. You yourself admit that OSes would be blocked. There is no reason to give a signal to a website about whether an environment is trusted other than to aid with blocking. Even the most charitable interpretation of this spec involves blocking. Every single risk listed in the spec involves blocking.
Please stop saying that this isn't about blocking, attestation as a concept is about blocking based on tampering signals.
> Imagine if there was a way to check if a user has antivirus installed and has ran a recent scan. This signal would be correlated with users who have malware installed.
I'm sorry, you think this is would be a good thing? You think that giving a website the ability to deny access if I don't have a trusted antivirus installed is in any way appropriate for the Open web?
> Malware on a user's machine can do the last 3.
I don't know if you're deliberately being obtuse about this, but very obviously malware is not what anyone is thinking about when they talk about cheating in video games or blocking bots from social websites.
> Be upset at sites that do that then.
Or, be upset at the people who give them the capability and encourage them to do so.
> Anyone can become an attester.
The proposal in fact says the opposite, that there will be a small number attesters and they'll be vetted by browsers.
> In that case I would recommend you to have Arch sign those drivers.
No. It's not Google's business if the drivers are signed. It's not my browser's business if those drivers are signed. It is none of their business what OS they're running on or what drivers are loaded.
> Attestation has nothing to do with preventing people from rooting their device. You still have the same autonomy to root your device.
I'm not sure what to respond to this with other than that it's obviously incorrect. Attestation in fact both can be used to directly prevent rooting and can be used to indirectly prevent rooting by shutting down services on rooted devices. Like... I don't know what argument to give you if you don't see a causal relationship between the two. Attestation is about blocking services and imposing consequences on modified devices, including rooted devices.
> You wouldn't have to boot into a different OS. The current state of the web is what you would experience. People using a secure environment will have benefits like seeing less captchas.
You're just kinda saying things. There is nothing in the proposal that indicates this. Attestation has never worked this way in any context.
> If your device is rooted you are able to remove any checks to the app itself that are blocking you from using it on a rooted device.
Oh my goodness, this is on a technical level just not how modern attestation works. It's designed to be incredibly difficult to circumvent, and hardware-level attestation makes that even more difficult. You can't just remove the checks, you need to be able to generate a signed attestation key. Please look up how TPMs work.
> Priorities change, but you can clearly see that it was being worked on and it did get to the point where it works for Chrome's adblocker.
No, the opposite. This is unreleased. It never got to the point where it works for Chrome's adblocker. It didn't get to any point. It got triaged a year ago and there's been zero activity on it since; CNAME uncloaking for extensions does not exist in Chrome. And to argue that the Chromium team cares about adblocking in one sentence and to say that it's everyone else's job to implement fixes is utterly absurd.
The reality is that Chrome has worse adblocking than Firefox and that they are lagging behind on extension features. There is no reason to believe that will change in the near future.
----
I'm just going to kind of group some stuff together here:
> Considering rooted devices might negatively impact their business it is their business. [...] Google on the other hand could kill many businesses, break people's sites, and cause a large amount of harm if they make big changes like that without finding someway to let people transition to a suitable alternative. [...] Imagine if there was a way to check if a user has antivirus installed and has ran a recent scan. [...] [etc]
This conversation started out as "nobody is trying to restrict anything" and whenever I actually poke at the edges of that, I find you offering excuses for why certain OS setups should be restricted. People should "just" get all of their custom drivers signed. If LineageOS isn't an authorized ROM, that's their fault, not Google's.
Your reply here is littered with technical misinformation and with assertions about how this will play out that seem to be based entirely on hopes and dreams rather than any technical mitigations or policies. But the bigger issue is that underneath all of it, you are trying to convince me that Google is not trying to limit device autonomy -- and the truth is, you do not support device autonomy in the way that Google's critics do.
It is bad for a custom ROM to have to get Google's permission to get signed or treated as a trusted app environment. That should not be Google's choice to make. It is bad for websites to have insight into whether or not an OS has a virus scanner installed. It is bad to require Open Source drivers to go through a validation process with Chrome. It is bad to punish users with rooted devices by throwing additional captchas at them. These are outcomes that are bad for user agency, user freedom, and user autonomy. And they will lead to worse outcomes including degraded adblocking performance and less user agency over devices.
Now, you're trying to convince me that they won't. But the underlying issue here is, once again, you disagree with me about what degraded adblocking performance even looks like. In your mind, it's not Google's responsibility to fix those problems, it's an Open Source project and someone else should do it for them. In your mind, blocking 20% fewer ads than another a browser is no big deal, it's not worth complaining about. And you can't get through one of your replies without going to bat for advertisers, basically saying that it would be irresponsible for Google to make user-privacy improvements in Chrome without thinking about the impact on advertisers.
The big issue here is not that we disagree about what the policy says (although we clearly do). What I'm seeing in your reply is that "critics are overreacting" on some level means "the user-freedom, privacy, and autonomy requests that they have are unreasonable."
So no, I don't trust Google's motivations and you probably can't convince me otherwise, because looking at the things you keep saying in these comments -- your list of acceptable outcomes from this policy are different from my list of acceptable outcomes. What you view as user abuse is different from what I and many Google critics view as user abuse. And it is not overreaction or ignorance or fearmongering that causes Google critics to advocate against this change. It's that critics have a different value system about user autonomy than you do.
Why aren't banking sites gone already? Because users expect to be able to use their desktop to do their banking. But if they can simply require you to use Chrome, suddenly you can get both birds with one stone! This is a bad thing for the web.
Banks are going to use this because some pointy headed boss reads an article in CIO Weekly or whatever talking about remote attestation and orders their IT team to implement it. It will not actually cut down on fraud but it will cut down on freedom. The only approach that enhances freedom is that banks, or any other internet sites, must simply not have the option to perform remote attestation outside of limited contexts like IT computers.
When P(fraud|request from browser) increases and P(fraud|request from mobile app) decreases and P(customer has mobile device) approaches 1 it starts making less and less sense to support running a web interface.
It looks very similar to the “secure boot” mechanisms in Windows and other commercial client OS.
Strikes me as very dangerous though on the web where there are so many paths for malware to get in and this could get in the way of plugging the holes.
No, it's similar to attestation APIs like android SafetyNet (now called Play Integrity API) that are used to check that "your ROM is valid according to Google".
Secure boot can protect you eg. against malware gaining write access and modifying your system. I see it as user protection, as long as you can sign the trust chain. This is what GrapheneOS is doing as far as I know.
A trust chain beginning at the bootloader is what will ultimately enable this API, though, because that's what SafetyNet/Play Integrity API relies on. If you don't have a locked bootloader, or you're not running stock Android, you won't pass SafetyNet/Play Integrity (at least the higher tiers of it).
It was also dangerous for your PC: as soon as people ceded the ability to led their parties control what we run on our devices--such as by "only firmware signed by Apple can run on my phone"--we lost this war.
> It was also dangerous for your PC: as soon as people ceded the ability to led their parties control what we run on our devices--such as by "only firmware signed by Apple can run on my phone"--we lost this war.
If that's how "we lost this war", then it was lost before it even started. Even before Apple released their phones, it was already the case that phone firmware came only from the phone manufacturer. That is: phones come from a different lineage than PCs, and were never as open as general purpose computers ended up being.
I mean, those were by and large fixed function devices and while phone calls are certainly a form of communication they aren't really networked devices. And... while it was technically possible to update the software on them, most people never did.
There were only a scant handful of years where there even existed phones where this could matter... but now this same mentality is being applied to every new category of device--all of which acting as general computing devices--based on these precedents.
Sure you can fake the results of an attestation in your fork, but your fork would be using your own key to sign the response, a key that the site can reject.
Has that been extracted already? I have to admit I'm behind on the current state of browser DRM...
Also I wonder if in the future this would require attestation of the entire chain: secure UEFI validated by key burned in CPU, validates secure boot os that prevents "hacking tools", which validates secure Chrome, which attests secure websites...
The current state of DRM is that you have to find a hardware vulnerability in order to extract a certificate. With this you can now decrypt DRM content, but you have to be careful not to get that key blacklisted.
I don't believe any of the HD widevine keys have been revealed.
I would practically guess the keys that did get revealed were deliberately leaked, low stake keys, that keep people still willing use to use widevine platforms at low res without being angry.
the TPM does the attestation of the entire running environment, starting with firmware, through the OS, through the browser all the way down to the website
The result: there is now effectively one dominating web browser run by an ad company who nigh unto controls the spec for the web itself and who is finally putting its foot down to decide that we are all going to be forced to either used fully-locked down devices or to prove that we are using some locked-down component of our otherwise unlocked device to see anyone's content, and they get to frame it as fighting for the user in the spec draft as users have a "need" to prove their authenticity to websites to get their free stuff.
(BTW, Brave is in the same boat: they are also an ad company--despite building ad blocking stuff themselves--and their product managers routinely discuss and even quote Brendan Eich talking about this same kind of "run the browser inside of trusted computing" as their long-term solution for preventing people blocking their ads. The vicious irony: the very tech they want to use to protect them is what will be used to protect the status quo from them! The entire premise of monetizing with ads is eventually either self-defeating or the problem itself.)