In 2023, Raytheon’s pres­i­dent stood at the Paris Air Show and de­scribed what it took to restart Stinger mis­sile pro­duc­tion. They brought back en­gi­neers in their 70s to teach younger work­ers how to build a mis­sile from pa­per schemat­ics drawn dur­ing the Carter ad­min­is­tra­tion. Test equip­ment had been sit­ting in ware­houses for years. The nose cone still had to be at­tached by hand, ex­actly as it was forty years ago.

The Pentagon had­n’t bought a new Stinger in twenty years. Then Russia in­vaded Ukraine, and sud­denly every­one needed them. The pro­duc­tion line was shut down. The elec­tron­ics were ob­so­lete. The seeker com­po­nent was out of pro­duc­tion. An or­der placed in May 2022 would­n’t de­liver un­til 2026. Four years. Not be­cause of money. Because the peo­ple who knew how to build them re­tired a decade ear­lier and no­body re­placed them.

I run en­gi­neer­ing teams in Ukraine. My peo­ple lived the other side of this equa­tion. Not the fac­tory floor. The re­ceiv­ing end. While Raytheon was strug­gling to restart pro­duc­tion from forty-year-old blue­prints, the US was ship­ping thou­sands of Stingers to Ukraine. RTX CEO Greg Hayes: ten months of war burned through thir­teen years’ worth of Stinger pro­duc­tion. I’ve seen this pat­tern be­fore. It’s hap­pen­ing in my in­dus­try right now.

In March 2023, the EU promised Ukraine one mil­lion ar­tillery shells within twelve months. European pro­duc­tion ca­pac­ity sat at 230,000 shells per year. Ukraine was con­sum­ing 5,000 to 7,000 rounds per day. Anyone with a cal­cu­la­tor could see this would­n’t work.

By the dead­line, Europe de­liv­ered about half. Macron called the orig­i­nal promise reck­less. An in­ves­ti­ga­tion by eleven me­dia out­lets across nine coun­tries found ac­tual pro­duc­tion ca­pac­ity was roughly one-third of of­fi­cial EU claims. The mil­lion-shell mark was­n’t hit un­til December 2024, nine months late.

It was­n’t one bot­tle­neck. It was all of them. France had halted do­mes­tic pro­pel­lant pro­duc­tion in 2007. Seventeen years of noth­ing. Europe’s sin­gle ma­jor TNT pro­ducer was in Poland. Germany had two days of am­mu­ni­tion stored. A Nammo plant in Denmark was shut down in 2020 and had to be restarted from scratch. The en­tire con­ti­nen­t’s de­fense in­dus­try had been op­ti­mized for mak­ing small batches of ex­pen­sive cus­tom prod­ucts. Nobody planned for vol­ume. Nobody planned for cri­sis.

The U.S. was­n’t much bet­ter. One plant in Scranton, one fa­cil­ity in Iowa for ex­plo­sive fill, no do­mes­tic TNT pro­duc­tion since 1986. Billions of in­vest­ment later, pro­duc­tion still had­n’t hit half the tar­get.

This was­n’t an ac­ci­dent. In 1993, the Pentagon told de­fense CEOs to con­sol­i­date or die. Fifty-one ma­jor de­fense con­trac­tors col­lapsed into five. Tactical mis­sile sup­pli­ers went from thir­teen to three. Shipbuilders from eight to two. The work­force fell from 3.2 mil­lion to 1.1 mil­lion. A 65% cut.

The am­mu­ni­tion sup­ply chain had sin­gle points of fail­ure every­where. One man­u­fac­turer for 155mm shell cas­ings, sit­ting in Coachella, California, on the San Andreas Fault. One fa­cil­ity in Canada for pro­pel­lant charges. Optimized for min­i­mum cost with zero mar­gin for surge. On pa­per, ef­fi­cient. In prac­tice, one bad day away from col­lapse.

Then there’s Fogbank. A clas­si­fied ma­te­r­ial used in nu­clear war­heads. Produced from 1975 to 1989, then the fa­cil­ity was shut down. When the gov­ern­ment needed to re­pro­duce it for a war­head life ex­ten­sion pro­gram in 2000, they dis­cov­ered they could­n’t. A GAO re­port found that al­most all staff with pro­duc­tion ex­per­tise had re­tired, died, or left the agency. Few records ex­isted.

After spend­ing an ad­di­tional $69 mil­lion and years of re­verse en­gi­neer­ing, they fi­nally pro­duced vi­able Fogbank. Then dis­cov­ered the new batch was too pure. The orig­i­nal had con­tained an un­in­ten­tional im­pu­rity that was crit­i­cal to its func­tion. That fact ex­isted nowhere in any doc­u­ment. Only the work­ers who made the orig­i­nal batch knew it, and they had re­tired years ear­lier.

A nu­clear weapons pro­gram lost the abil­ity to make a ma­te­r­ial it in­vented. The knowl­edge ex­isted only in peo­ple, and the peo­ple were gone.

I read the Fogbank story and rec­og­nized it im­me­di­ately. Not the nu­clear ma­te­r­ial. The pat­tern. Build ca­pa­bil­ity over decades. Find a cheaper sub­sti­tute. Let the hu­man pipeline at­ro­phy. Enjoy the sav­ings. Then watch it all col­lapse when a cri­sis de­mands what you op­ti­mized away.

In de­fense, the sub­sti­tute was the peace div­i­dend. In soft­ware, it’s AI.

I wrote about the tal­ent pipeline col­lapse be­fore. The hir­ing num­bers and the ju­nior-to-se­nior prob­lem are doc­u­mented. So is the com­pre­hen­sion cri­sis. What I did­n’t have was the right his­tor­i­cal par­al­lel. Now I do.

And it tells you some­thing the hir­ing data does­n’t: how long re­build­ing ac­tu­ally takes.

Every ma­jor de­fense pro­duc­tion ramp-up took three to five years for sim­ple sys­tems. Five to ten for com­plex ones. Stinger: thirty months min­i­mum from or­der to de­liv­ery. Javelin: four and a half years to less than dou­ble pro­duc­tion. 155mm shells: four years and still not at tar­get de­spite five bil­lion dol­lars in­vested. France only restarted pro­pel­lant pro­duc­tion in 2024, sev­en­teen years af­ter shut­ting it down.

Money was never the con­straint. Knowledge was. RAND found that 10% of tech­ni­cal skills for sub­ma­rine de­sign need ten years of on-the-job ex­pe­ri­ence to de­velop, some­times fol­low­ing a PhD. Apprenticeships in de­fense trades take two to four years, with five to eight years to reach su­per­vi­sory com­pe­tence.

Now map that onto soft­ware. A ju­nior de­vel­oper needs three to five years to be­come a com­pe­tent mid-level en­gi­neer. Five to eight years to be­come se­nior. Ten or more to be­come a prin­ci­pal or ar­chi­tect. That time­line can’t be com­pressed by throw­ing money at it. It can’t be com­pressed by AI ei­ther.

A METR ran­dom­ized con­trolled trial found that ex­pe­ri­enced de­vel­op­ers us­ing AI cod­ing tools ac­tu­ally took 19% longer on real-world open source tasks. Before start­ing, they pre­dicted AI would make them 24% faster. The gap be­tween pre­dic­tion and re­al­ity was 43 per­cent­age points. When re­searchers tried to run a fol­low-up, a sig­nif­i­cant share of de­vel­op­ers re­fused to par­tic­i­pate if it meant work­ing with­out AI. They could­n’t imag­ine go­ing back.

The soft­ware in­dus­try is in year three of the same op­ti­miza­tion. Salesforce said it won’t hire more soft­ware en­gi­neers in 2025. A LeadDev sur­vey found 54% of en­gi­neer­ing lead­ers be­lieve AI copi­lots will re­duce ju­nior hir­ing long-term. A CRA sur­vey of uni­ver­sity com­put­ing de­part­ments found 62% re­ported de­clin­ing en­roll­ment this year.

I see it in code re­view. Review is now the bot­tle­neck. AI gen­er­ates code fast. Humans re­view it slow. The in­dus­try’s an­swer is pre­dictable: let AI re­view AI’s code. I’m not do­ing that. I’ve re­worked our pull re­quest tem­plates in­stead. Every PR now has to ex­plain what changed, why, what type of change it is, screen­shots of be­fore and af­ter. Structured con­text so the re­viewer is­n’t guess­ing. I’m adding ded­i­cated re­view­ers per pro­ject. More eyes, more chances to catch what the model missed.

But even that does­n’t solve the deeper prob­lem. The skills you need to be ef­fec­tive now are dif­fer­ent. Technical ex­per­tise alone is­n’t enough any­more. You need peo­ple who can take own­er­ship, com­mu­ni­cate trade­offs, push back on bad sug­ges­tions from a ma­chine that sounds very con­fi­dent. Leadership qual­i­ties. Our last hir­ing round tells you how rare that is: 2,253 can­di­dates, 2,069 dis­qual­i­fied, 4 hired. A 0.18% con­ver­sion rate. The com­bi­na­tion of tech­ni­cal skill and the judg­ment to know when the AI is wrong barely ex­ists in the mar­ket any­more.

We doc­u­ment every­thing. Site Books, SDDs, RVS re­ports, boil­er­plate mod­ules with full cov­er­age. It works to­day, be­cause the peo­ple read­ing those docs have the en­gi­neer­ing ex­per­tise to act on them. What hap­pens when they don’t? Honestly, I don’t know. Maybe AI in five years is good enough that it won’t mat­ter. Maybe the prob­lem stays man­age­able. I can’t pre­dict the ca­pa­bil­i­ties of mod­els in 2031.

But crises don’t send cal­en­dar in­vites. Nobody ex­pected a full-scale land war in Europe in 2022. The de­fense in­dus­try had thirty years to pre­pare and did­n’t. Even Fogbank had records. They weren’t enough with­out the peo­ple who un­der­stood what they meant.

Five to ten years from now, we’ll need se­nior en­gi­neers. People who un­der­stand sys­tems end to end, who can de­bug dis­trib­uted fail­ures at 2 AM, who carry in­sti­tu­tional knowl­edge that ex­ists nowhere in the code­base. Those en­gi­neers don’t ex­ist yet be­cause we’re not cre­at­ing them. The ju­niors who should be learn­ing right now are ei­ther not be­ing hired or de­vel­op­ing what a DoD-funded work­force study calls “AI-mediated com­pe­tence.” They can prompt an AI. They can’t tell you what the AI got wrong.

It’s Fogbank for code. When ju­niors skip de­bug­ging and skip the for­ma­tive mis­takes, they don’t build the tacit ex­per­tise. And when my gen­er­a­tion of en­gi­neers re­tires, that knowl­edge does­n’t trans­fer to the AI.

It just dis­ap­pears.

The West al­ready made this mis­take once. The bill came due in Ukraine.

I know how this sounds. I know I’ve writ­ten about the tal­ent pipeline be­fore. The de­fense ex­am­ple is­n’t about re­peat­ing the ar­gu­ment. It’s about show­ing what hap­pens if the in­dus­try’s ex­pec­ta­tions don’t work out. Stinger, Javelin, Fogbank, a mil­lion shells no­body could make. That’s the cost of bet­ting wrong on op­ti­miza­tion. We’re mak­ing the same bet with soft­ware en­gi­neer­ing right now.

