• 0 Posts
  • 15 Comments
Joined 4 months ago
cake
Cake day: February 27th, 2026

help-circle
  • I skimmed the paper and wouldn’t take too much stock in it. One glaring issue I see is that the “control” for their analysis is another cell network that is absolutely tiny by comparison and services a completely different population from AT&T, so they’re not really isolating other variables, they’re cherry-picking data and over-indexing on it.

    The other thing that immediately jumped out at me is the format-- it sure looks an awful lot like an academic thesis, and the authors are a professor and a student who started this work during their undergrad. There’s surely no way a respectable journal would publish this document in its current iteration, so why is it in the news? Weird.


  • The webpage he hosted was a copy of his own blog post explaining the hack. It just about fit into the 20KB of available flash storage.

    We can infer that on every request, the whole static page needs to be spooled out of flash onto RAM (in chunks no larger than 3k), then sent out over Ethernet.

    That’s an awful lot of work for the chip. I’m not surprised at all that it errors out under heavy load. The request queue probably grows until it collides with the buffer that bucket brigades the web page to the network.

    I’m afraid to look up what optimizations were necessary to get that level of performance. It’s damned impressive work.














  • This might seem like a very indirect response, and that’s because it is largely a notion I have after a couple years of observing the fediverse. My background is in infrastructure for micro services, which is a powerful source of bias, so take this with a grain of salt.

    The fediverse is suffering from major problems caused by homogeneity, data duplication, and lack of meaningful coordination. It is completely unsurprising that it struggles to provide the level of service that most users expect. I’m not saying this to be mean, but because I’ve experienced these same growing pains in commercial settings.

    The solution has always been to restructure product services in a way that separates concerns. Most of the big guys will, at a very high level, use an API gateway which handles security + authn, then forward requests to high level product services which in turn reach down to the data layer services (which are often ORMs with huge caches sitting on top of databases). Works great, usually.

    The fediverse, from what I’ve seen, does not do this. Everyone sets up largely identical monolithic applications which share messages through the Pubsub protocol. Information is duplicated everywhere, and inter-instance communications are a liability not only in content but even in compute and persistence (you can absolutely get DDOS’d by a noisy neighbor). Individual instances are responsible for their own edge security, compute, and data. It’s just a lot to ask of a single person that wants to host a federated instance.

    I think that a healthy federated internet will eventually require highly specialized instances at several layers, and for certain maintainers to thanklessly support the public facing services. One of the most obvious classes of these specialized instances, to me, would be the data layer and catching instances, which exist to ensure that content posted on one instance is backed up and served for other instances. It reduces the strain on public facing instances because they no longer have to host all the content they’ve ever seen, and it also ensures that if a public instance goes down, the content does not disappear with it.

    This same principle could be used on “gateway” or “bastion” instances which enforce strict security on behalf of public instances. Public instances would block direct connections while treating requests from the gateway nodes as highly privileged. Each public instance would either find a gateway instance to protect it or handle its own security and inter-instance communications.

    This obviously isn’t a complete solution, and it’s a hell of a long way from a technical specification, but my hope is that others who are looking at the weird and wonderful landscape of our new internet are having similar concerns and reaching similar conclusions.