abalone

Here's a good interview with the director of the Free Speech Coalition on the consequences of these "protect the kids" moral panic laws, which include widespread surveillance, banning VPNs and raising the cost of running an independent website to unsustainable levels.

Remember it's not just about pornography. It's anything deemed "harmful to minors" including platforms like Reddit, Bluesky or stuff conservative lawmakers think is harmful like discussion forums for LGBTQ people, sexual health information or dissident political opinions.

They also examine how these laws, which are often backed by the religious Right, are getting support more broadly from people who see it as a way to rein in Big Tech who are creating "social media addiction" and so forth.

And even within our industry there is a lot of money to be made by creating and selling compliance products, so even on forums like this you will find people advocating for them.

"Another Internet Law That Punishes Everyone" - Power User Podcast 1/9/26: https://www.youtube.com/watch?v=8bnp3nmpK9g

The code they posted doesn't quite explain the root cause. This is a good study case for resilient API design and testing.

They said their /v1/prefixes endpoint has this snippet:

  if v := req.URL.Query().Get("pending_delete"); v != "" {
      // ignore other behavior and fetch pending objects from the ip_prefixes_deleted table
      prefixes, err := c.RO().IPPrefixes().FetchPrefixesPendingDeletion(ctx)
      
      [..snip..]
  }

The immediate problem of course is this block will never execute if pending_delete has no value:

  /v1/prefixes?pending_delete   <-- doesn't execute block

  /v1/prefixes?pending_delete=true   <--- executes block

  /v1/prefixes?pending_delete=false   <-- wrongly executes block

So, while there's plenty to criticize on the testing front, that's first and foremost a basic failure to clearly define an API contract and implement unit tests for it.

But there's a third problem, in my view the biggest one, at the design level. For a critical delete path they chose to overload an existing endpoint that defaults to returning everything. This was a dangerous move. When high stakes data loss bugs are a potential outcome, it's worth considering more restrictive API that is harder to use incorrectly. If they had implemented a dedicated endpoint for pending deletes they would have likely omitted this default behavior meant for non-destructive read paths.

In my experience, these sorts of decisions can stem from team ownership differences. If you owned the prefixes service and were writing an automated agent that could blow away everything, you might write a dedicated endpoint for it. But if you submitted a request to a separate team to enhance their service to returns a subset of X, without explaining the context or use case very much, they may be more inclined to modify the existing endpoint for getting X. The lack of context and communication can end up missing the risks involved.

Final note: It's a little odd that the implementation uses Go's "if with short statement" syntax when v is only ever used once. This isn't wrong per se but it's strange and makes me wonder to what extent an LLM was involved.

I think this comment misses that OpenAI hired the guy, not the project.

"This guy was able to vibe code a major thing" is exactly the reason they hired him. Like it or not, so-called vibe coding is the new norm for productive software development and probably what got their attention is that this guy is more or less in the top tier of vibe coders. And laser focused on helpful agents.

The open source project, which will supposedly remain open source and able to be "easily done" by anyone else in any case, isn't the play here. The whole premise of the comment about "squashing" open source is misplaced and logically inconsistent. Per its own logic, anyone can pick up this project and continue to vibe out on it. If it falls into obscurity it's precisely because the guy doing the vibe coding was doing something personally unique.

Taylor Lorenz has done excellent reporting on this. It's a right wing censorial moral panic that's forced some Democrats to go along with it by positioning it as "protecting kids". This legislation is moving at a fast clip and we have to fight back.

* SCREEN Act age verification with huge implications for all online privacy: https://www.youtube.com/watch?v=8bnp3nmpK9g&list=PLu4srHCWJr...

* Abolishing Section 230, the law that protects platforms like this from being sued for user content (just published today): https://www.youtube.com/watch?v=_eqt8vrtP-U&list=PLu4srHCWJr...