Maybe AI gets good enough, and the bet pays off. Maybe it does­n’t. The de­fense in­dus­try thought peace would last for­ever, too.

No posts

April 24, 2026

4 min read

Add Us On GoogleAdd SciAm

An am­a­teur just solved a 60-year-old math prob­lem—by ask­ing AI

An am­a­teur just solved a 60-year-old math prob­lem—by ask­ing AI

A ChatGPT AI has proved a con­jec­ture with a method no hu­man had thought of. Experts be­lieve it may have fur­ther uses

By Joseph Howlett edited by Lee Billings

Eugene Mymrin/Getty Images

Liam Price just cracked a 60-year-old prob­lem that world-class math­e­mati­cians have tried and failed to solve. He’s 23 years old and has no ad­vanced math­e­mat­ics train­ing. What he does have is a ChatGPT Pro sub­scrip­tion, which gives him ac­cess to the lat­est large lan­guage mod­els from OpenAI.

Artificial in­tel­li­gence has re­cently made head­lines for solv­ing a num­ber of “Erdős prob­lems,” con­jec­tures left be­hind by the pro­lific math­e­mati­cian Paul Erdős. But ex­perts have warned that these prob­lems are an im­per­fect bench­mark of ar­ti­fi­cial in­tel­li­gence’s math­e­mat­i­cal prowess. They range dra­mat­i­cally in both sig­nif­i­cance and dif­fi­culty, and many AI so­lu­tions have turned out to be less orig­i­nal than they ap­peared.

The new so­lu­tion—which Price got in re­sponse to a sin­gle prompt to GPT-5.4 Pro and posted on www.er­dosprob­lems.com, a web­site de­voted to the Erdős prob­lems, just over a week ago—is dif­fer­ent. The prob­lem it solves has eluded some promi­nent minds, be­stow­ing it some es­teem. And more im­por­tantly, the AI seems to have used a to­tally new method for prob­lems of this kind. It’s too soon to say with cer­tainty, but this LLM-conceived con­nec­tion may be use­ful for broader ap­pli­ca­tions—some­thing hard to find among re­cently touted AI tri­umphs in math.

On sup­port­ing sci­ence jour­nal­ism

If you’re en­joy­ing this ar­ti­cle, con­sider sup­port­ing our award-win­ning jour­nal­ism by sub­scrib­ing. By pur­chas­ing a sub­scrip­tion you are help­ing to en­sure the fu­ture of im­pact­ful sto­ries about the dis­cov­er­ies and ideas shap­ing our world to­day.

“This one is a bit dif­fer­ent be­cause peo­ple did look at it, and the hu­mans that looked at it just col­lec­tively made a slight wrong turn at move one,” says Terence Tao, a math­e­mati­cian at the University of California, Los Angeles, who has be­come a promi­nent score­keeper for AI’s push into his field. “What’s be­gin­ning to emerge is that the prob­lem was maybe eas­ier than ex­pected, and it was like there was some kind of men­tal block.”

The ques­tion Price solved—or prompted ChatGPT to solve—con­cerns spe­cial sets of whole num­bers, where no num­ber in the set can be evenly di­vided by any other. Erdős called these “primitive sets” be­cause of their con­nec­tion to sim­i­larly in­di­vis­i­ble prime num­bers.

“A num­ber is prime if it has no other di­vi­sors, and this is kind of gen­er­al­iz­ing that de­f­i­n­i­tion from an in­di­vid­ual num­ber to a col­lec­tion of num­bers,” says Jared Lichtman, a math­e­mati­cian at Stanford University. Any set of prime num­bers is au­to­mat­i­cally prim­i­tive, be­cause primes have no fac­tors (except them­selves and the num­ber one).

Erdős also came up with the Erdős sum, a “score” you can cal­cu­late for any prim­i­tive set. He showed that the biggest the sum could be was about 1.6—and con­jec­tured that this value must also hold for the (infinite) set of all prime num­bers. Lichtman proved Erdős right as part of his doc­toral the­sis in 2022.

Erdős also no­ticed that the score drops if all of a set’s num­bers are large—the larger the num­bers, the lower the score. He guessed that the low­est this score could be was ex­actly one, a limit that the score would ap­proach as the set’s num­bers ap­proached in­fin­ity. Lichtman tried to prove this, too, but got stuck like every­one else be­fore him.

Price was­n’t aware of this his­tory when he en­tered the prob­lem into ChatGPT on an idle Monday af­ter­noon. “I did­n’t know what the prob­lem was—I was just do­ing Erdős prob­lems as I do some­times, giv­ing them to the AI and see­ing what it can come up with,” he says. “And it came up with what looked like a right so­lu­tion.”

He sent it to his oc­ca­sional col­lab­o­ra­tor Kevin Barreto, a sec­ond-year un­der­grad­u­ate in math­e­mat­ics at the University of Cambridge. The duo had jump-started the AI-for-Erdős craze late last year by prompt­ing a free ver­sion of ChatGPT with open prob­lems cho­sen at ran­dom from the Erdős prob­lems web­site. (An AI re­searcher sub­se­quently gifted them each a ChatGPT Pro sub­scrip­tion to en­cour­age their “vibe math­ing.”)

Reviewing Price’s mes­sage, Barreto re­al­ized what they had was spe­cial, and ex­perts whom he no­ti­fied quickly took no­tice.

“There was kind of a stan­dard se­quence of moves that every­one who worked on the prob­lem pre­vi­ously started by do­ing,” Tao says. The LLM took an en­tirely dif­fer­ent route, us­ing a for­mula that was well known in re­lated parts of math, but which no one had thought to ap­ply to this type of ques­tion.

“The raw out­put of ChatGPT’s proof was ac­tu­ally quite poor. So it re­quired an ex­pert to kind of sift through and ac­tu­ally un­der­stand what it was try­ing to say,” Lichtman says. But now he and Tao have short­ened the proof so that it bet­ter dis­tills the LLM’s key in­sight.

More im­por­tantly, they al­ready see other po­ten­tial ap­pli­ca­tions of the AI’s cog­ni­tive leap. “We have dis­cov­ered a new way to think about large num­bers and their anatomy,” Tao says. “It’s a nice achieve­ment. I think the jury is still out on the long-term sig­nif­i­cance.”

Lichtman is hope­ful be­cause ChatGPT’s dis­cov­ery val­i­dates a sense he’s had since grad­u­ate school. “I had the in­tu­ition that these prob­lems were kind of clus­tered to­gether and they had some kind of uni­fy­ing feel to them,” he says. “And this new method is re­ally con­firm­ing that in­tu­ition.”

It’s Time to Stand Up for Science

If you en­joyed this ar­ti­cle, I’d like to ask for your sup­port. Scientific American has served as an ad­vo­cate for sci­ence and in­dus­try for 180 years, and right now may be the most crit­i­cal mo­ment in that two-cen­tury his­tory.

I’ve been a Scientific American sub­scriber since I was 12 years old, and it helped shape the way I look at the world. SciAm al­ways ed­u­cates and de­lights me, and in­spires a sense of awe for our vast, beau­ti­ful uni­verse. I hope it does that for you, too.

If you sub­scribe to Scientific American, you help en­sure that our cov­er­age is cen­tered on mean­ing­ful re­search and dis­cov­ery; that we have the re­sources to re­port on the de­ci­sions that threaten labs across the U.S.; and that we sup­port both bud­ding and work­ing sci­en­tists at a time when the value of sci­ence it­self too of­ten goes un­rec­og­nized.

In re­turn, you get es­sen­tial news, cap­ti­vat­ing pod­casts, bril­liant in­fo­graph­ics, can’t-miss newslet­ters, must-watch videos, chal­leng­ing games, and the sci­ence world’s best writ­ing and re­port­ing. You can even gift some­one a sub­scrip­tion.

There has never been a more im­por­tant time for us to stand up and show why sci­ence mat­ters. I hope you’ll sup­port us in that mis­sion.

After al­most three years of 6.x se­ries ker­nels, Linux 7.0 is fi­nally here.

That means it’s also time for an­other Asahi progress re­port!

Automate Everything

Users of al­ter­nate dis­tros and keen-eyed in­di­vid­u­als may have no­ticed some

changes to the Asahi Installer. After al­most two years, we fi­nally got around

to push­ing an up­dated ver­sion of the in­staller to the CDN! Two years is a long

time to go be­tween up­dates, so what took so long?

Our up­stream in­staller pack­age is a lit­tle bit of a Rube-Goldberg ma­chine. The

bulk of the in­staller is writ­ten in Python, with some small Bash scripts to

boot­strap it. When you run curl | sh, you’re ac­tu­ally down­load­ing the boos­t­rap

script, which then fetches the ac­tual in­staller bun­dle from our CDN. This bun­dle

con­sists of a Python in­ter­preter and very stripped down stan­dard li­brary, a built

m1n1 stage 1 bi­nary, and the in­staller it­self.

Until re­cently, cut­ting an in­staller re­lease meant:

Tagging the in­staller repo

Downloading a ma­cOS Python build

Building m1n1 from a blessed com­mit

Bundling Python, m1n1 and the in­staller

Uploading the in­staller bun­dle to the CDN

Updating the CDN’s ver­sion flag file

This process was time-con­sum­ing and re­quired ad­min­is­tra­tive ac­cess to the CDN.

As a re­sult, we ne­glected to push in­staller up­dated for quite some time; the

pre­vi­ous in­staller tag was from June 2024! As up­stream­ing work has pro­gressed

and Devicetree bind­ings churned, this be­came rather prob­lem­atic for our friends

main­tain­ing dis­tros.

The Asahi Installer of­fers a UEFI-only in­stal­la­tion op­tion. This op­tion

shrinks ma­cOS and only in­stalls what is nec­es­sary to boot a UEFI ex­e­cutable,

mean­ing m1n1 stage 1, the Devicetrees, and U-Boot. This al­lows users to

boot from live me­dia with Asahi sup­port, such as spe­cialised Gentoo Asahi

LiveCD im­ages.

Since the Devicetrees on a fresh UEFI-only in­stall come from the in­staller

bun­dle it­self, a ker­nel will only suc­cess­fully boot when the in­staller-bun­dled

Devicetrees match what that ker­nel ex­pects to see. The two have got­ten rather

out of sync as time has gone on due to Devicetree bind­ings chang­ing

as a re­sult of the up­stream­ing process. This sit­u­a­tion fi­nally came to a

head with ker­nel 6.18, which re­quired nu­mer­ous changes to both m1n1 and

the Devicetree bind­ings for the Apple USB sub­sys­tem. This made boot­ing

ker­nel 6.18 and above from live me­dia im­pos­si­ble. Oops.

Rather than go through the trou­ble of man­u­ally push­ing out an­other up­date,

we took the op­por­tu­nity to build some au­toma­tion and solve this prob­lem

per­ma­nently.

We moved the man­i­fest of in­stal­lable im­ages into the asahi-in­staller-data repo,

al­low­ing us to up­date it in­de­pen­dently of the in­staller code­base.

On top of this, we also now de­ploy

the in­staller us­ing GitHub work­flows. Going for­ward, every push to the main

branch of asahi-in­staller will

au­to­mat­i­cally build the in­staller and up­load it to https://​alx.sh/​dev.

Every tag pushed to GitHub will do the same for https://​alx.sh.

The lat­est ver­sion, 0.8.0, bumps the bun­dled m1n1 stage 1 bi­nary to

