Comment by klabb3 | Hacker News Reader

Comment by klabb3 | Hacker News Reader

Parent Full thread

SSL is in practice only used for server certificates. It was kinda shit and a lot of people complained because of CAs but then we got let’s encrypt etc which alleviated the situation. And the identity is only tied to domain control, unlike eg code signing certs which are orders of magnitude more invasive and frankly a racket.

In either case, WEI has the potential to be proper DRM, like in the “approved devices” fashion. It’s deeply invasive, and can be used to exclude any type of usage at the whim of mega corps, like screen readers, ad blocking, anti-tracking/fingerprinting, downloading copyrighted content, and anything new they can think of in the future. It’s quite literally the gateway to making the web an App Store (or at best, multiple app stores).

> What's the alternative solution?

To what problem? Bots specifically or humans who want to use the web in any way they want?

If bots, then elaborate. Many bots are good, and ironically the vast majority of bot traffic comes from the very corporations that are behind this stuff. As for the really bad bots, we have IP blocklisting. For the gray/manipulative bots, sure, that’s a problem. What makes you think that problem needs to be addressed with mandatory handcuffs for everyone else?

Why should sites be obligated to let anyone in? Do you let anyone into your house? I'm surprised WEI wasn't implemented long ago.

This notion of destroying the open web is so nonsensical. WEI is not obligatory. If it's being implemented it's because it solves a real problem. Think about it. There will still be sites that don't use it.

People's real issue is that the big sites will use WEI because the problem it solves is legitimate but they don't want to identify themselves, which makes sense, but they were never obligated to let you visit their site to begin with.

The issue is not that all websites should let anyone in, it's that Google often controls the entire stack of website, ad network, browser, operating system, and mobile device. So Google can use this to pressure web users into using Google products that they otherwise would not have used, without providing any benefits. You can't use Google Search without attesting that you're browsing with unmodified Chrome on unmodified Android on an unmodified Pixel, for example. Or, an independent website can't run Google Ads unless it verifies all users are visiting using approved Google web environments.

If it were impossible for a company to have such a high market share in all of these areas at once, this proposal would be much less concerning.

But how is this different than Google or any other company provide their services only through native apps? They can choose today to cut anyone who is not using native app and they are choosing not to do so.

The web is flooded with people complaining that their google accounts were terminated for seemingly arbitrary or random reasons. They are choosing to do so.

A good number of those companies only provide native applications for mobile, and web applications for desktop (Google Docs/Sheets is a good example). If forced to use only native apps, you'd be locking people using desktops out for the most part.

> Why should sites be obligated to let anyone in?

They're not. Depending on your competency, you have a _ton_ of tools at your disposal for filtering traffic ranging from basic throttle to sophisticated behavior/request profiling.

I've spent more than a little bit of my career dealing with bots and I'm not really sure that a cryptographically signed blob proving that the request came from $thisSpecificVersion of firefox running on $thisExactVersion of osx is really going to help me.

I don't care _what_ made the request because that can always be spoofed; this cat and mouse game always ends at the analog loop hole. I care about what the request(s) are trying to do and that is something that I figure out with just the data I have server side.

>I've spent more than a little bit of my career dealing with bots and I'm not really sure that a cryptographically signed blob proving that the request came from $thisSpecificVersion of firefox running on $thisExactVersion of osx is really going to help me.

It'll end DDOS by botnet. Compromised computers would (presumably) have to run a full browser. That's much more computationally expensive and (presumably) the user would see it running.

And the flaw here is that the proposal doesn't do enough. If that signed blob allowed you to uniquely ID the device it would help solve a lot more problems. That would end DDOS for the most part and make managing abuse a lot easier.

> And the flaw here is that the proposal doesn't do enough. If that signed blob allowed you to uniquely ID the device it would help solve a lot more problems.

This is more or less what the proposal does? It's akin to the same shady stuff seen here [1] except this time some third party gets to sign it.

> That would end DDOS for the most part and make managing abuse a lot easier.

Not every bot that I'm defending against is a DDoS but I can probably figure out a way to overwhelm the "pre-content" filter that's trying to figure out if a token is legit or not.

[1] - https://fingerprint.com/demo/

>Not every bot that I'm defending against is a DDoS but I can probably figure out a way to overwhelm the "pre-content" filter that's trying to figure out if a token is legit or not.

