Live data from Hacker News

Google Chrome Proposal – Web Environment Integrity

chromestatus.com

81–90 of 99 posts

Re: Google Chrome Proposal – Web Environment Integrity

#81
post #25

Lots of people doom and gloom here about threats to user privacy and freedom. This is the one I'd be worried about. Thought it was annoying to not be able to use banking apps on a rooted Android? Think about how annoying it will be when you can't do much of anything, even on the Web, unless it's from a sealed, signed Apple/Google/Microsoft image-based OS... I realize the way Firefox's user share is going, it might no…

Safari, rather than Firefox, might be only actor with the market share and motivation to drag out the implementation and adoption of this proposal.

You're right about the market share; I'm not sure about the motivation. Apple has the capacity to be an attester in this system, since they are an OS and hardware vendor. And while they care some about privacy (in as much as it's a marketing point), they manifestly don't care about user freedom (on iOS, and increasingly on MacOS). I think as long as their code running in a secure enclave is an acceptable attester to this API (which it will be), they don't have any motivation to oppose it.

Re: Google Chrome Proposal – Web Environment Integrity

#82
post #10

I'm surprised the ad corps haven't forked the internet yet: special drm-ed websites accessible only via special drm-ed browsers. At least it would relieve those who want to share knowledge from the presence of those who sell addiction.

This will enable the fork you've been fearing.

Re: Google Chrome Proposal – Web Environment Integrity

#83

API spec: https://rupertbenwiser.github.io/Web-Environment-Integrity/ It's morbidly amusing to see the browser referred to as a "user agent" here.

This probably isn't the best analogy to make the case you're trying to make. Agents in real life don't just blindly do whatever any customer asks. They actually have some standards and boundaries they have to observe, including ensuring integrity in their dealings on behalf of the customer. (To be clear I'm not endorsing the proposal, just commenting on the analogy.)

> on behalf of the customer

Not on behalf of the website.

Re: Google Chrome Proposal – Web Environment Integrity

#84

Earlier quoted context omitted.

> You do not, the user is responsible for the operation of their device. As time goes on hand-waving the matter as "user's responsibility" is becoming a less and less acceptable answer. Hard assurances are being demanded and applied technologies are progressively patching the existing loopholes.

It's not hand-waving; it literally is not the website's responsibility.

Organization executives and lawmakers are increasingly demanding that digital services be made un-hackable. Someone with an attitude and trying to shirk duty by claiming we just have to trust that all of the users will always be responsible and non-abusive all of the time, will at best be laughed and shooed out of the room. More realistically be given a final PIP. Telling your bosses "no I'm not going to do that" is a resume generating event.

Re: Google Chrome Proposal – Web Environment Integrity

#86
post #56

These proposals appear to be coming from the W3C Anti-Fraud Community Group. They haven't identified even a single use case[1] of the technologies they're trying to push onto the world being misused and abused. Use cases and their naivety appear to be largely copied from the OWASP Automated Threats to Web Applications[2]. There are no use case about these technologies being used by a dystopian country. No use case ab…

>There are no use case about these technologies being used by a dystopian country.

It's web 2.0, user is a product.

Re: Google Chrome Proposal – Web Environment Integrity

#87

Earlier quoted context omitted.

Sure, in theory it doesn't but in practice it does. I wanted to extract some data files from an app I was using and Google's Android told me that I was not allowed to do that. That was the apps data not my data. It doesn't really matter root/fine grained permissions. The fact is that on stock Pixel phones the user can't access whatever data they want. So in practice they don't have control.

That same ability makes it possible for 2FA apps to exist since the secrets can't be copied, turning the factor into something you know instead of something you have. Additionally just because someone is using a device that doesn't mean that the current user is the owner of the device.

Google Authenticator lets you export your entire set of secrets as a QR code. In fact, you can even store them on Google's servers. Though I have no clue why you would do this instead of just printing out the QR code and storing it in a lockbox...

Furthermore nothing prevents you from just taking pictures of the individual enrollment keys and printing those out either.

If you want TOTP 2FA that actually follows a one key per device policy you need to buy hardware tokens with some kind of out-of-band keying mechanism and enroll those. Then your problem changes from "how to stop people from copying my 2FA tokens" to "how to not get locked out of my account when my 2FA key device breaks."

Post reply on HN