一个玩笑域名如何卷入地缘政治战争

Strap in, this story involves a cheese fortune teller, the department of war, and nearly every other government department in between.

In 2017 (I think?) I was introduced to weather balloon hunting by Mark VK5QI. At the time the Australian balloon chasing community was small. Only Melbourne and Adelaide radiosondes (the transmitter on weather balloons) were being tracked on a website called Habhub - high altitude ballooning hub. This site was designed for amateur balloons and not meteorological weather balloons.

Over time more and more radiosondes were tracked on Habhub and eventually Habhub admins introduced a default filter that removed weather balloons by default. A query parameter could be added to the URL to remove the filter and on 12th of May 2018 sondehub.org registered with a single purpose - a URL redirect to Habhub with a radiosonde specific filter. To be clear - this was more of a joke than a decision to run a radiosonde tracking service. You’d go to sondehub.org and it would redirect you to habhub.org. That was it.

However Habhub was never designed for so many unique balloons each day. By July we decided to start proxying radiosonde ingestion data through SondeHub. This allowed us to capture more data as well (no longer rate limiting our selves). This went to a seperate OpenSearch cluster, however at this stage we didn’t use or expose this data. I was using this more as a toy - to play around with different Amazon Web Services (AWS) services and analytics platforms.

By 2019 the Habhub servers were really struggling - aprs.fi as well. We realised that we needed to run our own service and our initial plan was that we would build new APIs, and eventually new frontend. We then started getting information requests from government agencies regarding radiosonde data. For example we received a request regarding an insurance claim about a radiosondes hitting a horse, causing it to bolt through a fence. One of the reasons for this is because unlike official software at the time, our system tracked the radiosondes all the way to the ground.

Also in 2019 we detected a drop in radiosonde launches. This lined up with the GPS rollover date - we thought our software was broken however it turned out to be issues with Vaisala’s equipment which prevented launches from occuring. Funnily enough our software handled the rollover ok.

In 2020/2021 we ended up doing was building backwards compatible APIs for the Habhub frontend and started testing the Habhub frontend pointed at our backend. It mostly worked. We started receiving all the data rather than just partial data and providing open access to our data via S3. We even started running our own predictor - which is used by my entities today.

With our own predictor running Mark developed a system we call reverse predictions. This is where we take data from an already launched radiosonde and use the wind model to run the predictor backwards which determines a rough the launch location prediction. It works extremely well. We could detect a bunch of radiosonde launch sites that were poorly otherwise documented along with start assigning balloons to launch sites.

Our first taste of dealing with the military

Then in 2021 we received an email

sensitive/military/… installation. As such, we really prefer that it is not explicitly marked on any map.

The thing is though that wind data isn’t just used for predicting the weather. It’s also used to calculate artillery ranging. What we had started doing is accidentally mapping out artillery sites. We decided to keep reverse predictions but we delete launch sites on genuine requests.

The reverse prediction system has also detected many number of military vessels in the ocean.

Lots more development happened on SondeHub with features like websockets and MQTT for live feeds. We disconnected Habhub backend from our proxy and with grant funding from ARDC we were able to setup a prototype amateur high altitude balloon version of SondeHub.

Eventually Habhub was shutdown due to a lack of maintenance and we rushed together to migrate what we could to SondeHub.

$439,000 missile vs party balloon

All was going fine until the 2023 “China spy balloon” incident. SondeHub had a lot more traffic - but our architecture made it fairly manageable.

Then Feb 11th 2023 the US allegedly used AIM-9X Sidewinder to shot down an amateur radio balloon. That morning I woke to high usage alarms in my inbox. SondeHub had been linked to on the Washington Post. Our site managed to handled the extra traffic reasonably well.

Since then we’ve many support requests from .mil and .gov addresses. We’ve also had requests from aviation industry / air control towers.

In Dec 2024 - alarms in my inbox again. This time getting alarms for predictions. Someone decided to smash our api. This seemingly starts happening every week.

Full scale invasion

We turn on logging. The requests coming from a single IP. We had some suspicions that a private company was using our backend to generate predictions. We poke their website to see - sure enough they are - an angry email to them. However they weren’t the problem.

We ask some people.

Lol. Totally not the case. Right? Probably just an AI LLM bot scrapper gone crazy. Lets plot some predictions.

Note that the precision of these points has been intentionally been reduced. This data is also significantly old and does not show the entire dataset. This blog post has been delayed until balloon warfare was more common knowledge.

Fuck. And Fuck Russia.

(for time travellers and people in the future - in 2022 started a “special military operation” - aka a full scale invasion into Ukraine. The war continues at time of writing. Fuck Russia)

Suddenly my mind was filled with ethic and legal questions. We also suspected they aren’t using the API correctly. However we didn’t know how to get in contact.

We did eventually got some messages out via a contact

“We work with mHAB’s as you know, but some other groups likely fly fixed-wing and use Sondehub to help them “surf” the sky to target areas.

“Sent this in Ukrainian to a few milchats and will see what turns up: “I wish everyone good health. If anyone knows of a deep strike team that uses a python script with some open source wind forecasting engine, please contact me directly. They are causing numerous problems with queries, which can lead to them being blocked and they need to take action to be able to continue using the prediction system.””

I also quickly rushed together a docker compose file so anyone could quickly run their own predictor that wasn’t reliant on us.

Meanwhile (and you might have noticed me asking for AWS help on fedi) we contacted AWS as the source IP was from an AWS network. It was very important however to make sure the AWS support did not shutdown access.

Our messaging included:

It is incredibly important that the http request data is not distributed. It is also important that the source AWS account is not blocked, rate limited or terminated - loss of life could occur.

Something that I thought I’d never have to write in support emails. The messaging was important because I did not want the service cut off, and I did not want the data to reveal launch sites.

After a bit of waiting we received:

AWS reached out to me that a lambda function of mine was flagged for potentially scraping api.v2.sondehub.org and they told me to reach out to you to get this resolved.

We emailed back and forth and provided documentation on how to run the predictor locally.

Office of the Secretary of War (Intelligence and Security)