They'll rename it and reintroduce it subrepticiously, just as they did with ~~FLoC~~ Topics API.
They'll rename it and reintroduce it subrepticiously, just as they did with ~~FLoC~~ Topics API.
Internet Runtime Robustness API
"surreptitiously"
Maybe the GP is also insinuating that Google is full of reptilians?
No, just a native French speaker, where the root word is "subreptice".
In the time honored way of English, we stole it from you and changed the spelling to match our crummy pronunciation.
Well, it happened sometime after 1652:
Also in the time-honored way of English, we didn't really standardize spelling for another 200 years. Then we started being really pedantic.
And (Norman) French was the official legal language of England from 1066 to 1362, at a time it wasn't even the official language of France itself (that only happened in 1539 with the ordinance of Villers-Cotteret replacing Latin in legal documents).
To this day some ceremonials of Parliament like the King's Assent to promulgate legislation are still in Norman French.
> Topics API
Really messed up having something so far reaching and giving it such an innocuous name a normal person couldn't possibly understand the implications of. Definitely an evil mind behind that one.
With ideas like this, it may often be just as dangerous to publish them in the first place. Governments are now aware of it (including Apple's CSAM tech). How long until they start mandating this from browser/phone makers?
What interest would a government have in getting something like the "Web Environment Integrity" API?
Create a blacklist of websites built into browsers for one. Would defeat VPNs and other techniques for the average users.
Afaik most governments don't build browsers. How would this defeat VPNs? As far as I understood this API allows websites to make sure they run on unmodified browsers. The underlying network stack is not checked.
The more relevant question is when governments will force Apple and Google to open up their app stores. Particularly Apple is enforcing a monopoly on browser engines by not allowing applications to use anything else than Safari on IOS. Google isn't much better and is forcing OEMs into, arguably, illegal licensing deals where they are required to ship Google apps. Breaking that monopoly will change the mobile web landscape.
While they are at it, they can force PlayStation and Xbox to sell each others games on their closed systems. Then force Walmart to allow Target to open a kiosk rent free in their stores… Closing an adtech attack vector by restricting the browser engine on a device they paid all the R&D for to develop doesn’t make Apple a monopoly.
Sony and Microsoft should be forced to not prevent users from doing whatever they want on the hardware they purchased. Your second example isn't relevant.
When you buy it, it's your hardware, not theirs.
Disagree. My second example is very relevant just inconvenient for your argument. It demonstrates what you’re asking for applied to physical stores.
You can take apart the hardware and do anything you want with it. Replace any of chips, use any of the components to make your own console, etc. It’s not Sony or Microsofts fault you don’t have the technical chops for it.
The security engineer in me loved this proposal, the privacy/FOSS enthusiast in me hated it.
It seems to me like most security engineers have a strange view of security. They seem to take an abstract view of security as enforcing certain invariants in a system, but have no problem with exploiting other systems or abusing human beings. Google will gladly exploit my system, coming up with ever-more-nefarious ways of making it disclose my private information and trying to limit what software I'm able to run. Yet they employ myriad security engineers and have the ability to dictate de-facto standards for the security of the web. How is it that their "Project Zero" can speak at a conference without getting booed out of the room?
> but have no problem with exploiting other systems or abusing human beings.
Security is about making sure that something happen via a certain path, without things going wrong in ways that can be abused.
Web Integrity effectively enables a way for, say, a bank to validate that the request isn't coming from botnet VMs spun up in the cloud, but rather an actual device with an actual human behind it. In fact, many websites already try to accomplish this with fingerprinting, which is why certain browsers and VPNs are already effectively blocked from the web.
Yes, it has the effect of limiting your freedom and privacy, but there is a definite security gain here that will lower the likelihood of account compromise.
Security != privacy; and security != freedom. Often there's a tradeoff. Security engineers are employed by their company to increase security - not freedom, and not privacy (unless mandated by regulation), hence the bias you typically see from them.
I read the proposal to be a way for sites to execute a hash function on my ram? It sounds like a security nightmare.
I'm not sure how you got that impression. Attestation doesn't require any sort of scans on your current memory content, only the hash of the code that was executed.
https://en.wikipedia.org/wiki/Trusted_Computing#Remote_attes...
And for us that do not run Harvard architecture computers?
It could ensure that an employee laptop is not infected when connecting to the intranet which could prevent customer data leakage which would be a benefit for all of us.
It would not ensure the laptop is not infected.
It would only ensure that the laptop user does not run software that is not approved by Google or similar, a DRM, as Trojans will continue to find ways to disguise themselves and insert themselves into authorized processes.
The company would find difficult to run custom software not covered by such DRM. In time, the Web Environment Integrity API organisation would say that there are too many authorisation requests or similar and demand economic compensation from developers to be included in the authorized filter scans, at time the supposed initial objective is not accomplished, as this DRM does not ensure the laptop is not infected.
In was speaking in general about remote attestation, not about the Chrome only one.
A good example is Xbox, for which there is no known custom software, which in turn guarantees the lack of cheating software.
Such a scan would take like half an hour. You need to scan each unloaded executable. WEI won't be used for that. It will be used for blocking ad blockers and ensure Google's malware is active.
I am quite sure that the client programs need to be cooperating for the WEI to be practical.
Great. Now kill WebHID and WebUSB next.
What is your problem with WebUSB? It is really cool actually. I like making things with micro controllers that work with the browser. For example I made a device that lets you login to websites with an NFC card. Without WebUSB it would have been impossible.
I used WebUSB to flash GrapheneOS to my Pixel. Super easy and really cool, but kind of crazy that it's possible.
WebUSB is pretty useful for web-based POS. Scanner and printer integrations.
But why should web-based POS be better than dedicated devices?
That's the wrong comparison. We used to only have dedicated POS systems, now we have the option to run POS software on a general purpose computing device. The question is why should that POS software be a native app instead of a web app?
you know what is better? a upstream kernel driver
I think you don't understand the use case. Kernel drivers don't connect the USB device to the JavaScript in the web-app.
It's great for a lot of use cases. We use it to enable a cross platform device flashing tool. Much easier to build and distribute than native applications for all platforms we need to support. Serial is similarly useful for getting logs off of devices.
After reading through the proposal, I really don't think it was that bad.
As a recap, websites never see any information about your device but basically receive a 'thumbs-up' from a trusted provider that your browser is 'likely' to be a human agent and untampered with. There is definitely the potential for it to go quite badly if Google ends up as the sole trust source, but if it was executed well I could see a situation where it ends up similar to TLS, where there are a relatively large number of trusted providers including some like LetsEncrypt that are non-profit and considered a public good. In that sense it would allow quite a bit of flexibility in what 'untampered' means based on the trust source which would be a good thing.
IMO the dialogue around this was incredibly disappointing. I understand and support the hesitation around a proposal like this that could do harm to the web, but people were basically attacking these people and having meltdowns in the GitHub comments.
Given how much large platforms have struggled to fight bots, and that it's only going to get worse with the rise of AI, I think something like this is going to end up being a necessity eventually. This won't be the last we will see of something like this.
> a 'thumbs-up' from a trusted provider that your browser is 'likely' to be a human agent and untampered with
Sites are not entitled to this. They should have to interoperate with literally any HTTP user agent. I am the user and the owner of the machine, I am entitled to "tamper" with anything I want.
>Sites are not entitled to this. They should have to interoperate with literally any HTTP user agent.
Says who? The government? At the end of the day, any voluntary interaction between two entities is a two way street. Either side can refuse to engage with the other side for any reason.
The government should definitely say so by implementing laws and regulations. Computer freedom and choice should be law.
> There is definitely the potential for it to go quite badly if Google ends up as the sole trust source, but if it was executed well I could see a situation where it ends up similar to TLS
If you are that naive look where Android is now today.
Despite being open source and having some alternative distributions, many banking and other "serious" institutions apps only work on official builds blessed by Google. They also block screenshots and remote screen.
All thanks to Android\Google Play Protect DRM.
If DRM is added to the web expect these same institutions to be early adopters so they can restrict access to their websites to only the browsers controlled by big tech and only without extensions.
DRM already exists on the web and most sites gracefully degrade when a user's browser does not support it. They don't just restrict access.
Citation needed.
Unless you're calling extra low resolution graceful? I wouldn't when there's no reason for it. And things that use the Google DRM on phones usually just shut off.
Yes, I am talking about low resolutions that they understand will be easily stolen. Websites aren't mobile apps and the intention was that this API was not to be used for blocking.
The 4K DRM'd stuff is also easily "stolen". It's not as if it's actually working. It only takes one mildly sophisticated actor to get around it, share the resulting files and then your fancy DRM is completely useless.
So what is this DRM actually accomplishing? Well, it makes it so that on platforms that don't support the DRM, piracy is actually a better user experience. All it did was create an additional(if minor) incentive for Linux users to just download the stuff for free instead of paying for Netflix.
The only DRM currently available on the web that I'm aware of relates to video.
Banks don't have to restrict their apps against unauthorized Android builds and rooted devices with Play Protect but they do. There is nothing to gracefully degrade when your goal is actually to just restrict access.
Also the banks already just plain restrict access on the web, unconditionally, by making a smartphone app a mandatory auth / confirmation factor. And the app itself, of course, makes full use of Google's attestation APIs like you describe.
So at this point allowing for the web to be nearly as secure as a native app would allow for these sites to potentially start working on the web again.
I've commented to this point in the past, but I don't care about the web winning, I care about the things that make the web the web -- user-controlled agents, being platform-agnostic, extensibility, etc...
If we're willing to give that stuff up in order to bring native apps back to the web, then we can save a lot of time and effort and just redefine the web to include mobile apps and get Google to re-label all the native apps in the Play Store as webapps and change nothing else. Then those apps will technically be on the web! No developer changes even needed, the web won! /s
The problem is not that the banks aren't on the web. The problem is that the banks deny user-agency. That's the problem I want to fix by bringing apps to the web. My goal is not to get the bank app served over an HTTP request, I don't care about that part. I don't care if the bank's interface was written in Java or Javascript. I don't care if the bank is caching data in service workers or on disk.
My goal is to get the bank app to respect user-agency, that's the part I care about.
If we make the web into a native environment, then it doesn't matter anymore whether or not app developers are using it. The web forcing developers to support user freedoms is the primary reason we want webapps. The web is a means to an end, not an end in and of itself.
No. The problem isn't web being not secure enough, but native apps being too secure - secure against their users.
...but if it was executed well I could see a situation where it ends up similar to TLS, where there are a relatively large number of trusted providers including some like LetsEncrypt that are non-profit and considered a public good
The proposal didn't include anything like that and I don't see how it possibly could while still meeting its goals... It seems to me that WEI's goals are fundamentally incompatible with letting end users compile their own software.
> but basically receive a 'thumbs-up' from a trusted provider that your browser is 'likely' to be a human agent and untampered with.
Where "untampered with" means blocking anyone with an adblocker installed, using accessibility tools, or running Linux. DRM for the whole web is Bad.
That is definitely a possible outcome which is why I believe people are right to be concerned about a proposal like this, however my thought was that if there were many trusted providers it would drastically reduce the likelihood of a scenario like this. For example, I could imagine an organisation like Brave as a trusted provider who would almost certainly not restrict ad blockers or Linux use.
Notice Windows 11's TPM requirement and the growing infestation of Android apps with Google Play Integrity? Brave would be a signed web browser, running on a signed OS stack, launched from a signed bootloader, all with hardware attestation. This is the end goal, since any part of that chain becoming compromised means any application running within that environment can be compromised be it Chrome, Brave, Firefox or whatever.
This would effectively exclude FOSS as a second class citizen when accessing the modern web.
FOSS is already a second class system because there is no DRM. The web still functions for these users despite that.
Yes, and exactly that is at risk.
Why would websites want to trust Brave? And what if I want to compile my own browser? Now I can't use my bank website...
Or build your own browser from scratch, at least three HN users are doing that. (And I'm following, I think a fourth engine is needed)
I'm not denying there are challenges and potential bad outcomes with this, you're asking valid questions that I don't claim to have a good answer for.
My point is that the WEI proposal is trying to solve a genuine and increasingly important issue for providers on the web. And, there's at least a possible outcome where we have many trusted providers that maintain the core parts of the open web that we love while giving these providers some better solution than what exists now.
As for why would they trust Brave? I imagine it'd be similar to TLS now, where website owners probably wouldn't even think about this and they'd just use CA chains provided by browsers, operating systems, etc.
> My point is that the WEI proposal is trying to solve a genuine and increasingly important issue for providers on the web.
There is no issue. In general the companies who encounter this "issue" the most are already making plenty of money. They have billions of dollars available to fight bots and they're free to use them if they think it's worth it. No one writes sophisticated bots for Mom&Pop websites, there's nothing to be gained from doing so.
> My point is that the WEI proposal is trying to solve a genuine and increasingly important issue for providers on the web.
> Given how much large platforms have struggled to fight bots, and that it's only going to get worse with the rise of AI, I think something like this is going to end up being a necessity eventually.
I want my browser experience to be focused on solving _my_ issues. Helping trillion dollar big tech companies fighting bots is honestly very low in my priority list of browser (anti)features.
> My point is that the WEI proposal is trying to solve a genuine and increasingly important issue for providers on the web
What is that important issue?
Bots and abusive users at increasing rates
>Abusive users
I'm much more worried about abusive service providers, which this will enable. A browser is a user agent. It ought to act on behalf of the user, not some random website I'm visiting.
Just so I'm clear, why should a site expect to vet me all the while demanding I can't modify whatever they send to me?
Why do you want a one way street?
It doesn't matter if it solves a real problem if the cost is too great.
The security model of TLS is chained to the DNS. What one proves by holding a TLS cert is that one owns a given domain, no more no less (I mean there's EV certs but no one cares about EV certs).
You won't ever have that with browser builds because there's nothing like that to tie them to.. (user agent string?). There will be no basis upon which to build trust except for market share, and to gain market share you have to already be trusted.
Also, for WEI to work, you need to certify a lot more then just the build of the browser.... You need to certify all of the shared libraries it pulls in (including the userspace graphics libraries), everything that runs in kernel mode, the firmware, and the actual hardware.
I would assert that the idea you are proposing is simply not going to happen. There is just no way that anything other than an unmodified build of a big-name browser running on an OS from a big-name vendor gets certified.
> In that sense it would allow quite a bit of flexibility in what 'untampered' means based on the trust source which would be a good thing.
The problem is that the APIs for botting are the same APIs that are used for browser automation and extension support and that are implemented by experimental browsers that are building new tools for the web.
You're correct to bring up that people didn't trust Google; that's part of it. But there's a more fundamental problem: there is no way to restrict someone from using APIs to automate a browser without also killing a lot of more traditionally accepted use-cases for those APIs.
Every accessibility API and presentation API is an adblocking API. Every web extension and request redirector is a bot API. Google didn't seem to understand this; they came into the discussion believing that as long as they could get people to believe Google wouldn't abuse the API, everything would be fine (whether or not that was an honest claim is another discussion, the problems with WEI were numerous). But beyond the discussions of Google's motivations, at a fundamental level what critics were saying was that there was no such thing as a working version of this API that would be effective at reducing bots without reducing user freedom. Making the API more Open or getting more implementers on board wouldn't change that.
It simply isn't possible to truthfully verify to a server that a user environment is "trusted" without blocking the user from accessing normal browser APIs.
I absolutely agree that it's very much a big nothing burger compared to the reaction it got.
> Instead, the Android team aims to focus on the Android WebView Media Integrity API, which provides a similar form of attestation but only for WebViews embedded in Android apps.
I'm not as dismissive of this as the Register is; it's definitely less harmful than the original proposal, but it's still DRM, and now it's no longer going through a standards process so we just don't have a ton of details about how it will work.
I honestly feel like this announcement should probably be getting more skepticism than I've seen from the news sites reporting it. I'm not saying it's just as bad, I'm just saying we should question how much this is going to help security for end users or whether this is just going to to turn into more DRM to let embedded webapps act like native apps.
https://groups.google.com/a/chromium.org/g/blink-dev/c/Ux5h_...
This was mentioned earlier in the thread if someone wants to follow the source.
To me, it sounds like: We are going to develop and test it anyways, and we will try to standarize it again when the time comes.
Yeah it reads like they got too much bad press and outright hostile pushback from Plan A so they're switching to Plan B and hoping to boil the proverbial frog slowly over time.
This is almost exactly my worry, especially since this will for all intents and purposes be a web API that only works on one browser. So if Google comes back and tries to standardize this again, do they now rush it through the standardization process and say, "look, servers are already using this API, we're not doing anything new, we're just adding it to more browsers."
Embedded webview is a web browser. This allows them to launch an API for remote attestation as a working implementation in a web browser and ship it to developers and users -- and that's a big chunk of standardization right there.
----
I'm not thrilled with it for Android either, but if I could trust that it was only ever going to stay in Android webview then I'd feel at least a little better about it. But Google has no way to credibly commit to that, and they've given no details or retrospectives about WEI. We get like 2 paragraphs in an email thread and 2 sentences in a press release that just says, "yeah, we're not working on that anymore." It's very difficult to trust that.
WebViews can already be given access to literally anything you want to give them from your app you embedded them in, so I don't see any fundamental change? It's basically a new android DRM API, of which there are already several.
I wonder how hard it would have been before this to simulate the same API using the Play Integrity API and just exposing it to the webview. Is that something where the remote server would still have to trust the client to not lie about the API, or could they do an attestation check remotely in a way that would be difficult to fake?
The difference may be that any app could embed a "Google Verified" webview. (And presumably the OS would prevent the embedding app from modifying the webview in any "unapproved" way.
For example this could be used by Google to allow apps to embed a Google login page without them being able to access the users credentials or steal the full-access auth token (although this is still a bad idea for a variety of ways including click jacking, confusing overlays, conditioning the user to type their password into untrusted apps... but the raw capability is interesting and could potentially have "reasonable" use cases)
A couple of people have brought this up, and I'm certainly open to learning more about it, but I'll admit that I don't see the user benefit.
The problem with embedding Google login pages probably isn't user credential stealing as much as it's phishing? Webviews don't show the URL on Android, so what about this change prevents me from sending you to a "Google" log-in page that harvests your credentials using an old-fashioned phishing attack?
Okay, I can't steal the credential directly from the actual Google log-in, but is that how most malicious actors are stealing log-in information today? I wouldn't have guessed that, but :shrug: maybe I'm wrong. It seems like for all the problems you bring up, standardizing a feature to use user-controlled browsers for a subset of auth requests for native apps would be way better. Or (for all of my skepticism about them) using passkeys. Both would provide more opportunities to encourage developers/companies to do auth the "right" way -- via limited access tokens where credentials aren't shared between apps.
Don't get me wrong, embedded log-in forms in apps are dangerous for user security, but it seems like there are far better solutions to that problem that don't have any of the downsides of attestation?
----
Edit: Also, I'm realizing as I'm typing this that "non-approved apps shouldn't be able to load certain web pages" would be a far better candidate for a user-permission with sensible defaults rather than a server setting. Browsers have CORS requests today, the key point being that as a user, if I want to, I can override them. It changes the entire model from being "prove to the server that you're trustworthy" to "here is a recommendation to the client (in this case the Android OS) on how to keep the user safe, and if you want to ignore it, fine, but you probably shouldn't by default."
I still am not sure this would solve phishing and I'm not sure it would be a meaningful increase in security, but I'm realizing that if this wasn't attestation and Android was announcing that they were rolling out user-controlled permissions and routing tables for the system webview that would allow you to specify allowed domains on system/app level, I would only have praise for that announcement.
Could copy CORS for servers to set defaults; webview would do a preflight check for app IDs based on the system and refuse to load the webpage if the "CORS" request fails. I'd support that as a web standard, off the top of my head I don't think it would have almost any of the downsides of attestation since it would ultimately be up to the user-agent whether to respect the restriction, not the server.
> although this is still a bad idea for a variety of ways including [...] conditioning the user to type their password into untrusted apps
Right -- again, assuming the best intentions around this change and only thinking about the security implications, I'm just wondering if trying to secure that process is counterproductive in itself.
I really like the engineering concept of encouraging developers to fall into a "pit of success" and I wonder if having an alternate auth flow that genuinely avoids most of these problems beyond the very narrow "developers can access the context of the current web page" problem would be better. We really shouldn't do embedded login forms at all, we should encourage developers to move away from them.
I'd support a web standard that made it easier to use the user-controlled actual browser to handle auth requests by apps. That would at least give the user visual access to the URL which would fend off some phishing attacks. And (assuming the FIDO Alliance shapes up and actually addressed current problems with spec) passkeys would be even better for this since cross-environment authentication that doesn't transfer credentials and is invulnerable to (most) phishing is passkey's entire deal.
I don't want to make a hard claim because I don't know the research, but I would not take it as a given that a change that as a side-effect encourages developers to embed login forms is a net benefit for user security.
For most purposes, you could probably have the phone have a TLS cert for an identity, have the identity provider sign that cert, then use mTLS. No phishing possible because you're not giving access to anything; just proving your identity to whichever server you talk to (and they can't forward that proof).
Honestly I'm not sure why oauth became such a thing and mutual SSL did not. Most "social login" use cases don't need a token that grants any access to anything from the idp. Just proof of id, which could be done in the background by your browser/OS service though some standardized cert renewal process.
Remote attestation happens in hardware now. Significantly harder to fake.
Can you elaborate? I'm not sure I understand what you mean by "now".
What I'm asking is whether or not the Play Integrity API supports remote attestation on its own today (ie, before any of the webview changes ship). Or I guess, more specifically, is there a challenge-response API currently for the Play Integrity API that a remote server could use?
If yes, then sure, I buy that this is not really adding anything new. If no, then adding a webview API does seem to me like a meaningful expansion of Android's DRM capabilities.
It does. It's called SafetyNet and it wiped out the freedom Android used to have.
https://www.xda-developers.com/safetynet-hardware-attestatio...
This sort of lockdown (along with others) is why I'm abandoning smartphones altogether.
It will be back. Somewhere along the line the kinds of people who push these sorts of things realised that it doesn't matter if everyone hates the thing and it gets temporarily "defeated". If you can afford to keep reinventing the same thing under another name, you can get the outcome you want through sheer persistence. See also: surveillance laws.
The only way to stop it coming back is to remove their ability to implement it. If Chrome was <20% market share it doesn't really matter how many harmful APIs they have because very few sites would require them. As long as they remain popular they will continue to sneak in these features, then other browsers will have to adopt them or face extinction because websites don't work on them.
See also: any unpopular law. It has to be fought and defeated every time, but only has to succeed and pass once.
Should it not be easier to remove laws than to add them?
It should be. It isn't.
The key is to keep aggressively attacking the ones that already exist. If they have to be constantly vigilant to things from getting better, they won't have as much time to spend trying to make it worse. And sometimes they'll lose and you'll actually make things better.
The tiring part is that, we have to be vigilant and won every time. They have to win once.
The tables are stacked against us.
Why are you assuming bad decisions can't be reversed?
It takes too long for them to be reversed, and by that time the damage is done.
"I have encouraged the team working on this to ignore feedback in any forum in which something like Chromium's code of conduct is not being maintained as anything else would be creating an unsafe working environment." - Rick Byers
https://groups.google.com/a/chromium.org/g/blink-dev/c/Ux5h_...
I'm sorry for the raw words but this is soy as fuck. This is the usual excuse of "well, we got harassment (which we totally deserved) so we are finally justified to do <bad thing>"... These companies present it like harassment and threats just come out of nowhere because people are unreasonable or "hateful", and they refuse to acknowledge they deliberately create the conditions for such extreme measures.
If they don't want harassment or threats, they should maybe stop messing with people's stuff...
Nonsense and an excuse to ignore any criticism they don't like
> unsafe working environment
what does that even mean? we are talking about internet arguments here right? how does "safety" even enter the conversation? this guy sounds off his rocker.
> find ways to reduce the harms of invalid traffic across the whole web
crazy talk.
Makes sense to me. If during the course of your work you have to read a bunch of internet comments with so much vitriol it is a personal and psychological safety issue. Personally I would not have chosen any job that would subject me to this kind of psychological abuse, and I would imagine someone choosing to work at Google would have thought the same.
Curiously your HN profile says "removed due to doxing, because people are awful" so I'd like to think you at least would have the empathy to imagine someone experiencing something similar to what you experienced. Internet arguments can hurt people; period.
Agreed. And, I can imagine anyone working on anything like WEI will not find a safe work environment so as long as their work environment involves being on the internet in any shape or form. So I guess if you work on the Chrome team and this is assigned to you, I genuinely do feel empathy, although I also think that you should probably quit if you value psychological safety.
This is a complicated issue. I view work as a mutual exchange: I work on software in exchange for money. It is a bonus when I think the software or mission is genuinely cool. That said, I'm not one to be highly moralizing about it. I'd quit if someone asked me to do something illegal, and I will (and have) generally refuse to do work that is just simply morally bankrupt (And I have been tested on this. Early in my career, I refused to remove annual subscription renewal reminders for a subscription service. I didn't suggest that I would quit if it were done, but I voiced my disapproval and made it clear I wouldn't do it. We didn't wind up doing this, thankfully.) But, I will generally work on things that I don't agree with. I'm vocal about it, but work is work.
But y'know, people have livelihoods to maintain. It's easy to say this if you live alone, have plenty in the bank, a great safety net, and a great network. (Not that all of that applies to me, but for sake of argument.) Certainly the job market is also tighter and the future of software engineering as a career is uncertain in some regards. So outright refusing to do work could be a scary prospect. Even being vocal about it and rocking the boat may be scary.
But that said, this being the case does not make the answer any less certain. While harassment and toxicity that crosses certain lines is not something I think people should justify, I certainly understand the why: working on something like WEI triggers an immune response from the proponents of the open web. And while I'm sure many people would prefer to do things "right", I think that there is an overwhelming feeling that the open web is hostage to the big corporate interests, and that the open web proponents are strongly outnumbered and outgunned in the modern world. And Google never played fair anyway, so they probably don't feel especially enticed to either.
So I think it's natural. What's going to happen is that this will probably continue to escalate, and I can't really say I strongly blame anyone. Google is probably happy to push this responsibility onto employees knowing it could be very mentally taxing, employees with increasingly poor career prospects will not want to rock the boat, and disgruntled "internet activists" who feel pushed to their limits are unlikely to care tremendously about the emotional damage they cause (it's not like the Internet is really known for its kindness to begin with.)
I'm thinking it's gonna be a good time to pivot away from computer careers these next few years...
I'm glad you used the phrase immune response. I would've opted for something like visceral reaction but yours is a better term. It's certainly the case on this forum. People on this forum can get way too attached to specific technologies or principles that they forget personal attack is never okay.
Why? I don't know the name of anyone who worked on Private Access Tokens at Apple or Cloudflare. Likewise the developers who worked on the Secure Enclave, or the slow march Windows has taken to enforce TPM's.
This was mostly a media/social media storm in a teacup. With bad press because its Google.
Chromium is huge because its open source, so the bar is higher than Macos, Safari & Windows.
But it didnt make this proposal much different/worse than any of the others that already exist and are enforced.
At least we got some hilarious statements like "its not needed because bots identify themselves by their user agent!"
Private Access Tokens are bad too, but they were much more limited in scope based on their design. One of the design elements of WEI in its own words is that some use cases would only work if it could be required for all users. Meanwhile PAT is attestation but the scope is explicitly intended to be for fulfilling the role CAPTCHA does today... optionally. Nothing about extensions like adblock that I am aware of. The point was to put users on proxies at the same level as users on residential IPs.
But is PAT good? Well no. It's bad for similar but ultimately different reasons. But until Chrome adopts it, it's just not scary.
The health of the open web depends on not having different user agents being treated as second-class citizens. Not only that, but locking the internet behind CAPTCHAs and remote attestation to fight bots is bad because it will always be playing favorites to bots like Google's. Today, and in the past, we've already seen what it looks like when the Internet does this. But it's just not going to be an acceptable solution to bots. If the Internet of the future is a hellscape of big corps controlling literally everything that remains with cryptographically enforced adblock, Yes I'd happily see it burn down instead. I don't really care if other people would prefer that to nothing, because to me its a worthless future and a waste.
Attestation is not a real option that's really on the table.
The bad press is simply because Google has a bad PR team that does not do an adequate job to control its brand reputation. As simple as that. When other companies attempt this, at least the PR department does some damage control be it press releases or press conferences or whatnot. Google didn't.
> It's somewhat ironic to me that some folks arguing passionately for the openness of the web (something I and many of the proposal contributors are also passionate about)
I cannot imagine the level of cognitive dissonance required to simultaneously believe you are passionate about the open web, and push something like WEI.
Either they're flat out lying about their "passion", or they've internalized some very contradictory ideas. Not sure which is worse.
Of course then there's:
> Attacks and doxing make me personally MORE likely to support stronger safety features in chromium, as such acts increase my suspicion that there is significant intimidation from criminals who are afraid this feature will disrupt their illegal and/or unethical businesses, and I don't give in to criminals or bullies.
Which makes me think they're just lying. Or, at best, they don't understand basic logic. Personal attacks and doxing are unacceptable, but just because people who do bad things hold a certain opinion, it doesn't mean everyone who holds that opinion does bad things. Or even that more than a small, vocal minority do.
But ultimately Google is an advertising & surveillance capitalism company. If you're going to work there, and on one of most of their public-facing products, it's pretty likely you're going to eventually do shady things in service of the company's main revenue streams. Your continued employment depends on it.
> I cannot imagine the level of cognitive dissonance required to simultaneously believe you are passionate about the open web, and push something like WEI.
> Either they're flat out lying about their "passion", or they've internalized some very contradictory ideas. Not sure which is worse.
After observing Google for many years, I've figured out that when Googlers say "the open web", what they mean is "running in a browser, not a native app". So anything that makes apps running in a web browser more competitive with native apps is "good for the open web", even if it reduces openness. I think for a lot of people this is not even bad faith; it's just how language is used inside Google, and people pick it up and it shapes their thinking.
it is the same thing govs do to suppress and label everyone as rioter and therefor evil
>I cannot imagine the level of cognitive dissonance required to simultaneously believe you are passionate about the open web, and push something like WEI.
Imagine a world where EME was not accepted as a standard.
1. Browsers do nothing to support DRM and sites like Netflix recommend people to just use a native app to experience the full Netflix experience. This weakens the open web by having sites leave the web and opt to move users to the mobile web instead.
2. Browsers adopt a closed standard for DRM. This weakens the open web because now a care use case of the web now uses a closed standard instead of an open one.
> 1. Browsers do nothing to support DRM and sites like Netflix recommend people to just use a native app to experience the full Netflix experience. This weakens the open web by having sites leave the web and opt to move users to the mobile web instead.
It would be easier if it was just Netflix using this crap like you imply. Nowadays, a good 10% of the websites have a popup "this page has DRM content, do you want to enable it?", I'm assuming it's used for advertising fingerprinting and malware even more than videos.
So yeah, requiring a netflix app is an improvement on the current situation.
> 2. Browsers adopt a closed standard for DRM. This weakens the open web because now a care use case of the web now uses a closed standard instead of an open one.
DRMs aren't the open web, they are the closed web, regardless if there's a specification or not, that doesn't change a thing.
And having an open specification for it lowers the cost of deploying them (as we've seen now, it's in a lot of places) which is bad.
>So yeah, requiring a netflix app is an improvement on the current situation.
If you are botherd by popups I'm sure you can disable them. I've never seen a popup asking me to enable DRM when I browse the web.
>DRMs aren't the open web
EME has a standardized javascript API for people to use. This is a public standard developed openly.
>And having an open specification for it lowers the cost of deploying them (as we've seen now, it's in a lot of places) which is bad.
Allowing copyright holders to have their hard work be protected is a good thing and allows for them to be willing to share them more if they can trust they won't be stolen from. Artists want control over how their art is used. Saying tough luck and that they should just deal with it being stolen is not productive and is ignoring their needs.
The open specification doesn't really even mean much, because the specification covers how the DRM module interfaces with the browser, not compatibility between DRM modules. In practice, there is exactly one DRM implementation used on the web, and it is proprietary (Wildvine). You could implement another standard-compliant DRM scheme, but no one would use it; the value of the standard is basically nil.
It still helps interfacing with Widevine, if the website had to tell each user to install a custom plugin, that would increase the work to do
3. Firefox somehow manages to remain the dominant browser, refuses to adopt the standard and sites have to suck it up and deal with it.
If only that had actually happened.
That is the same thing as option 2. It would end up being an addon to Firefox like in the old days.
> Attacks and doxing make me personally MORE likely to support stronger safety features in chromium, as such acts increase my suspicion that there is significant intimidation from criminals who are afraid this feature will disrupt their illegal and/or unethical businesses, and I don't give in to criminals or bullies
That makes it _really_ hard to believe they're debating in good faith.
Anyway the entire thread makes it sound like they're temporarily backing down but still intenting to implement something similar in the future:.
Justifying shady corporate practices by pretending to stand the moral high-ground is nothing new. Just recall Apple's child pornography nonsense.
"We are introducing web DRM to protect users from those evil people out there..."
The hell you are.
They're saying anything that disagrees with them is bullying and criminal. But, labelling anything that disagrees with them as bullying, is a bullying tactic to try to silence dissent.
Why do they want to silence opposition? Because their position does not stand up to scrutiny.
Pushing anything in tech uses this playbook. Look at systemd and Wayland. They take the bullying approach and act like their intentions can't be questioned.
We need a stronger response to their arrogance. Something that will affect network performance and intercept revenue. We can start by blocking them at the DNS level. Host with Google? Too bad your choice in tech sucks.
> Pushing anything in tech uses this playbook.
no, they don't. Google just criminally accused the opposition to their new "internet law" of being doing so in order to continue committing crimes.
>They're saying anything that disagrees with them is bullying and criminal.
That is not want was said. People making direct and indirect threats against the author are not acting in good faith and want to just silence the author without anyone fairly evaluating the proposal.
>Why do they want to silence opposition?
Threats are not productive for deciding if a proposal should be adopted. They are just noise. Wanting to get rid of noise and focus on signal is not "silencing opposition."
Threats can never be a justification for them to act against all of internet users, this is BS. One threat which can be manipulated by themselves (false flag) and now they have an excuse? Bullshit. If they have any problem with that, call the police, that's no excuse.
There's a big difference between using robust language and threatening someone. What we're seeing here is an obvious attempt by a small minded individual to play the victim.
There isn't playing the victim here. He was pointing out the large amount of noise around this. 99% of the people making this noise have not even read the proposal and do not actually understand what it means. It is hard to engage in a productive conversation if people are arguing against a something that your proposal doesn't even do.
> It is hard to engage in a productive conversation if people are arguing against a something that your proposal doesn't even do.
First thing they should stop taking for granted the right to make proposals. Which obviously leads to the fact that they should accept when their BS is rejected.
> People making direct and indirect threats against the author
Indeed that would be the case if that were so, yet it looks like what actually occurred here is the author is abusing the labelling of bullying and criminal in order to falsely tar all disagreement as that.
This labelling abuse is itself a bullying act designed to intimidate and shame into silence any disagreement by misrepresenting it as a threat. Which is itself a threat: agree with me or I will accuse you of evil and silence you.
That's what it seemed like at the time. Let's note that the quoted comments are from a months' old thread.
Do you have any evidence to support your claim about there being direct and indirect threats?
>Do you have any evidence to support your claim about there being direct and indirect threats?
Read the Github issue and you will see people irrationally freaking out about this, indirectly and directly threatening to sue the author, etc. The people disagreeing and bring up problems were much more civilized until it went vital and then it turned into a cess pool of unproductive discussion.
In the linked Groups post, the author reports "physical threats and other forms of abuse". I find that very easy to believe and your post reads very uncharitable, unless you have concrete reasons to think that the author is lying.
I find that very easy to believe
Yes, and that's the problem the GP is pointing out. We're a social species that's predisposed to defend a victim, that's why playing the victim is a very successful bullying tactic.
>who are afraid this feature will disrupt their illegal and/or unethical businesses
While benefiting unethical businesses like Google? That's called a cartel.
In my town, a couple (both doctors) unilaterally gated a forest service road that led to a popular outdoor area used by the citizens for years.
Apparently rights of way are tough to determine on this road that's well over a century old, but the Forest is working on it.
In the meantime, the doctors' business were figuratively destroyed and their property vandalized. [I don't approve of illegal actions.]
And I think they're genuinely confused by the reaction of the general public. They are so far out of touch, they just can't understand.
Google pushing things like this and being surprised by the violent backlash has the same feel.
The Verheydens?
> violent backlash
There's no backlash. Is there anyone stating to stop buying Google Ads? Moving to Firefox (since there's no else alternative non-Google-chromium-based browser out there)? Except the HN audience, if course.
There's no danger from "users" for Google. Because their users are huge enterprises paging billions for ads. Not us.
DRM is what banks love. Recently, there're several major banks' mobile apps in Singapore stopped working as they started scanning all apps installed on a device, and some they don't like (MS Authenticator, for instance; F-Droid, and any opensource apk from there, also any developers installed app). This is nightmare as mobile bank apps are a first class citizen now. Web just does not open without push dialog. Not sms otp anymore, but the app push dialog. The only way to handle it is to buy a cheapest android and install all bank apps there.
> There's no backlash.
Why did they roll it back, then?
> There's no backlash. Is there anyone stating to stop buying Google Ads? Moving to Firefox [...] ?
I've actually noticed and increased number of "this is it, I move to FF" posts, here and on Reddit. Since FF fixed their main performance problems, switching is not particularly burdensome anymore; and now the assumption that Google is "evil" has reached the same level of popularity that Microsoft used to have at the peak of their powers.
I think we're in a similar position as early-00s opensource: commercially fledgling, but establishing a solid mindstream in geek circles that will shape the future in unpredictable ways that are not favourable to Google.
I moved to Firefox. This nonsense was the final straw on that.
> DRM is what banks love.
> Recently, there're several major banks' mobile apps in Singapore stopped working as they started scanning all apps installed on a device, and some they don't like
This seriously triggers me. I can't even enable developer mode on my phone without these apps flipping out.
Banks in my country (Brazil) have a long standing tradition of doing this. Even on PCs they have these asinine "security plugins" for browsers. You literally cannot log into their systems without the goddamn thing installed. Not a single person managed to explain to me what they do, so years ago I was bored at work and tried my hand at reverse engineering the plugin to figure out why it made the computer so unusably slow.
I caught it intercepting every single network connection.
Didn't bother to check anything else. Just assumed it was phoning home with private information and started treating it like the malware it is from then on. Actually switched banks to one which didn't require this crap. These freaking banks think their "fraud prevention" justifies anything.
There's a package for this "banking security tool" in the Arch User Repository.
https://aur.archlinux.org/packages/warsaw
https://aur.archlinux.org/packages/warsaw-bin
Who the hell knows what this thing does nowadays? Maybe it doesn't monitor people anymore, it's been years and we even have a GDPR equivalent now. But I will never install it.
South Korea is the same. I knew Brazil were our only brothers in arms when it came to this hellscape but I was under the impression that unlike here, in Brazil over the last 5 years or so this had become a thing of the past and you don't have to deal with this crap anymore, making Korea unique in the world.
I take it this is not the case, and theyre still making you install malware?
Yes, it is completely a thing of the past for most if not all banks
If you're using a phone, maybe. If you're using a desktop computer, you still have to install that malware.
What's the country mentioned above with the mandatory bank security plugins?
Brazil.
Check this out. They even have a Linux support page, complete with screenshots depicting it running as root.
https://seg.bb.com.br/duvidas.html?question=10
https://seg.bb.com.br/img/faq/linux/verificar_modulo2.png
I looked it up the package I posted above and found a gist with the unpacked contents:
https://gist.github.com/fititnt/8d94b0574c6a4ec7e8c4088c6474...
Literally asks for your root password, downloads some proprietary software off the internet and runs them without even computing checksums or anything.
Corporation that made this thing is owned by Diebold, the corporation that made our voting machines. Bone chilling.
> Corporation that made this thing is owned by Diebold, the corporation that made our voting machines. Bone chilling.
Right, let me just put my tin foil hat.
It won't help.
It's hilarious how some people's stance on voting machines did a 180 after the 2020 elections (or at least, all the pro voting machine people started coming out of the woodwork). Politics really is the mind-killer
I remember when Diebold were Dick Cheney's personal election-riggers in 2004, although it seemed like a bad long-term plan since the plan was always for Bush to cancel elections in 2008, but I guess quarterly earnings are king.
Wait what? Do you have any further details about the f-droid and Ms auth? Damnit I'm going to have to do a PSA at work if this is true.
> It is difficult to get a man to understand something, when his salary depends upon his not understanding it
7 hours ago: https://news.ycombinator.com/item?id=38118627 (it originally had the title of "Google abandons WEI" or something similar to that)
let's be honest, WEI & similar are poor approaches to solve market-issues framed wrongly as a "user problem".
the problem is not the User wanting to download your content, bypassing ads, or spoofing Geo location using VPNs, or sharing of passwords.
The real issue is with the Providers/Vendors relying on the Web as a Cheap Ways & Means to quickly access, conquer the market.
The web is a generic platform, powered by general-purpose tech and methods, therefore it's "open", "cheap", and easily accessible, that's why it's popular and adopted globally.
There are tradeoffs - choose web for being cheap, open and accessible, or chose to build expensive, risky custom standalone services.