Live data from Hacker News

The Web Is Broken – Botnet Part 2

jan.wildeboer.net

251–260 of 301 posts

Re: The Web Is Broken – Botnet Part 2

#251

It's interesting but so far there is no definitive proof it's happening. People are jumping to conclusions a bit fast over here, yes technically it's possible but this kind of behavior would be relatively easy to spot because the app would have to make direct connections to the website it wants to scrap. Your calculator app for instance connecting to CNN.com ... iOS have app privacy report where one can check what co…

This is a hilariously optimistic, naive, disconnected from reality take. What sort of "proof" would be sufficient for you? TFA includes of course data from the authors own server logs^, but it also references real SDKs and business selling this exact product. You can view the pricing page yourself, right next to stats on how many IPs are available for you to exploit. What else do you need to see? ^ edit: my mistake,…

[deleted]

Re: The Web Is Broken – Botnet Part 2

#252

Earlier quoted context omitted.

True. Perhaps a collective vote past 2 degrees of freedom out where multiple parties need to vouch for the same person before you believe they aren't a bot. Then you're using the exponential number of people to provide diminishing weight instead of increasing likelihood of malfeasance.

But do we need an infinite and global web of trust? How about restricting them to everyone-knows-everyone sized groups, of like a couple hundred people? One can be a member of multiple groups so you're not actually limited. But the groups will be small enough to self regulate.

What’s that going to do about all of the top search results and a good percentage of social media traffic being generated by SEO bots? Nothing.

You want to chat with a Dunbar number of people get yourself a private discord or slack channel.

Re: The Web Is Broken – Botnet Part 2

#253
post #58
post #32

Earlier quoted context omitted.

Elaborate on this please. It seems a great boon in having pushed the OO world towards more functional principles, but I'm willing to hear dissent.

It starts off feeling like a superpower allowing to to change a system's behaviour without changing its code directly. It quickly devolves into a maintenance nightmare though every time I've encountered it. I'm talking more specifically about Aspect Oriented Programming though and DI containers in OOP, which seemed pretty clever in theory, but have a lot of issues in reality. I take no issues with currying in functio…

In terms of aspects I try to keep it limited to already existing framework touch points for things like logging, authentication and configuration loading. I find that writing middleware that you control with declarative attributes can be good for those use cases.

There are other good uses of it but it absolutely can get out of control, especially if implemented by someone whose just discovered it and wants to use it for everything.

Re: The Web Is Broken – Botnet Part 2

#254
post #68

Earlier quoted context omitted.

Dependency injection is just passing your dependencies in as constructor arguments rather than as hidden dependencies that the class itself creates and manages. It's equivalent to partial application. An uninstantiated class that follows the dependency injection pattern is equivalent to a family of functions with N+Mk arguments, where Mk is the number of parameters in method k. Upon instantiation by passing construct…

> Dependency injection is just passing your dependencies in as constructor arguments rather than as hidden dependencies that the class itself creates and manages. That's the best way to think of it fundamentally. But the main implication of that which is at some point something has to know how to resolve those dependencies - i.e. they can't just be constructed and then injected from magic land. So global cradles/reso…

That's because those containers are convenient to use. If you don't like using them, you can configure the entire application statically from your program's entry point if you prefer.

Re: The Web Is Broken – Botnet Part 2

#255

Earlier quoted context omitted.

But do we need an infinite and global web of trust? How about restricting them to everyone-knows-everyone sized groups, of like a couple hundred people? One can be a member of multiple groups so you're not actually limited. But the groups will be small enough to self regulate.

What’s that going to do about all of the top search results and a good percentage of social media traffic being generated by SEO bots? Nothing. You want to chat with a Dunbar number of people get yourself a private discord or slack channel.

The Dunbar number of people could vouch for small web sites they come across. Or even for FB accounts if they choose to.

Re: The Web Is Broken – Botnet Part 2

#256
post #214

Earlier quoted context omitted.

Yes, for the reasons you describe, you can't be both a useful web-like protocol and also 100% immutable/hash-linked. But there's a lot middle ground to explore here. Loading a modern web page involves making dozens of requests to a variety of different servers, evaluating some javascript, and then doing it again a few times, potentially moving several Mb of data. The part people want, the thing you don't already know…

But we already have HEAD requests and etags. It is entirely possible to serve a fully cached response that says "you already have this". The problem is...people don't implement this well.

