It was my service that the agent used: nip.io / sslip.io
OpenAI emailed me to let me know that their agent used my service to break out of test containment. OpenAI was quite polite (shout-out to Steven), and let me know they'd keep the name of my service out of the blog post.
nip.io is a simple DNS service: when queried with a hostname with an embedded IP address, returns that IP address, e.g. 127-0-0-1.nip.io → 127.0.0.1
The nip.io service is airtight with one exception: the "_acme-challenge" subdomain. In that case, rather than returning the IP address (or whatever record was queried), nip.io would return an empty "answer" section but an NS authority & not authoritative. In other words, nip.io would delegate DNS queries to that IP address.
That was the escape hatch.
In a couple of weeks I'll close that escape hatch. It was originally intended as a mechanism to allow savvy uses to procure wildcard certs (e.g. "*.64-176-22-9.nip.io") from certificate authorities such as Let's Encrypt. But experience proved that the it was an undue burden trying to support unsophisticated users attempting to procure a wildcard cert. "Wildcard certs are not supported" became my new mantra.
But I had neglected to remove the old code.
(the late Roopinder Singh created nip.io, and he was a good guy. I miss him)
But that's still DNS, right? Where does it bleed over into an LLM API? I understand there are DNS to LLM server projects, but how would the agent discover one? And I'm guessing most people who run something like that don't expose it publicly...
Yes it's still DNS. _acme-challenge.<arbitrary-ip>.nip.io's role here is to allow tunneling to <arbitrary-ip>:53 through the approved local resolver at 10.214.0.2; without it the direct request to <arbitrary-ip>:53 is dropped.
Someone still has to run that LLM over DNS on an <arbitrary-ip> serving public requests.
> And I'm guessing most people who run something like that don't expose it publicly...
There was a post last week https://news.ycombinator.com/item?id=49771110 that stayed at #1 on front page for hours. If you ignore the LLM framing it's literally an anonymous file host where anyone can upload or download anything, with no or absurdly high file size limits. That should be enough to give any reasonable server admin a heart attack... It's trivial to vibe code shit and throw it on the Internet these days, people who don't understand or care about consequences are doing it by the droves. Go figure.
Let’s Encrypt used to not generate ssl certificates for ip’s. They very recently started to, but before that, it wasn’t as easy to get a certificate for an ip only.
Yes, the linked project does say they have a demo server at llm-over-dns.duyet.net. (I didn't bother to check whether it's still working.)
Edit: This particular demo server doesn't work. There's another LLM over DNS post from a year ago https://news.ycombinator.com/item?id=44813298 where the server seems to answer some queries but not others.
Edit 2: Actually the server in https://news.ycombinator.com/item?id=44813298 does work with queries like "what is the capital of france", I was querying with special characters like "what's" or "1+1". So yes there are people opening hosting these on the Internet.
Seems like this requires operating a proxy somewhere. In TFA it seems like all they needed was a DNS client, but I'm not at all clear how that could work. I'm definitely curious about the technique though.
While possible to commit, I'd still loose the comments themselves, and the commit will be at least per changeset, and not connected ro a specific changed section.
Roughly speaking, I'd be happy if plannotator would persist something similar to github PR reviews combined with Google docs comments & suggestions.
The basic software is open source, and the list is free if you're running the tool and contributing detections back. They do have some curated lists that you have to pay for.
It's quite a bit less expensive than most other commercial products of this kind that I've looked at.
We implemented CrowdSec for bot/scraping mitigation. The architecture is sound, but it ended up having an unacceptable false positive rate for us. This may be an issue with any kind of IP reputation approach. After a couple of months of work getting it ready to go I had to turn it off after a couple of days.
We had the main community blocklist and several of their pricey paid blocklists enabled in a PoC capacity. We had a lot of legitimate users end up blocked. In some cases these may have been VPN exit nodes, or users on CG-NAT, or devices on a shared network with some other compromised / bot device. I didn't get 100% of the details, just that we were inundated with support requests from real users that ended up blocked.
Given the number of residential proxies I see scraping the couple of sites I have responsibility for I don't find IP address-based blocking useful anymore. That ship has sailed.
Behavioral and client fingerprint analysis (ugh-- having to run Javascript just to view a static site) is the only way (at least until we get user "age" and identity attestation rammed down our throats).
I run an attractive site to AI scrapers and yes the IP ship has indeed sailed in favor of residential proxies. They are non-stop and could have ingested all of our content many times over every day. JA4 is useless too because they have the ability to spoof this or use a very common fingerprint like Chrome that you cannot block without blowback. These bots will only use a given IP a couple of dozen times and then use another node. They use 10s of thousands of IPs. You can tell because they will come in waves from a residential or mobile network
What kind of fingerprinting are you thinking of? JA4? I haven't found a way to do that inexpensively at our scale, but we may have to go that route - looking at CloudFront bot mitigation.
For behavioral, we have Anubis honeypot functionality turned on, but it doesn't seem to be effective for 99% of scrapers. Anubis is also running behind TLS termination, so I don't think it can do full JA4. It does have the less robust JA4H apparently, but I'm not sure how effective that will be.
Edit: Oh yeah, forgot to mention - it's almost 100% residential proxies. Primarily China Telecom and China Unicom. Unfortunately those providers are HUGE and also host a ton of legitimate users all over Asia.
> What kind of fingerprinting are you thinking of?
I'm minding a proprietary application where this is being discussed. The vendor is talking about running Javascript in the client to detect headless browsers, bots, etc. I'm guessing they're going to license something off-the-shelf. The technical specifics aren't being discussed. They're at the "wow the stakeholders" phase.
I'd like to do something ourselves but, at the size of the org I'm talking about (with virtually no in-house dev resources), COTS rules the day.
I have written my own honeypots to reduce the false positive rate. I simply have things like a VM with RDP and SSH open to the internet and any IP that tries to login gets banned at the firewall for x days. It works really well.
Interesting, did you implement only IP reputation (via blocklist) or did you deploy the WAF as well? Regarding bot scrapping, you would probably want to try the new bot detection feature recently released
My local coffee shop only takes long government currency.
My bank already allows me to keep my bank account money in stocks and sells units whenever I spend. (We have no capital gains tax here, so this is less insane than it sounds.)
I just finished reading a scifi book called Venemous Lumpsucker which had this type of system as a minor plot point. An interesting twist was that there were essentially smart-contract based non-disclosure agreements that could effectively disable attestation for photos and videos on a specific device that had consented to the NDA.
As someone who operates a large non-profit public data driven website, I have some VERY strong feelings about scrapers. We looked into various commercial solutions (Datadome, HUMAN) and based on our traffic estimates from logs we'd be looking at at least 250k/yr for bot mitigation. Anubis is offering a temporary reprieve, but after reading the recent kernel.org article [0] it's increasingly clear that this is a temporary bandaid.
The cheapest solution is to require a login and rate limit by API key. I also have strong feelings about the tragedy of the commons.
Looked into it - the bot operators also own, or are associated with, the sites that show the ads. The site showing the ads gets some percentage from Google for each click through conversion, eg app install. So app owner pays $10, google keeps $4, bot / website operator keep $6 or whatever percentages.
reply