ver­sion 1.5.2, in­tro­duces in­staller sup­port for the Mac Pro, and adds

a firmware up­date mode which ties in nicely with…

How do you ov­erengi­neer a light sen­sor?

Basically every­thing with a screen now comes with some sort of light

sen­sor. This is usu­ally to en­able au­to­matic bright­ness ad­just­ment based

on am­bi­ent con­di­tions. It’s a very con­ve­nient fea­ture in de­vices like

smart­phones, where a user may walk out­side and find their dis­play too

dim to see. The cheap­est ver­sions of this use a sim­ple pho­tore­sis­tor.

This is fine if the goal is just to change bright­ness, but bright­ness

is not the only thing af­fected by am­bi­ent light­ing con­di­tions. What about

colour ren­der­ing?

Apple’s de­vices have had the True Tone dis­play fea­ture for quite some time.

This works by mea­sur­ing both the bright­ness and the colour char­ac­ter­is­tics

of the en­vi­ron­men­t’s am­bi­ent light­ing. This data is then used to ap­ply

bright­ness and colour trans­for­ma­tions to the dis­play to en­sure that it is

al­ways dis­play­ing con­tent as ac­cu­rately as pos­si­ble. This is most no­tice­able

in en­vi­ron­ments with light­ing fix­tures that have a low Colour Rendering

Index, such as flu­o­res­cent tubes or cheap cool white LEDs. The de­vices that

en­able this, am­bi­ent light sen­sors, are usu­ally lit­tle ICs that con­nect

to the sys­tem over I2C or other in­dus­try-stan­dard bus. This is

fine for ba­sic ap­pli­ca­tions, but this is Apple. There are some other con­sid­er­a­tions

to be had:

The light sen­sor is do­ing stuff when­ever the screen is on, so pro­cess­ing its

out­put should be as ef­fi­cient as pos­si­ble

The light sen­sor should be able to be cal­i­brated for max­i­mum ac­cu­racy

There are mul­ti­ple mod­els of light sen­sor in use, and the OS should not

have to care too much about that

The light sen­sor has to have a three let­ter acronym like every other piece

of hard­ware on this plat­form (ALS)

Naturally, this sounds like a job for the Always-On Processor1 (AOP)!

We’ve had a work­ing AOP+ALS dri­ver set for a while thanks to chaos_princess,

how­ever the raw data AOP re­ports back from ALS is rather in­ac­cu­rate with­out

cal­i­bra­tion. That cal­i­bra­tion is a bi­nary blob that must be up­loaded to the AOP

at run­time. It is es­sen­tially firmware. Since we can­not re­dis­trib­ute Apple’s

bi­na­ries, it must be re­trieved from ma­cOS at in­stall time and then stored some­where the dri­ver

knows to look for it.

To achieve this, the Asahi Installer gath­ers up all

the firmware it knows we will need in Linux and stores it on the EFI System

Partition it cre­ates. A Dracut mod­ule then mounts this to a sub­di­rec­tory of

/lib/firmware/, where dri­vers can find it. However, is­sues arise when we

need to re­trieve more firmware from ma­cOS af­ter Asahi Linux has al­ready been

in­stalled. To avoid a re­peat of the we­b­cam sit­u­a­tion, where users

were re­quired to man­u­ally do surgery on their EFI System Partition, chaos_princess

added the abil­ity for the Asahi Installer to au­to­mat­i­cally up­date the firmware

pack­age. Starting with ALS, any re­quired firmware up­dates will be a sim­ple

mat­ter of boot­ing into ma­cOS or ma­cOS Recovery, re-run­ning the Asahi Installer, and fol­low­ing

the prompts.

To en­able ALS sup­port (and to do firmware up­grades in the fu­ture), fol­low these steps:

Ensure you are run­ning ver­sion 6.19 or above of the Asahi ker­nel

Ensure your dis­tro ships iio-sen­sor-proxy as a de­pen­dency of your DE (Fedora

Asahi Remix does this)

What would you do if your or­ga­ni­za­tion had used a do­main name for 27 years, and the reg­is­trar hold­ing the do­main seized it with­out any ad­vance warn­ing? All email and web­sites went dark. The com­pa­ny’s tech sup­port spent four days telling you to “Just wait, we are work­ing on it.” On the fourth day, the com­pany in­formed you that some­one else has the do­main now, and it is no longer yours.

Read on. This crazy story hap­pened ex­actly one week ago.

My friend Lee Landis is a part­ner in Flagstream Technologies, a lo­cal IT firm in Lancaster, PA. Last Saturday af­ter­noon one of his clien­t’s do­mains van­ished from his GoDaddy ac­count.

Lee is one of the most com­pe­tent IT guys I know. The GoDaddy ac­count had dual two-fac­tor au­then­ti­ca­tion en­abled, re­quir­ing both an email code and an au­then­ti­ca­tion app code to log in. The do­main it­self had own­er­ship pro­tec­tion turned on. The au­dit log just said “Transfer to Another GoDaddy Account” by an “Internal User” with “Change Validated: No.”

Some names have been changed

Some names and the do­main it­self have been changed be­cause peo­ple wanted to re­main anony­mous. The pat­tern of the do­main names mir­rors the ac­tual mis­take, so the ex­pla­na­tion still makes sense. Every fact in this post is true. Lee has hard ev­i­dence for every one of them.

As you can see above, GoDaddy emailed Flagstream at 1:39pm that an ac­count re­cov­ery had been re­quested. Three min­utes later, the trans­fer was ini­ti­ated. Four min­utes later, it was com­plete. On a Saturday af­ter­noon.

Everything at the im­pacted or­ga­ni­za­tion went of­fline be­cause GoDaddy re­set the DNS zone to de­fault when they moved the do­main into the new ac­count. Same name­servers. Empty DNS zone file.

Lee’s client lost their web­site and email for the next four days.

27 yrs

Domain in ac­tive use

32

Calls to GoDaddy

9.6 hrs

On the phone with GoDaddy

17

Emails to GoDaddy. Zero call­backs.

Domain and ac­count were fully pro­tected.

The do­main had the “Full Domain Privacy and Protection” se­cu­rity prod­uct that GoDaddy sells. Dual two-fac­tor on the ac­count. None of it mat­tered. The trans­fer was done by an “Internal User” in­side GoDaddy.

The do­main was HELPNETWORKINC.ORG. The real do­main name has been changed be­cause the or­ga­ni­za­tion wanted to re­main anony­mous. It be­longs to a na­tional or­ga­ni­za­tion with twenty lo­ca­tions across the United States. The do­main has been in ac­tive use for 27 years. Each chap­ter runs its web­site and email on a sub­do­main of that one par­ent do­main. When HELPNETWORKINC.ORG went dark, every chap­ter went dark with it.

Thirty-two calls. 9.6 hours on the phone. Zero call­backs.

Lee called GoDaddy on Sunday. They con­firmed the do­main was no longer in his ac­count but could not say where it went due to pri­vacy con­cerns. They told him to email undo@go­daddy.com. He did but did not re­ceive any type of re­sponse when email­ing that ad­dress. Of course Lee did­n’t re­ally feel like this was the ap­pro­pri­ate level of ur­gency for this is­sue. He asked for a su­per­vi­sor who was even less help­ful. Lee was not happy. He may have said some hurt­ful things to GoDaddy’s sup­port per­son­nel dur­ing this call. That first call lasted 2 hours, 33 min­utes, and 14 sec­onds.

On Monday morn­ing, Lee and a coworker started work­ing in earnest on this is­sue be­cause there was still no up­date from GoDaddy. Calling in yielded a dif­fer­ent agent who told Lee to email trans­fer­dis­putes@go­daddy.com instead. By Tuesday the ad­dress had changed again to artre­view@go­daddy.com. The in­struc­tions shifted by the day. It seemed like every GoDaddy tech sup­port per­son had a slightly dif­fer­ent rec­om­men­da­tion.

The one thing that stayed con­sis­tent was the mes­sage: “Just wait a day or two. We are work­ing on it. Why do you think this is so ur­gent?”

One of the most frus­trat­ing parts of this process is that all of­fi­cial com­mu­ni­ca­tion to and from GoDaddy about this is­sue was done with gener­i­cally named email ac­counts. It just seems like there should have been a named in­di­vid­ual in charge of man­ag­ing and com­mu­ni­cat­ing about this is­sue. Rather there were just ran­dom generic email ac­counts that seemed to change on a daily ba­sis.

Every call gen­er­ated a fresh case num­ber. Lee lost count of the to­tal num­ber of cases. A few of the cases are 01368489. 894760. 01376819. 01373017. 01376804. 01373134. 01370012. None of them tied to­gether on GoDaddy’s side. Every es­ca­la­tion started from zero. These are ac­tual case num­bers, in case any­one at GoDaddy wants to check into this.

I posted on X to see if any­one I knew at GoDaddy could es­ca­late.

Can any of my GoDaddy friends help? A good friend of mine had a do­main taken. My friend is very com­pe­tent. Domain own­er­ship pro­tec­tion was on. Owner did not get any no­tices. Audit log looks fishy. Phone/email sup­port telling them to wait. Did a GoDaddy em­ployee take it? pic.twit­ter.com/​OW­cJIal­WcF— Austin Ginder (@austinginder) April 20, 2026

Can any of my GoDaddy friends help? A good friend of mine had a do­main taken. My friend is very com­pe­tent. Domain own­er­ship pro­tec­tion was on. Owner did not get any no­tices. Audit log looks fishy. Phone/email sup­port telling them to wait. Did a GoDaddy em­ployee take it? pic.twit­ter.com/​OW­cJIal­WcF

My friend Courtney Robertson, who works at GoDaddy, re­posted it and started es­ca­lat­ing in­ter­nally on her own time. Thank you, Courtney. GoDaddy has a lot of great peo­ple like her. That part is not in ques­tion. What GoDaddy does not have is a way to ac­tu­ally fix a mis­take once one has been made. Tickets pile up. Phone calls re­set. Every es­ca­la­tion is a new per­son read­ing the case from scratch. The thing you ac­tu­ally need solved drifts be­tween queues.

And there was no real way to dis­pute it.

While Lee was on the phone, his col­league was on a dif­fer­ent phone try­ing to file a Transfer Dispute. GoDaddy di­rected him to cas.go­daddy.com/​Form/​Trans­fer­Dis­pute. He filed a dis­pute and re­ceived this mes­sage, which he cap­tured via a screen­shot.

Lee and his col­leagues worked dili­gently at chal­leng­ing the trans­fer. They sup­plied the cor­rect name of the per­son listed on the do­main. They sup­plied that per­son’s dri­vers li­cense as re­quired. They also sup­plied the cor­rect busi­ness doc­u­men­ta­tion as listed in GoDaddy’s own re­quire­ments. Every time they sub­mit­ted a re­quest, they were told they would hear back in 48 to 72 hours.

GoDaddy FINALLY re­sponds with a SHOCKING state­ment

Tuesday af­ter­noon, af­ter four days of wait­ing, Flagstream fi­nally got an of­fi­cial email re­sponse back from GoDaddy.

GoDaddy’s re­ply to Lee

After in­ves­ti­gat­ing the do­main name(s) in ques­tion, we have de­ter­mined that the reg­is­trant of the do­main name(s) pro­vided the nec­es­sary doc­u­men­ta­tion to ini­ti­ate a change of ac­count. … GoDaddy now con­sid­ers this mat­ter closed.

