An experimental Android WebView Media Integrity API early next year | Hacker News Reader

An experimental Android WebView Media Integrity API early next year

android-developers.googleblog.com

377 pointsbrycewray229 comments

WEI itself was previously discussed across a number of threads, which make interesting reading:

(July 2023, 456 comments) https://news.ycombinator.com/item?id=36854114 - "Google's nightmare Web Integrity API wants a DRM gatekeeper for the web"

(July 2023, 431 comments) https://news.ycombinator.com/item?id=36817305 - "Web Environment Integrity API Proposal"

(July 2023, 434 comments) https://news.ycombinator.com/item?id=36875940 - "Unpacking Google’s Web Environment Integrity specification"

(July 2023, 111 comments) https://news.ycombinator.com/item?id=36857676 - "So, you don't like a web platform proposal" - Google employee's view on how folks should've responded to the proposal

(August 2023, 100 comments) https://news.ycombinator.com/item?id=36960882 - "Web Environment Integrity: Locking Down the Web"

Oof, that hyper-aggressive whitewashing of the DRM proposal from yoavweiss_ was a harsh lesson in realpolitik. Nerds were bringing good faith arguments to a bad faith optics war and getting slaughtered.

For people wondering which of the links to click: https://news.ycombinator.com/item?id=36857676

It's mostly just the classic "nono if you don't agree it's because you don't understand" and "please educate yourself" approach.

At least they didn't try, "I don't have time to educate you about why you're bad!"

> "P.S. I'd love to discuss this with y'all like professional adults. Can we do that?"

You can tell somebody is a snake when they aren't from the South but use "y'all". It's become a sort of corporate snake shibboleth.

Meh, it spreads a lot more broadly than the corporate snake people. And honestly I’ve never heard the corporate snakes use it myself (at least not before the example which you quoted), but I’m sure there are corporate snakes who do.

I certainly think that a lot but I sure as hell wouldn’t say it. It doesn’t help, that discussion never goes well.

Uhhh, what?

I use y'all 'cus that's how all the kids in my school talked growing up.

I ditched a lot of the lexicon because after my family moved to the suburbs, I got made fun of by my new friends, literally calling me "less white". So no more finna', for example.

I will die on the hill of having a good second person plural pronoun though.

Once you've used English with a second person plural pronoun, you can't go back.

PS: "Yous guys" doesn't count

"y'all" is a bit fraught in the US because (incorrectly, in my opinion), in some parts the use is associated with certain unflattering cultural stereotypes. Not usually racial ones.

> I will die on the hill of having a good second person plural pronoun though.

I'm with you there -- we really need one, but I haven't found one that is broadly safe to use.

If you actually grew up using it, then you're not who I'm talking about. The word, like "folks", has become part of the affected dialect used by corporate ass-kissers to tell other corporate ass-kissers what they're about. Used primarily by slimy management, HR and PR types.

These types do not say finna, that isn't part of this affected dialect. If you say finna then you're not who I'm talking about.

…Okay, again, I really need/want there to be a gender-neutral plural familiarism like "guys", though, and "folks" fits great....

Here in the rural parts of Ontario (well not in my rural part of Ontario, but further north), that pronoun is "youse"

As a long boy visiting from Alberta I was astounded that this existed.

It might be dying out tho

Exists in Australia, has connotations of rural government (un)education, youse can rip it from my cold dead hands because plural second person is fabulous.

> I's the by that build the boat.

> You's the by that sail 'er.

— Wait, that's singular.... I think? Does it change again when you go further east? ....Or actually, is the second line also "I"?

My take is that "uneducated" people with "undisciplined" language spontaneously create their own plural second person pronouns wherever they go because, well, the language has needed them ever since they were lost from Anglo-Saxon ("ge", pronounced "ye").

I vote we just bring back this "ye" and make it official.

Ah, indeed. The plague of prescriptivism, as a gross exclusionary method of filtering social status, holding us back…

Look, it's either "y'all", "vous", or bringing back "thou" for the singular, okay?

Looks like yoavweiss was slaughtered, not the good-faith nerds.

I don't think they were. After reading this my view of this person is just a corporate drone. Obviously this proposal is to serve the content owners, not the users, whatever the thoughts behind it are. And yes it may not be intended to block adblockers but it certainly can easily be used for that once it's ubiquitous. Attestation which is basically what this is, always implies a move of some measure of control from the user to the content or service provider. It exists purely because they don't trust the user. There is just no way this would have ended positively.

And why would I go into discussion with Google? They don't own the web and never will. And their business model means they (and their employees) will always be my enemy because their goals are opposite to my own. I can criticise but it doesn't have to be constructive. A "Just NO" is fine too. I would be very happy with a world where Google doesn't exist.

But in this case the nerds won which means the way it was done worked perfectly fine. Perhaps they will have stepped on a few toes at Google but I'm kinda glad to hear that.

Even more simply: let's not get dragged into debating the technical merits of something which is philosophically wrong. That particular person was trying really hard to reframe the whole argument into terms that would work in Google's favor -- if we just pointed out what was technically wrong with the proposal, why, they'd just fix those things and then we'd be good to go. But, it was philosophically wrong, because we've all understood the web to be fundamentally open and anonymous and not controlled by any one entity [1] for decades and most of us want it to stay that way. Even if WEI was technically sound, it would still be an enormous erosion of the principles of an open, anonymous, decentralized web. Any attempt to argue against WEI on its technical merits alone was just allowing Google to drag the whole fight into favorable territory.

> And why would I go into discussion with Google? They don't own the web and never will.

Oh, I think this is a big mistake. Google very nearly does own the web. Gmail handles, at last estimates, between 45% and 60% of email traffic, depending on who you talk to. Chrome or Chromium gets somewhere around 65% of the global browser market. Google gets around 90% of search traffic. Google ads. Google domains. YouTube. Google Cloud, which WPEngine for example runs on. Google Docs. Chromebooks. Android.

I really need more people to pause and reflect for a moment on just how much of the internet is currently owned by Google.

[1]: Well, ignoring ICANN, or Microsoft, or Google, or Cisco, or...

Hey, look, it's the bad faith optics war again.

So we can take that yoavweiss_ character as a Google representative.

if it walks like a duck, and it quacks like a duck, it must be a...