That's true of every DDOS filter. It doesn't mean that having a cryptographically secure way to make requests more expensive to produce isn't a tremendous help.

>This is more or less what the proposal does? It's akin to the same shady stuff seen here [1] except this time some third party gets to sign it.

The fingerprint isn't unique to the extent that you can rely on it always correctly identifying a single user. So you can't ban based on the fingerprint or automatically log someone in.

> It doesn't mean that having a cryptographically secure way to make requests more expensive to produce isn't a tremendous help.

A malicious actor wouldn't bother. They'll tap `/dev/random` when it comes time to send the blessed token to the origin. The onus is going to be on the origin to figure out that it's _not_ a valid/signed token. If it's as easy for the origin to do this as it is for the adversary to tap a RNG then what was the point? If it's harder for the origin to figure out my token isn't legit than it was for me to generate one, how is the origin better off?

In any case, you're filtering the DDOS out *after* you've managed to set up the TCP/TLS/HTTP connection. That seems to be a rather late/expensive point to do so!

>If it's as easy for the origin to do this as it is for the adversary to tap a RNG then what was the point? If it's harder for the origin to figure out my token isn't legit than it was for me to generate one, how is the origin better off?

Because it's less computational intense than serving responses and/or trying to fingerprint malicious actors. It also tells you with near certainty that the request is malicious and future requests from that IP can be blocked.

> It also tells you with near certainty that the request is malicious and future requests from that IP can be blocked.

So I can still use this to DDOS. My malware running somewhere on your network just needs to submit a bogus request from your IP address. Origin sees the bogus requests from your IP and now that IP is on the bad list. Later - your legit requests from the same IP are ... denied.

I don't know that an "inverse" DDOS is novel, but it's certainly not been common. Perhaps that may change in the future...

>It'll end DDOS by botnet.

Not even remotely. This proposal is adding this attestation to one of the last network layers, most DDOS methods won't be touched by this.

It will help a lot of services like Cloudflare, basically stopping most of spamming/ddos on sites behind it. Big cloud vendors will probably implement similar solutions in which you will be able to only allow attested traffic to your site.

It ends DDOS's as much as putting basic-auth in front of it. If that were the case: SSL should already prevent it as well.

Even less so since this is a proposal for a javascript api.

> Why should sites be obligated to let anyone in? […] This notion of destroying the open web is so nonsensical.

I mean.. I think you’re answering your own question here.

You can argue that the web shouldn’t be open. In fact, there are many arguments for that, which I don’t mind arguing against.

There are many things that do not belong on the web, precisely because it’s open. For instance, a registry of people’s political views. Or naked pictures you don’t want the world to retain forever. And so on. The fact that the (open) web is not suitable for everything has been true since its inception. Openness comes with trade offs.

The honest way of putting it, is that WEI wants to make the web less open so that it can have more content, or protect content better.

On an opt-in basis, this is fine in theory. But WEI would never ever be opt-in with meaningful consent. It’s entirely dead in the water there, because non techies will not understand what or why this is “needed”. Heck, people don’t even grok cookies. In practice, this will be enabled by default, which is exactly the fear. Alt browsers would be bullied to support it, and users would be forced to use it.

I want to build a business in the near future that will need to scrape large bits of the web, but I probably will not be able to with this in place. I wouldn't mind so much if I didn't have a sneaking suspicion that the company pushing this won't have any problem running their business that depends on scraping a large part of the web.

> Do you let anyone into your house?

You didn't finish your metaphor, let me.

I don't let anyone in my house, therefore what? Therefore I am joining a worldwide program whereby I am able to find out from a source I choose whether I want to let this person into my house. If they don't make their information available to my trusted source, they ain't getting in.

Also my house happens to contain things that billions of people want to see and use, but they have to sit through my time share pitch first. And they HAVE to listen.

> If it's being implemented it's because it solves a real problem.

If something solves a real problem, must it then be implemented?

Also, it solves a problem for web sites, and in such a way that non-malicious users will be less free to use the web the way they want.

And if Google decides later that adsense from untrusted browsers doesn't count? Youtube and gmaol refuses to run at all on untrusted browsers? Is it still optional, realisticly?

Reply on news.ycombinator.com