Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Environment Integrity API Proposal

github.com

Post reply on HN
Print view View original

391–400 of 460 posts

Re: Web Environment Integrity API Proposal

#391

Post by Tanoc »

p-e-w wrote: post #289
Fatnino wrote: post #226

Earlier quoted context omitted.

We could at least get everyone here to use Firefox. There's really no excuse for a technically minded person to still be using Chrome for their day to day browsing. If you do eventually run into a poorly crafted webpage that doesn't work on Firefox you have the wherewithal to decide if you are simply not going to use that site or hop over to chrome just this once. But the important thing is checking in automatically…

> We could at least get everyone here to use Firefox. That would accomplish nothing. > But the important thing is checking in automatically as a Firefox user in the logs of every other site online. No, that's not important. HN users are a tiny minority compared to the billions of people that use the web daily. I'm sorry, there's no easy way to say this: Firefox is never coming back. The web of old is never coming bac…

A defeatist attitude like this certainly predicts the future... If you're playing by the rules. And the rules were set by Google, so it's in your best interest to break them by actively harming Google. Restrictions in choice happen because people don't oppose the narrowing enough to make the corporations lose money. This might be one of the few times where targeted malware could be beneficial if it destroys Google's services and makes them too much of a risk to use. If somebody puts a latent trigger into a Javascript library that's widely used like Node.js that makes Chromium and only Chromium break then that would start a cascade effect of Chromium locking itself up more and more until it's impossible to use. You could even make cookie bombs, where you have two cookies, and when one expires before the other it triggers the surviving poisoned cookie to ruin Chrome's functionality by poisoning the browser agent. Google wouldn't be able to trust anything they didn't make themselves. You can force Google to barricade themselves in until it's impossible to reach them, and have them do it so fast that updating systems for developers and users would be too much of a pain to constantly keep up with. The downside is once you use a tactic like this then it's not just Google that wouldn't trust anything they didn't make themselves.

Re: Web Environment Integrity API Proposal

#392

Post by saagarjha »

charcircuit wrote: post #229
saagarjha wrote: post #220

Earlier quoted context omitted.

A good way to drive fraud to zero is to make it so that nobody uses your service.

okay?

The point is that if you actually don’t offer web banking people may decide to not bank with you.

Re: Web Environment Integrity API Proposal

#393

Post by saagarjha »

Thorrez wrote: post #295
saagarjha wrote: post #212

Earlier quoted context omitted.

This just seems like a generic “oh people might hate this proposal here’s a place where we mention this”, not a response to the question asked above.

Why isn't it a response to the question above asked? The question above seems to be saying that this API will be used to create walled gardens; the linked part of the design is about how to prevent the API from being used to create walled gardens. Disclosure: I work at Google but not on this.

It doesn’t have very concrete answers. It’s really more of a couple of ie thoughts, with an exhortation for people to provide ideas on how to fix this. For example:

> Attesters will be required to offer their service under the same conditions to any browser who wishes to use it and meets certain baseline requirements.

What prevents this set of baseline requirements from being e.g. “the device is backed by a TPM from these four vendors”?

> Although a holdback would prevent the attestation signal from being used for per-request enforcement decisions, there remains immense value for measurement in aggregate populations. However, a holdback also has significant drawbacks.

“So, like, here’s a vague idea on how we might prevent this. However this idea has significant problems.” Not a very convincing argument?

> If the community thinks it's important for the attestation to include the platform identity of the application

“If we assume that we can’t actually solve this…”

Basically there’s not much in the way of answers there. Generally when you put out proposals with a history of significant pushback I’d expect the likely feedback to be addressed in more depth than this.

(I guess since we’re doing disclaimers I also work at Google but not on this.)

Re: Web Environment Integrity API Proposal

#394

Post by saagarjha »

Hixie wrote: post #321
saagarjha wrote: post #211

Earlier quoted context omitted.

The end result of this seems to me like clicking on any link means I’m going to download 50 MB before I can see any content?

It wouldn't be 50MB. Five maybe. That's not that unusual today already anyway.