This person does not hide the fact that they work for Google (at least that's why take from their about page), so yes, they represent Google. Because if there's anything that was beaten into me in my time at Microsoft, it's that you can put all the "views are my own" in your posts you want, but probably most people that read your post will take you to represent $COMPANY's views no matter the disclaimers.

Which is why when I worked at Google the advice was basically STFU. You'll end up saying something you will regret in some fashion. Either make yourself look like an idiot, or the company, or both.

But I quit so now I get to trash them all I want.

Vivaldi (from the 3rd link) also posted an update today:

Hot off the press, we have learned that Google is not proceeding with its Web Integrity API.

This is massively positive for the neutrality of the open Web. Though of course, with Google being so heavily driven by their interests rather than the benefit of the Web in general, it remains to be seen (and we strongly suspect it won’t take long) what they choose to replace it with. Are they, for example, just preparing a seemingly less obnoxious spec that is actually just as harmful to users (as they did with FLOC and Topics)? It also seems highly suspicious that it coincides with their very recent announcement to move from pay-per-click to pay-per-impression for ads.

Generally, Google hasn’t shown itself to be a trustworthy custodian of the web and we can’t let this apparent victory lure us into resting on our laurels. As always, a strong diversity of browsers and browser engines is going to be crucial to counteract any future attempt by a single party to dictate the future of the web.

The world needs to stop looking to a global data broker who feeds data to advertisers as a legitimate and good faith steward of Web technologies.

It violates the separation of concerns between server and client, for starters. Clients are user agents, i.e. they do what the user wants, not what the server wants. This fundamental misunderstanding/skewing of perspective is part of the problem.

If we want HTTP(S) and friends to remain a free and open protocol for all, we have to cut Google out of the decision-making process. They've been behind Encrypted Media Extensions, they've been behind Manifest v3, and now WEI.. The Web doesn't belong to Google. They can go do QUIC and leave HTTP alone.

> Android WebView Media Integrity API is narrowly scoped

I don't see any benefit to the user... Surely any app which wishes to embed a webview can simply add an api to said webview with native code to use existing android integrity API's?

To me, this looks like a backdoor way to prevent people making "hacked" apps which, for example, play youtube but without ads. This API doesn't benefit the users.

It's not intended to benefit the user.

The benefit to the user is they can supposedly "trust" the content that is being shown in the webview is, in fact, owned by or affiliated somehow with the app. They don't give an example, but i'd imagine its something like: "bad app lets user's sign into their bank account through the app's webview, then webview scrapes/intercepts content to do as they wish".

Isn't that something that should be solved at the App Store and/or application fraud detection levels?

I get bad actors exist.

But they're not an excuse to strip everyone else of rights.

>> The Android WebView API lets app developers display web pages which embed media, with increased control over the UI and advanced configuration options to allow a seamless integration in the app. This brings a lot of flexibility, but it can be used as a means for fraud and abuse, because it allows app developers to access web content, and intercept or modify user interactions with it.

This proposal was always a stick of dynamite when a screwdriver was needed.

Start with the assumption that a user client should be able to do whatever the user decides it should. And while keeping that in mind as an absolute, work backwards.

If it creates false ad clicks... tough. Deal with it.

And if it drains people’s bank accounts because they aren’t savvy enough to know that their bank’s app is realbank not realbankofficial? Deal with it?

The stance that other people should have their savings stolen, when we could have easily stopped it, because of nebulous freedom reasons is pretty ghoulish.

Perhaps the solution is to have two classes of machines, some "safe" for those who don't want to (or can't) be proactive and alert to security threats, and some "unsafe" for those who want total control over their machines and are willing to take on the security risks and responsibilities to do that.

I mean, yes. 1000% yes.

But the reality is that the 'market' will push to only make content for the "safe" machines, and the total control folks will slowly get locked out.

Banks have required auditors that will mandate only allowing access from 'safe' environments Media companies will do everything to make sure content is only played in 'safe' environments Government will allow allow you to interact with their technology from 'safe' environments, etc.

And they will all believe 100% they are doing the right thing to protect the users.

I am deeply afraid for open general purpose computing.

It's economics.

If "safe" means ceding control, and there's a business model by which I can make more money if the user cedes control (e.g. enforcing DRM), then I can subsidize the "safe" version and sell it for less than the total control version. I'll make it up on the backend.

If they installed it through a commercial app store, hold the store owner liable as an accessory to fraud.

> And if it drains people’s bank accounts because they aren’t savvy enough to know that their bank’s app is realbank not realbankofficial? Deal with it?

But... will this proposal stop that from happening? I think with every tradeoff between security and freedom, before we get into the philosophical questions we have to ask, "are we getting security from this tradeoff."

Tbh, it is not clear to me how this improves security. The way I'll drain your bank account is by setting up a phishing site and proxying requests to your bank. That's how I would do it before this proposal, and it seems like post-proposal that would still work exactly the same way?

I don't feel like I've seen enough information yet about how this is going to work to be able to confidently say that this is going to improve security.

This is not how bank accounts work at all. "Regulation E". Bank accounts are not bearer bonds, and the system is not meant to be impervious to unauthorized transactions. Your vulnerability/responsibility essentially ends at checking your statements for unauthorized transactions.

> This is not how bank accounts work at all.

Of course it is.

It is allegedly the case that you are correct. It is actually the case that using the system is incredibly painful, and hard to understand, and lots of people end up in a terrible situation because of it.

Resorting to what appears as a moral high ground by labeling any dissenter with extreme negative attributes is, in essence, a shaming tactic intended to stifle opposition. This method is prevalent in political discourse, where extremists might brand those who disagree with them with the most severe moral condemnations available.

The reliance on such shaming suggests that the accuser’s arguments might not withstand critical examination. Instead of yielding to this intimidation, intended to silence dissent, people should recognize these tactics as signs of argumentative weakness and a questionable moral stance. True morality, in contrast, supports the free exchange of ideas in a secure environment where all perspectives can be considered.

Hostile tactics like these often betray an immoral position by those who employ them, despite their attempts to claim moral high ground. Their quickness to suppress dialogue through shaming undermines any claim to ethical superiority.

Recognizing these tactics should prompt us to steer the conversation towards more constructive, open engagement, rather than engaging with any of the points raised in the moral intimidation directly, and question the robustness of the positions of those who resort to such methods.

They could protect against that easily by simply adding a header to all outgoing requests saying "this request originated from com.appname".

If a website didn't want to be embedded in that app, the webpage could refuse to let the user log in.

The whole thing is a bit moot, because any app can just implement their own web renderer or just fake the login screen to Chase.com entirely to get the users creds.

> The benefit to the user is they can supposedly "trust" the content that is being shown in the webview is, in fact, owned by or affiliated somehow with the app.

You got it backwards. The user gets to trust nothing.

The “trust” in this case is for the server to asses if it a trusted (not hacked/hackable) environment to deploy content to.

DRM is the only use case.

This is incorrect. If Chase uses attestation then only the Chase app can access their login site. It prevents DefinitelyChaseAndNotMalware from masquerading as Chase.

Well, no, at best it prevents DefinitelyChaseAndNotMalware from directly proxying Chase; it doesn't do anything to prevent someone... for the sake of argument, screenshotting the real Chase site and login flow, and serving that up to the user. It trades completely undermining user freedom and control for a minor increase in friction for bad actors.

It forces them to do the much harder to do and easier to notice work of making a fake login page. This is easier to detect with static analysis (bouncer) and allows the easier path of taking down fraudulent apps via DMCA request. It also means that the app won’t actually work for what users want it to do, which leads to low scores which harm discovery and push people towards the legit app.

This is anti-fraud 101, forcing the bad actor to do more work makes the vector less viable. All anti-fraud tactics are about making an adversary do extra work.

> It forces them to do the much harder to do and easier to notice work of making a fake login page.

Are you sure it's more work to take a screenshot and stick it in the app vs building a wrapper that pulls data out of a site? It seems easier to me, though I grant it's marginally easier for the user to notice.

> This is easier to detect with static analysis (bouncer)

Unfortunately in this world your automated scanner is trivially blocked by the server because WEI forces your scanner software to tell every single site exactly what it is.

> and allows the easier path of taking down fraudulent apps via DMCA request.

If the authors get tired of playing whack-a-mole, they can just put the content in the app itself.

> It also means that the app won’t actually work for what users want it to do, which leads to low scores which harm discovery and push people towards the legit app.