That was it. No ex­pla­na­tion of what doc­u­men­ta­tion. The sug­gested next steps were three links. A WHOIS lookup. ICANN ar­bi­tra­tion providers. A page about get­ting a lawyer in­volved to rep­re­sent you in lit­i­ga­tion.

Flagstream mi­grates client to new do­main

Once GoDaddy de­clared the mat­ter closed, Flagstream be­gan mi­grat­ing the client to a new do­main. New email ad­dresses. New web­site ad­dresses. Coordinating with var­i­ous teams through­out the night to change every­thing over to a new do­main.

Switching to a new do­main is a mas­sive amount of work, and it leaves a lot of lin­ger­ing prob­lems be­hind be­cause there is no con­trol over the orig­i­nal do­main.

Every email ad­dress that ex­ists out in the world is now wrong. You have to tell every­one the new ad­dress. If they try the old one, it bounces.

Every piece of mar­ket­ing ma­te­r­ial that ref­er­ences the old do­main is now in­cor­rect. There is no way to for­ward any­thing to the new do­main.

All of the SEO is gone. You are start­ing an on­line pres­ence from scratch.

Then a stranger found the do­main in her ac­count.

Wednesday morn­ing Susan (not her real name), 2,000 miles away from the clien­t’s head­quar­ters, no­ticed some­thing odd. Susan had been work­ing at re­claim­ing a to­tally dif­fer­ent do­main used by a for­mer em­ployee. When she looked closely at her GoDaddy ac­count, the do­main in her ac­count was­n’t the one she had re­quested. She made a few phone calls be­cause she knew this was a prob­lem and even­tu­ally got hooked up with Flagstream. Working with Susan, they ran a GoDaddy ac­count-to-ac­count trans­fer, and put the do­main back where it be­longed. DNS came back up while Lee was still typ­ing the email telling me it was over. The en­tire process of re­claim­ing the do­main lasted less than 5 min­utes.

Once the do­main was back and DNS was work­ing, Flagstream started the ar­du­ous task of re­vert­ing every­thing that they had done the day be­fore. They switched email and web­sites back to the orig­i­nal do­main, once again work­ing through the night to get every­thing fixed.

The res­o­lu­tion for this prob­lem did not come from GoDaddy sup­port. It did not come from the dis­pute team. It did not come from the Office of the CEO team. It came from a stranger who ac­ci­den­tally ended up with the do­main and was smart and hon­est enough to start call­ing around be­cause she knew some­thing was­n’t right.

Susan is re­ally the hero of this en­tire story. Without her, Flagstream would still have no idea what hap­pened to this do­main. Lawyers would have got­ten in­volved, but it would prob­a­bly be months un­til any­thing was re­solved.

Timeline of events

Apr 18, 1:39pm

GoDaddy emails Flagstream that an Account Recovery has been re­quested for the ac­count.

Apr 18, 1:42pm

Transfer ini­ti­ated by GoDaddy Internal User. Three min­utes af­ter the re­cov­ery no­tice.

Apr 18, 1:43pm

Transfer com­pleted. Change Validated is listed as “No”. Website and email go dark across the en­tire or­ga­ni­za­tion.

Apr 19

Lee dis­cov­ers the do­main is gone. GoDaddy says email undo@go­daddy.com and wait.

Apr 20

Flagstream team starts call­ing and email­ing GoDaddy for up­dates. GoDaddy now says email trans­fer­dis­putes@go­daddy.com. Austin posts on X. Courtney Robertson routes the case to the Office of the CEO team.

Apr 21

Flagstream files mul­ti­ple Transfer Dispute cases with the re­quested doc­u­men­ta­tion. Every sub­mis­sion is met with a 48 to 72 hour re­sponse win­dow. GoDaddy emails Lee that the mat­ter is closed and the do­main be­longs to some­one else. Flagstream starts the painful process of mi­grat­ing the or­ga­ni­za­tion to a new do­main so they can func­tion.

Apr 22

Susan no­tices the wrong do­main in her ac­count and calls Lee. Account-to-account trans­fer brings it home.

Then it got cra­zier. GoDaddy ap­proved the trans­fer with zero doc­u­ments.

The or­ga­ni­za­tion on the re­ceiv­ing end of the trans­fer was a re­gional chap­ter of the same net­work. Susan, the ex­ec­u­tive as­sis­tant, had emailed GoDaddy two weeks ear­lier ask­ing to re­cover a dif­fer­ent do­main. HELPNETWORKLOCAL.ORG. Not HELPNETWORKINC.ORG.

Flagstream spent some time talk­ing to Susan to fig­ure out ex­actly how she was able to ac­ci­den­tally get the do­main trans­ferred into her ac­count. Did she un­in­ten­tion­ally sup­ply all of the cor­rect doc­u­men­ta­tion? Talking to Susan they fig­ured out that GoDaddy ac­tu­ally ap­proved the trans­fer with­out her sup­ply­ing ANY doc­u­men­ta­tion.

Her email sig­na­ture hap­pened to ref­er­ence her chap­ter’s web­site at a sub­do­main of HELPNETWORKINC.ORG. GoDaddy’s re­cov­ery team ap­par­ently looked at the sig­na­ture, saw the par­ent do­main, and trans­ferred that do­main into her ac­count.

GoDaddy sent Susan a link to up­load sup­port­ing doc­u­ments. The link ex­pired be­fore she got around to us­ing it. She emailed back re­quest­ing a new link so she could up­load the re­quired doc­u­men­ta­tion. However, be­fore the new link ar­rived, she re­ceived an email say­ing the do­main trans­fer had been ap­proved.

Susan never sub­mit­ted a sin­gle doc­u­ment. Not for the do­main she was ac­tu­ally try­ing to re­cover, and cer­tainly not for the one GoDaddy ended up giv­ing her. GoDaddy ap­proved the change of ac­count, trans­ferred a 27-year-old non-prof­it’s do­main into a stranger’s ac­count, and “considered the mat­ter closed” with­out re­quir­ing any doc­u­men­ta­tion.

This is a huge se­cu­rity is­sue.

If Susan had been a bad ac­tor, she could have in­ter­cepted email. She could have used that email to re­set pass­words, get MFA codes, launch phish­ing at­tacks, etc. She could have put up a new web­site with mal­ware on it, redi­rected pay­ments on the web­site, etc.

When the do­main ini­tially dis­ap­peared and Flagstream was un­able to ob­tain any in­for­ma­tion about who had it, Flagstream feared the worst. Flagstream and the im­pacted client started to come up with a plan to pro­tect against the threats men­tioned above which was a huge un­der­tak­ing for an or­ga­ni­za­tion of this size. Basically, all users across the en­tire or­ga­ni­za­tion needed to start log­ging into every im­por­tant web­site and make sure the com­pro­mised do­main was re­moved from the ac­count. This in­cludes bank web­sites, Amazon, IRS, pay­roll, Dropbox, email ac­counts, and even iron­i­cally enough, GoDaddy ac­counts.

It is out­ra­geous that Susan was able to ob­tain this do­main with­out sup­ply­ing any doc­u­men­ta­tion. Everyone was lucky it was Susan that got this do­main.

GoDaddy: please fol­low up with Flagstream.

This is not ac­cept­able.

A GoDaddy em­ployee trans­ferred a 27-year-old do­main out of a pay­ing cus­tomer’s ac­count with no val­i­da­tion. With zero doc­u­men­ta­tion sub­mit­ted by the re­cip­i­ent. When the cus­tomer dis­puted with le­git­i­mate doc­u­men­ta­tion, every sub­mis­sion was met with “We will re­spond in 48 to 72 hours.” After four days, GoDaddy claimed the do­main be­longed to some­one else and the case was closed. The fix came from the re­cip­i­ent of the mis­take, not from GoDaddy de­spite 9.6 hours of phone con­ver­sa­tions.

To any­one at GoDaddy read­ing this. Please fol­low up with Lee Landis at Flagstream Technologies and make this right. An apol­ogy is prob­a­bly in or­der. An in­ter­nal re­view of how the trans­fer team val­i­dates doc­u­men­ta­tion is in or­der, in­clud­ing how a trans­fer can be ap­proved with zero doc­u­men­ta­tion. Lee would like a clear an­swer on how this hap­pened. Lee does­n’t want an email from a generic GoDaddy ac­count. Lee wants a real per­son to call or email him. This per­son needs to leave an email ad­dress and phone num­ber in case Lee has fol­low-up ques­tions.

Even dis­clos­ing this to GoDaddy was bro­ken.

Before pub­lish­ing this post, I wanted to share the find­ings with GoDaddy’s se­cu­rity team di­rectly. I emailed se­cu­rity@go­daddy.com with the full re­port. The mes­sage bounced.

GoDaddy’s auto-re­ply to se­cu­rity@go­daddy.com

A cus­tom mail flow rule cre­ated by an ad­min at se­cure­server­net.on­mi­crosoft.com has blocked your mes­sage. We hope this mes­sage finds you well. This email mail­box is no longer mon­i­tored. To ad­dress your needs, we have out­lined two pop­u­lar op­tions for you: 1: To sub­mit an abuse re­port, please visit our Abuse Reporting Form. 2: If you are look­ing to sub­mit a vul­ner­a­bil­ity, please visit our bounty pro­gram https://​hackerone.com/​go­daddy-vdp.

So I filed the same re­port through HackerOne in­stead, re­port #3696718.

This is the same pat­tern that played out across the four-day out­age. The of­fi­cial chan­nel does not work. The al­ter­na­tive path re­quires know­ing to by­pass it. Most hon­est peo­ple who no­tice a se­cu­rity is­sue are not go­ing to have a HackerOne ac­count. They send an email. How is it that GoDaddy does­n’t have a pub­lic se­cu­rity dis­clo­sure email ad­dress?

Whether the orig­i­nal trans­fer was a sin­gle agen­t’s mis­take or a flaw in the re­cov­ery work­flow, it is still a se­cu­rity is­sue. And there is no clean path from “I found some­thing” to “a hu­man at GoDaddy is look­ing at it.”

The only way to get GoDaddy’s at­ten­tion is to leave.

Lee is up­set about the four days of stress and lost pro­duc­tiv­ity across the im­pacted or­ga­ni­za­tion. But his big­ger con­cern is what comes next. Apparently there is no way to pro­tect against this threat if your do­main is hosted at GoDaddy. In ad­di­tion, it seems like there is no ef­fi­cient way to con­test the GoDaddy trans­fer.

Flagstream will most likely mi­grate every one of their do­mains off GoDaddy. That is the only pro­tec­tion they have left, and the only es­ca­la­tion GoDaddy seems to re­spond to.

Are you at risk?

Is your do­main hosted on GoDaddy? What would you do if the do­main dis­ap­peared out of your GoDaddy ac­count and your en­tire busi­ness went dark?

Most peo­ple think EU Age Control apps are about iden­ti­fy­ing users. The sales pitch is all zero-knowl­edge proofs of age. You prove you’re over 18 with­out the site learn­ing your name, ex­act birth­day or any­thing that can link one proof to an­other.

