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

The Web Is Broken – Botnet Part 2

jan.wildeboer.net

Post reply on HN
Print view View original

161–170 of 301 posts

Re: The Web Is Broken – Botnet Part 2

#161

Post by layer8 »

squeaky-clean wrote: post #128
layer8 wrote: post #107

Earlier quoted context omitted.

The pattern you are describing is what I know as the Strategy pattern [0]. See the example there with the Car class that takes a BrakeBehavior as a constructor parameter [1]. I have no issue with that and use it regularly. The Strategy pattern precedes the notion of dependency injection by around ten years. The term Dependency Injection was coined by Martin Fowler with this article: https://martinfowler.com/articles/…

They're not really exclusive ideas. The Constructor Injection section in Fowler's article is exactly the same as the Strategy pattern. But no one talks about the Strategy pattern anymore, it's all wrapped into the idea of DI and that's what caught on.

I'm curious, which language/dev communities did you pick this up from? Because I don't think it's universal, certainly not in the Java world.

DI in Java is almost completely disconnected from what the Strategy pattern is, so it doesn't make sense to use one to refer to the other there.

Re: The Web Is Broken – Botnet Part 2

#162

Post by nickphx »

arewethereyeta wrote: post #23
ivas wrote: post #18

Earlier quoted context omitted.

Checked my connection via VPN by Google/Cloudflare WARP: "Proxy/VPN not detected"

Could be, I don't claim 100% success rate. I'll have a look at one of those and see why I missed it. Thank you for letting me know.

measuring latency between different endpoints? I see the webrtc turn relay request..

Re: The Web Is Broken – Botnet Part 2

#163

Post by XorNot »

zzo38computer wrote: post #116
philippta wrote: post #79

Earlier quoted context omitted.

Apps should be required to ask for permission to access specific domains. Similar to the tracking protection, Apple introduced a while ago. Not sure how this could work for browsers, but the other 99% of apps I have on my phone should work fine with just a single permitted domain.

I think capability based security with proxy capabilities is the way to do it, and this would make it possible for the proxy capability to intercept the request and ask permission, or to do whatever else you want it to do (e.g. redirections, log any accesses, automatically allow or disallow based on a file, use or ignore the DNS cache, etc). The system may have some such functions built in, and asking permission migh…

Try actually using a system like this. OpenSnitch and LittleSnitch do it for Linux and MacOS respectively. Fedora has a pretty good interface for SELinux denials.

I've used all of them, and it's a deluge: it is too much information to reasonably react to.

Your broad is either deny or accept but there's no sane way to reliably know what you should do.

This is not and cannot be an individual problem: the easy part is building high fidelity access control, the hard part is making useful policy for it.

Re: The Web Is Broken – Botnet Part 2

#164

Post by __MatrixMan__ »

alakra wrote: post #135
jevogel wrote: post #134

Earlier quoted context omitted.

IPFS

I had high hopes for IPFS, but even it has vectors for abuse. See https://arxiv.org/abs/1905.11880 [Hydras and IPFS: A Decentralised Playground for Malware]

Can you point me at what you mean? I'm not immediately finding something that indicates that it is not fit for this use case. The fact that bad actors use it to resist those who want to shut them down is, if anything, an endorsement of its durability. There's a bit of overlap between resisting the AI scrapers and resisting the FBI. You can either have a single point of control and a single point of failure, or you can have neither. If you're after something that's both reliable and reliably censorable--I don't think that's in the cards.

That's not to say that it is a ready replacement for the web as we know it. If you have hash-linked everything then you wind up with problems trying to link things together, for instance. Once two pages exist, you can't after-the-fact create a link between them because if you update them to contain that link then their hashes change so now you have to propagate the new hash to people. This makes it difficult to do things like have a comments section at the bottom of a blog post. So you've got to handle metadata like that in some kind of extra layer--a layer which isn't hash linked and which might be susceptible to all the same problems that our current web is--and then the browser can build the page from immutable pieces, but the assembly itself ends up being dynamic (and likely sensitive to the users preference, e.g. dark mode as a browser thing not a page thing).

But I still think you could move maybe 95% of the data into an immutable hash-linked world (think of these as nodes in a graph), the remaining 5% just being tuples of hashes and pubic keys indicating which pages are trusted by which users, which ought to be linked to which others, which are known to be the inputs and output of various functions, and you know... structure stuff (these are our graph's edges).

The edges, being smaller, might be subject to different constraints than the web as we know it. I wouldn't propose that we go all the way to a blockchain where every device caches every edge, but it might be feasible for my devices to store all of the edges for the 5% of the web I care about, and your devices to store the edges for the 5% that you care about... the nodes only being summoned when we actually want to view them. The edges can be updated when our devices contact other devices (based on trust, like you know that device's owner personally) and ask "hey, what's new?"

I've sort of been freestyling on this idea in isolation, probably there's already some projects that scratch this itch. A while back I made a note to check out https://ceramic.network/ in this capacity, but I haven't gotten down to trying it out yet.

Re: The Web Is Broken – Botnet Part 2

#165

Post by hinkley »

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 our highschool class who would do anything for a bit of money and introducing his 'friend' Paul who is in fact a bot whose owner paid for the lie. And not like enough money to make it a moral dilemma, just drinking money or enough for a new video game. So once you get past about 10,000 people you're pretty much back where we are right now.

