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.
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.)
"Sorry, you can only access this website using this specific device with a browser compiled by Big Tech, it's for your own good."
Not surprising that this is all coming from Google, the world's biggest adtech company.
They don't even try to masquerade it.
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.
[0]: https://github.com/RupertBenWiser [1]: https://github.com/RupertBenWiser/Web-Environment-Integrity/... [2]: >>26344013
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.
> An owner of this repository has limited the ability to comment to users that have contributed to this repository in the past.
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.
[0]: https://www.eff.org/press/releases/eff-makes-formal-objectio... [1]: https://github.com/w3c/encrypted-media
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.
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.
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.
> 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.
Giving more control to corporations and less control to individuals.
Heh. I was there when it was IE6, and people said the same.
WebAssembly exists as a replacement now, too.
But in this case it could report "sure, this is a real user alright" by being its own attester, can't it?
DRM isn't going away.
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.
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)
Step 4: Profit
I’d have a field day grilling the CEOs of Big Tech companies over stuff like this that only serves to kneecap their current and future competitors.
In fact, their first example (!) outlines how this would be appealing to advertisers because they can attest a real human is viewing the content.
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.
[0] https://github.com/RupertBenWiser/Web-Environment-Integrity/...
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.
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.
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."
It's honestly comical and a little sad.
[1]: http://benwiser.com/blog/I-just-spent-%C2%A3700-to-have-my-o...
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.
But it still happened, against M$, who was the behemoth of the time, so things are never impossible.
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.
It can be reconciled with love for money and total lack of moral fiber.
Aka « I don’t give a shit about my actions destroying every one, as long as I go get paid »
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...
"Google to explore alternatives to robots.txt".
[1] https://blog.google/technology/ai/ai-web-publisher-controls-...
[2] >>36641607
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?
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)
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 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.
Yeah, not for long. Go back and read the proposed changes.
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.
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.
>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 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 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.
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.
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.
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.
To take your GrapheneOS example, apps wishing to support it must add GrapheneOS keys: https://grapheneos.org/articles/attestation-compatibility-gu...
If this proposal goes ahead, it's unlikely that you'll be able to convince site owners and/or ad networks to add the keys of your open source OS.
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.
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.
https://github.com/RupertBenWiser/Web-Environment-Integrity/...
https://awesomekling.github.io/Ladybird-a-new-cross-platform...
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.
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.
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.
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]: https://www.urbandictionary.com/define.php?term=Pick%20me
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.
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.
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.
Is... is the Verification Can actually going to happen? https://i.kym-cdn.com/photos/images/original/000/983/286/ea5...
It’s not generally easy, but I think I’m in the position to say that.
The guy has the choice of company to work with and has the choice in the company and what department to work in.
"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.
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.
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.
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. >>22937303
Measured Boot is essential for any attestation based scheme.
It is not like you'll be loosing much. This is the time to change, while we still have other players in the market.
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/
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).
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...
Truly royally screwed at that point...
Mozilla's revenue is proportional to usage so they need enough users to cover their development costs.
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.
Perhaps, make a web page with something like:
if(navigator.getEnvironmentIntegrity) window.location="[some URL with the protest]";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.
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.
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.
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.
― Upton Sinclair
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.
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!!!
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.
Today? Guess who Grandma's gonna call with "my Netflix isn't working"? And she won't care why, all she cares about is Netflix.
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).
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.
I think the comment you originally replied to is trying to say "use the other browsers, even if they are not good for much".
Wikimedia is honestly the only organization with the right ideology, the right business model, and enough money to do something like this sustainably.
i agree they should be broken up, but it might be the wrong time for 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.
as long as they get their $1280 bonus they don't care
even if they're destroying their future employment prospects
I feel this is the bit that's going to be hand waved away for the sake of convenience.
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...
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.)
https://www.reddit.com/r/BATProject/comments/bw6sek/
https://www.reddit.com/r/BATProject/comments/b7rwbx/
> 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.
https://www.reddit.com/r/BATProject/comments/9yys6b/
https://www.reddit.com/r/BATProject/comments/97trex/comment/...
> 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.
(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. )
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
True. Try to screenshot anything from Apple TV+ content. You'll get a black image.
Google needs to stop this bullshit start innovating again. First AMP, now this? Leave the web alone!
Where's the Google that makes great web applications with simple, great UX, like Maps, Gmail, Drive and Search (which has severely degraded)?
Or great tools like Go, Lighthouse and Devtools?
Disappointing!
It's like they're trying really hard to be the villain.
Google is heading in that direction and their velocity is accelerating.
> 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.
Ben, you've thought about the impact your proposal would have on Linux laptop users, right? Surely you sometimes use your laptop for banking, right?
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.
What, you think taking down the ad industry on the web is going to be painless?
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.
You can't run your own attester - these are implemented by the companies who provide the hardware, such as Microsoft or Apple.
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.
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.
We could be here saying "Google was genius releasing Google Plus - that stopped Facebook etc. in their tracks and now they own social media"
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.
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.
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.
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.
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.
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.
They considered it enough that Apple had a monopoly on distribution for apps for a device with ~50% marketshare in the US, and even less in Europe.
Imagine what they would do for something that has ~97%
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.
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.
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.
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.
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.
The web is an app platform which competes against other app platforms.
>device controlled, unmodifiable, broken on any non-approved hardware
That's already true of the web without this API. It doesn't change anything in regards to that.
>at least I'd still be able to use my adblocker when I browse the web
Please read the proposal. It has nothing to do with preventing adblocking or detecting people with adblockers.
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.
google watches everything I do because chrome, and has a good idea if I'm a bot or not.
through clever cryptography google tells each website I visit its assessment of me?
Does it also give them the same Id for me each time I visit? (But unique to them)
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.
That said, I haven't had the desire to watch TV for a long time.
There are lots of other smaller players in the tech industry who are against monopoly-building hostilities like this.
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.
>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.
Almost no users want to be digital hermits. This protest approach has nobody following you up that mountain to the hermitage.
Most users are more comfortable with computers that are toasters, not (hackable) general purpose machines.
The flexibility to hack implies the flexibility to be owned. Users don't want to get owned. They hate that so much they'd voluntary choose an owner
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."
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.
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.
I don't work in the banking industry so I can't answer.
>Because users expect to be able to use their desktop to do their banking.
I question if this is true. Especially amongst younger people who grew up with phones.
Regardless if with this banks are able to cut down fraud this will be a benefit to the world.
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.
> device controlled [...] unmodifiable [...] nonaproved hardware
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.
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.
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!
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)
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.
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.
[0]: https://blog.samuelmaddock.com/posts/google-widevine-blocked...
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.
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.
This is entirely predicted by Richard Stallman.
Sadly, Chrome is substantially more secure than Firefox.
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.
If you subscribe to Apple TV, you are literally voting with your dollars for more of this crap. Stop giving them money!
That includes password databases.
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.
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.)
I never thought I'd see a CoC being used as ammo against this, but it's excellent.
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.
https://developer.android.com/google/play/integrity -- please do any amount of research into how this has played out.
> uBlock Origin already objectively runs worse on Chrome than Firefox > I use it just fine on Chrome and do not see any ads.
https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b... -- this is also not very difficult to look up, I kind of feel like you should have been able to find this link yourself.
> 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."
Tell it to angry devs even here who lambast Safari and Firefox for not implementing Chrome's hardware APIs
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.
I can assure you most people don't think about their tech choices long enough to conclude anything like this.
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.
You are far safer on Firefox than Chrome.
https://www.macrumors.com/how-to/how-to-bypass-website-captc...
> 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.
If Google wants a war, let’s give them one. Tell everyone who will listen. Give Google hell.
I'd guess not an insignificant amount.
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.
>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.
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.
For example, they threaten to remove FaceTime and iMessage from UK iPhones if the government there changes the law on encryption [1].
[1]: https://www.macrumors.com/2023/07/20/apple-threatens-to-pull...
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).
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.
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].
[1]: https://developer.apple.com/videos/play/wwdc2023/10120/
Disclosure: I work at Google but not on this.
And five years isn't "fairly recent".
One would also note Spotify is a failing business, and it was failing even harder then.
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.
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.
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)?
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.
"Who owns Waterfox?"
"System1 now own Waterfox, but Alex Kontos is still leading the direction of Waterfox and will be for the foreseeable future."
And who's owner, System1, states at the top of their page[1]:
"System1 operates the most dynamic Responsive Acquisition Marketing Platform
Connecting high intent customers with advertisers at scale"
[0]: https://www.waterfox.net/docs/faq#5-who-owns-waterfox [1]: https://system1.com
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.
Not a pretty thing, but necessary.
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.
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.
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.
And then there's stuff like banks, government services, school services. You might not even be able to escape those ones.
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.
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.
But bank apps won't implement it because the market share isn't large enough. This is a great showcase of the issues with the new proposal as well.
[1] https://grapheneos.org/articles/attestation-compatibility-gu...
The more bandwidth and OS features we use the more dependent we become on the cloud/ISP vendors and device/OS makers.
One tab with an ad opening when the browser has updated every few weeks or so is not what I would call "keeps constantly displaying 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.
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
[1] https://github.com/RupertBenWiser/Web-Environment-Integrity/...
[2] https://github.com/RupertBenWiser/Web-Environment-Integrity/...
Cynical outlook because I guess its where my mind wanders I guess...
In the last year Puppeteer became a lot harder to detect, which creates a problem.
THIS would provide a solution, no?
Probably a coincidence, but a fortuitous one if creating demand for THIS feature was your goal.
/tinhat off
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.
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.
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.
Of course, if you know a better browser (that is not Chromium-based), I'll be happy to hear your suggestions!
Presumably this is because if it was, it would open Google to abuse of dominant position claims.
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.
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.
(1) Understands what this is about
(2) cares about its citizens' freedom
(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.
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.
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.
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.
Hard to stay optimistic for the open web. :/
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.
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"?
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.
[1] https://chromium.googlesource.com/chromium/src.git/+/refs/he...
Despite all that, I would recommend only FOSS browsers with good privacy policy - because they exist.
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.
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.
It's just an open question, and as such, it does seem it's an afterthought, when it should be front and center if anyone care for an open web.
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.
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 works on CNAME stuff": where?
https://bugs.chromium.org/p/chromium/issues/detail?id=118065...
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.
>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.
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.
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.
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.
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.
---
> 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.
----
> Can you quote that section. I don't see it.
See https://github.com/RupertBenWiser/Web-Environment-Integrity/..., specifically the bullet-point list under the introduction:
> [...] 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?
----
> https://bugs.chromium.org/p/chromium/issues/detail?id=118065...
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.
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.
Disclaimer: Googler, but not working on Chrome
kinda abusing if you ask me
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.
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.
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.
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
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.
> 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.)
* 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.
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.
"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."
https://github.com/RupertBenWiser/Web-Environment-Integrity/...
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.
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.
It seems more likely to be fought in Taiwan conventionally then on either country’s turf.
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.
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)
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.
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
but I'm afraid the Chinese already know how to make them
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.
Why do you think that's acceptable?
But this will likely fall on deaf ears because you already made up your mind last year: >>32283932
Otherwise Palemoon is as doomed to obscurity as Firefox, if not moreso.
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.
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!
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?
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 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.
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.
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.
Full disclosure: I was employed as a software release engineer at the Wikimedia Foundation from 2015 through 2022.
Your username is the same as the initialism used internally to refer to the Wikimedia Foundation.. The WikiMediaFoundation: WMF
The majority of users had no idea and it didn't affect them at all. Nor is there any evidence that it had any impact on Spotify's business.
I'm aware Apple implemented similar tech a while ago, but I have infinitely less confidence that Google would use it responsibly.