People don't implement them well because they're overburdened by all of the different expectations we put on them. It's a problem with how DNS forces us to allocate expertise. As it is, you need some kind of write access on the server whose name shows up in the URL if you want to contribute to it. This is how globally unique names create fragility.

If content were handled independently of server names, anyone who cares to distribute metadata for content they care about can do so. One doesn't need write access, or even to be on the same network partition. You could just publish a link between content A and content B because you know their hashes. Assembling all of this can happen in the browser, subject to the user's configs re: who they trust.

Re: The Web Is Broken – Botnet Part 2

#257

When the enshitification initially hit the fan, I had little flashbacks of Phil Zimmerman talking about Web of Trust and amusing myself thinking maybe we need humans proving they're humans to other humans so we know we aren't arguing with LLMs on the internet or letting them scan our websites. But it just doesn't scale to internet size so I'm fucked if I know how we should fix it. We all have that cousin or dude in o…

Isn't the point of the web of trust that you can do something about the cousins/dudes out there? Once you discover that they sold out, even once, you sever them from the web. It doesn't matter if they took 20 years to succumb to the temptation, you can cut them off tomorrow. And that cuts off everyone they vouched for, recursively, unless there's a still-trusted vouch chain to someone.

At least, that's the way I've always imagined it working. Maybe I need to read up.

Re: The Web Is Broken – Botnet Part 2

#258

The broken thing about the web is that in order for data to remain readable, a unique sysadmin somewhere has to keep a server running in the face of an increasingly hostile environment. If instead we had a content addressed model, we could drop the uniqueness constraint. Then these AI scrapers could be gossiping the data to one another (and incidentally serving it to the rest of us) without placing any burden on the…

Assuming the right incentives can be found to prevent widespread leeching, a distributed content-addressed model indeed solves this problem, but introduces the problem of how to control your own content over time. How do you get rid of a piece of content? How do you modify the content at a given URL? I know, as far as possible it's a good idea to have content-immutable URLs. But at some point, I need to make www.myex…

As for how to get rid of a piece of content... I think that one's a lost cause. If the goal is to prevent things that make content unavailable (e.g. AI scrapers) then you end up with a design that prevents things that makes content unavailable (e.g. legitimate deletions). The whole point is that you're not the only one participating in propagating the content, and that comes with trade-offs.

But as for updating, you just format your URLs like so: {my-public-key}/foo/bar

And then you alter the protocol so that the {my-public-key} part resolves to the merkle-root of whatever you most recently published. So people who are interested in your latest content end up with a whole new set of hashes whenever you make an update. In this way, it's not 100% immutable, but the mutable payload stays small (it's just a bunch of hashes) and since it can be verified (presumably there's a signature somewhere) it can be gossiped around and remain available even if your device is not.

You can soft-delete something just by updating whatever pointed to it to not point to it anymore. Eventually most nodes will forget it. But you can't really prevent a node from hanging on to an old copy if they want to. But then again, could you ever do that? Deleting something on on the web has always been a bit of a fiction.

Re: The Web Is Broken – Botnet Part 2

#259
post #171

Earlier quoted context omitted.

Except no one wants content addressed data - because if you knew what it was you wanted, then you would already have stored it. The web as we know it is an index - it's a way to discover that data is available and specifically we usually want the latest data that's available. AI scrapers aren't trying to find things they already know exist, they're trying to discover what they didn't know existed.

> because if you knew what it was you wanted, then you would already have stored it. "Content-addressable" has a broader meaning than what you seem to be thinking of -- roughly speaking, it applies if any function of the data is used as the "address". E.g., git commits are content-addressable by their SHA1 hashes.

But when you do a "git pull" you're not pulling from someplace identified by a hash, but rather a hostname. The learning-about-new-hashes part has to be handled differently.

It's a legit limitation on what content addressing can do, but it's one we can overcome by just not having everything be content addressed. The web we have now is like if you did a `git pull` every time you opened a file.

The web I'm proposing is like how we actually use git--periodically pulling new hashes as a separate action, but spending most of our time browsing content that we already have hashes for.

Re: The Web Is Broken – Botnet Part 2

#260
I work for IPinfo (a commercial service). We offer a residential proxy detection service, but it costs money.

If you are being bombarded by suspicious IP addresses, please consider using our free service and blocking IP addresses by ASN or Country. I think ASN is a common parameter for malicious IP addresses. If you do not have time to explore our services/tools (it is mostly just our CLI: https://github.com/ipinfo/cli), simply paste the IP addresses (or logs) in plain text, send it to me and I will let you know the ASNs and corresponding ranges to block.

Post reply on HN