Before go­ing fur­ther, it is worth lay­ing out three sep­a­rate prob­lems this post is wor­ried about. They are easy to blur but they are very dif­fer­ent. First: the DSA fall­back — plat­forms don’t ac­tu­ally need the pri­vacy-pre­serv­ing wal­let; the rules let them use a nor­mal KYC provider in­stead. Second: at­tes­ta­tion lock-in — Google and Apple de­cide what soft­ware runs on the phones that can use this sys­tem. Third: the sys­tem it­self is weaker than ad­ver­tised — the cryp­tog­ra­phy the ref­er­ence app ac­tu­ally ships is not the cryp­tog­ra­phy the mar­ket­ing de­scribes, un­link­a­bil­ity de­pends on wal­let be­hav­ior not math, and there is a whole class of re­lay at­tacks the pro­to­col can­not stop. When com­men­ta­tors wave away “the hacks,” they usu­ally mean bugs in the mock-up.

It is also worth ask­ing when this app started be­ing de­scribed as “just a ref­er­ence im­ple­men­ta­tion” or a “white-label demo.” The README tells a story. On 12 May 2025, a dis­claimer ap­peared fram­ing the pro­ject as an “Age Verification Solution Toolbox” that Member States are ex­pected to build on. On 31 July 2025, fur­ther soft­en­ing was added — lan­guage ex­plic­itly call­ing the app a white-la­bel ref­er­ence for coun­tries to adapt — and in the ex­act same edit, the ear­lier, blunter dis­claimer (which said this was an ini­tial ver­sion not in­tended for pro­duc­tion) was qui­etly re­moved. In any case, it was al­ways pre­sented as a tool­box that coun­tries should adapt into their apps — so judg­ing the app by it­self does not make much sense, it de­pends on how these tech­niques are im­ple­mented in each coun­try’s ver­i­fi­ca­tion app. There will be no sin­gle EU app, de­spite what the hon­chos of EU say.

The DSA fall­back no­body talks about

Big plat­forms must ver­ify age for cer­tain con­tent. They can use the fancy EU wal­let with its pri­vacy fea­tures. They can also just plug in a nor­mal KYC provider that scans your full pass­port, runs live­ness checks and sees every­thing. Which path do you think most com­pa­nies will ac­tu­ally take when the “privacy-preserving” op­tion re­quires in­te­grat­ing with sys­tems that barely ex­ist yet across 27 coun­tries?

It’s mar­ket­ing sleight of hand. They push the pri­vacy an­gle hard while the rules qui­etly al­low the non-pri­vate fall­back. The pri­vacy part is op­tional. (I think they mainly know the apps will not be ready by the end of the year).

KYC com­pa­nies have been avoid­ing real elec­tronic IDs for years. I have a Slovak eID chip that’s been in my wal­let for­ever. It has proper cryp­to­graphic keys and can prove who I am far more cleanly than a photo of my dri­ver’s li­cense plus video call. Yet al­most every KYC provider still does the bitmap and live­ness rou­tine. The rea­son is sim­ple. Integrating with 27 dif­fer­ent na­tional eID sys­tems is a night­mare. Maintaining a data­base of what every coun­try’s phys­i­cal ID looks like is cheaper and works every­where. The cryp­to­graphic route does­n’t — in prac­tice, not in the­ory.

So the EU so­lu­tion only “works” if plat­forms de­cide to do all that in­te­gra­tion work them­selves. Right now the of­fi­cial trusted list has zero pro­duc­tion apps. The ref­er­ence im­ple­men­ta­tion is still half-baked. Believing this turns into clean in­ter­op­er­abil­ity across all EU coun­tries by the end of 2026 is wish­ful think­ing.

How ver­i­fi­ca­tion ac­tu­ally works

The main high-as­sur­ance path in the ref­er­ence app uses an NFC pass­port. You scan the MRZ code at the bot­tom of the photo page; it gives the keys to read and de­crypt the data on the NFC chip. That chip con­tains signed data in­clud­ing a JPEG photo of the holder. The de­sign calls for a live photo to be taken and matched lo­cally against the chip’s JPEG — this is in­tended to stop a kid scan­ning a par­en­t’s pass­port to get a cre­den­tial for them­selves.

The app is open-source so you can read every line. But chang­ing even one bit would break the hard­ware at­tes­ta­tion once at­tes­ta­tion is ac­tu­ally en­forced by na­tional de­ploy­ments. In the cur­rent ref­er­ence code, at­tes­ta­tion ver­i­fi­ca­tion is not wired up on the server side — it is a promise na­tional de­ploy­ments would need to add. The bi­nary must ul­ti­mately match ex­actly what Google or Apple signed. No GrapheneOS, no cus­tom Linux phones.

Attestation locks it down. It is the same EU that hates these American cor­po­ra­tions and wants EU al­ter­na­tives for every­thing — yet no one can make a phone us­able for age ver­i­fi­ca­tion with­out the bless­ing of Google (or Apple, who does not cer­tify third-party de­vices for iOS at all). Bought a Huawei phone that does not pass Play Integrity? Sorry. Note: Huawei phones can pro­duce hard­ware at­tes­ta­tion via their fac­tory key chain, but they can­not pass Google’s Play Integrity ver­dict — the same ap­plies to GrapheneOS, Linux phones, and any­thing out­side the Google bless­ing. Use a Daylight com­puter that does­n’t wreck your cir­ca­dian rhythm? Back to the of­fice.

There is a sim­pler MRZ-only path in the ref­er­ence app where you pho­to­graph an ID card with no NFC read or face match. Real na­tional apps may not sup­port it, and the ref­er­ence rec­om­mends the high-as­sur­ance path. Countries will prob­a­bly force the chip-based route. It’s a tro­jan horse to dig­i­tal ID any­way.

The mar­keted crypto and the shipped crypto are not the same thing

The pub­lic story is built around zero-knowl­edge proofs. The ref­er­ence Android app does­n’t ac­tu­ally use zero-knowl­edge crypto in the flow that runs. It uses an older ISO stan­dard (ISO 18013 – 5 mdoc with ES256) where each at­tribute is signed in ad­vance and the wal­let re­veals only the ones asked for, hid­ing the rest us­ing salted-di­gest com­mit­ments. A ZK li­brary is pulled in, but noth­ing in the pre­sen­ta­tion path ever calls it. So when peo­ple cite “ZK age proofs” as the in­no­va­tion, they are cit­ing some­thing that is in the repo but is not switched on. Whether na­tional apps even­tu­ally turn it on is an open ques­tion. Today’s ref­er­ence is plain sig­na­tures.

The cryp­tog­ra­phy could be solid — zero-knowl­edge proofs over pass­port sig­na­tures are a real and tractable thing. But the crypto ac­tu­ally ship­ping in the cur­rent ref­er­ence is the older plain-sig­na­ture for­mat with dis­pos­able-batch un­link­a­bil­ity, not ZK. So when peo­ple de­fend “the math works,” they are de­fend­ing math that is not turned on. Although if you use each signed at­tes­ta­tion only once, it only re­veals that you are over 18 and maybe from the sig­na­ture who is­sued the at­tes­ta­tion. There’s no unique iden­ti­fier.

What’s pri­vate and what is­n’t

The over­all flow is lo­cal-first, but still needs a server to is­sue cre­den­tials. Scanning and ini­tial checks hap­pen on the phone. Because the app is (or would be) at­tested, the is­su­ing server can be rea­son­ably con­fi­dent what ex­act code ac­tu­ally ex­e­cuted. The server ver­i­fies the doc­u­ment sig­na­tures and is­sues a signed cre­den­tial. That cre­den­tial can then be used to pro­duce a proof of age when talk­ing to web­sites.

From the ver­i­fier’s (say, a porn site or so­cial me­dia plat­form) point of view it looks un­link­able — as long as the wal­let be­haves. The de­sign is not “the math guar­an­tees two proofs can’t be cor­re­lated.” The de­sign is “the wal­let hands out a pile of dis­pos­able cre­den­tials, uses each one once, then asks for more.” If the wal­let obeys that rule, two ver­i­fiers see two dif­fer­ent sig­na­tures and can’t tie them to­gether. If the wal­let cheats, or if a proof is re­played, the two ver­i­fiers see the same sig­na­ture bytes, and the link­age is triv­ial. This is an im­por­tant nu­ance — the usual “ZK = math = un­link­able for­ever” pitch does­n’t ap­ply here. The prop­erty holds be­cause the wal­let is sup­posed to ro­tate cre­den­tials, not be­cause the cryp­tog­ra­phy makes reuse im­pos­si­ble. Real cryp­to­graphic un­link­a­bil­ity schemes like BBS+ or CL sig­na­tures would pro­duce un­cor­re­lated proofs even on reuse. This is not that.

From the is­suer’s point of view — they is­sue cre­den­tials when you pre­sent your ID. The is­suer does­n’t know what you’ll use the cre­den­tial for, or how many times you’ll use it — the one-use rule lives in­side the wal­let, not on the server. So if the wal­let is mod­i­fied, or if proofs are cap­tured and re­played, no­body up­stream sees it. Any “rate limit” you might imag­ine is a limit on how many cre­den­tials you mint, not on how many times a cre­den­tial is used in the wild.

They can of course in­fer that you are an EU coun­try cit­i­zen. But they can’t (under nor­mal wal­let be­hav­ior) tell which ac­counts are yours or link your ac­tiv­ity across sites.

What about re­lay at­tacks?

Here’s a sce­nario the spec does­n’t re­ally an­swer. Suppose a child wants to get into an age-gated site. A ser­vice pops up — call it Grandma-as-a-Service — that of­fers to ver­ify on their be­half for a few eu­ros. The child opens the site, gets a QR code or a link, and in­stead of scan­ning it them­selves they paste it into the proxy ser­vice. The proxy for­wards it to a real adult some­where with a real, gov­ern­ment-is­sued wal­let on a clean phone. The adult ap­proves. The adult’s wal­let pro­duces a cryp­to­graph­i­cally per­fect “over 18” proof. The site sees a valid proof and lets the child in.

Nothing failed. Every sig­na­ture is real, every at­tes­ta­tion is real, the adult re­ally is over 18, the wal­let re­ally is run­ning un­mod­i­fied on a gen­uine Android. The catch is that the pro­to­col binds the proof to “some wal­let some­where said yes,” not to “the hu­man at this browser right now.” There is no prox­im­ity check. The browser-side Digital Credentials API par­tially closes this — but only when the user ver­i­fies on the same phone they’re brows­ing from. QR codes and deep links, which work across de­vices, are wide open.

People as­sume Google’s Play Integrity would stop this. It does­n’t. Play Integrity at­tests what code is run­ning on what de­vice. It says noth­ing about who is in front of it or where the de­vice is. In the proxy flow, the adult’s phone is a real phone and every at­tes­ta­tion is real. The re­lay — the web ser­vice the child talks to — is­n’t be­ing at­tested; it’s just mov­ing bytes.

And once an adult is en­rolled, the re­sale ver­sion gets ugly. The wal­let has thirty dis­pos­able cre­den­tials, re­freshed on a short in­ter­val. The is­suer never sees how those get used. So the proxy op­er­a­tor can reuse each cre­den­tial across many chil­dren; noth­ing up­stream raises an alarm. The “one-time use” rule is an honor-sys­tem rule in­side the wal­let soft­ware, not some­thing the is­suer can en­force af­ter the fact. This is not a bug that pro­duc­tion apps will “fix.” It’s in­her­ited from the shape of the pro­to­col, so it will be pre­sent in all 27 na­tional apps.