Yes, that's true; the optimal flow would be to fake the login to capture credentials, throw a nonsense error, and then redirect to the clean/unaltered page for real login (which the user sees as "log in, get weird error, try again as prompted, it works, move on with day"). And that is more friction and easier to catch, but not that much.

> This is anti-fraud 101, forcing the bad actor to do more work makes the vector less viable. All anti-fraud tactics are about making an adversary do extra work.

Sure, but tactics that destroy user freedom for a tiny benefit deserve to be thrown out.

You should reread more carefully, you clearly don’t understand the points you’re replying to.

So then this is just an end run by Google around their own shitty vetting for their appstore... If the central tenet here is that people will be downloading fake apps to try to get people's login information at the bank, it its Google's responsibility to make sure those apps never make it into the app store.

Chase also could require an authentication code from any Big3 Auth app or roll their own auth app that should be installed alongside the banking app, which will call down to it upon login.

> its Google's responsibility to make sure those apps never make it into the app store

Good, we agree, they should take this action which helps them keep fraudulent apps out of their App Store.

> Chase also could require an authentication code

Chase does require that. It doesn’t help here, because you can obviously phish codes just as easily as passwords. The solution here is attestation, anything else is a hack that makes bad behavior much too easy.

> The benefit to the user is they can supposedly "trust" the content that is being shown in the webview is, in fact, owned by or affiliated somehow with the app.

How so? Phishing sites will still work. Okay, let's say I can't embed a bank's login form into an embedded webview. I can still embed a login form that looks to-the-pixel identical to the bank's login form. I can still proxy requests to other servers (even though Android natively).

My guess would be that webviews are strictly easier than a normal browser to do a phishing attack in because they don't display the domain of the page they're visiting to the user. It's not immediately clear to me how attestation to the server would change that.

The "trust" in "trusted computing" is very much the reverse. In this threat model, the user is considered an adversary. The device and its software is built such that the corporate server could "trust" that the device isn't acting in user's interests, instead enforcing the corporation's business model.

DRM schemes, especially when they masquerade as public service, rarely are.

Do you really believe that the ability for people to play YouTube without ads benefits the user? I mean, it sounds great on some level.

Perhaps browsers should just ship with ad blocking by default. Everybody the world over can use the internet and have a better experience without anybody ever seeing any of those pesky paid ad things.

I think there are some end-user benefits, but they're more side-effects than the reason the technology was invented.

What is the basis for assuming that something like this was created in bad faith?

>Do you really believe that the ability for people to play YouTube without ads benefits the user

Umm, yes? Google themselves even offer this as a product: Youtube Premium.

My impression is that it's not people paying for Youtube Premium who are complaining about Google targeting people with ad blockers. I suppose Netflix used to offer only paid, ad free video streaming, so it isn't really out of the question for somebody to wish that were youtube's model; however, I can't help but imagine that if YouTube said they were switching to that most people on this site would be even more upset.

> To me, this looks like a backdoor way to prevent people making "hacked" apps which, for example, play youtube but without ads.

More like "impersonate your bank and steal your login credentials". MitM attacks using interposed clients are a genuine threat outside the Apple and Google walled gardens (and even a little bit within). WEI was an attempt at solving a real problem.

Now, maybe it had unacceptable side effects, maybe it was more harmful than useful. And now it's dead. But the underlying issues got completely lost in the hyperbole wars around here. People were wildly slinging accusations of secret agendas and general bad faith[1]. It wasn't our finest moment as a community.

[1] Most of them while typing said comments on an Apple device objectively even less friendly to nonstandard clients!

You’re being downvoted at the moment, but this is absolutely true. Fake bank apps are a huge problem, which this addresses.

It absolutely does not. The ability to craft a realistic phishing login page is unaffected by Google's proposed MI API.

Crafting a fake login page in your app is a totally different problem than transparently proxying the web interface. First, if you copy the login page those assets are in the apk. This is easily detectable by bouncer and allows those apps to be denied (this happens today). Second, stealing the assets opens the app up to dmca takedown, which also happens today. Third, and most importantly, if you reverse proxy the page then the app will appear to users to actually work. This is crucial for the bad actor as it keeps the app from having a low rating in the App Store for not working. When they just steal the login page, the app gets downvoted quickly for being “broken”.

All of this adds up to making the bad actors have to work much harder, which is the goal.

> First, if you copy the login page those assets are in the apk.

You don't need to store the assets in the APK if you can load a webpage.

> Third, and most importantly, if you reverse proxy the page then the app will appear to users to actually work. This is crucial for the bad actor

You don't need to show the working bank app if it isn't advertised as one. Name it "Government assistance program" with "application process" requiring logging in with bank credentials (to confirm identity, because bank knows who you are). Then you can make it more convincing by adding some bs forms and stuff like "your application will be processed in two weeks".

I saw this stuff already implemented and used. They can add as many integrity protection layers as they want, but it won't trigger one. So it looks like a measure to say "bank apps are safe now we are great guys" without real effect.

I'd say that it may increase login thefts because users may get a false impression that anything they will install is safe now.

Google tried to take actions that would trivially lead to the end of the open web and enforce complete control over the software people ran on their own hardware. You can't accuse people of "hyperbole wars" when the worst-case is realistic (and indeed most likely).

> Google tried to take actions that would trivially lead to the end of the open web and enforce complete control over the software people ran on their own hardware.

So did Apple though, years ago. And no one freaked out like this. It just seems like maybe the argument is about something else.

People did complain about Apple; fewer because it's harder to get press attention about Apple on privacy issues, but it's pure revisionism to say that Apple's attestation systems weren't criticized.

This is how HN reacted to Apple's announcement: https://news.ycombinator.com/item?id=31751203

I have my own set of negative comments in that very thread where I literally call Apple's system DRM. So do I pass this ridiculous "hypocrisy" check well enough now that I'm allowed to complain about Google killing the Open web?

It's arguable that the "open web" will exist for as long as Linux and KHTML exists. There will always be agnostic choices available, even if people choose outdated, locked-down or underdeveloped devices. Unlike the situation with AdSense, I'd argue it's really hard to identify any potential harm in this scenario. Multiple companies (Apple included) have also built their own remote attestation services, and nobody cried bloody murder then.

If you think this is bad, then I regret to inform you that your war is probably lost. Maybe give GrapheneOS or Lineage a try?

I am literally typing this on a LineageOS device; I don't see how that helps, if anything it just highlights the problem. The problem is that WEI, in any form, is most likely to be used in a way that results in websites blocking my device because I'm running my own operating system. And I'm pretty sure people did in fact cry bloody murder when Apple started doing it, but at least Apple was small enough percentage of the overall web browser share that nobody was going to try and mandate a feature that only they supported, unlike Chrome.

Edit: In short, the open web relies on being able to run any client you want; having KHTML doesn't do any good if sites block it.

> Multiple companies (Apple included) have also built their own remote attestation services, and nobody cried bloody murder then.

HN, at the time, crying bloody murder about Apple's attestation system: https://news.ycombinator.com/item?id=31751203

This argument keeps getting brought out about Google, but in reality people are critical of iOS and Apple all the time. Yes, it is harder to get widespread reactions from people who are disengaged from web standards because Apple doesn't have Google's reputation. Yes, people tend to be more worried about Chrome than Safari in part because Safari is sitting at 20% market share.

But people do (and did) criticize Safari. It's not separate standards; if you pay attention to the people who are most engaged on these issues, Apple's DRM systems get criticism.