How are you measuring this? Like, I would expect someone to want to ship e.g. WPF or something into the browser as their UI toolkit. Why would this fit in 5 MB?

Re: Web Environment Integrity API Proposal

#395

Post by saagarjha »

saurik wrote: post #303
saagarjha wrote: post #211

Earlier quoted context omitted.

The end result of this seems to me like clicking on any link means I’m going to download 50 MB before I can see any content?

So... you prefer the end result we got, with there being only ~1.75 browsers in existence--and only 1 that truly matters to developers--where ~1.66 of them are owned by companies that would prefer to implement this specification? :(

I think, given your history, is that what you’re looking for is apps but distributed on the web. However I believe there is also a market for app clips of sorts that are meant to be more lightweight and have some default APIs available to them, for cases where people don’t actually want the overhead of apps.

Re: Web Environment Integrity API Proposal

#396

Post by fireant »

garganzol wrote: post #47

I see one more dangerous development imposed by this move: limiting access to web content for rival search engines. I'm sure that Google Robot will pass all "high security standards" and web integrity checks, while others won't be able to do so.

Wow I didn't even think of this. Truly a brilliant move that intends to kill the open web on two fronts at once.

Re: Web Environment Integrity API Proposal

#397

Post by Spivak »

kibwen wrote: post #72

It's time to break Google up. They're the AT&T and Standard Oil of our generation. Make Ads, YouTube, Search, Cloud, Chrome, etc. all independent companies. Demand that antitrust regulators do their damn jobs for a change.

It won't happen for two reasons:

* The US would never kill its golden calf except as a last resort.

* The US standard for antitrust is consumer harm. Google implementing a thing that other companies have been asking for, any company can join and send their own attestation signals, and then those other companies in unrelated markets use the thing to maybe not support unapproved stacks which could reasonably include Android/Chrome won't fall on Google.

Re: Web Environment Integrity API Proposal

#398

Post by Thorrez »

mackie_roy wrote: post #364
Thorrez wrote: post #295

Earlier quoted context omitted.

Why isn't it a response to the question above asked? The question above seems to be saying that this API will be used to create walled gardens; the linked part of the design is about how to prevent the API from being used to create walled gardens. Disclosure: I work at Google but not on this.

Unfortunately, what you link doesn't answer how they will prevent it being used to create walled gardens. It's just an open question, and as such, it does seem it's an afterthought, when it should be front and center if anyone care for an open web.

Wouldn't a holdback prevent it from being used to create walled gardens?

Re: Web Environment Integrity API Proposal

#399

Post by piaste »

marcthe12 wrote: post #274
20after4 wrote: post #146

Earlier quoted context omitted.

It might be time to abandon that half of the web. Radical software freedom ideology is looking less radical and more rational by the day.

It may not be that easy as now that stuff like banks and government services have embrance it. If they or your work/school apps need it, you are screwed

I'm already using a separate device for "official" stuff. It's a fully Google/Microsoft managed phone that runs my professional life (work profile, LinkedIn, etc.) and accesses government and some financial services. It mostly sits in a drawer outside work hours and don't use it to browse or talk to anyone outside of work. It has SimpleX installed so it can send anything I need (eg. financial statements) to my personal phone, without even needing to store my personal phone number.

My personal phone, and my personal laptop and PC, run open source OSes and are as privacy-focused as I can make thrm. They're the ones I use to browse and talk to people, both on public and private platforms. They're the ones that have my photos, my books, my passwords, my movies and my music. (I don't use streaming services, except for YouTube via Newpipe.)

I do make sure that I always have at least one bank account with a bank that doesn't require SafetyNet or similar, and can therefore be accessed without needing the "official" phone. So far, all but one of my financial service providers work fine from my personal devices.

I think the dual-device approach will quickly become the only realistic one for individuals who want privacy in their computer use (which will remain a minority). I will even say that, although Google is doing this purely for the sake of ads and profits, it is not unreasonable to expect citizens to have an "official" online presence in the form of a highly standardised Internet client, without prejudicing their ability to use other ones. In the same way that you have an official residential address, without prejudicing your ability to have other mailboxes or live on the road.

Post reply on HN