In any case, this is the tro­jan horse. Start with “protect the chil­dren from porn and scary so­cial me­dia.” Create enough fric­tion that peo­ple reach for the con­ve­nient at­tested wal­let. The app it­self must be at­tested — which in prac­tice means Google or Apple de­cide what runs. The cre­den­tial can be killed by the is­suer.

The ref­er­ence app leaks face pho­tos, al­though only lo­cally. Twenty-seven coun­tries will each build their own ver­sion. With their own pri­vacy bugs.

Then you get the Hawthorne ef­fect. Every con­tro­ver­sial site that makes you pull out the wal­let cre­ates self-cen­sor­ship, even if the proof is sup­pos­edly anony­mous. Governments have a ter­ri­ble track record pro­tect­ing this data. Any data. History is full of ex­am­ples.

(Want to watch porn? Criticize a politi­cian? Are you re­ally go­ing to open the EU coun­try’s ID app to ver­ify that you are over 18 and be­lieve it’s un­link­able ZK proof — even if it re­ally is?)

Later they link it to Digital Euro and every­thing else. Suddenly a big chunk of your life can be switched off re­motely. Didn’t pay a park­ing ticket on time? Let’s tem­porar­ily re­voke your cre­den­tials — when you can’t log in any­where, you will come and pay the ticket.

The ar­chi­tec­ture and pol­i­tics are the usual con­trol layer with fresher paint. We don’t need re­vo­ca­ble dig­i­tal IDs as the price of en­try to the in­ter­net. We were do­ing just fine.

Are the pub­lished hacks real?

It’s worth split­ting the re­ported prob­lems into two piles. Pile one: “bugs in the mock-up” — leaked files, unchecked MRZ scans, Chrome-extension demos hit­ting a place­holder back­end. These are fix­able and will be fixed per coun­try. Pile two: struc­tural prop­er­ties that fall out of the pro­to­col it­self — no prox­im­ity bind­ing, client-side one-time-use, un­link­a­bil­ity that breaks on reuse. These are not bugs. They’ll be pre­sent in every na­tional im­ple­men­ta­tion that fol­lows the spec. When com­men­ta­tors wave away “the hacks,” they usu­ally mean pile one. Pile two is what this post is ac­tu­ally about.

There have been sev­eral “hacks,” mostly by peo­ple who don’t un­der­stand how this is sup­posed to work. Leaving files on disk in the ref­er­ence app is some­thing that will be fixed, and does not re­ally mat­ter. The ref­er­ence app will not be used by any coun­try di­rectly — they will have their own bugs. It’s for coun­tries to know how to gen­er­ate the proofs and stay in­ter­op­er­a­ble. It does­n’t even mat­ter that you can fool it into giv­ing you a test cre­den­tial, be­cause the pri­mary ver­i­fi­ca­tion path will be coun­tries’ own eID sys­tems, not their mock-up of unchecked MRZ scan­ner.

There was a “hack” that cre­ated a cus­tom Chrome ex­ten­sion. That would fail app at­tes­ta­tion once at­tes­ta­tion is en­forced. The MRZ path also does not con­nect to a real back­end, be­cause there’s no real EU-side back­end — the reg­istries of valid doc­u­ments are the com­pe­tence of in­di­vid­ual coun­tries.

I’m 99% sure that even though I con­sider EU com­pletely in­com­pe­tent, these par­tic­u­lar mock-up hacks won’t work in pro­duc­tion apps. So this “haha, I hacked the app with my Claude Max sub­scrip­tion” does­n’t mean any­thing. They’re hack­ing a mock-up show­ing the use of a li­brary. Yes, Frau Ursula called it “EU Age Verification app,” but there will not be an EU app — there will be a Slovak app, a Hungarian app, a German app, a Dutch app, a French app…

But Why?

Many of us nat­u­rally ask why peo­ple want this. I think it’s a mis­take to think they don’t. There is de­mand for this. The in­ter­net is scary, par­ents think they can’t pro­tect their chil­dren from many bad things hap­pen­ing, and some­one came to pro­vide a “solution.” Doesn’t mat­ter that I am sure the kids will go around it eas­ily. The clients (the vot­ers) are not the chil­dren be­ing pro­tected, but their par­ents, feel­ing good.

I think a very good and deep ex­pla­na­tion is in my novel Tamers of Entropy. Have a look. It is very cypher­punk/​lu­narpunk and ex­plains also the psy­chol­ogy be­hind these dystopias — and a way out­side. Plus it’s fun to read. Check it out at tamer­sofen­tropy.net. The char­ac­ters also have Nostr ac­counts.

Conclusion

The EU fancy ZK apps will not be ready. Platforms will use nor­mal KYC providers, AI face age es­ti­ma­tors and other means.

When done ac­cord­ing to spec, the age ver­i­fi­ca­tion app has mean­ing­ful pri­vacy prop­er­ties — the plat­forms don’t know your iden­tity or link your ac­counts. But those prop­er­ties rest on wal­let be­hav­ior, not cryp­to­graphic guar­an­tees. The ZK math that would make un­link­a­bil­ity a hard guar­an­tee is in the repo and not switched on.

The apps will not work un­less you have a Google or Apple ap­proved de­vice. Forget Linux, GrapheneOS, Huawei, af­ter-mar­ket firmwares. It’s part of the se­cu­rity model.

And re­lay at­tacks — chil­dren us­ing adult prox­ies to get into age-gated sites — are not fix­able bugs. They are a struc­tural prop­erty of the pro­to­col that will ship in all 27 na­tional apps.

The pri­vacy the­ater hides the wolf. The wolf is still there.

As the global pop­u­la­tion of pho­tog­ra­phers swells, so do their dig­i­tal li­braries, leav­ing every­one with the same ques­tion: where and how to share their best work. Flickr was among the first on­line com­mu­ni­ties de­signed to ad­dress that dilemma, and it re­mains one of the best. Some de­mand sweep­ing over­hauls or ar­gue the price is­n’t jus­ti­fied.

However, Flickr’s re­fusal to chase fleet­ing trends—opt­ing in­stead for it­er­a­tive im­prove­ments—is ac­tu­ally one of its great­est strengths. And while its an­nual Pro sub­scrip­tion is on the pricier side, ul­ti­mately, the ben­e­fits con­tinue to out­weigh the costs.

Editor’s Note: This ar­ti­cle was writ­ten largely as a re­but­tal to Matt Payne’s January 2026 ar­ti­cle, Empty Promises: A Deep Dive into Flickr Pro for 2026. It is worth fa­mil­iar­iz­ing your­self with that per­spec­tive be­fore div­ing into Mr. Weinstein’s re­sponse be­low.

A Brief History

Launched in 2004 with an icon­i­cally miss­ing vowel, Flickr pi­o­neered the Web 2.0 era of so­cial photo shar­ing be­fore en­dur­ing a decade of mi­nor and cos­metic changes amid cor­po­rate sta­sis un­der Yahoo.

After years of ne­glect, SmugMug ac­quired the plat­form in 2018. Don MacAskill, SmugMug’s CEO, said “[w]e’ll work very hard to not ruin Flickr. After suc­cess­fully not ru­in­ing it, we’ll work even hard[er] to make it bet­ter than its al­ready awe­some self,” and “Flickr’s com­mu­nity is unique in the world and on the Internet. That’s where we’d like to in­vest.” So, what are the re­sults of those in­vest­ments, and is Flickr Pro still worth it?

Flickr in 2026

The Social Core

In stark con­trast to the ma­jor­ity of photo-fo­cused ser­vices, Flickr re­mains pri­mar­ily a sim­ple photo-shar­ing web­site where one can find friends and view their work in a clean, chrono­log­i­cal stream. While the plat­form sup­ports video, the fea­ture feels like a quiet af­ter­thought—a log­i­cal choice for a site built by and for pho­tog­ra­phy en­thu­si­asts. There is sim­ply no chance that Flickr will sud­denly pivot to video to chase short-form trends.

Groups & Discovery

The heart of the Flickr com­mu­nity lies in its Groups, many of which cater to highly spe­cific niches that you won’t find else­where. These range from tech­ni­cal com­mu­ni­ties fo­cused on spe­cific lenses, cam­era bod­ies, or brands, to aes­thetic en­claves for ana­log purists, black-and-white en­thu­si­asts, and quirkier cor­ners like Stick Figures in Peril.

Metadata & Organization

The plat­for­m’s util­ity is bol­stered by its ro­bust han­dling of tags and ge­o­t­ag­ging, al­low­ing for a level of search­a­bil­ity that mod­ern so­cial me­dia of­ten lacks. Users can man­age their li­braries through Sets, Galleries, and Albums, mak­ing it easy to or­ga­nize thou­sands of im­ages by sub­ject mat­ter, lo­ca­tion, per­son, or era. Flickr pre­serves and dis­plays com­pre­hen­sive EXIF data, in­clud­ing de­tailed cam­era and lens in­for­ma­tion for every shot.

Integration & Syndication

Flickr also re­tains its early web roots: every user has an RSS feed, and the site main­tains open APIs and makes it sim­ple to cre­ate em­beds for other web­sites—a lin­ger­ing re­minder of the flex­i­ble fea­tures that made early Flickr such a vi­tal tool for blog­gers and cu­ra­tors.

Explore

Of course, there’s also Explore, Flickr’s way of high­light­ing 500 pho­tos each day. When a photo is se­lected for Explore—driven by an in­scrutable, of­ten mer­cu­r­ial al­go­rithm—it typ­i­cally re­ceives thou­sands of views and a surge of en­gage­ment.

Pro Benefits

In 2026, the leap from a free ac­count to Flickr Pro pri­mar­ily al­lows a user to pre­sent a long-term or large body of work pub­licly. The most im­me­di­ate ben­e­fit is the re­moval of the 1,000-photo cap (which also lim­its free users to a mere 50 non-pub­lic pho­tos), re­placed by un­lim­ited, full-res­o­lu­tion JPEG stor­age. For those who use Flickr as a port­fo­lio, the Pro sta­tus also en­sures an ad-free ex­pe­ri­ence—not just for the pho­tog­ra­pher, but for any­one vis­it­ing their pho­to­stream, en­sur­ing the work re­mains the sole fo­cus with­out the dis­trac­tion of third-party ban­ners.

Pro users also gain ac­cess to Advanced Stats, pro­vid­ing gran­u­lar data on the sources of views and traf­fic, in­clud­ing which spe­cific groups or tags are dri­ving traf­fic. Pro mem­bers get a suite of part­ner perks, in­clud­ing sav­ings on Adobe Creative Cloud, Blurb photo books, Phlearn mem­ber­ships, and SmugMug plans, and a sig­nif­i­cant 5% off gear at KEH. Additionally, Pro mem­bers gain ac­cess to ex­clu­sive sav­ings on a wide range of classes and ed­u­ca­tion. These are, at best, fringe ben­e­fits, but a user who spends a bit un­der $2,000 at KEH in a year will have es­sen­tially jus­ti­fied the en­tire cost of the Pro mem­ber­ship through the dis­count.

Why Flickr is Still Great in 2026

There are cer­tainly cheaper ways in 2026 to host an ad-free, pub­lic port­fo­lio on the open web. Yet, few to none meet those cri­te­ria while si­mul­ta­ne­ously of­fer­ing an ac­tive, built-in com­mu­nity of ded­i­cated pho­tog­ra­phy en­thu­si­asts seek­ing out high qual­ity pho­tog­ra­phy. I sus­pect that’s the value propo­si­tion that keeps many Flickr users pay­ing for Pro in 2026, my­self in­cluded.

