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...?
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.
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
(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
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.
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 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.
"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.
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.
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.
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...
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
> 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.
- 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..
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.
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).
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...)
> 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.
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.
> 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.
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.
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 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.
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.
> 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.
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.
> 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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
246 comments
[ 3.3 ms ] story [ 161 ms ] threadthey will have more power once current anti-trust trial will be over.
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.
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?"
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...?
https://github.com/RupertBenWiser/Web-Environment-Integrity
Now they just want to do it in WebViews, which is ineffectual at best, and still harmful at worst.
For the time being.
(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"
It's mostly just the classic "nono if you don't agree it's because you don't understand" and "please educate yourself" approach.
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.
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.
PS: "Yous guys" doesn't count
> 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.
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.
As a long boy visiting from Alberta I was astounded that this existed.
It might be dying out tho
> 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"?
I vote we just bring back this "ye" and make it official.
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.
> 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...
But I quit so now I get to trash them all I want.
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.
> 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?
[1] https://en.wikipedia.org/wiki/Next-Generation_Secure_Computi...
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.
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.
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.
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.
That's why it makes me nervous.
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.
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.
And that's the problem. I have little actual trust of vendors anymore. Too many bridges have been burned to trust by default.
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.
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.
Also, you know, GNU.
> 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...
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.
You can:
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.
Which is totally what happened, right? /s
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.
https://wiki.debian.org/SecureBoot#What_is_UEFI_Secure_Boot_...
Some BIOSes let you enter your own Secure Boot keys (like my desktop and laptop), but not all.
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.
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.
> 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).
Also, from that link is a somewhat notable cultural nugget:
"For their part Lenovo intimate that it is "
Fortunately, this one went nowhere. But the same concept could be repeated on x64.
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...)
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.
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?
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.
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.
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.
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.
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.
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?
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.
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.
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.
People celebrating this aren’t realizing that it’ll probably stop api scraping via a web view back door.
for now
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
Umm, yes? Google themselves even offer this as a product: Youtube Premium.
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!
All of this adds up to making the bad actors have to work much harder, which is the goal.
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.
So did Apple though, years ago. And no one freaked out like this. It just seems like maybe the argument is about something else.
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?
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?
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.
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.
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?
I guess it means that at some point I won't be able to use many apps under GrapheneOS with its Vanadium WV?
That's a huge difference.
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.
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.