> If you think this is bad, then I regret to inform you that your war is probably lost.

There's an awful lot of gust in that sail, and yet no wind... Got anything to back it up or are we just being a corporate sycophant?

It seems pretty straightforward to prevent that anyway, through Play Integrity attestation. This just makes it easier to do with a webview-based app.

I don't understand how this works.

> The new Android WebView Media Integrity API will give embedded media providers access to a tailored integrity response that contains a device and app integrity verdict so that they can ensure their streams are running in a safe and trusted environment, regardless of which app store the embedding app was installed from.

But this only applies to the Android WebView API, not standalone web browsers like Google Chrome. Otherwise we'd be back to where we started with the original Web Environment Integrity proposal.

But no one has to use the WebView API, it's a convenient option but Chromium is open source! What stops Bob the Evil Android Developer from compiling his own version of Chromium, bundling that into his app, and doing whatever malevolent website trickery his ink black heart desires?

Put another way, if this is only built into the special WebView API, wouldn't a malicious developer just avoid using that API?

All this is about attesting authenticity to the server.

But only Android WebViews can attest their authenticity. Are servers going to block standalone web browsers?

If they are, why even use a WebView? Just make it part of your app.

Many corporate apps in e.g. banking are just Cordova/browser wrappers around a website.

A lot of "native" apps are just thin wrappers around web components, since it's a lot cheaper to develop.

Okay, thanks. So then this truly doesn't affect websites at all, it's for apps which work like websites behind the scenes, but whose content no one is ever supposed to access from within a web browser anyway.

I can live with that!

Can you live with that? What about when your rooted, or out of date, or LineageOS phone won't be authenticated and your banking app doesn't work? Or Uber or the scooter app or the social network?

What about when Google in 10 years requires some absurd personal identity verification for WEI, perhaps because xy or z union of states decides to require it?

These security apparatuses are checks that nations and leagues of nations will not resist meddling with, once the hooks for control are on place.

I already live with that (and life is fine).