* UK online safety act (it's not just the U.S.) - interview with the lawyer defending 4chan: https://www.youtube.com/watch?v=DD3PGp9RhTw&list=PLu4srHCWJr...

The argument here is simply over your false claim that "You don’t need to do anything to keep panels with a significant angle clear of dust in deserts." Your only source does not, in fact, establish that, and cementation is in fact a challenge with desert solar -- something that happens much faster than every five years.

Repeating unsupported claims and declaring yourself the winner does not, it turns out, actually help you win an argument.

Thank you for providing a source. That’s an early stage research paper, not the proven solution you originally implied. There are tons of early stage research papers on all these problems on earth and in space. Often we encounter a bunch of complications in applying them at scale such as dew-related cementation[1], which is a key reason why they haven’t been deployed at sufficient scale.

That you point to the Mars rover, a mission with extremely budgeted power requirements, as proof of how soiling doesn’t pose an impediment to mega scale desert solar farms, only underscores the flaw in your reasoning.

[1] https://www.sciencedirect.com/science/article/abs/pii/S22131...

We don't use fibre optics on earth rather than lasers because of some specific limitation of the earth's surface being in orbit would avoid.

That's incorrect. Lasers can suffer from atmospheric interference and fogging on earth.

Here is a post from NASA explaining why they like laser communications better than RF in space.[1]

[1] https://solc.gsfc.nasa.gov/modules/kidszone7/mainMenu_textOn...

You are again misquoting the article. She did not say soiling was "significantly less of a problem" in the desert. She in fact said it "requires you to clean them off every day or every other day or so" to prevent cement formation.

You claimed it was already a solved problem thanks to wind, which is false. You are unable to provide any source at all, not even a controversial one.

And that's just generation. Desert solar, energy storage and data center cooling at scale all remain massive engineering challenges that have not yet been generally solved. This is crucial to understand properly when comparing it to the engineering challenges of orbital computing.

You’re not summarizing the article fairly. She is saying the soiling mechanisms are environmentally dependent, not that there is no soiling in the desert. Again, it cites an efficiency hit of 50% in the ME. The article later notes that they’ve experimented with autonomous robots for daily panel cleaning, but it’s not a generally solved problem and it’s not true that “the wind takes care of it.”

And you still haven’t provided a source for your claim.

What’s your source for that claim? Soiling is a massive problem for desert solar, causing as high as 50% efficiency loss in the Middle East.[1]

[1] https://www.nlr.gov/news/detail/features/2021/scientists-stu...

I’m all for it — converting just a third of that land to solar would be enough to power the grid in terms of raw output — but there is still a huge, unsolved problem of energy storage that scale. Without that you’re only powering your data center for five hours a day.

using wireless communication means even less bandwidth between nodes, more noise as the number of nodes grows, and significantly higher power use

Space changes this. Laser based optical links offer bandwidth of 100 - 1000 Gbps with much lower power consumption than radio based links. They are more feasible in orbit due to the lack of interference and fogging.

Building data centres in the middle of the sahara desert is still much better in pretty much every metric

This is not true for the power generation aspect (which is the main motivation for orbital TPUs). Desert solar is a hard problem due to the need for a water supply to keep the panels clear of dust. Also the cooling problem is greatly exacerbated.

Even just building a long powerline around the globe to fetch it from warmer regions would be cheaper.

Deserts have good sun exposure and land availability but extremely poor water resources, which is necessary for washing the sand off the panels. There are many challenges with scaling both terrestrial and orbital solar.

What makes you say they "clearly have not read" their citations? Are you assuming that because they used ChatGPT to generate the citation section based on their description of the papers that they haven't read the papers? Are you suggesting that their clarifications of which real papers the ChatGPT citations were meant to map to are fake, and if so which ones?

It makes far more sense to build data centers in the arctic.

What (literally) on earth makes you say this? The arctic has excellent cooling and extremely poor sun exposure. Where would the energy come from?

A satellite in sun-synchronous orbit would have approximately 3-5X more energy generation than a terrestrial solar panel in the arctic. Additionally anything terrestrial needs maintenance for e.g. clearing dust and snow off of the panels (a major concern in deserts which would otherwise seem to be ideal locations).

There are so many more considerations that go into terrestrial generation. This is not to deny the criticism of orbital panels, but rather to encourage a real and apolitical engineering discussion.

There are plenty of legit concerns here about e.g. the launch externalities which are actually greater than the launch costs themselves, i.e. climate impact to future generations.

However one flaw in this critique is that is only looks at the cost of ground-based solar panels and not their overall scalability. That is, manufacturing cost is far from the only factor. There is also the need for real estate in areas with good sun exposure that also have sufficient fresh water supply for cleaning.

When we really consider the challenges of deploying orders of magnitude more terrestrial solar, it really requires a more detailed and specific critique of the orbital vision. Positive includes near continuous solar exposure (in certain orbits) and no water requirements.

Much has been said of cooling but remember, there is a lot of literal space between the satellites for radiative cooling fins. It is envisioned they would network via optical links, and each mini satellite would be roughly on the order of a desktop GPU (not a whole data center rack). The vision is predicated on leveraging a ton of space for lots of mini satellites on the order of a Dell desktop tower. The terrestrial areas that are really cold are also not that great for solar exposure.

Personally I don't know how it will play out but the core concern I have about making these kinds of absolutist predictions is they make weak assumptions about the sustainable scalability of terrestrial power. And that is definitely the case here in that it only looks at the manufacturing cost of solar.

At least in one case the authors claimed to use ChatGPT to "generate the citations after giving it author-year in-text citations, titles, or their paraphrases." They pasted the hallucinations in without checking. They've since responded with corrections to real papers that in most cases are very similar to the hallucination, lending credibility to their claim.[1]

Not great, but to be clear this is different from fabricating the whole paper or the authors inventing the citations. (In this case at least.)

[1] https://openreview.net/forum?id=IiEtQPGVyV

I tried clicking on every number on this site and none of them linked to any primary sources.

I clicked through on the first news item I saw, "Security forces open fire on woman filming them."

This led to a post on X captioned 'Yasuj; "Firing a shotgun at a lady who was filming."'

The attached video[1] did not show a weapon. It appeared to show uniformed forces on motorbikes and some kind of muted firing sound.

A subsequent comment said: "Don't write the wrong text, it's marking with paintball so the operations team can arrest him. The sound of a shotgun is like this, don't give wrong information."

To be clear, this is not meant to defend security forces firing paintballs at or arresting people recording them, just calling into question the integrity of this particular claim suggesting lethal force, and the overall lack of support for the figures claimed.

[1] https://x.com/ManotoNews/status/2008440556867702830

I just think it's funny he has an obnoxious snow animation all over his screed against arbitrary graphic elements.

I am skeptical as well BUT on the cooling question, which is one of the main concerns we all seem to have, the article is doing a bit of an apples-to-oranges comparison between the ISS and a cluster of small satellites.

It cites the ISS's centralized 16kW cooling system which is for a big space station that needs to collect and shunt heat over a relatively large area. The Suncatcher prototype is puny in comparison: just 4 TPUs and a total power budget of ballpark 2kW.

Suncatcher imagines a large cluster of small satellites separated by optical links, not little datacenter space stations in the sky. They would not be pulling heat from multiple systems tens of meters away like on the ISS, which bodes well for simpler passive cooling systems. And while the combined panel surface area of a large satellite cluster would be substantial, the footprint of any individual satellite, the more important metric, would likely be reasonable.

Personally I am more concerned with the climate impact of launches and the relatively short envisioned mission life of 5 years. If the whole point is better sustainability, you can't just look at the dollar cost of launches that don't internalize the environmental externalities of stuff like polluting the stratosphere.

Sure, but there's an obvious tradeoff: You're also delaying the uptake of fixes for zero-day vulnerabilities.

The article does not discuss this tradeoff.

It was a change to the database that is used to generate a bot management config file. That file was the proximate cause for the panics. The kind of observability that would have helped here is “panics are elevated and here are the binary and config changes that preceded it,” along with a rollback runbook for it all.

Generally I would say we as an industry are more nonchalant about config changes vs binary changes. Where an org might have great processes and systems in place for binary rollouts, the whole fleet could be reading config from a database in a much more lax fashion. Those systems are quite risky actually.

Thank you. I am sympathetic to CF’s need to deploy these configs globally fast and don’t think slowing down their DDoS mitigation is necessarily a good trade off. What I am saying is this presents a bigger reliability risk and needs correspondingly fine crafted observability around such config changes and a rollback runbook. Greater risk -> greater attention.

By rapid I mean a rapid rollout of changes to 100% of the fleet, not how often changes are made.

I’ve led multiple incident responses at a FAANG, here’s my take. The fundamental problem here is not Rust or the coding error. The problem is:

1. Their bot management system is designed to push a configuration out to their entire network rapidly. This is necessary so they can rapidly respond to attacks, but it creates risk as compared to systems that roll out changes gradually.

2. Despite the elevated risk of system wide rapid config propagation, it took them 2 hours to identify the config as the proximate cause, and another hour to roll it back.

SOP for stuff breaking is you roll back to a known good state. If you roll out gradually and your canaries break, you have a clear signal to roll back. Here was a special case where they needed their system to rapidly propagate changes everywhere, which is a huge risk, but didn’t quite have the visibility and rapid rollback capability in place to match that risk.

While it’s certainly useful to examine the root cause in the code, you’re never going to have defect free code. Reliability isn’t just about avoiding bugs. It’s about understanding how to give yourself clear visibility into the relationship between changes and behavior and the rollback capability to quickly revert to a known good state.

Cloudflare has done an amazing job with availability for many years and their Rust code now powers 20% of internet traffic. Truly a great team.

Or there's 3.5: separate services where it makes sense, but not necessarily small in number. "Makes sense" would entail things like, does it have distinct resource utilization or scaling characteristics, or do you want to enable your service to more gracefully degrade if that module becomes unavailable.

(This is basically the definition of 3 without the implication that it will be rare.)

As opposed to 4 which is about proactively breaking everything down into the smallest possible units on the expectation that the added complexity is always worth it.

I did primary research. I just bought an M5 Mac and confirmed by doing:

  $ sysctl -a | grep MTE4
  hw.optional.arm.FEAT_MTE4: 1

Not only does M5 have MTE, it has an "enhanced" version of it.

"We conducted a deep evaluation and research process to determine whether MTE, as designed, would meet our goals for hardware-assisted memory safety. Our analysis found that, when employed as a real-time defensive measure, the original Arm MTE release exhibited weaknesses that were unacceptable to us, and we worked with Arm to address these shortcomings in the new Enhanced Memory Tagging Extension (EMTE) specification, released in 2022."[1]

The enhancements add:[2]

* Canonical tag checking

* Reporting of all non-address bits on a fault

* Store-only Tag checking

* Memory tagging with Address tagging disabled

[1] https://security.apple.com/blog/memory-integrity-enforcement...

[2] https://developer.arm.com/documentation/109697/0100/Feature-...

That's really cool. I will just add that in my experience, with a bit of conditioning it is possible to get this satisfaction from crossing things off digital lists. The benefits are manifold:

- It saves paper

- It's easier and faster to reprioritize tasks

- It's always with you in your pocket

Personally I use Apple Notes which has checklists, as opposed to a task management system or even Reminders. The flexibility of just writing things into a freeform note and hitting a button to turn them into todos is the right balance of low friction and just enough structure. Hitting that circle to check it off when done is actually quite satisfying.

Bonus: I added a keyboard shortcut for strikethru which adds some extra satisfaction of crossing off the task (or portions of a task that i've written out).

Note that even with OAuth it took, as of today, security engineers many iterations of review and prompt tweaking to get this result. We’re still in the “mapping” phase.