Re: The Web Is Broken – Botnet Part 2

#166

Post by greesil »

wyck wrote: post #130
greesil wrote: post #88

How would I know if an app on my device was doing this?

Install a network monitor or go even deeper and sniff packets.

I feel like this could be automated. Spin up a virtual device on a monitored network. Install one app, click on some stuff for awhile, uninstall and move onto the next. If the app reaches out to a lot of random sites then flag it

Google could do this. I'm sure Apple could as well. Third parties could for a small set of apps

Re: The Web Is Broken – Botnet Part 2

#167

Post by internetter »

vbezhenar wrote: post #158
philippta wrote: post #79

Earlier quoted context omitted.

Apps should be required to ask for permission to access specific domains. Similar to the tracking protection, Apple introduced a while ago. Not sure how this could work for browsers, but the other 99% of apps I have on my phone should work fine with just a single permitted domain.

Do you suggest to outright forbid TCP connections for user software? Because you can compile OpenSSL or any other TLS library and do a TCP connection to port 443 which will be opaque for operating system. They can do wild things like kernel-level DPI for outgoing connections to find out host, but that quickly turns into ridiculous competition.

> but that quickly turns into ridiculous competition.

Except the platform providers hold the trump card. Fuck around, if they figure it out you'll be finding out.

Re: The Web Is Broken – Botnet Part 2

#168

Post by 0dayz »

realusername wrote: post #138
jeroenhd wrote: post #75

Earlier quoted context omitted.

Welcome scrapers (IA, maybe Google and Bing) can publish their IP addresses and get whitelisted. Websites that want to prevent being on the Internet Archive can pretty much just ask for their website to be excluded (even retroactively). [Cloudflare]( https://developers.cloudflare.com/cache/troubleshooting/alwa... ) tags the internet archive as operating from 207.241.224.0/20 and 208.70.24.0/21 so disabling the bot-pr…

That's basically asking to close the market in favor of the current actors. New actors have the right to emerge.

No they don't.

There's no rule that you have to let anyone in who claims to be a web crawler.

Re: The Web Is Broken – Botnet Part 2

#169

Post by reconnecting »

andelink wrote: post #112
reconnecting wrote: post #35

Residential IP proxies have some weaknesses. One is that they ofter change IP addresses during a single web session. Second, if IP come from the same proxies provider, they are often concentrated within a sing ASN, making them easier to detect. We are working on an open‑source fraud prevention platform [1], and detecting fake users coming from residential proxies is one of its use cases. [1] https://www.github.com/ti…

The first blog post in this series[1], linked to at the top of TFA, offers an analysis on the potential of using ASNs to detect such traffic. Their conclusion was that ASNs are not helpful for this use-case, showing that across the 50k IPs they've blocked, there is less than 4 IP addresses per ASN, on average. [1] https://jan.wildeboer.net/2025/02/Blocking-Stealthy-Botnets/

What was done manually in the first blog is exactly what tirreno helps to achieve by analyzing traffic, here is live example [1]. Blocking an entire ASN should not be considered a strategy when real users are involved.

Regarding the first post, it's rare to see both datacenter network IPs and mobile proxy IP addresses used simultaneously. This suggests the involvement of more than one botnet. The main idea is to avoid using IP addresses as the sole risk factor. Instead, they should be considered as just one part of the broader picture of user behavior.

[1] https://play.tirreno.com

Re: The Web Is Broken – Botnet Part 2

#170

Post by zzo38computer »

XorNot wrote: post #163
zzo38computer wrote: post #116

Earlier quoted context omitted.

I think capability based security with proxy capabilities is the way to do it, and this would make it possible for the proxy capability to intercept the request and ask permission, or to do whatever else you want it to do (e.g. redirections, log any accesses, automatically allow or disallow based on a file, use or ignore the DNS cache, etc). The system may have some such functions built in, and asking permission migh…

Try actually using a system like this. OpenSnitch and LittleSnitch do it for Linux and MacOS respectively. Fedora has a pretty good interface for SELinux denials. I've used all of them, and it's a deluge: it is too much information to reasonably react to. Your broad is either deny or accept but there's no sane way to reliably know what you should do. This is not and cannot be an individual problem: the easy part is b…

I suggested proxy capabilities, that it can easily be reprogrammed and reconfigured; if you want to disable this feature then you can do that too. It is not only allow or deny; other things are also possible (e.g. simulate various error conditions, artificially slow down the connection, go through a proxy server, etc). (This proxy capability system would be useful for stuff other than network connections too.)

> it is too much information to reasonably react to.

Even if it asks, does not necessarily mean it has to ask every time if the user lets it keep the answer (either for the current session for until the user deliberately deletes this data). Also, if it asks too much because it tries to access too many remote servers, then might be spyware, malware, etc anyways, and is worth investigating in case that is what it is.

> the hard part is making useful policy for it.

What the default settings should be is a significant issue. However, changing the policies in individual cases for different uses, is also something that a user might do, since the default settings will not always be suitable.

If whoever manages the package repository, app store, etc is able to check for malware, then this is a good thing to do (although it should not prohibit the user from installing their own software and modifying the existing software), but security on the computer is also helpful, and neither of these is the substitute for the other; they are together.

Post reply on HN