Other op­tions are bet­ter po­si­tioned to pre­sent a pro­fes­sional pho­tog­ra­pher’s work to the world ex­actly as they want it seen. But Flickr Pro should­n’t be con­fused with “Flickr for pro­fes­sion­als,” just like the iPhone Pro is­n’t in­tended for “professional smart­phone users.” Most Flickr users are se­ri­ous—or not-so-se­ri­ous—hob­by­ists.

But more gen­er­ally, Flickr is great pre­cisely be­cause it is­n’t try­ing to be­come the next Instagram, TikTok, crypto play, meta­verse ex­per­i­ment, or AI train­ing ground. While it’s al­ways nice to have ex­po­sure on Flickr, the plat­form is largely de­void of the “influencers” who dom­i­nate other net­works. In an era of al­go­rithm-dri­ven con­tent, Flickr re­mains a sanc­tu­ary for pho­tog­ra­phy en­thu­si­asts who are gen­uinely ex­cited to see what their peers are up to. The com­mu­nity re­mains very ac­tive; while you’ll en­counter the oc­ca­sional ro­botic “Great shot!” com­ment, the plat­form still fos­ters en­gaged dis­cus­sion, hon­est feed­back, and shared tips that are hard to find on more trans­ac­tional so­cial net­works. If it feels like a ghost town, con­sider join­ing new groups and in­ter­act­ing with new users whose work you en­joy and might learn from.

The ro­bust tag­ging and ge­o­t­ag­ging sys­tems make Flickr an un­der­ap­pre­ci­ated plat­form for lo­ca­tion scout­ing. Before head­ing to a new area, a user can search within the area or for spe­cific land­marks to see how a lo­ca­tion looks at dif­fer­ent times of day, in vary­ing weather con­di­tions, or across dif­fer­ent sea­sons. Furthermore, the full EXIF data dis­play makes Flickr a great place to learn. There is no bet­ter place to see what a dif­fer­ent lens or cam­era body can pro­duce in the hands of real pho­tog­ra­phers.

One of Flickr’s most un­der­rated power fea­tures is the Organize tool. It pro­vides a high-level view of your en­tire li­brary, al­low­ing you to batch-edit ti­tles, tags, and per­mis­sions with a sim­ple drag-and-drop in­ter­face, en­sur­ing every photo has the ex­act at­trib­utes you want it to. Flickr of­fers ro­bust fea­tures to limit who sees your work, al­low­ing you to hide spe­cific pho­tos from pub­lic searches while still shar­ing them with a se­lect cir­cle via pri­vate links. And it’s easy to change the li­cense as­so­ci­ated with pho­tos in bulk, for in­stance to as­sign a Creative Commons li­cense so oth­ers can share or reuse your work if you so choose.

To sup­port the sense of com­mu­nity, Flickr reg­u­larly hosts free pho­tog­ra­phy com­pe­ti­tions that cel­e­brate its mem­bers’ tal­ent, in­clud­ing the an­nual Your Best Shot con­test and themed events like the World Photography Day Contest. Flickr of­ten hands out prizes, big and small, in con­junc­tion with pop­u­lar photo-re­lated brands. And pho­tos en­tered into con­tests of­ten get a boost in in­ter­ac­tion from other par­tic­i­pants—a nice con­so­la­tion prize.

Flickr sup­ports its com­mu­nity in the real world too. The site fa­cil­i­tates photo walks, spon­sors Photoville in New York City, and main­tains a pres­ence at ma­jor pho­tog­ra­phy gath­er­ings. These events are ex­cel­lent op­por­tu­ni­ties to meet like-minded pho­tog­ra­phers, swap sto­ries about gear, and dis­cover new sub­jects to shoot. I’ve per­son­ally met avid Flickr users in places like New York City, Atlanta, and London; it’s a true global net­work. While it’s a rarely used fea­ture, if a photo up­loaded to the site con­tains an­other Flickr mem­ber, you can tag that user di­rectly, mak­ing it easy to keep track of friends and col­lab­o­ra­tors from real-world pho­towalks.

The site is also heav­ily pro­mot­ing MODE by Flickr, a three-day pho­tog­ra­phy fes­ti­val tak­ing place in Minneapolis from September 18 – 20, 2026. Billed as a “photographer’s play­ground,” MODE is de­signed to bring the com­mu­nity away from their de­vices and into the phys­i­cal world through work­shops, dark­room ses­sions, and city-wide pho­towalks. At a min­i­mum of $330 for ad­mis­sion, plus air­fare to and lodg­ing in Minnesota, MODE may prove to be a one-time ex­per­i­ment, but it’s a gen­uine ef­fort to in­vig­o­rate the com­mu­nity, which is wor­thy of praise.

And while Explore is and has been al­go­rith­mi­cally cu­rated for years, the site is gen­er­ally free of ar­ti­fi­cial in­tel­li­gence, both with re­spect to the con­tent users up­load and use­less fea­tures shoe­horned into the ser­vice. Flickr’s Terms make clear that users own the copy­right to their pho­tos:

You re­tain all in­tel­lec­tual prop­erty rights in and to any User Content you post, up­load or oth­er­wise make avail­able through the Services, in­clud­ing the copy­right in and to your pho­tos and videos. SmugMug does not claim any own­er­ship, right, ti­tle or in­ter­est in and to your User Content.

You re­tain all in­tel­lec­tual prop­erty rights in and to any User Content you post, up­load or oth­er­wise make avail­able through the Services, in­clud­ing the copy­right in and to your pho­tos and videos. SmugMug does not claim any own­er­ship, right, ti­tle or in­ter­est in and to your User Content.

While users grant SmugMug the right to re­pro­duce users’ im­ages to pro­vide the ser­vice there’s lit­tle risk—at least un­der the cur­rent Terms—that Flickr will turn into an AI-focused plat­form, min­ing its users’ pho­tos. Of course, third par­ties may take a dif­fer­ent view and scrape the full Flickr cor­pus, but there’s only so much Flickr, like vir­tu­ally every web­site op­er­a­tor, can do with re­spect to that sce­nario.

While Flickr has dab­bled in al­low­ing users to li­cense pho­tos, com­merce has never been the core el­e­ment of the ser­vice. Today, rather than act­ing as a mid­dle­man for stock sales, as do many of its com­peti­tors, Flickr fo­cuses on pro­vid­ing the in­fra­struc­ture for pho­tog­ra­phers to man­age their own des­tinies. Ultimately, Flickr’s great­est strength in 2026 is its re­fusal to pivot or sell out.

It’s Not Perfect

Tech Issues

While Flickr has an im­pres­sive list of at­trib­utes, it is far from flaw­less. When SmugMug ac­quired the ser­vice and mi­grated its mas­sive li­brary to Amazon Web Services (AWS), the plat­form en­tered a pe­riod of rel­a­tive in­sta­bil­ity. Even in 2026, users oc­ca­sion­ally en­counter the dreaded “bad panda”—Flick­r’s in­ter­nal par­lance for a site er­ror or out­age—and in­ter­mit­tent slow-load­ing pages re­main an un­for­tu­nate re­al­ity of the brows­ing ex­pe­ri­ence. A fully func­tional plat­form is table stakes, es­pe­cially for the price Pro users pay.

Stagnant Community Hubs

Flickr Groups used to fea­ture ro­bust con­ver­sa­tions, but much of that en­ergy has mi­grated to plat­forms like Reddit or Facebook. While many groups re­main ac­tive—specif­i­cally those cen­tered around lo­cal pho­tog­ra­phy clubs, spe­cific so­cial or­ga­ni­za­tions, and re­gional events—the broader “global” dis­cus­sion feels qui­eter than it once was. Similarly, the in­ter­nal FlickrMail mes­sag­ing sys­tem has not seen a sig­nif­i­cant up­date in years; it lacks con­ve­niences like multi-per­son threads or the abil­ity to eas­ily em­bed pho­tos and map lo­ca­tions di­rectly into a chat. The SmugMug man­age­ment promised im­prove­ments to the com­mu­nity as­pects of Flickr, and more is needed—be­yond a pricey, ex­per­i­men­tal fes­ti­val in Minnesota—before they can de­clare suc­cess on this front.

Rusty Features

Some of the site’s most beloved legacy fea­tures are be­gin­ning to show their age. The Camera Finder, for ex­am­ple, is still a use­ful re­source for see­ing trend­ing gear, but it lacks gran­u­lar data or the abil­ity to fil­ter in any use­ful way.It used to be pos­si­ble to fil­ter pho­tos taken by a spe­cific cam­era by genre (e.g., land­scape, sports). Restoring this fea­ture—and build­ing out ro­bust search­a­bil­ity by cam­era body, lens, and ex­act set­tings—would be a mas­sive win for the com­mu­nity.

The World Map could also use at­ten­tion. While ge­o­t­ags are a fan­tas­tic re­source, the World Map cur­rently lacks the fil­ter­ing and search­a­bil­ity that would make it a much more pow­er­ful and use­ful way to find pho­tos with cer­tain key­words at a spe­cific place at a spe­cific time.

The “Interestingness” Algorithm

The “Interestingness” al­go­rithm—which pow­ers the Explore page—can be enig­matic. While tastes vary, vir­tu­ally every­one can agree that the al­go­rithm some­times re­wards ob­jec­tively mun­dane pho­tos as more “interesting” than more cap­ti­vat­ing work. I sus­pect that the al­go­rithm is tuned to re­ward cer­tain user be­hav­iors that Flickr con­sid­ers de­sir­able at the ex­pense of show­cas­ing truly “interesting” pho­tos. While some users have long since learned to game the sys­tem, com­plain­ing about Explore is an old cliché—and it ul­ti­mately rep­re­sents only a frac­tion of the plat­for­m’s value. Nonetheless, im­prove­ments would be wel­come.

Beyond JPEG

Flickr al­lows Pro users to show­case their work at full res­o­lu­tion, but as of 2026, JPEG is over 30 years old, and cam­era and dis­play hard­ware has sur­passed its lim­i­ta­tions. While Flickr does­n’t overly com­press pho­tos and does sup­port mod­ern color pro­files—al­low­ing the ser­vice to take ad­van­tage of wide gamuts like Display P3 used by high-end smart­phones and mon­i­tors—it still lacks na­tive sup­port for next-gen­er­a­tion for­mats like JPEG XL, HEIC, or AVIF. These for­mats are in­creas­ingly sup­ported and com­mon­place, of­fer bet­ter com­pres­sion and greater bit depths, and adding them would sig­nif­i­cantly mod­ern­ize the plat­for­m’s tech­ni­cal foun­da­tion.

The Cost of Independence

There is an old adage in tech: “If you’re not pay­ing for the prod­uct, you are the prod­uct.” Through that lens, Flickr Pro users are de­fin­i­tively not the prod­uct. Currently, Flickr Pro costs $82 when billed once per year, which is a sig­nif­i­cant jump from its early days. To put that in per­spec­tive, 500px is $59.94 per year, and Glass, a re­cent en­trant in the field some­times con­sid­ered Flickr’s clos­est com­peti­tor, costs roughly $40 per year. On the other hand, they lack the full fea­ture set de­scribed above, and they don’t of­fer their Pro-level users an ad-free gallery space open to the pub­lic that does­n’t gen­er­ate its profit by pro­fil­ing its users for ad­ver­tis­ers.