The situation with SafetyNet isn't great, it's just... not new? It's not pushing us any further down the path than where we already are, and it's not corrupting the open web (because mobile apps aren't a part of the web).

I've posted elsewhere about this as well, and I think it means the WebView Integrity solution will effectively do nothing. It just won't solve the problems Google is trying to solve. The bad actors they want to route out will work around it, so even if websites implement it, the fraud or other bad behaviors they describe will continue mostly unimpeded, because the websites literally cannot block unattested access (because all legitimate non-WebView browsers will be unattested)

Step 1: Cryptographically fingerprint an attested environment, for one method among alternatives

Step 2: Ban the alternatives

Step 3: Profit

I appreciate your succinct explanation regarding WEI—it highlights the core issue effectively.

I’d like to expand upon your point, not to contradict, but to further explore the implications. I’m encouraged by recent announcements suggesting a shift away from policies that could hinder browser user agents.

I believe Google’s actions represent a compromise with media IP owners, who were instrumental in the initial advocacy for these changes. By limiting technological controls to Android, Google appears to appease media stakeholders while avoiding restrictions on the open web, despite their dominant browser market share.

This issue is particularly pertinent to me since my business depends on the freedom of alternative browser user agents to access the web unimpeded. While some might argue my stance stems from self-interest, it does not diminish the value of an unrestricted web.

My product, BrowserBox, is designed to circumvent web content embedding restrictions on both mobile and desktop, eliminating the need for a Webview tag. Hence, Google’s approach doesn’t concern me personally.

In fact, I view it as a positive—if it deflects media companies’ pressure from the open web.

Furthermore, if Android’s technology faces constraints, people might look for other options, and BrowserBox stands as a prime, open-source choice. It’s a low-maintenance solution compared to others, like proxy-based DOM mirroring, which often result in site breakages and require constant, costly tweaks.

As video streaming bandwidth becomes more affordable, the operational cost advantages of these alternative solutions diminish. High-volume operations can leverage colocation services with unlimited bandwidth, further reducing concerns over data transmission costs.

The title is misleading. They've dropped the proposal as applied to Chrome, but are still pursuing it for the Android WebView API, which is basically a wrapper around Chrome.

Webviews are particularly vulnerable though, being used for embedded logins for sometimes dubious 3rd party apps.

Is there a reasonable angle to view this from?

I personally don't think embedded webviews should be allowed general browsing capability unless they are part of a standalone browser.

It's usually a trick to capture traffic that would otherwise go off to the open web.

If that's the problem you're trying to solve, disallow embedded ~~logins~~ webviews and do it through a proper browser, same as on a regular computer. The other way seems overkill and smells like foul play to me.

I'm not sure how you disallow embedded login without disallowing embedded webviews. The line is very blurry.

I'm sorry, I wrote embedded logins but was thinking embedded webviews in general. The only legitimate use of that in my mind is "a web browser app that's a usability skin over Chrome". Everything else is just a way of keeping you in a walled garden, and would be better if it just sent you to your default browser.

Ok. So I think we are in agreement. I struggle to think of a use case that is in the user's best interests.

You have two types of webviews... "Webviews to the appmakers server", and "Webviews for the wider web".

Webviews to the appmakers server need to be authorized by some manifest file on the server whitelisting the app identifier.

Webviews for the wider web don't allow the app to know what's going on inside the webview, nor interact with it. So these are safe to type passwords into etc.

So this would have no effect, because you can simply embed Chromium in your app instead of using the system-provided WebView. Because Android is very fragmented and there are still a significant amount of devices out there running less than Android M when the web view was made an upgradeable package, there is, at least for now, a very legitimate reason to ship your own browser implementation within an app that is primarily implemented using web tech: The Web View implementation shipped with M and earlier is not sufficient to run such an application.

> disallow embedded logins and do it through a proper browser

How would you propose doing this from a technical standpoint?

How is android supposed to know what an embedded login is on a web page?

What happens when you're in an SSO or other secure environment and need to refresh credentials after a redirect?

Is Friendly Social Browser maybe a good solution to this problem?

> being used for embedded logins for sometimes dubious 3rd party apps.

That's a difficult problem to solve though. To do it properly you'd need something like Windows' secure key sequence (ctrl-alt-del) which apps can't intercept. Otherwise there's no way that a user can know that what they're seeing is the system rather than a malicious app.

Consider that any app can embed any browser or UI that they want.

That exists on mobile though... They could easily have a "swipe down to login" gesture, where you would see some system UI saying "Appname wants your password to foo.com, do you want to allow the app to log in using your saved password?".

foo.com could also cooperate and allow the message to say:

"Appname wants to 'send pokes' on foo.com, do you want to allow this?" - allowing the app a scoped login to only specific actions.

Yeah an edge swipe could work. It would be difficult to introduce but Google doesn't seem to shy away from forcing app developers to make big changes so who knows.

Of course a malicious app could still just show a webview and make you type the password in. The above solution would only work if everyone uses a password manager and showing a webview becomes way more suspicious than it is now.

Official confirmation in the WEI public discussion thread: https://groups.google.com/a/chromium.org/g/blink-dev/c/Ux5h_...

Great. Really dodged a bullet there.

Not really. More like the entity pointing the gun has now decocked it.

The scary part is that there is a single entity with that kind of power to begin with. It's a testament of the failure of the modern web, and how far it has strayed from the original spirit of the internet.

This is the point. Let’s celebrate a reduced scope implentation on a more limited number of platforms until we perfect the technology? No. Not really a victory. Just a pause.

Mostly because most people don’t care about the original spirit of the internet. As long as they can get their job done, consume entertainment, and play status game, they are content. Which is why for most people, their internet is just a handful of tech companies. It’s basically Minitel, but fueled by ads.

what's a "status game"?

I spent way too much time wondering the same thing. Maybe social media?

Not a native speaker. My definition of status game is jockeying for social position. On the internet, it is trying to get the maximum “points” for your posts (views, likes, retweets,…) instead of sharing for the content itself.

I think that sounds close to "popularity contest".

They are still making it easier for developers to create apps that limit what you can do with your own hardware.

Yeah I wish they would not have.

However, it does eliminate this issue for 90% of my usecases. The apps that will want to do this stuff I probably won't even want to use anyway.

Until next time, for the sake of the open Internet we can't stop pushing back. It's exhausting.

Never back down, never what!

It only took "privacy sandbox" what two, three years too cool off before it was rolled out to everyone? They're a big company, they'll wait you out.

Repo has be archived - "NOTE: This proposal is no longer pursued."

https://github.com/RupertBenWiser/Web-Environment-Integrity

Click on "Issues" for a good time.

Probably started working on some more cryptic solution already.

Probably, but I will take this victory. Google has power to make this happen.

> Google has power to make this happen.

they will have more power once current anti-trust trial will be over.

I mean this is the problem with the entire situation. I immediately read the article looking for any evidence that they would abandon the direction of the idea rather than do what Google does sometimes and roll out a POC on some other less controversial part of their infrastructure and then come back to it when the timing is more right (like after a large cybersecurity event happens, mark these words). They did exactly that. They rolled it back to the Android team and promised to perfect a smaller effort in a less controversial sandbox but rest assured they are publicly saying only that they are retiring the effort for the web for now.

I really wish Google would go back to being the champion of the Open Internet I once knew them for and step away from the MBA’ification of everything they keep trying. Seems like the moment they dropped “don’t be evil” they started going there. It’s exhausting.

Instead of celebrating a victory, every one of the Open Internet crowd gets to celebrate a smaller project execution and nothing but a pause in the web platform version of it. Yay.

> They rolled it back to the Android team and promised to perfect a smaller effort in a less controversial sandbox

Conveniently this also seems to mean (assuming I understand the announcement correctly) they get to roll it out for the webview and finalize everything without going through the web standards process and without dealing with any community feedback because it's not technically a web standard anymore.

They get to build a working implementation in Chromium (oh, sorry, not Chromium. Android Webview, an entirely different browser that just happens to be based on V8 and the same rendering engine, but is definitely not Chromium) and they get to make sure everything is working and even get websites using it for webapps. And then if they come forward again to standardize it they can say, "look, developers are already using the API so we're not going to change anything, and it's not controversial, and we're just slightly expanding it so that browsers are all compatible with each other, so it's fine if we just launch this in Chrome and ask the standards committee to sign off, right?"

This is part of what's concerning about 'open' platforms like the Web; large and influential parties inevitably end up steering things to serve someone's bottom line somewhere.

I'm beginning to think we need hard forks of the Web, because we already have two "spheres" of the Web: the JS-heavy sites-are-apps Web, and the documents-and-links Web. The former can be argued to be a superset of the latter, but with continued anti-user efforts coming from that crowd and their diametrically opposite endgoals compared to an open platform... what real choice do the major parties have but to part ways...?

Original title:

“Increasing trust for embedded media”

> Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.

https://news.ycombinator.com/newsguidelines.html

The original title is misleading.

The original title is misleading enough to be incoherent.

Read in the voice of a Sith master: they have learned their lesson well, my young Android apprentice.

This title is also misleading. Google backs off on WEI in Chrome, but still pushes it in the webview, thus making it easier to create apps that limit what you can do with your own hardware.

Actual blog post title is, "Android Developers Blog: Increasing trust for embedded media"

True, but that seriously buried the lede. Sorry for the edit.

Why not post the repository instead of editorializing?

If dang thinks that’s better, fair enough.

"WEI" isn't used on the page.

They used Web Environment Integrity in the post, not the acronym. They did tag it WEI as well.

The guidelines are there to guide and mostly folks try to abide. I'd agree this is a case where a useful edit is the better option.

I like the edit. That dull blog title would get ZERO traction.

Caveat that I'm by no means educated about WEI, the actual title feels a bit Orwellian to me. I just wanted to point out the actual title and not an editorialized one (without commenting on whether editorialization is good or bad here).

In case this is all new to you: effectively WEI aimed to bring hardware-based remote attestation to the web for the purposes of allowing servers to refuse service when the device and its software was not approved by the authors of the server.

Now they just want to do it in WebViews, which is ineffectual at best, and still harmful at worst.

but if the title is "Increasing trust for embedded media", where's the intent to back off? The changed title implies everybody can stop worrying.

It’s funny how techies complain about clickbait yet celebrate and engage with… clickbait

We just want the headlines to somehow reflect what we will see if we click on them.

I don't think you know what clickbait is, because "accurate description of the main content" is not clickbait.

probably better off picking some language from the article in those cases (the original title is almost certainly worth an edit) which has a higher chance of avoiding explosion of title meta and less likely to be wrong in some minor, title-meta-generating way

Great way to bury it now... WEI being killed should be celebrated, great win for the HN crowd

Reading between the lines:

They're leveraging their monopolistic position to force APIs into an "open source" project to prevent users from skipping ads.

> In contrast, the Android WebView Media Integrity API is narrowly scoped

I guess it means that at some point I won't be able to use many apps under GrapheneOS with its Vanadium WV?

This is really good. Google did the right thing. We don’t need to thank them for acting the way they should have originally, but we can appreciate it.

I have been walking around with this dread ever since the proposal was announced. Thinking about its implications made me appreciate even in today’s screwed up internet we still don’t have it that bad.

Major war on general purpose computing vibes resumes

'It's in the users best interest to not let them bring their own computer & have to use a Google approved computer because [fill in corporate doublespeak bullshit here]'.

Fwiw, the whole system of native apps have dealt with this hlkind of crap forever & it's expected. An old super small native app we had failed pen testing because it would run on jailbroke devices. Google Play SafetyNet and probably three other frameworks on Android all exist to make sure users don't have ownership of devices.

So this is basically a Google Project Fugu effort, but the dark side. the web should be capable of doing everything native apps do, even when that thing is placing a huge boot on the face of users & rejecting their user-agency. Womp womp.

Also, notably, Apple already shipped a just as bad implementation of PrivateTokens where websites can ask Apple to make sure the device is legitimate. I'm not sure why Google built a new spec, why they decided to be a huge lightning rod for this, a lightning rod with much less cover from publicity, as instead of being a generic attestation system (and relying on Apple having dominion over their platform in a way Android lacks), it's a very narrow attestation system about device integrity. https://httptoolkit.com/blog/apple-private-access-tokens-att...

So... it's being implemented anyway, just only for the embedded browser?

This doesn't make me feel better. And it's a very Google type of answer to give: announce that you're moving forward anyway, but pretend like you're listening to feedback and giving everyone what they want.

It's annoying that the entire retrospective is two sentences. Still no conversation with the dev community of course, just two sentences that say it's not being considered and we move on. And it's convenient that the new API is no longer a proposal, it's just an internal program that Google is building on their own.

----

Off the top of my head, I think some of the concerns here still apply? Not all of them, this is better than the original proposal, but this is now dividing the web up into webviews that are supposedly only going to work on Android? Because iOS I don't think supports this kind of thing -- maybe I'm wrong though. We still have this inversion of the Open web where clients attest DRM capabilities to the server, which is not how the web is supposed to work. But I guess that's supposedly OK because the idea is you'd only use this API on a site that was only ever intended to be viewed in a webview for a single app? I'll admit I don't know how common that is.

And all of this to paper over embedded web views, which arguably should be used less on Android anyway. I don't know, that could be a long conversation; but the point being I'm still worried about the announcement -- less worried, but still worried.

It's both so weirdly narrow and so unsuitable for the goals that the original proposal outlined that my most cynical side almost feels like it's being done purely because Google doesn't like complete capitulation and wants to have the last word? But it's also still so weirdly antithetical to how an Open web works (even within that very narrow band of apps it would apply to) that I can't shake the feeling there's some horrible side-effect that isn't immediately obvious to me.

Of course I don't know the details or whether or not it'll all be fine; maybe this will be nothing and mostly won't matter for anything. It's hard to tell because we're no longer talking about a standards proposal as far as I can tell. It sounds like Google is just going to do this internally and roll it out to small numbers of partners and then will launch it and that will be that, no community feedback required. Which... :shrug: not having your attestation plans be publicly available to comment on is definitely a way to avoid criticism, I guess.

Web Environment Integrity (WEI) is a controversial API proposal currently being developed for Google Chrome.

https://en.wikipedia.org/wiki/Web_Environment_Integrity

It’s interesting that a single googlers repository was what was being used for wei discussion instead of something more “official”.

People celebrating this aren’t realizing that it’ll probably stop api scraping via a web view back door.

This way, they can hide it in another repo later

This blog post is how they should have started the discussion about WEI, but better late than never.

That being said, while I can somewhat understand the use case for preventing fraud, misconception of source, etc, what we're talking about effectively kneecaps the ability to write bonafide Android browsers that leverage the WebView engine, while doing little to prevent the fraud and abuse the proposal intends to solve.

If you are an Android browser author, you certainly can ship your own browser engine, unlike on Apple's platforms where that's still prohibited. However, if your motivation for creating that browser is primarily around the user experience or other "over the top" features, building your own browser engine simply because WebView cannot operate as a real web browser to your users, is unfortunate.

Meanwhile, as an app developer who is interested in engaging in fraud, misinformation, or other nefarious things, they _can_ ship their own browser engine to bypass this functionality entirely. Does it add more work? Yes, but if their goals include this bad behavior, why wouldn't they?

Even without all this, assuming that Chrome itself, Firefox nor anyone else will actually implement some kind of "this is definitely not a web view" attestation, the content owner has no choice but to allow that access, since they have no idea if the user agent they are looking at is a legitimate browser or an embedded webview.

Google, there is no way to solve this problem using attestation short of the original WEI proposal, which is bad for users. All you are doing now is muddying the waters and adding _some_ harm instead of _a lot_ of harm.

Sure, malware can ship its own browser engine but it can not attest authenticity to the server.

The proposal doesn't limit the Android WebView in any way.

Yes, but that's not sufficient.

If, say, YouTube would like to prevent an Android game from running an invisible and silent webview watching videos on YouTube.com (because some ethically challenged YouTubers paid them to help juice their view counts), YouTube could use the new web view integrity API to validate that webview, but if the developer ships an engine inside of that game and uses that instead of using the WebView, then YouTube cannot tell that its not just a third party browser. So unless they are going to block all third party browsers, which they can't actually do because the browser could be configured to emulate Chrome, and Chrome doesn't actual implement any kind of attestation...

So there's already a way to bypass what they are trying to do.

...for the time being, but them being the comic-book, mustache twirling evil villains they are there's no doubt WEI will be coming back, in a even more evil package, sometime down the line.

"We’ve heard your feedback, and the Web Environment Integrity proposal is no longer being considered by the Chrome team."

Instead we'll roll it out bit-by-bit with different names.

Sorry Google, too late, already switched to Firefox.

> backed off WEI

for now

Title should be:

“Increasing trust for embedded media”

There is a guideline against editorialising in the title

Glad to see the chrome team listening to feedback

"Google apparently backs off on WEI."

For the time being.

Can anyone summarize what WEI is an why its bad?

DRM for web browsing. A website would be able to request an attestation that your browser is “trusted”, i.e. it is secure and unmodified. Because some systems are by definition untrusted, e.g. Linux, or Firefox compiled from source, these users might be blocked from certain websites. At least that seemed like the intention, otherwise what’s the point of building such a feature?

If you want the "assuming good intent" explanation it was to be able to detect spam and bots which apparently are a significant problem now and are no longer stopped by captchas. One online community I'm part of literally turned off new sign ups because they couldn't stop the bot problem (ldjam.com). Users also find captchas annoying so it supposedly stop the need for that for many cases (except for when you're in the 10% hold out group or whatever)

There’s still no way to tell the difference between a Linux user and a bot through such an attestation mechanism. So the effect on users is the same regardless of the intention.

Sorry big G. You lost the trust on this one.

Doesn't matter, they've already showed their hand with how they're wiling to ignore everyone and try to push through whatever they want.

They’ve shown their willingness to ignore by… scrapping something that was disliked?

I imagine they're pulling the politician card. When there's a lot of pushback, you scrap it for optics, and then a few months or years later you bring it back under a different name and presented as something new and hope people don't pick up on it. And if they do, then you repeat until people are exhausted enough to not give any pushback anymore.

A.k.a. “Outrage fatigue”.

Google has been claiming to want to break adblockers (although they don’t put it that way) with Manifest v3 and removing Manifest v2 for a while and they have always backed off actually pulling the trigger on it.

I notice that this post's title hasn't been edited by HN mods for "editorialization." Why not?

bullying corporations once again yields results

... (for now)

should firstly explain what WEI is

For now.

Good

Good.

TFA is about more than just WEI, but it does address it directly:

> We’ve heard your feedback, and the Web Environment Integrity proposal is no longer being considered by the Chrome team. In contrast, the Android WebView Media Integrity API is narrowly scoped, and only targets WebViews embedded in apps. It simply extends existing functionality on Android devices that have Google Mobile Services (GMS) and there are no plans to offer it beyond embedded media, such as streaming video and audio, or beyond Android WebViews.

This is really great to hear, thank you Chrome team!

Is there a risk that this is one of those "shelve it for 6 months and we'll try again later" playbooks, and that already having the implementation will make it just "an expansion" of existing tech rather than "new" tech, which will make the pill easier for most people to swallow even though it gets to the same end result?

What does your heart tell you? Palladium[1] came and went and then suddenly most laptops and mobile devices have a built-in TPM today. No doubt history will repeat.

[1] https://en.wikipedia.org/wiki/Next-Generation_Secure_Computi...

Uhm… what?

Your beef is with things like Pluton, Intel’s ME and AMD’s PSP.

TPM at their base are nothing else than a more secure place to store cryptographic data.

It's a place that applications can store such data without my knowledge or control, and I don't trust applications enough to be comfortable with them having that ability.

Don't get me wrong, it's not a major issue for me, it's just uncomfortable. It just means I prefer my machines to not have TPM hardware in them.

I don't trust applications enough to have things like the encryption key for my hard drive outside a TPM.

I don't disagree, but how do you feel about you (the machine owner) also not having access to it?

That's my major problem with it; it locks you out of messing with your own machine data, which you can see being instantly abused by third parties to prevent modifications.

That feels wrong in some ways but it’s also the only way you can trust used hardware, or anything which has been compromised. I do get considerable value out of the resale value for my stolen Apple devices being much lower, and that’s probably a higher risk for most people.

TPM chips are pretty open. I had a look through the spec & API for tpm 2.0 a few years ago and there’s a lot of neat tricks you can do with them. TPM chips are an open standard with many implementations.

As far as I can tell, as a software developer you have full access to the chip. The only thing you can’t do with them (by design) is read the signing keys or generate secure boot attestations for machines which didn’t secure boot. I think you can even replace the signing keys entirely if you want to.

They aren’t a hard drive. They don’t store your data. And unfortunately I don’t think they’ll do much to prevent software bugs from causing problems. Particularly in the operating system, where software bugs can undermine the entire chain of trust model.

Don’t get me wrong; the idea of getting my computer to cryptographically prove it’s running in some locked down Xbox mode to be allowed to play Netflix or do online banking is quite the ask. The hackability of computers is one of their best features and I don’t want that genie to go back in the bottle.

But every time the conversation comes up there’s so much misinformation about them. People conflate tpm chips with intel’s management engine (which is secret and closed source), Apple’s secure enclosure (which I think can store some data?) and other stuff that works really differently.

> The only thing you can’t do with them (by design) is read the signing keys

That's why it makes me nervous.

That's pretty interesting. I wonder if replacing the signing keys could help negate DRM-y uses of the TPM

Doubtful. TPM chips come pre loaded with signing keys from the manufacturer. That allows 3rd parties to verify that an attestation made by your TPM is genuine. (They can do that by checking signatures all the way back to the manufacturer’s public cert).

If you replace the manufacturer’s signing keys with some keys you generated yourself, the only real effect is that your computer can no longer do remote attestations. So you can no longer convince any 3rd parties that your computer is operating in a “secure” mode.

> That's my major problem with it; it locks you out of messing with your own machine data, which you can see being instantly abused by third parties to prevent modifications.

It locks everybody, including the owner, out of any data it doesn't own. That's the point. If you can pull it out, so can anybody else, and you've just made a small hard drive. Could it be used by vendors for DRM-like things? Sure. That's on the vendor, though, and not the technology itself.

> That's on the vendor, though, and not the technology itself.

And that's the problem. I have little actual trust of vendors anymore. Too many bridges have been burned to trust by default.

I'm not storing my fingerprint anywhere else.

The problem isn't the cryptography, who's using it and for what. There's nothing wrong with it if we're using it to empower and secure ourselves. There's everything wrong with it if it's some corporation using it to protect themselves from us, the owners of the machines. The former is just normal user activity. The latter means our computers are not really ours, they come pwned straight off the factory.

They can store that data, but they cannot retrieve that data. That's because the data it stores are cryptographic secrets (private keys). If they store a private key there and then delegate encryption/decryption to the TPM, you can also ask the TPM to perform said encryption/decryption using that key as the system owner.

The entire point of a TPM is ensuring that private keys intended for a specific device are never leakable off of that device.

Now that being said, there is an additional function of TPMs that is more controversial, and that's how it can be used by the CPU and firmware to refuse to execute code when a chain of attestation coming from a root key stored in the TPM is not satisfied. That controversy is very valid for TPMs or other "enclave" devices which do not allow the system owner to change those root keys. And of course there is the extended ability to leverage this attestation over a network, to allow a _server_ to be able to refuse service if the attestation is not valid.

When the user can change the root attestation keys, I think local attestation is a net positive for the security of the user. When they cannot, it means that only the "blessed" builds from the hardware manufacturer can run. This second case should be made illegal in my opinion.

Though there's nuance here, remote attestation however is a net negative for the user. Taken to it's logical conclusion where unattested access is 100% refused without exceptions, it means that the user effectively cannot run their own software on devices that they own, and that is not acceptable. It also ensures that the user can only use hardware devices that the service provider deems as allowed, which is the more practical and likely outcome at scale.

Remote attestation is what's at issue with WEI (and indeed things like Google Play Integrity and the equivalent feature of Apple's iOS stack), not the ability to ensure that private keys cannot be leaked.

> They can store that data, but they cannot retrieve that data.

Right, which means software can engage in encryption that I can't decrypt because I can't get the keys.

You're right, RA (when the user can't change the keys) is a much more concerning thing. It can be used to prevent me from exerting full control over my own hardware.

