[brookst]

Mandating 100% availability sounds like regulating pi to 3.0.

It can’t be done. If someone is on a home network whose router has been compromised and is part of a ddos attack, there’s no way their innocent HTTP traffic is getting through. Ditto if their machine has been compromised. Lots of scenarios where an innocent user must be blocked, unless the entire internet is reinvented. Which is beyond the scope of my project.

[neilv]

> It can’t be done. If someone is on a home network whose router has been compromised and is part of a ddos attack, there’s no way their innocent HTTP traffic is getting through. Ditto if their machine has been compromised.

To me, this sounds like giving up way too easily on engineering problems.

One distinction to start with: Let's say grandma's router isn't part of a DDoS attack. Even if she might be trying to talk with a site that someone is trying to attack.

After solving that one, maybe the solution also somehow solves the problem of when grandma's router is involved in DDoS (or that site? of a different one?), or maybe we have to think harder.

[jedberg]

We have thought harder. We know the solution. But you have to trade off privacy for security. It's having every person get a cryptographic key from the government to identify themselves.

Some states are trying this now with porn sites and users are rightfully not having it.

[neilv]

You know a solution, not necessarily the?

What do you have to do to characterize packets sufficiently to shield against DDoS with negligible false-positive significant blocking? (Without needing to associate packets with an identifiable person, nor zero-knowledge proofs of a person, etc.)

It's OK to discard some prior requirements. (For example, it's OK to insert occasional brief latency (not barge-in Web browser JS) to some traffic, if that permits an approach that greatly reduces false-positive blocking. And it's OK to pass some traffic with a suspected single client, but then change your mind later. It's OK to forget about connection abstractions and clients, and look only at stateless packets and the entirety of traffic.)

[brookst]

Great, please start a service to do this. From my perspective, it can’t be done. I would be thrilled to be wrong!

[neilv]

I would be thrilled if this one pest control company stopped kicking puppies.

I bet they could figure out a way to check for fleas that doesn't involve kicking puppies.

But I don't want to get into the flea-checking business myself.

[brookst]

“I’m pretty sure they’re doing it wrong but can’t be bothered to figure out a better way” is not super persuasive.

[neilv]

How about this: "You just can't kick puppies. Find another way for whatever it is you're trying to do."

[mvdtnz]

The people behind Cloudflare spend all day, every day trying to solve these kinds of problems. They're just not as simple as you make it sound.

[neilv]

> They're just not as simple as you make it sound.

I didn't say it was simple. I said I thought it was more achievable than "it can't be done."

I suspect one of the barriers to it being done is that it's not a top requirement like I assert it should be, for basic resources of society.

When led with that requirement, I have faith that some smart engineers and product management can figure it out.

With apologies to JFK, "We do these things, not because they are easy, but because--" they need doing. Even if they are hard.

[mvdtnz]

I doubt a single person in Cloudflare would claim it can't be done.

[globie]

The people behind Cloudflare engineer this issue for profit, which is a very different motive than to "solve" the problem.

The people most interested in doing away with the problem altogether are not Cloudflare, but its customers.