A 100-Year Vision

Hosting petabytes of high-res­o­lu­tion data is an ex­pen­sive en­deavor—Ya­hoo should have never of­fered ter­abytes of stor­age for free. MacAskill ad­dressed this bal­ance di­rectly when speak­ing to the com­mu­nity about two years ago:

“Flickr is the health­i­est it’s ever been. More ac­tive users, more en­gage­ment, more con­nec­tions, more rev­enue, more of every­thing — ex­cept peo­ple treat­ing it like a photo dump’. Most im­por­tantly, our mem­bers are ec­sta­tic about it, it’s now prof­itable and cash flow pos­i­tive, so not in im­mi­nent dan­ger (and we’re try­ing to build it, sus­tain­ably, for 100+ years). IMHO, it’s not nearly enough, yet, but the tra­jec­tory is awe­some. It’s work­ing. And it’s work­ing with­out in­vad­ing peo­ple’s pri­vacy, un­like nearly every other so­cial me­dia plat­form.”

“Flickr is the health­i­est it’s ever been. More ac­tive users, more en­gage­ment, more con­nec­tions, more rev­enue, more of every­thing — ex­cept peo­ple treat­ing it like a photo dump’. Most im­por­tantly, our mem­bers are ec­sta­tic about it, it’s now prof­itable and cash flow pos­i­tive, so not in im­mi­nent dan­ger (and we’re try­ing to build it, sus­tain­ably, for 100+ years). IMHO, it’s not nearly enough, yet, but the tra­jec­tory is awe­some. It’s work­ing. And it’s work­ing with­out in­vad­ing peo­ple’s pri­vacy, un­like nearly every other so­cial me­dia plat­form.”

He’s also been clear very re­cently that SmugMug is “not plan­ning on sell­ing Flickr.” Ultimately, while the site may feel rusty in a few places, its tra­jec­tory sug­gests a plat­form that is fi­nally sta­ble. For those who value pri­vacy, a long-term home for their work, and an ad-free port­fo­lio-like space, the Pro price tag is the cost of en­sur­ing Flickr sur­vives into the next decade and be­yond.

It’s not of­fi­cially a part of Flickr, but the closely af­fil­i­ated non-profit Flickr Foundation is work­ing on pro­jects like the Data Lifeboat, which aims to be a “user-friendly archiv­ing so­lu­tion to en­sure mem­o­ries on Flickr can be en­joyed by fu­ture gen­er­a­tions, in eas­ily brows­able pack­ages.”

If you’re look­ing for the next big thing, Flickr may not be for you. Flickr is great be­cause—in con­trast to vir­tu­ally all of its com­peti­tors—it of­fers the fea­tures pho­tog­ra­phy en­thu­si­asts care about while avoid­ing dis­trac­tions and min­i­mal mon­e­ti­za­tion of its Pro users via ad­ver­tis­ing. It’s a com­mu­nity with vir­tual and real-world events. It’s a place to post and seek out your fa­vorite pho­tos. It’s a place to be in­spired. Because it is­n’t (currently) be­holden to mas­sive share­holder de­mands, it has­n’t needed to “move fast and break things.” Instead, it has moved de­lib­er­ately, main­tain­ing and im­prov­ing the tools that mat­ter. I ex­pect to see more of that go­ing for­ward and will will­ingly pay the (admittedly high) fee nec­es­sary to keep this lit­tle slice of the early, more pure web alive—not for the sake of nos­tal­gia, but be­cause things ac­tu­ally were bet­ter back when the web con­nected real peo­ple, and plat­forms did­n’t as­pire to take over the world. In short, if it’s not bro­ken, why fix it?

About the au­thor: Brett Weinstein is an am­a­teur pho­tog­ra­pher and will mark 20 years of Flickr mem­ber­ship this year. His work is fea­tured in the Smithsonian National Museum of African American History and Culture, he was the Photography Editor at the Emory Wheel and the 2008 Southeast Journalism Conference Best Press Photographer, and his pho­tos have been listed with Getty and fea­tured in press and ad­ver­tis­ing. By day, he is a pri­vacy and con­sumer pro­tec­tion lawyer. The opin­ions ex­pressed above are solely those of the au­thor.

What is a stat­e­chart?

A stat­e­chart can be ex­plained in many ways, and we’ll get to those ex­pla­na­tions, but es­sen­tially, a stat­e­chart is a draw­ing. Here’s a sim­ple stat­e­chart:

However, this draw­ing is­n’t very use­ful for soft­ware en­gi­neers who want to reap the ben­e­fits out­lined else­where on this site, so let’s dive into some other ways of de­scrib­ing what a stat­e­chart is. The orig­i­nal pa­per that de­fines stat­e­charts bills them as “A vi­sual for­mal­ism for com­plex sys­tems” (Harel, 1987). With that out of the way, let’s try to ex­plain stat­e­charts.

Introduction to stat­e­charts

Put sim­ply, a stat­e­chart is a beefed up state ma­chine. The beef­ing up solves a lot of the prob­lems that state ma­chines have, es­pe­cially state ex­plo­sion that hap­pens as state ma­chines grow. One of the goals of this site is to help ex­plain what stat­e­charts are and how they are use­ful.

What is a state ma­chine?

What is a stat­e­chart?

Why should you use stat­e­charts?

Statecharts of­fer a sur­pris­ing ar­ray of ben­e­fits

It’s eas­ier to un­der­stand a stat­e­chart than many other forms of code.

The be­hav­iour is de­cou­pled from the com­po­nent in ques­tion.

This makes it eas­ier to make changes to the be­hav­iour.

It also makes it eas­ier to rea­son about the code.

And the be­hav­iour can be tested in­de­pen­dently of the com­po­nent.

This makes it eas­ier to make changes to the be­hav­iour.

It also makes it eas­ier to rea­son about the code.

And the be­hav­iour can be tested in­de­pen­dently of the com­po­nent.

The process of build­ing a stat­e­chart causes all the states to be ex­plored.

Studies have shown that stat­e­chart based code has lower bug counts than tra­di­tional code.

Statecharts lends it­self to deal­ing with ex­cep­tional sit­u­a­tions that might oth­er­wise be over­looked.

As com­plex­ity grows, stat­e­charts scale well.

A stat­e­chart is a great com­mu­ni­ca­tor: Non-developers can un­der­stand the stat­e­charts, while QA can use a stat­e­charts as an ex­ploratory tool.

It’s worth not­ing that you’re al­ready cod­ing state ma­chines, ex­cept that they’re hid­den in the code.

Why should you not use stat­e­charts?

There are a few down­sides to us­ing stat­e­charts that you should be aware of.

Programmers typ­i­cally need to learn some­thing new, al­though the un­der­pin­nings (state ma­chines) would be some­thing that most pro­gram­mers are fa­mil­iar with.

It’s usu­ally a very for­eign way of cod­ing, so teams might ex­pe­ri­ence push­back based on how very dif­fer­ent it is.

There is an over­head to ex­tract­ing the be­hav­iour in that the num­ber of lines of code might in­crease with smaller stat­e­charts.

Why are they not used?

People don’t know about them, and YAGNI.

What are the main ar­gu­ments against stat­e­charts?

There are a few com­mon ar­gu­ments against stat­e­charts in ad­di­tion to the ones listed above:

It’s sim­ply not needed.

It goes against the grain of [insert name of tech­nol­ogy].

It in­creases the num­ber of li­braries, for web ap­pli­ca­tions this means in­creased load time.

The ben­e­fits out­lined above should make it clear that the in­tro­duc­tion of stat­e­charts is gen­er­ally a net pos­i­tive.

How do you use stat­e­charts?

First of all, know that a W3C com­mit­tee spent 10+ years (2005 to 2015) stan­dard­iz­ing some­thing called SCXML (yes, Statechart XML), and that it de­fines a lot of the se­man­tics and spec­i­fies how to deal with cer­tain edge cases. There are tools to read, au­thor and even ex­e­cute stat­e­charts writ­ten in SCXML, in var­i­ous lan­guages. There are also some de­riv­a­tives that sup­port the same model as SCXML, but us­ing a dif­fer­ent syn­tax.

Additionally, there are stat­e­chart libaries for a va­ri­ety of plat­forms, that in vary­ing de­grees sup­port the se­man­tics de­scribed by SCXML. You should con­sider us­ing these li­braries just to get those edge cases taken care of. The li­braries gen­er­ally per­form en­try and exit ac­tions in the right or­der and so on.

With that out of the way, read on!

Executable stat­e­charts

In ad­di­tion to just us­ing stat­e­charts to model the be­hav­iour in doc­u­ments sep­a­rate from the ac­tual run­ning code, it’s pos­si­ble to use one of var­i­ous ma­chine for­mats, both to de­sign the be­hav­iour, and at run-time to ac­tu­ally be the be­hav­iour. The idea is to have a sin­gle source of truth that de­scribes the be­hav­iour of a com­po­nent, and that this sin­gle source dri­ves both the ac­tual run-time code, but that it can also be used to gen­er­ate a pre­cise di­a­gram that vi­su­alises the stat­e­chart.

This car­ries along some dif­fer­ent pros and cons:

Why should you use ex­e­cutable stat­e­charts?

No need to trans­late di­a­grams into code

No bugs in­tro­duced by hand trans­la­tion of di­a­grams

The di­a­grams are al­ways in sync

The di­a­grams are more pre­cise

Why should you not use ex­e­cutable stat­e­charts?

The di­a­grams may be­come quite com­plex

The for­mat and tools for ex­e­cutable stat­e­charts is lim­ited

Type safety be­tween stat­e­chart and the com­po­nent is hard to en­force

How do you use ex­e­cutable stat­e­charts?

In essence, if you have any de­f­i­n­i­tion of a stat­e­chart in your code, all you need to do is to take that rep­re­sen­ta­tion and au­to­mate the gen­er­a­tion of the vi­sual stat­e­chart. This is of course sim­pler when the de­f­i­n­i­tion is in a sep­a­rate file, e.g. in a JSON or XML file.

This is all ex­plained on the page on how to use stat­e­charts!

If you feel like chat­ting to some­one about stat­e­charts, you can go to git­ter.im (no lo­gin re­quired to see the chat), where you’ll find a com­mu­nity of like minded de­vel­op­ers that can help you un­der­stand and reap the ben­e­fits of us­ing Statecharts. For a more Q&A-type site, head on over to the stat­e­charts GitHub dis­cus­sions, where we’ll do your best to an­swer your ques­tion.

Quite a few peo­ple have writ­ten books or held pre­sen­ta­tions that deal with stat­e­charts in var­i­ous ways, and they’re in­cluded in our re­sources page. If you’ve writ­ten some­thing, please share it by post­ing it to GitHub Discussions.

There are some pages that haven’t found any place in the web of doc­u­ments, so they’re ho­n­ourably men­tioned here:

Use case: Statecharts in User Interfaces

Concepts — The most im­por­tant con­cepts in a stat­e­chart and what they look like in a di­a­gram.

Glossary — A list of terms that get thrown around when talk­ing about stat­e­charts, with their de­f­i­n­i­tions.

FizzBuzz — FizzBuzz is a well known prob­lem, and it’s been used as a back­drop to ex­plain var­i­ous stat­e­chart con­cepts.

Acknowledgements