My problem with TPM isn't really the TPM itself, it's that I have very little trust in software and so want to be able to keep a close eye on it and audit things as needed. I want to be able to do things like decrypt data streams sent over the wire, etc.

And, as I said, this is a relatively minor thing for me. Even writing as much about it as I have puts more emphasis on it than I would prefer. In practice, the majority of the software that I use doesn't even want to use the TPM, so it's all good.

Yeah. Intel SGX seems kinda similar and is or at least was used for DRM.

Don’t forget that the anti-TPM stuff comes from the guy, RMS, who opposes “sudo” because it serves to let a machine owner control and audit use of super-user commands, whereas just having a root password shared by multiple users gives anyone who learns the password the freedom to do whatever they want with plausible deniability. He has a very strange and quaint way of thinking but people uncritically parrot him without appreciating what his world-view actually entails.

Given that RMS has a pretty good track record or predicting the kinds of abuses that we're seeing today, it seems like a good idea to at least pay attention to his ideas and not dismiss them out of hand.

Also, you know, GNU.

For those that would appreciate context: Stallman did say this but the incident that he cites as justification happened _four decades ago_ and he wrote about it in 2002 [1]:

> Sometimes a few of the users try to hold total power over all the rest. For example, in 1984, a few users at the MIT AI lab decided to seize power by changing the operator password on the Twenex system and keeping it secret from everyone else. (I was able to thwart this coup and give power back to the users by patching the kernel, but I wouldn't know how to do that in Unix.)

> However, occasionally the rulers do tell someone. Under the usual su mechanism, once someone learns the root password who sympathizes with the ordinary users, he or she can tell the rest. The "wheel group" feature would make this impossible, and thus cement the power of the rulers.

> I'm on the side of the masses, not that of the rulers. If you are used to supporting the bosses and sysadmins in whatever they do, you might find this idea strange at first.

He was talking about a time-sharing system in an academic context. We have no idea what his thoughts are now, and it's logically fallacious to discount his feelings on what multinational corporations bake into their silicon on the basis of an experience that he had back when Van Halen was still topping the charts. It isn't exactly a secret that RMS is a bit "out there" - lots of historically-significant people are. Contextualizing their work and speech in a constructive way is preferable to writing them off wholesale.

[1] https://ftp.gnu.org/old-gnu/Manuals/coreutils-4.5.4/html_nod...

TPM at their base are nothing else than a more secure place to store cryptographic data.

One which you, as the owner, don't have the keys to.

If you use a mobile device maybe. My desktop machine has a TPM and AFAIK I do have access to load my own keys / replace the root keys. Of course, nothing says there isn't a backdoor within the TPM, but it's not this secret locked down thing.

It's unlikely that there is a backdoor on the TPM itself. The more likely scenario is that given a TPM serial number or EKpub the vendor could furnish a seed in response to a subpoena or warrant -- however, even this is unlikely, as it would make TPM vendors huge targets for hacking. Also TPM vendors make a big deal of how they don't keep TPMs' seeds, and I tend to believe them, because again if they did keep them then they'd be huge targets.

"Crypto AG's products being compromised is extremely unlikely, because that would make them a huge target."

Good point!

> One which you, as the owner, don't have the keys to.

One which nobody, not even the owner, can extract keys from. I don't understand why people don't like the fact that they can't pull keys out of the TPM. If you, the owner, can pull them so can anybody else. I know TPMs aren't invulnerable but you have to admit they significantly raise the bar of compromise.

What do you mean specifically?

You can:

  - set passwords on the key hierarchies
  - roll the seeds for the key hierarchies,
    thus invalidating *all* keys on the TPM

Now, Windows might stop working if you do that, and naturally, if you wanted to use a TPM for locking your filesystems then you'll need to do this _before_ you install your OS.

Also, once you change the seed for the Endorsement Key hierarchy you'll lose the ability to prove that the TPM is a legit TPM made by whatever legit TPM vendor.

So sure, this is only something you do if you know what you're doing, especially if the TPM is soldered onto the motherboard.

Yes and according to discussions at that time Palladium would be always on, on all PCs and it would banish Linux from all PCs making Windows the some possible OS..

Which is totally what happened, right? /s

and it would banish Linux from all PCs making Windows the some possible OS

We're getting closer to that with things like "secure" boot. Fortunately that can still be disabled, but MS even required that on ARM platforms it can't. The bigger Linux distros have bent over and gotten MS to sign their bootloaders, essentially making them at the mercy of MS.

This is a weird way to describe an open, transparent standard.

https://wiki.debian.org/SecureBoot#What_is_UEFI_Secure_Boot_...

It doesn't matter how open and transparent the standard is if part of the de facto implementation is that Microsoft is the only one with the keys.

Some BIOSes let you enter your own Secure Boot keys (like my desktop and laptop), but not all.

I’ve complained about this before, but I’ve been hearing “Microsoft is going to block you from installing Linux!” since like 2004, when it was a reliable way to get an easy “+5 Insightful” on Slashdot. It hasn’t happened, even on Microsoft’s own first-party computers.

At this point I think it’s firmly FUD and the people who say it’s coming any second now need to put up the evidence. Microsoft doesn’t seem to care, especially now that Windows is an afterthought to Azure, O365, etc.

If you keep track of the changes to the BIOS firmware, you can see the changes. Their minuscule but happening. We don't have full blow preventing from disabling secure boot yet, but it appears to me that's were this is going. (Disabling usb ports, having keys that prevent disabling Secure boot unless you clear them or change them. All it takes is some event to bring these companies over the edge. The Asus MB development relies totally on Microsoft's decisions about this.

I think the point, at least for me, is that they shouldn't be taking away any user control for consumer products. And yet that is what we have let them do. Its not going to stop.

> > I’ve complained about this before, but I’ve been hearing “Microsoft is going to block you from installing Linux!” since like 2004 [...]

> If you keep track of the changes to the BIOS firmware, you can see the changes. Their minuscule but happening. We don't have full blow preventing from disabling secure boot yet, but it appears to me that's were this is going.

Case in point: until recently, even with SecureBoot enabled by default, you could boot Linux distributions which have their bootloader signed by Microsoft, without going into the firmware setup screen. Nowadays, at least with some Lenovo models, you have to go to the firmware setup screen, and either enable a cryptically named option or disable SecureBoot. A quick web search gave me https://www.omglinux.com/boot-linux-modern-lenovo-thinkpads-... which has a screenshot, and which mentions that this is a new Microsoft requirement (instead of something Lenovo came up with).

Yes, it's all about boiling the frog slowly. Very slowly.

Also, from that link is a somewhat notable cultural nugget:

"For their part Lenovo intimate that it is "

I just seems like we need to create coalition and put pressure on OEMS to stop buying int Microsoft's crap.

It did happen - on Windows RT machines. Linux was locked out, only Microsoft-blessed binaries would load; not just efi, os-ones as well.

Fortunately, this one went nowhere. But the same concept could be repeated on x64.

Back when EFI consortium wanted to make Secure Boot always on, it wasn't even clear if ARM is going to win in mobile market, let alone PC/server one.

Nowadays all non-mobile aarch64 devices I used, and even many mobile ones, let you boot your own unsigned kernel. Arm's SBBR only states that IF you implement Secure Boot and TPM support in your EFI firmware (you don't have to), it has to comply with certain rules. Nothing about preventing users from disabling it. (https://documentation-service.arm.com/static/5fb7e66fd77dd80...)

Hallelujah

> Is there a risk that this is one of those "shelve it for 6 months and we'll try again later" playbooks...?

Odd way to phrase a sure thing. The "war on general purpose computing" is real and fought continuously by the powers that be. I believe Doctorow has one of the important works on the subject.

It'll be back, in another form.

Pay no attention to specific projects and proposals that are offered and withdrawn. Look at the bigger picture over a longer time-frame and ask; what are the forces acting within and upon an entity?

Meadows' leverage points taxonomy can be used analytically as well as instrumentally. What are the values behind misadventures like WEI ?

Google want to own your browser and infiltrate as much of the client-side as they can.

What other technical avenues and regulations can they make politically expedient use of?

To fight this abuse don't attack proposals, projects, or even behaviours. Study and attack their core values. What are they really about?

Sometimes what you're describing is a valid approach-- once a pattern is clear. This is looking pretty reasonable for Google.

But it seems like a bit of a toxic, pessimistic response in general.

There's other times where a party just screws up. e.g. Apple's CSAM-- once the industry educated them, they took a very different tack. There was no fundamental structural or cultural issue pushing them towards the problematic choices.

> There's other times where a party just screws up. e.g. Apple's CSAM

Did Apple really screw up? Their proposal is pretty much what the EU and UK governments want now :(

I think they screwed up because to have my own phone spying on me is unthinkable and I would never have considered another Apple product again. But politics seem to like the idea.

Those governments are mostly coming around as to why that’s a bad idea.

I don't think so, I think they're just regrouping to find another approach to push it through.

> But it seems like a bit of a toxic, pessimistic response in general.

I'm a twisted firestarter, but it's mostly out of a passionately optimistic and generous view of other human beings. Big corporations are not human beings. I think they fail humanity. They have too much power and no accountability. For that I think they deserve all the toxicity and pessimism fitting for what they are.

Wow that surprises me. A lot.

I'm sure they will cook up something else evil though. FLoC just came back under a different name.

It is so surprising to me that the one company that had "don't be evil" in their motto has become the one most antagonous company to society (or at least in a digital services manner, I'm sure Palantir and Monsanto can take that crown in their own areas).

I expect to see the usual Google approach: back off, then come back with another take on the same thing, but wrapped differently.

They have been tamed in the past. Correct me if I'm mistaken, but Google Native Client was completely discontinued and wasm was adopted eventually. I see that as a victory for the open internet.

I'm not sure WASM is markedly different from PNaCL, other than using SSA-based LLVM bitcode instead of a stack-based bytecode.

It's a well-defined standard with lots of different implemenetations, instead of "whatever Chrome does", tied to one specific codegen backend.

That's a huge difference.

They learned it from Congress.

We did it. Massive hckrnews W

Reply on news.ycombinator.com