329
A Project to Poison LLM Crawlers (rnsaffn.com)
submitted 10 months ago by to c/technology@lemmy.world
105 comments fedilink hide all child comments
 

Website operators are being asked to feed LLM crawlers poisoned data by a project called Poison Fountain.

The project page links to URLs which provide a practically endless stream of poisoned training data. They have determined that this approach is very effective at ultimately sabotaging the quality and accuracy of AI which has been trained on it.

Small quantities of poisoned training data can significantly damage a language model.

The page also gives suggestions on how to put the provided resources to use.

you are viewing a single comment's thread
view the rest of the comments
[–] 1 point 9 months ago (4 children)

To be honest bandwidth isn't a problem because it's text files. The problem is to optimize network stack for multiple connections because they're hitting from whole subnets without any delay so literally ddos and cache those html files because at some point CPU becomes bottleneck.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 9 months ago* (3 children)

    This is assuming aggressively cached, yes.

    Also "Just text files" is what every website is sans media. And you can still, EASILY get 10+ MB pages this way between HTML, CSS, JS, and JSON. Which are all text files.

    A gitea repo page for example is 400-500KB transferred (1.5-2.5MB decompressed) of almost all text.

    A file page is heavier, coming in around 800-1000KB (Additional JS and CSS)

    If you have a repo with 150 files, and the scraper isn't caching assets (many don't) then you just served up 135MB of HTMl/CSS/JS alongside the actual repository assets.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 9 months ago (2 children)

    I don't know from theory or counting but I know that my 8 cores depleted sooner than my bandwidth and I have like 60 Mb/s uplink. My linux network stack parameters are pretty aggressive. The way I figured out that something is not right was when I heard loud fan noise from my server inside room. I logged in and all cores were red and logs were showing corporate fuckers trying to burn my house.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 9 months ago* (1 child)

    I assume that the gitea instance itself was being hit directly, which would make sense. It has a whole rendering stack that has to reach out to a database, get data, render the actual webpage through a template....etc

    It's a massive amount of work compared to serving up static files from say Nginx or Caddy. You can stick one of these in front of your servers, and cache http responses (to some degree anyways, that depends on gitea)

    Benchmarks like this show what kind of throughput you can expect on say a 4 core VM just serving up cached files: https://blog.tjll.net/reverse-proxy-hot-dog-eating-contest-caddy-vs-nginx/#10-000-clients

    90-400MB/s derived from the stats here on 4 cores. Enough to saturate a 3Gb/s connection. And caching intentionally polluted sites is crazy easy since you don't care if it's stale or not. Put a cloudflair cache on front of it and even easier.

    You could dedicate an old Ryzen CPU (Say a 2700x) box to a proxy, and another RAM heavy device for the servers, and saturate 6Gb/s with thousands and thousands of various software instances that feed polluted data.

    Hell, if someone made it a deployable utility..... Oof just have self hosters dedicate a VM to shitting on LLM crawlers, make it a party.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 9 months ago

    You won't get those numbers from internet requests, they do it locally or in cloud vpc, honestly those benchmarks are shit unless you are ISP. It's because you have ISP and your router involved before you even receive request. If you have traffic from all over the world there is also speed of light delay. Then you have linux tcp/ip stack and number of open files.

    I use openresty, I could add lru cache on top but it doesn't even make sense because each bot just tries one unique request so you would have to generate html files manually instead of hosting gitea instance.

    Gitea is on sqlite database on nvme so db doesn't really matter. I could put the sqlite on ramdisk as server is using UPS so I don't care about power outage but this would be ridiculous.

    Anyways simplest way is just block ip ranges in firewall and move on.

  • permalink
  • fedilink
  • source
  • parent