September 2024

At a YC event last week Brian Chesky gave a talk that every­one who

was there will re­mem­ber. Most founders I talked to af­ter­ward said

it was the best they’d ever heard. Ron Conway, for the first time

in his life, for­got to take notes. I’m not go­ing to try to re­pro­duce

it here. Instead I want to talk about a ques­tion it raised.

The theme of Brian’s talk was that the con­ven­tional wis­dom about

how to run larger com­pa­nies is mis­taken. As Airbnb grew, well-mean­ing

peo­ple ad­vised him that he had to run the com­pany in a cer­tain way

for it to scale. Their ad­vice could be op­ti­misti­cally sum­ma­rized

as “hire good peo­ple and give them room to do their jobs.” He

fol­lowed this ad­vice and the re­sults were dis­as­trous. So he had to

fig­ure out a bet­ter way on his own, which he did partly by study­ing

how Steve Jobs ran Apple. So far it seems to be work­ing. Airbnb’s

free cash flow mar­gin is now among the best in Silicon Valley.

The au­di­ence at this event in­cluded a lot of the most suc­cess­ful

founders we’ve funded, and one af­ter an­other said that the same

thing had hap­pened to them. They’d been given the same ad­vice about

how to run their com­pa­nies as they grew, but in­stead of help­ing

their com­pa­nies, it had dam­aged them.

Why was every­one telling these founders the wrong thing? That was

the big mys­tery to me. And af­ter mulling it over for a bit I fig­ured

out the an­swer: what they were be­ing told was how to run a com­pany

you had­n’t founded — how to run a com­pany if you’re merely a

pro­fes­sional man­ager. But this m.o. is so much less ef­fec­tive that

to founders it feels bro­ken. There are things founders can do that

man­agers can’t, and not do­ing them feels wrong to founders, be­cause

it is.

In ef­fect there are two dif­fer­ent ways to run a com­pany: founder

mode and man­ager mode. Till now most peo­ple even in Silicon Valley

have im­plic­itly as­sumed that scal­ing a startup meant switch­ing to

man­ager mode. But we can in­fer the ex­is­tence of an­other mode from

the dis­may of founders who’ve tried it, and the suc­cess of their

at­tempts to es­cape from it.

There are as far as I know no books specif­i­cally about founder mode.

Business schools don’t know it ex­ists. All we have so far are the

ex­per­i­ments of in­di­vid­ual founders who’ve been fig­ur­ing it out for

them­selves. But now that we know what we’re look­ing for, we can

search for it. I hope in a few years founder mode will be as well

un­der­stood as man­ager mode. We can al­ready guess at some of the

ways it will dif­fer.

The way man­agers are taught to run com­pa­nies seems to be like mod­u­lar

de­sign in the sense that you treat sub­trees of the org chart as

black boxes. You tell your di­rect re­ports what to do, and it’s up

to them to fig­ure out how. But you don’t get in­volved in the de­tails

of what they do. That would be mi­cro­manag­ing them, which is bad.

Hire good peo­ple and give them room to do their jobs. Sounds great

when it’s de­scribed that way, does­n’t it? Except in prac­tice, judg­ing

from the re­port of founder af­ter founder, what this of­ten turns out

to mean is: hire pro­fes­sional fak­ers and let them drive the com­pany

into the ground.

One theme I no­ticed both in Brian’s talk and when talk­ing to founders

af­ter­ward was the idea of be­ing gaslit. Founders feel like they’re

be­ing gaslit from both sides — by the peo­ple telling them they

have to run their com­pa­nies like man­agers, and by the peo­ple work­ing

for them when they do. Usually when every­one around you dis­agrees

with you, your de­fault as­sump­tion should be that you’re mis­taken.

But this is one of the rare ex­cep­tions. VCs who haven’t been founders

them­selves don’t know how founders should run com­pa­nies, and C-level

ex­ecs, as a class, in­clude some of the most skill­ful liars in the

world.

Whatever founder mode con­sists of, it’s pretty clear that it’s go­ing

to break the prin­ci­ple that the CEO should en­gage with the com­pany

only via his or her di­rect re­ports. “Skip-level” meet­ings will

be­come the norm in­stead of a prac­tice so un­usual that there’s a

name for it. And once you aban­don that con­straint there are a huge

num­ber of per­mu­ta­tions to choose from.

For ex­am­ple, Steve Jobs used to run an an­nual re­treat for what he

con­sid­ered the 100 most im­por­tant peo­ple at Apple, and these were

not the 100 peo­ple high­est on the org chart. Can you imag­ine the

force of will it would take to do this at the av­er­age com­pany? And

yet imag­ine how use­ful such a thing could be. It could make a big

com­pany feel like a startup. Steve pre­sum­ably would­n’t have kept

hav­ing these re­treats if they did­n’t work. But I’ve never heard of

an­other com­pany do­ing this. So is it a good idea, or a bad one? We

still don’t know. That’s how lit­tle we know about founder mode.

Obviously founders can’t keep run­ning a 2000 per­son com­pany the way

they ran it when it had 20. There’s go­ing to have to be some amount

of del­e­ga­tion. Where the bor­ders of au­ton­omy end up, and how sharp

they are, will prob­a­bly vary from com­pany to com­pany. They’ll even

vary from time to time within the same com­pany, as man­agers earn

trust. So founder mode will be more com­pli­cated than man­ager mode.

But it will also work bet­ter. We al­ready know that from the ex­am­ples

of in­di­vid­ual founders grop­ing their way to­ward it.

Indeed, an­other pre­dic­tion I’ll make about founder mode is that

once we fig­ure out what it is, we’ll find that a num­ber of in­di­vid­ual

founders were al­ready most of the way there — ex­cept that in do­ing

what they did they were re­garded by many as ec­cen­tric or worse.

Curiously enough it’s an en­cour­ag­ing thought that we still know so

lit­tle about founder mode. Look at what founders have achieved

al­ready, and yet they’ve achieved this against a head­wind of bad

ad­vice. Imagine what they’ll do once we can tell them how to run

their com­pa­nies like Steve Jobs in­stead of John Sculley.

Notes

The more diplo­matic way of phras­ing this state­ment would be

to say that ex­pe­ri­enced C-level ex­ecs are of­ten very skilled at

man­ag­ing up. And I don’t think any­one with knowl­edge of this world

would dis­pute that.

If the prac­tice of hav­ing such re­treats be­came so wide­spread

that even ma­ture com­pa­nies dom­i­nated by pol­i­tics started to do it,

When I’m work­ing on main­tain­ing an un­fa­mil­iar code­base, I will spend a lot of time grep­ping the code base for strings. Even in pro­jects ex­clu­sively writ­ten by my­self, I have to search a lot: func­tion names, er­ror mes­sages, class names, that kind of thing. If I can’t find what I’m look­ing for, it’ll be frus­trat­ing in the best case, or in the worst case lead to dan­ger­ous sit­u­a­tions where I’ll as­sume a thing is not needed any­more, since I can’t find any ref­er­ences to it in the code base. From these sit­u­a­tions, I’ve de­rived some rules you can ap­ply to keep your code base grep­pable:

It turns out that split­ting up, or dy­nam­i­cally con­struct­ing iden­ti­fiers is a bad idea.

Suppose you have two data­base ta­bles ship­ping_ad­dresses, billing_ad­dresses, it might seem like a per­fectly good so­lu­tion to con­struct the table name dy­nam­i­cally from the or­der type.

const get­Table­Name = (addressType: ‘shipping’ | ‘billing’) => {

re­turn `${addressType}_addresses`

Though it looks nice and DRY, it’s not great for main­taine­nance: some­one will in­evitably search the code base for the table name ship­ping_ad­dresses and miss this oc­curence.

const get­Table­Name = (addressType: ‘shipping’ | ‘billing’) => {

if (addressType === ‘shipping’) {

re­turn ‘shipping_addresses’

if (addressType === ‘billing’) {

re­turn ‘billing_addresses’

throw new TypeError(‘addressType must be billing or ship­ping’)

The same goes for col­umn names, ob­ject fields, and, god for­bid, method/​func­tion names (it’s eas­ily pos­si­ble to dy­nam­i­cally con­struct method names with javascript).

Don’t re­name fields at ap­pli­ca­tion bound­aries to match nam­ing schemes. An ob­vi­ous ex­am­ple is then im­port­ing post­gres-style snake_­case iden­ti­fiers into javascript, then con­vert­ing them to camel­Case. This makes it harder to find—you now have to grep for two strings in­stead of one in or­der to find all oc­curences!

const getAd­dress = async (id: string) => {

const ad­dress = await getAd­dress­ById(id)

re­turn {

street­Name: ad­dress.street_­name,

zip­Code: ad­dress.zip_­code,

You’re bet­ter off bit­ing the bul­let and re­turn­ing the ob­ject di­rectly:

const getAd­dress = async (id: string) => {

re­turn await getAd­dress­ById(id)

Taking in­spi­ra­tion from the Zen of Python, when deal­ing with name­spaces, flat­ten­ing your fold­ers/​ob­ject struc­tures is mostly bet­ter than nest­ing.

For ex­am­ple if you have two choices to set up your trans­la­tion files:

“auth”: {

“login”: {

“title”: “Login”,

“emailLabel”: “Email”,

“passwordLabel”: “Password”,

“register”:

“title”: “Register”,

“emailLabel”: “Email”,

“passwordLabel”: “Password”,

“auth.login.title”: “Login”,

“auth.login.emailLabel”: “Email”,

“auth.login.passwordLabel”: “Password”,

“auth.register.title”: “Login”,

“auth.register.emailLabel”: “Email”,

“auth.register.passwordLabel”: “Password”,

take the sec­ond op­tion! You will be able to eas­ily find your keys now, which you are prob­a­bly re­fer­ring to as some­thing like t(‘auth.lo­gin.ti­tle’).

Or con­sider React com­po­nent struc­ture: a com­po­nent stuc­ture like

./components/AttributeFilterCombobox.tsx

./components/AttributeFilterDialog.tsx

./components/AttributeFilterRating.tsx

./components/AttributeFilterSelect.tsx

./components/attribute/filter/Combobox.tsx

./components/attribute/filter/Dialog.tsx

./components/attribute/filter/Rating.tsx

./components/attribute/filter/Select.tsx

from a grep­pa­bil­ity per­spec­tive, since you’ll be able to grep for the whole name­spaced com­po­nent AttributeFilterCombobox just from the us­age, as op­posed to just Dialog, which you might have mul­ti­ple of ac­cross your ap­pli­ca­tion.

Beautiful, and Boring Investment Tracker, with Local Data Storage. No Subscriptions, No Cloud. Wealthfolio is a sim­ple, desk­top-based in­vest­ment tracker. Your fi­nan­cial data is stored safely on your own com­puter Ditch the spread­sheets, for­get about those pesky sub­scrip­tion fees, and no more wor­ries about SaaS ser­vices play­ing around with your data.The Essentials You Need to Track Your WealthForget jug­gling spread­sheets or com­pro­mis­ing pri­vacy with on­line apps. Choose Wealthfolio’s sim­ple, se­cure ap­proach to man­age your fi­nances.Gather all your in­vest­ment and sav­ings ac­counts in one place. See every­thing at a glance, from stocks to sav­ings! Import your state­ments from your bro­ker or bank.Track your ac­counts’ hold­ings and per­for­mance over time. See how a par­tic­u­lar ac­count is per­form­ing, and how it’s chang­ing over time.Get a clear pic­ture of what’s in your port­fo­lio. Stocks, bonds, or mu­tual funds - know what you have and how it’s per­form­ing.Mon­i­tor div­i­dends and in­ter­est in­come across your en­tire port­fo­lio. Get a clear view of your pas­sive in­come streams, help­ing you make in­formed de­ci­sions about your in­vest­ments.Set your sav­ings tar­gets clearly. Distribute your funds across these ob­jec­tives, as­sign­ing a spe­cific per­cent­age to each. Keep an eye on your progress.

Hello every­one - it’s been a while!

I was su­per busy with uni­ver­sity and my manda­tory in­tern­ship in a soft­ware com­pany for the past 6 months, so I haven’t posted in a while. But that does­n’t mean that I was in­ac­tive - I spent nearly every evening and every week­end work­ing on SpaceHey. I did­n’t de­velop any new ground-break­ing fea­tures, but in­stead I fo­cused on im­prov­ing the over­all SpaceHey ex­pe­ri­ence - mak­ing it smoother, more sta­ble, eas­ier to use and safer.

But be­fore I get into the de­tails, let’s have a look at a huge mile­stone first: SpaceHey hit 1 Million reg­is­tered users!! That’s crazy!!

I launched SpaceHey at the end of 2020 - I had just grad­u­ated high-school, and the world was on Covid lock­down. I made SpaceHey, so my gen­er­a­tion could ex­pe­ri­ence the early days of so­cial me­dia - with­out a feed, likes and what­not - but in­stead with col­or­ful, cus­tomiz­able pro­files, bul­letins and fo­rums. I did­n’t plan to cre­ate any­thing big - I just had some fun cre­at­ing this site and im­prov­ing my cod­ing skills at the same time.

Still, three and a half years later - SpaceHey has in­deed be­come big. One mil­lion peo­ple is an in­cred­i­bly huge num­ber of peo­ple - it’s  sim­ply crazy! If some­one would’ve told my 18-year-old self in 2020, I would’ve never be­lieved them. And yet - here we are. I am so in­cred­i­bly thank­ful for all the sup­port over the past three and a half years - the friends I made along the way and the lessons I’ve learned - both in run­ning a com­mu­nity as big as this one as well as the tech­ni­cal chal­lenges that came along.

One mil­lion peo­ple from all over the world have used SpaceHey so far - an in­de­pen­dently run plat­form that does not track you and does not show you per­son­al­ized feeds nor ads. My mis­sion is not to be­come an­other big so­cial net­work like Facebook or Twitter (I don’t think I’ll ever call it “X”) - but rather try­ing to be dif­fer­ent. More per­sonal, more fun to use, and more hu­mane. And I’m proud to say that this mis­sion is still very much alive - no mat­ter if there were 500 users or 1,000,000.

If you like SpaceHey and want to sup­port the plat­form, you can sup­port me here, and there is also a spe­cial #1 Million Merch drop avail­able here

to sup­port SpaceHey. Your sup­port - no mat­ter if it’s a do­na­tion or a Merch or­der - is what keeps SpaceHey run­ning: thank you!!

I’ve stopped my­self from work­ing on any new fea­tures in the past months, but rather im­prove the ex­ist­ing ones and make SpaceHey over­all a bit smoother. It was­n’t easy - but I think it was worth it. You may have al­ready no­ticed less down­time and less App crashes in the past weeks - and there are some more im­prove­ments com­ing soon.

I’m now also start­ing to work on some new fea­tures again - which is su­per fun - and I can’t wait to share more with you soon (T8 👀) - so stay tuned!

Another big topic I worked on in the past months is safety. As more and more peo­ple joined SpaceHey, the bots and spam­mers also in­creased. Spam, hate speech, and other kinds of harm­ful con­tent has no place on SpaceHey - that’s why a so­lu­tion was needed, and even­tu­ally found.

The so­lu­tion is­n’t ac­tu­ally one so­lu­tion - but a com­bi­na­tion of mul­ti­ple. On the one hand, I’ve im­ple­mented more ways to pre­vent spam in the first place - and on the other hand, I’ve de­vel­oped more ways to com­bat ex­ist­ing spam. I’ve ex­panded the vol­un­teer mod­er­a­tion team and im­proved the ways the team can dis­cover spam, re­act to re­ports

and keep track of rule vi­o­la­tions. I am im­mensely thank­ful to the vol­un­teers help­ing me, and I think we are on a great path to keep SpaceHey safe.

If you come across harm­ful con­tent on SpaceHey, please click the “Report” icon next to it, and we’ll check it. Thank you for do­ing your part!

I am su­per thrilled to keep work­ing on SpaceHey - there are so many awe­some, tal­ented and fun peo­ple here. I can’t wait to keep im­prov­ing the site and the App and keep work­ing on some great new fea­tures in the near fu­ture. I am su­per happy to have you all here, and I hope you are en­joy­ing this jour­ney as much as I do!

Last but not least, a huge thank you to every sin­gle one of you - you are the peo­ple who make SpaceHey what it is - you make it awe­some. Thank you so, so much!

Have an awe­some day & thank you for us­ing SpaceHey!

An

Secure el­e­ments are small mi­cro­con­trollers whose main pur­pose is to gen­er­ate/​store se­crets and then ex­e­cute cryp­to­graphic op­er­a­tions. They un­dergo the high­est level of se­cu­rity eval­u­a­tions that ex­ists (Common Criteria) and are of­ten con­sid­ered in­vi­o­lable, even in the worst-case at­tack sce­nar­ios. Hence, com­plex se­cure sys­tems build their se­cu­rity upon them.

FIDO hard­ware to­kens are strong au­then­ti­ca­tion fac­tors to sign in to ap­pli­ca­tions (any web ser­vice sup­port­ing FIDO); they of­ten em­bed a se­cure el­e­ment and the FIDO pro­to­col uses Elliptic Curve Digital Signature Algorithm (ECDSA for short) as its core cryp­to­graphic prim­i­tive. are cer­tainly the most wide­spread FIDO hard­ware to­kens, their se­cure el­e­ment is an Infineon .

This doc­u­ment shows how — find­ing a JavaCard open plat­form (the ) based on a sim­i­lar Infineon  — we un­der­stood the Infineon ECDSA im­ple­men­ta­tion, found a side-chan­nel vul­ner­a­bil­ity and de­signed a prac­ti­cal side-chan­nel at­tack. The at­tack is then demon­strated on a . Finally, we show that the vul­ner­a­bil­ity ex­tends to the more re­cent Infineon and Infineon se­cu­rity mi­cro­con­trollers.

Our work un­earths a side-chan­nel vul­ner­a­bil­ity in the cryp­to­graphic li­brary of Infineon Technologies, one of the biggest se­cure el­e­ment man­u­fac­tur­ers. This vul­ner­a­bil­ity — that went un­no­ticed for 14 years and about 80 high­est-level Common Criteria cer­ti­fi­ca­tion eval­u­a­tions — is due to a non con­stant-time mod­u­lar in­ver­sion.

The at­tack re­quires phys­i­cal ac­cess to the se­cure el­e­ment (few lo­cal elec­tro­mag­netic side-chan­nel ac­qui­si­tions, i.e. few min­utes, are enough) in or­der to ex­tract the ECDSA se­cret key. In the case of the FIDO pro­to­col, this al­lows to cre­ate a clone of the FIDO de­vice.

All YubiKey 5 Series (with firmware ver­sion be­low 5.7) are im­pacted by the at­tack and in fact all Infineon se­cu­rity mi­cro­con­trollers (including TPMs) that run the Infineon cryp­to­graphic li­brary (as far as we know, any ex­ist­ing ver­sion) are vul­ner­a­ble to the at­tack. These se­cu­rity mi­cro­con­trollers are pre­sent in a vast va­ri­ety of se­cure sys­tems — of­ten re­ly­ing on ECDSA — like elec­tronic pass­ports and crypto-cur­rency hard­ware wal­lets but also smart cars or homes. However, we did not check (yet) that the EUCLEAK at­tack ap­plies to any of these prod­ucts.

Authentication to­kens (like FIDO hard­ware de­vices) pri­mary goal is to fight the scourge of phish­ing at­tacks. The EUCLEAK at­tack re­quires phys­i­cal ac­cess to the de­vice, ex­pen­sive equip­ment, cus­tom soft­ware and tech­ni­cal skills. Thus, as far as the work pre­sented here goes, it is still safer to use your YubiKey or other im­pacted prod­ucts as FIDO hard­ware au­then­ti­ca­tion to­ken to sign in to ap­pli­ca­tions rather than not us­ing one.

* All Infineon se­cu­rity mi­cro­con­trollers em­bed­ding Infineon cryp­to­graphic li­brary (any ex­ist­ing ver­sion). For in­stance, all ex­ist­ing ver­sions of Infineon TPMs are af­fected.

* All (with firmware ver­sion be­low 5.7)

1. The im­pacted Feitian A22 Javacard used in this work is an old prod­uct no more avail­able for sale. All Feitian prod­ucts cur­rently avail­able on their web­store (and based on an Infineon se­cu­rity mi­cro­con­troller) use Feitian own cryp­to­graphic li­brary, and are not im­pacted by our work to our knowl­edge.

2. The new YubiKey firmware 5.7 up­date (May 6th, 2024) switches the YubiKeys from Infineon cryp­to­graphic li­brary to Yubico new cryp­to­graphic li­brary. To our knowl­edge, this new cryp­to­graphic li­brary is not im­pacted by our work.

3. Infineon has al­ready a patch for their cryp­to­graphic li­brary, to our knowl­edge it did not yet pass a Common Criteria cer­ti­fi­ca­tion eval­u­a­tion.

We are still wait­ing for a CVE ID.

It’s a quiet Saturday af­ter­noon. I’ve carved out a few pre­cious hours for cod­ing, armed with a steam­ing cup of cof­fee and the fa­mil­iar urge to dive into a pro­ject. As I set­tle into my chair and open my ter­mi­nal, I’m con­fronted with a chal­lenge that’s be­come all too fa­mil­iar: de­cid­ing which of my many un­fin­ished pro­jects to tackle.

I nav­i­gate to my pro­ject di­rec­tory, greeted by a grave­yard of half-im­ple­mented ideas and stalled works-in-progress. Each one rep­re­sents a dif­fer­ent prob­lem I’ve tried to solve, a dif­fer­ent tech­nol­ogy I’ve at­tempted to mas­ter. They’re all in­ter­est­ing, each with its own pur­pose and po­ten­tial. But as I scan through them, I can al­ready feel my en­thu­si­asm wan­ing. I know that whichever one I choose, I’ll be fac­ing not just the orig­i­nal prob­lem, but a hy­dra of new chal­lenges that have sprouted since I last looked at the code.

After some de­lib­er­a­tion, I make my choice and fire up my IDE. As I pull the lat­est changes and be­gin the ar­chae­o­log­i­cal dig through my com­mit his­tory, I brace my­self for what I know I’ll find. Sure enough, there it is: an un­fin­ished fron­tend task, more wire­frame than pol­ished UI. Or per­haps it’s a li­brary in­te­gra­tion that’s hit­ting lim­i­ta­tions I had­n’t an­tic­i­pated. Or, in clas­sic over-en­gi­neer­ing fash­ion, I’ve built a com­plex ar­chi­tec­ture for a prob­lem that could have been solved with a sim­ple script.

I roll up my sleeves and dive in, de­ter­mined to make progress. The next cou­ple of hours fly by in a flurry of ac­tiv­ity — refac­tor­ing code, de­bug­ging in­te­gra­tion is­sues, or wrestling with CSS to get that one com­po­nent to align just right. Before I know it, my al­lo­cated time is up.

As I pre­pare to step away from my desk, I can’t shake a feel­ing of frus­tra­tion. I started the ses­sion full of op­ti­mism, ready to make sig­nif­i­cant head­way. Now, I’m left with a nag­ging sense of in­ad­e­quacy. Despite my ef­forts, it feels like I’ve barely moved the nee­dle. The code­base is still a maze of TODO com­ments and half-im­ple­mented fea­tures. The Hydra of soft­ware de­vel­op­ment has grown two new heads for every one I man­aged to ad­dress.

This cy­cle of en­thu­si­asm, strug­gle, and dis­ap­point­ment has be­come all too fa­mil­iar. It’s the Hydra Project Effect: no mat­ter how much progress I make, new chal­lenges al­ways seem to sprout in their place. But while this pat­tern may seem un­break­able, I’m de­ter­mined to find a way to tame this beast. In this post, I’ll ex­plore strate­gies for break­ing out of this cy­cle of end­less be­gin­nings and un­sat­is­fy­ing mid­dles. It’s time to learn the art of fin­ish­ing, to slay this Hydra once and for all, and to fi­nally ex­pe­ri­ence the sat­is­fac­tion of a com­pleted pro­ject.

There’s a cer­tain com­fort in the realm of in­fi­nite pos­si­bil­ity. When a pro­ject is on­go­ing, it can be any­thing. It’s Schrödinger’s1 pro­ject — si­mul­ta­ne­ously per­fect and flawed un­til you ac­tu­ally fin­ish it and put it out into the world. The mo­ment you de­clare a pro­ject “done,” you open it up to crit­i­cism, both ex­ter­nal and in­ter­nal. What if it’s not good enough? What if I missed some­thing cru­cial?

This fear of fi­nal­ity, com­bined with the ex­cite­ment of new ideas, cre­ates an ideal en­vi­ron­ment for pro­ject pro­cras­ti­na­tion. It’s al­ways eas­ier to start some­thing new than to push through the fi­nal, of­ten te­dious stages of com­ple­tion of a pro­ject. But there’s more to it than just fear.

An un­fin­ished pro­ject is full of in­tox­i­cat­ing po­ten­tial. It could be the next big thing, a rev­o­lu­tion­ary idea, or your mag­num opus. This po­ten­tial of­ten feels more ex­cit­ing than the re­al­ity of a fin­ished prod­uct. There’s also com­fort in the fa­mil­iar ter­ri­tory of an on­go­ing pro­ject. You know the code­base, you un­der­stand the prob­lems, and you’re in your el­e­ment. Starting some­thing new means fac­ing the un­known, which can be daunt­ing.

The il­lu­sion of pro­duc­tiv­ity plays a sig­nif­i­cant role too. As long as you’re work­ing on some­thing, you feel pro­duc­tive. Jumping from pro­ject to pro­ject gives you a con­stant stream of “new pro­ject en­ergy,” which can feel more in­vig­o­rat­ing than the grind of fin­ish­ing a sin­gle pro­ject. It’s a way of avoid­ing dif­fi­cult de­ci­sions that come with com­ple­tion. Do you cut that fea­ture you spent weeks on but is­n’t quite right? Do you re­lease now or spend an­other month pol­ish­ing? By keep­ing pro­jects on­go­ing, you can side­step these chal­leng­ing choices.

The ab­sence of dead­lines in per­sonal pro­jects adds an­other layer to this com­plex­i­ty2. Without the ex­ter­nal pres­sure of a due date, it’s all too easy to fall into the trap of per­fec­tion­ism. We find our­selves end­lessly tweak­ing and re­fin­ing, al­ways chas­ing that elu­sive “perfect” so­lu­tion. The irony is that this pur­suit of per­fec­tion of­ten leads to im­per­fect re­sults — or no re­sults at all. In our pro­fes­sional lives, dead­lines force us to pri­or­i­tize and make prag­matic de­ci­sions. But in per­sonal pro­jects, the lux­ury of un­lim­ited time can be­come a curse, al­low­ing us to jus­tify spend­ing hours, days, or even weeks on mi­nor de­tails that, in re­al­ity, make lit­tle dif­fer­ence to the pro­jec­t’s over­all suc­cess or use­ful­ness. It’s a stark re­minder that some­times, “good enough” truly is per­fect, es­pe­cially when the al­ter­na­tive is never fin­ish­ing at all.

Paradoxically, some­times we fear suc­cess as much as fail­ure. A suc­cess­ful pro­ject might lead to in­creased ex­pec­ta­tions, more re­spon­si­bil­ity, or a change in iden­tity that we’re not quite ready for. The un­fin­ished pro­ject be­comes a safety net, pro­tect­ing us from the un­known con­se­quences of suc­cess.

But this cy­cle of end­less be­gin­nings comes at a steep price. There’s a unique sat­is­fac­tion in see­ing a pro­ject through to com­ple­tion that no amount of start­ing can match. Moreover, un­fin­ished pro­jects carry a men­tal weight. They linger in the back of your mind, qui­etly drain­ing your men­tal en­ergy and en­thu­si­asm.

Perhaps most im­por­tantly, we learn dif­fer­ent lessons from fin­ish­ing pro­jects than we do from start­ing them. Starting teaches us about ideation and ini­tial im­ple­men­ta­tion. Finishing, on the other hand, teaches us about per­se­ver­ance, at­ten­tion to de­tail, and the art of know­ing when to let go. These are in­valu­able skills that can only be honed through the act of com­ple­tion.

The costs of never fin­ish­ing ex­tend far be­yond just missed op­por­tu­ni­ties. While start­ing pro­jects might ex­pose you to new tech­nolo­gies or con­cepts, it’s in the act of fin­ish­ing — of solv­ing those last, trick­i­est prob­lems — where real skill growth of­ten oc­curs. Each un­fin­ished pro­ject can chip away at your con­fi­dence. Over time, you might start to doubt your abil­ity to com­plete any­thing sub­stan­tial, cre­at­ing a self-ful­fill­ing prophecy of in­com­ple­tion.

The end stages of a pro­ject of­ten in­volve op­ti­miza­tion, refac­tor­ing, and re­ally un­der­stand­ing the in­tri­ca­cies of your code. By not fin­ish­ing, you miss out on these valu­able learn­ing ex­pe­ri­ences. In pro­fes­sional set­tings, be­ing known as some­one who starts things but does­n’t fin­ish them can be detri­men­tal to your ca­reer. Employers and clients value those who can de­liver com­pleted pro­jects, mak­ing the abil­ity to fin­ish a cru­cial pro­fes­sional skill.

Every un­fin­ished pro­ject takes up men­tal space. It’s like hav­ing dozens of browser tabs open — each one uses a lit­tle bit of your men­tal RAM, leav­ing you with less ca­pac­ity for new ideas and fo­cused work. This men­tal clut­ter can be a sig­nif­i­cant drain on your cre­ativ­ity and pro­duc­tiv­ity.

Perhaps most im­por­tantly, you deny your­self the in­com­pa­ra­ble feel­ing of sat­is­fac­tion when you re­lease a fin­ished pro­ject into the world. There’s a joy in ship­ping that can’t be repli­cated by start­ing some­thing new. Finished pro­jects also in­vite feed­back, and with­out ship­ping, you miss out on valu­able in­sights from users or peers that could sig­nif­i­cantly im­prove your skills and fu­ture pro­jects.

Understanding both the al­lure of end­less pro­jects and the cost of never fin­ish­ing is cru­cial. It’s not about dis­miss­ing the ex­cite­ment of new be­gin­nings, but rather about find­ing a bal­ance — learn­ing to chan­nel that ini­tial en­thu­si­asm into the equally im­por­tant (if some­times less glam­orous) work of see­ing things through to com­ple­tion. By rec­og­niz­ing these pat­terns in our­selves, we can start to de­velop strate­gies to over­come them and fi­nally slay the Project Hydra.

So, how do I break this cy­cle? How do I learn to fin­ish what I start? Here are some strate­gies I’m im­ple­ment­ing to tame my own Project Hydra:

✅ Define “Done” from the Start: Before div­ing into a pro­ject, I’ll clearly de­fine what “finished” looks like. What are the core fea­tures that con­sti­tute a com­plete pro­ject? I’ll write them down and re­sist the urge to ex­pand this list as I go. This clar­ity helps pre­vent scope creep and gives me a clear tar­get to aim for.

🚀 Embrace MVP: Instead of aim­ing for per­fec­tion, I’ll aim for “good enough.” I’ll get a ba­sic ver­sion work­ing and out into the world. I can al­ways it­er­ate and im­prove later. This ap­proach helps main­tain mo­men­tum and pro­vides early feed­back op­por­tu­ni­ties.

⏳ Time-Box My Projects: I’ll give my­self a dead­line. It does­n’t have to be short, but it should be fi­nite. Having an end date cre­ates ur­gency and helps me pre­vent end­less fea­ture creep. I find that break­ing larger pro­jects into smaller, time-boxed phases helps main­tain a sense of progress.

🧩 Practice Finishing Small Things: I’ll build my “finishing mus­cle” by com­plet­ing small pro­jects or tasks reg­u­larly. I rec­og­nize that the skill of fin­ish­ing is like any other — it im­proves with prac­tice. This could be as sim­ple as fin­ish­ing a blog post or com­plet­ing a small cod­ing chal­lenge each week.

💡 Separate Ideation from Implementation: I’ll keep a sep­a­rate idea log. When new fea­tures or pro­ject ideas pop up dur­ing im­ple­men­ta­tion, I’ll jot them down for fu­ture con­sid­er­a­tion in­stead of im­me­di­ately act­ing on them. This helps main­tain fo­cus on the cur­rent pro­ject while still cap­tur­ing po­ten­tially valu­able ideas.

🎉 Celebrate Completions: I’ll make fin­ish­ing a big deal. I’ll cel­e­brate when I com­plete a pro­ject, no mat­ter how small. This pos­i­tive re­in­force­ment can help shift my mind­set to­wards com­ple­tion. Whether it’s treat­ing my­self to a nice din­ner or sim­ply shar­ing my ac­com­plish­ment with friends, ac­knowl­edg­ing these wins boosts mo­ti­va­tion for fu­ture pro­jects.

👥 Embrace Accountability: I’ll find ways to make my­self ac­count­able for fin­ish­ing pro­jects. This could in­volve find­ing an ac­count­abil­ity part­ner, mak­ing pub­lic com­mit­ments about pro­ject mile­stones, or join­ing a group of fel­low de­vel­op­ers. External ac­count­abil­ity adds mo­ti­va­tion and sup­port to the of­ten soli­tary jour­ney of per­sonal pro­jects.3

These strate­gies pro­vide my per­sonal roadmap for over­com­ing the chal­lenges of the Project Hydra. By im­ple­ment­ing them con­sis­tently, I hope to de­velop bet­ter habits and in­crease my chances of see­ing pro­jects through to com­ple­tion. It’s about cre­at­ing a sup­port­ive struc­ture around my work, bal­anc­ing in­ter­nal mo­ti­va­tion with ex­ter­nal ac­count­abil­ity, and grad­u­ally build­ing the skill of fin­ish­ing.

Of course, strate­gies are just the be­gin­ning. The real chal­lenge lies in con­sis­tently ap­ply­ing these ap­proaches to my work. It’s a process of trial and er­ror, of learn­ing what works best for my per­sonal style and the spe­cific de­mands of each pro­ject. But with each small win, with each pro­ject pushed a lit­tle closer to com­ple­tion, I’m build­ing the habits and mind­set needed to fi­nally tame the Project Hydra.

The path ahead will be chal­leng­ing. I know that chang­ing in­grained habits and thought pat­terns will take time and con­sis­tent ef­fort. There will likely be set­backs along the way — mo­ments when the al­lure of a new pro­ject tempts me away from fin­ish­ing the cur­rent one, or when the fear of im­per­fec­tion makes me hes­i­tate to de­clare some­thing “done”. But I’m com­mit­ted to push­ing through these ob­sta­cles and build­ing my “finishing mus­cle”.

This jour­ney is­n’t just about com­plet­ing code; it’s about grow­ing as a de­vel­oper and cre­ator. Each fin­ished pro­ject, no mat­ter how small, is a step to­wards be­com­ing some­one who not only starts with en­thu­si­asm but fin­ishes with sat­is­fac­tion.

The Project Hydra has loomed over my work for too long. Armed with new strate­gies and de­ter­mi­na­tion, I’m ready to face this beast head-on. It’s time to stop plan­ning and start do­ing.

Now, if you’ll ex­cuse me, I have a pro­ject to fin­ish — and this time, I in­tend to see it through.4

I hap­pened to look at a slide deck from Sandia National Laboratories from 2007 that some­one had posted on Reddit late last night (you know, as one does, in­stead of sleep­ing), and one par­tic­u­lar slide jumped out at me:

It’s a lit­tle graphic ad­ver­tis­ing the dif­fer­ent kinds of mod­el­ing soft­ware that are part of some­thing called the SIERRA frame­work, as part of a pretty stan­dard “overview” pre­sen­ta­tion on com­puter mod­el­ing at Sandia that was given at a meet­ing in Luxembourg.

Did you catch the part that made me stop and au­di­bly say, “uhhhhh“? Look at the lower right:

So, that looks an aw­ful lot like the cut­away of a com­pact ther­monu­clear weapon de­sign. I im­me­di­ately won­dered if I could­n’t find a bet­ter res­o­lu­tion ver­sion of the same graphic, so I went onto OSTI.gov and start­ing plug­ging in terms that seemed rel­e­vant. Searching for “Sierra” and “Salinas” and re­strict­ing to “Conference pre­sen­ta­tions” turned up a bunch of other in­stances of it from the 2007-2011 or so time­frame. The one with the high­est res­o­lu­tion came from an­other pre­sen­ta­tion, from 2008:

So this is aw­fully strange. We’ve got some­thing here that looks like a plau­si­ble reen­try ve­hi­cle for a nu­clear war­head. The bits in red, yel­low, per­haps fus­cia at the “tip” are in the po­si­tion (and about the right size) to be the arm­ing, fuz­ing, and fir­ing sys­tem. The bits be­low that — the green, the blue, etc. — look like a ther­monu­clear war­head. The green part looks like it is meant to rep­re­sent the lo­ca­tion of the “primary,” while the the cylin­ders-within-cylin­ders are a clas­sic rep­re­sen­ta­tion of a ther­monu­clear “secondary.” One could de­bate about the ex­act iden­tity of each color, but it looks a lot like it is meant to rep­re­sent a ra­di­a­tion case, an in­ter­stage medium, a tam­per, fu­sion fuel, and a “sparkplug.” You’ve even got an in­ter­est­ing lit­tle “dip” into the cen­tral cylin­der which looks like a chan­nel to get neu­trons into the “sparkplug.”

By com­par­i­son, this im­age from later in the pre­sen­ta­tion looks a lot more like what one would ex­pect them to re­lease about a reen­try ve­hi­cle in a pub­lic doc­u­ment — just the arm­ing, fuz­ing, and fir­ing sys­tem (the top part, with the de­tail at right), and then the “warhead” sec­tion de­picted as a fea­ture­less blank:

Even that is a lit­tle more re­veal­ing than usual, as it gives pretty pre­cise di­men­sions. So see­ing some­thing that looks like it is meant to rep­re­sent the war­head it­self is… pretty sur­pris­ing!

This is­n’t some one-off slip up kind of thing. This par­tic­u­lar graphic is pre­sent in at least half-a-dozen con­fer­ence pre­sen­ta­tions on OSTI.gov, and even some on a few other gov­ern­ment web­sites (like this pre­sen­ta­tion given to NASA). It’s lit­er­ally the logo they use for this par­tic­u­lar soft­ware pack­age. And it’s not some kind of redac­tion er­ror, like the ones I wrote about pre­vi­ously, in which things not dis­sim­i­lar from the above were very clearly in­tended to be redacted, but were done so poorly that you could in fact see some as­pects of them. This is lit­er­ally the logo for this par­tic­u­lar soft­ware frame­work, and it has been used in lots of pre­sen­ta­tions (including those done over­seas), and is posted all over un­clas­si­fied, pub­lic-fac­ing data­bases hosted by the fed­eral gov­ern­ment.

It took me a lit­tle more search­ing, but I even­tu­ally tracked down an iso­lated ver­sion of the im­age from yet an­other Sandia pre­sen­ta­tion:

The slide does­n’t give any clar­i­fi­ca­tion as to what we’re look­ing at, here, other than in­di­cat­ing that it part of mod­el­ing work for the pur­poses of struc­tural dy­nam­ics, and is clearly part of a nu­clear weapons con­text.

The SIERRA soft­ware frame­work, I gather, is a sim­u­la­tion/​mod­el­ing toolkit that al­lowed sci­en­tists to ba­si­cally sim­u­late a rel­a­tively “full spec­trum” of weapons safety is­sues. This is Sandia’s bread and but­ter: mak­ing sure that your weapon won’t go off if, say, you drop it, or set it on fire, or let it get hit by light­ning. Things which have hap­pened a num­ber of times over the years. The “Salinas” pack­age in par­tic­u­lar seems to be about mod­el­ing me­chan­i­cal as­pects of ma­te­ri­als. Which is to say, this demon­stra­tion of its “capabilities” is not about show­ing you that it is mod­el­ing how a nu­clear weapon would det­o­nate. It is show­ing you, “look, we can model a lot of dif­fer­ent ma­te­ri­als — steel, ura­nium, lithium, etc. — and could prob­a­bly tell you whether they would crack or strain or shat­ter or what­ever if you, say, dropped this weapon.” That’s my quick gloss on the var­i­ous pre­sen­ta­tions, any­way.

To give a sense of how strange this is, here is the only “officially sanc­tioned” way to rep­re­sent a mul­ti­stage ther­monu­clear weapon, ac­cord­ing to US Department of Energy guid­ance since the 1990s:

Two cir­cles in a box, maybe in­side of a reen­try ve­hi­cle. That’s it. Nothing that gives any ac­tual sense of size, lo­ca­tion, ma­te­ri­als, phys­i­cal­ity. One can com­pare this with the im­ages of more spec­u­la­tive ther­monu­clear weapon de­signs in the pub­lic do­main for a sense of how lim­ited the of­fi­cial re­lease is com­pared with what is “believed to be known” about such things:

Incidentally, I sub­mit­ted a FOIA re­quest on that par­tic­u­lar guid­ance doc­u­ment (TCG-NAS-2) some time back, and the doc­u­ment that I got back was hi­lar­i­ously redacted to the point that even terms like “gun-type” and “implosion” were redacted, much less any and all im­ages, de­spite that doc­u­ment ap­par­ently con­tain­ing ex­am­ples of what ac­tu­ally could be said pub­licly about these things. Which is just to em­pha­size, it’s not like the DOE is par­tic­u­larly loose about even as vaguely rep­re­sen­ta­tional an im­age as is that one — if any­thing, the err in the other di­rec­tion.

Why are they so up­tight about ther­monu­clear weapon de­sign “shapes”? The of­fi­cial rea­son, of course, is be­cause of pro­lif­er­a­tion con­cerns. But there’s an­other rea­son: even the ap­pear­ance of giv­ing away “secrets” can gen­er­ate un­wanted pub­lic­ity and po­lit­i­cal scan­dal.

In 1999, the Cox Committee’s re­port on Chinese nu­clear es­pi­onage made some hay out of pub­licly-avail­able de­pic­tions of H-bombs, and fea­tured an en­tire spread ded­i­cated to the fact that “visitors to Los Alamos National Laboratory are pro­vided a 72-page pub­li­ca­tion that pro­vides, among other things, a primer on the de­sign of ther­monu­clear weapons.” It sen­sa­tion­al­ized that very two-cir­cles-in-a-box im­age that I showed above, and weaponized it. How dare Los Alamos give that away! Despite it be­ing un­clas­si­fied. But that’s what I mean by un­wanted po­lit­i­cal scan­dal — lots of scan­dals about the re­lease of “secrets” in­volve non-se­crets. (There’s a lot on this sort of thing in my book, of course.)

Which leads us to an in­ter­est­ing puz­zle: why would the cen­sors re­peat­edly al­low Sandia to use what ap­pears to be a ther­monu­clear weapon cut­away as part of a pro­mo­tional di­a­gram for a soft­ware pack­age? There are a few pos­si­bil­i­ties that come to my mind.

One is the idea that this is an ac­ci­dent, a leak, an oop­sie. I find this un­likely to the point of near im­pos­si­bil­ity. Not be­cause the clas­si­fi­ca­tion of­fi­cers are per­fect. But this is so ob­vi­ously not some­thing you would au­tho­rize for re­lease if you thought it was rep­re­sent­ing some­thing clas­si­fied. To have ap­proved many pre­sen­ta­tions with this graphic in it to go out into the world, to be posted on the web­sites of mul­ti­ple gov­ern­ment agen­cies… they’re not per­fect, but they’re not fools. Again, if any­thing, they tend to err on the side not re­leas­ing enough. So I find it hard to be­lieve that they’d have messed this up, again and again, when it is the most bla­tant thing in the world. This is­n’t some sub­tle tech­ni­cal thing. Anyone who thinks about weapons in­for­ma­tion and se­crecy is go­ing to know what a cylin­dri­cal sec­ondary looks like. I mean, this thing jumps off the page if you are that kind of per­son. Which I am, of course, but so are redac­tors. If this were the case, it would be an in­cred­i­ble and re­peat fail­ure of the clas­si­fi­ca­tion sys­tem at many points, in the same way, over sev­eral years. One can’t say such a thing is im­pos­si­ble but I find that ex­tremely un­likely.

Another eas­ily dis­mis­si­ble pos­si­bil­ity is that this is some kind of de­lib­er­ate re­lease of clas­si­fied in­for­ma­tion. Again, there is an en­tire in­fra­struc­ture de­voted to not let­ting this hap­pen. With peo­ples’ jobs, se­cu­rity clear­ances, and per­sonal free­doms on the line. Plus the fact that the peo­ple who tend to work in these jobs take for granted that se­crecy trans­lates to se­cu­rity. Even ac­tual spies would­n’t do it this way — they’re not about re­leas­ing se­crets to the pub­lic, they’re about chan­nel­ing them to the peo­ple they are spy­ing to, quiet-like.

So we’re left with much more plau­si­ble con­clu­sion that they con­sider this to be un­clas­si­fi­able and be­nign. But why would they think that, given what we know about how sen­si­tive they are to any­thing that comes even re­motely close to rep­re­sent­ing in­ter­nal weapon com­po­nents?

The “obvious” an­swer, if my above as­ser­tions are true, is that it must not ac­tu­ally rep­re­sent a ther­monu­clear sec­ondary. What else could it be? It could be some kind of pre-ap­proved “unclassified shape” which is used for di­ag­nos­tics and model ver­i­fi­ca­tion, for ex­am­ple. There are other ex­am­ples of this kind of thing that the labs have used over time. That is en­tirely a pos­si­bil­ity. What would be bizarre about this be­ing the an­swer is that a) “unclassified shapes” gen­er­ally don’t look like ac­tual, plau­si­ble weapon de­signs, and this thing looks “close-enough”; b) it still gives off the ap­pear­ance of a clas­si­fied shape, which as noted, is dan­ger­ous in and of it­self from a po­lit­i­cal stand­point; and c) if the goal is just to show off mod­el­ing ca­pa­bil­i­ties in a very su­per­fi­cial way (this is es­sen­tially an ad­ver­tis­ing logo) they surely could have picked a mil­lion less provoca­tive (from a clas­si­fi­ca­tion stand­point) ex­am­ples.

It’s also pos­si­ble that it is­n’t even meant to be a nu­clear weapon at all. Sure, it looks like a reen­try ve­hi­cle. Yeah… it seems aw­fully nuke-shaped. But there are other things that can look like nukes but at re­ally meant to be some­thing else. Maybe I’m see­ing a “secondary” be­cause I’m primed to see one, by the con­text? It’s… pos­si­ble. Neither spheres-within-sphere nor cylin­ders-within-cylin­ders are in­her­ently re­lated to nu­clear weapons com­po­nents. But when you place them like that, in a reen­try ve­hi­cle, in that or­der… it looks very much like a fus­ing sys­tem, a pri­mary, a sec­ondary… It would be quite sur­pris­ing to me if it was not meant to be rep­re­sen­ta­tive of those things, but some­thing to­tally dif­fer­ent. And, again, the orig­i­nal con­text of that model ap­pears to be very firmly rooted in nu­clear weapons de­vel­op­ment.

Another pos­si­bil­ity is that it is some kind of “deliberate dis­in­for­ma­tion” or “misinformation.” This is the kind of thing that I think peo­ple as­sume the gov­ern­ment labs might do, but in my ex­pe­ri­ence, is pretty un­usual and pretty un­likely. In gen­eral, you have to re­mem­ber that the na­tional lab­o­ra­to­ries are pretty, well, bor­ing, when it comes to clas­si­fied in­for­ma­tion. They want to be bor­ing in this re­spect. They are not do­ing cloak-and-dag­ger stuff on the reg­u­lar. They’re sci­en­tists and en­gi­neers for the most part. These are not James Bond-wannabes. They don’t para­chute be­hind en­emy lines to set up palace coups. They are ex­tremely rule-abid­ing for the most part. There are lots of so­cial and his­tor­i­cal rea­sons for this (again, my book goes into the his­tor­i­cal ones — the anx­i­ety about “nuclear se­crets” al­ways made the Atomic Energy Commission and its suc­ces­sor or­ga­ni­za­tions very anx­ious about be­ing ac­cused of be­ing lax about them).

And be­yond the in­sti­tu­tional cul­ture as­pects, the idea that a bunch of en­gi­neers at Sandia are go­ing to be us­ing a soft­ware pack­age logo to de­lib­er­ate leak out mis­in­for­ma­tion, just wait­ing for some­one to no­tice it, seems a lit­tle un­likely to me on the face of it. I mean, re­ally. What is the “operation” here? Who is meant to be “fooled”? Me? You? The North  Koreans? It does­n’t feel very re­al­is­tic.

And one can add to the above the fact that, at least his­tor­i­cally, the Atomic Energy Commission and its suc­ces­sor or­ga­ni­za­tions have frowned on dis­in­for­ma­tion and mis­in­for­ma­tion for other very prac­ti­cal rea­sons. If you re­lease a lie, you run the risk of some­one notic­ing it is a lie, which can draw more at­ten­tion to the re­al­ity. And even mis­in­for­ma­tion/​in­ac­cu­racy can put “brackets” around the pos­si­bil­i­ties of truth. The goal of these or­ga­ni­za­tions is to leave a to­tal blank in the ar­eas that they don’t want peo­ple to know about, and mis­in­for­ma­tion/​dis­in­for­ma­tion/​in­ac­cu­racy is some­thing other than a to­tal blank.

That’s where I’ve ended up, in think­ing about what this “means” and what pos­si­bly ac­counts for it. But it’s still bizarre that any­one would al­low some­thing that looks so sug­ges­tive, even if it is not ac­cu­rate, to be re­leased as an of­fi­cial prod­uct of a na­tional lab­o­ra­tory. It seems like a bad idea, any­way. And yet — I can’t come up with an ex­pla­na­tion for this that is­n’t one kind of bad idea or an­other. But I think this is the “most plau­si­ble bad idea” of the set.

One last thing. In more re­cent pre­sen­ta­tions on the SIERRA Mechanics frame­work, they changed the di­a­gram some­what:

The res­o­lu­tion is­n’t great, but you can see that the po­ten­tially prob­lem­atic part is much more ob­scured. But it’s still there, so I don’t think that is re­ally an at­tempt to draw at­ten­tion from it, so much as it is an ar­ti­fact of some­what care­less graphic de­sign. In gen­eral, it’s not a great logo by any means — too busy, too com­pli­cated, too much in­for­ma­tion, does not re­pro­duce well at small sizes or low res­o­lu­tions, etc. — but, as dis­cussed, that is not even close to the most po­ten­tially prob­lem­atic as­pect of it!

I saw this and could­n’t re­sist quickly writ­ing some­thing up about it. That’s all I’ve got. If you’ve got thoughts on it, let me know. And if you haven’t al­ready signed up for it, I am much more ac­tive on my other blog, Doomsday Machines, as of late!

I’ve up­dated this post a few times since I first put it up this af­ter­noon, but just stum­bled across some­thing even more help­ful. Here’s an im­age from a 2014 ar­ti­cle about com­pu­ta­tional sci­ence at Sandia that looks aw­fully sim­i­lar to the one above:

Unlike the oth­ers, it comes with a cap­tion: “The mul­ti­ple com­po­nents of a nu­clear weapon body are high­lighted in this in­ten­tion­ally sim­pli­fied mesh. Each part is com­prised of nu­mer­ous sub­com­po­nents, fas­tened to­gether with screws, nuts, bolts, jar-lid-like fit­tings and more.” Which is just to say, it is pretty clearly say­ing that this “thing” is meant to be some kind of rep­re­sen­ta­tion of a nu­clear weapon, al­beit “intentionally sim­pli­fied.” Which does­n’t re­ally solve the mys­tery — if any­thing, it just high­lights why I still find it so odd that this thing got ap­proved for re­leased at all! Not in the sense that it con­tains “secrets” — but in the sense that it is just not the kind of im­age the na­tional labs tend to re­lease.

Someone re­minded me of some­thing I had seen years ago: the British nu­clear pro­gram at Aldermaston, when it has pub­lished on its own com­puter mod­el­ing in the past, used a sort of “bomb mockup” that looks far more de­lib­er­ately “fake” than this Sandia one. I of­fer this up as what I would think is a more  “safe”  ap­proach than some­thing that looks, even su­per­fi­cially, like a “real” sec­ondary de­sign:

This is called the MACE (Modal Analysis Correlation Exercise) as­sem­bly, and was cre­ated by the UK Atomic Weapons Research Establishment in the 1990s to serve as a sort of a Utah Teapot of weapons struc­tural mod­el­ing: a be­nign shape that could be used to test as­pects of the code that would nonethe­less tell you if the code would work for real weapons as­sem­blies.

Anyway, I’m just sur­prised the DOE would re­lease any im­age that gave re­ally any im­plied graph­i­cal struc­ture of a ther­monu­clear sec­ondary, even if it is clearly schematic and meant to be only some­what rep­re­sen­ta­tive. It’s more than they usu­ally al­low!

This en­try was posted

on Wednesday, September 4th, 2024 at 1:21 pm and is filed un­der Redactions.

You can fol­low any re­sponses to this en­try through the RSS 2.0 feed.

You can leave a re­sponse, or track­back from your own site.

Citation: Alex Wellerstein, “Did Sandia use a ther­monu­clear sec­ondary in a prod­uct logo?,” Restricted Data: A Nuclear History Blog, September 4, 2024, ac­cessed September 8, 2024, https://​blog.nu­clear­secrecy.com/​2024/​09/​04/​did-san­dia-use-a-ther­monu­clear-sec­ondary-in-a-prod­uct-logo/.

2M users but no money in the bank. Tough times 😔

Find the post in­ter­est­ing or use­ful?

Share it around and have oth­ers ben­e­fit too!

Update: This post went some­what vi­ral be­yond the Exercism com­mu­nity. Thanks to every­one who’s of­fered wishes of sup­port and to the hun­dreds who have do­nated in re­sponse. I added a lit­tle more con­text and clar­i­fied a few things in a Hacker News com­ment.

Last week we hit the huge mile­stone of two mil­lion users. Within a few hours, we also hit 45 mil­lion ex­er­cise sub­mis­sions.

A day later, I paid the fi­nal pay­roll for me, Erik and Aron, and our bank ac­count re­duced down to the point we can’t af­ford to pay an­other.

I think this sums up Exercism’s story pretty well. Over 1,200 peo­ple per day sign up to Exercism. Tens of thou­sands solve ex­er­cises each day. But we don’t have enough money to con­tinue to work on the plat­form.

We’ve tried a lot of things to change that. We’ve spo­ken to hun­dreds of fun­ders and com­pa­nies, but Exercism is­n’t the right fit for their sup­port. It does­n’t fit a niche that makes sense for them. By serv­ing peo­ple every­where, it seems we don’t serve a nar­row enough de­mo­graphic that we align to fun­ders’ of­ten nar­row mis­sions!

The one area we have had some promis­ing suc­cess is in ad­ver­tis­ing on the site. But the ef­fort it takes to find ad­ver­tis­ers and man­age them, and my gen­eral de­sire not to flood Exercism with ad­verts, has meant that I feel this is­n’t a very sus­tain­able strat­egy.

I think it’s fair to say that at this stage I’ve lost faith in the non­profit busi­ness model work­ing in a way that al­lows Exercism to reach any of its po­ten­tial. Keeping some­thing free for every­one re­lies on ei­ther the user be­ing the prod­uct, or on sig­nif­i­cant do­na­tions, and with­out ei­ther, it’s very hard to grow.

Probably the hard­est thing about the sit­u­a­tion right now, is that we can no longer af­ford to pay Erik, so he’s leav­ing as an em­ployee at the end of this week.

Erik has been an ab­solute crit­i­cal part of Exercism’s growth and suc­cess over the last few years. He’s also been a won­der­ful col­league and friend, and I’ll re­ally miss work­ing along­side him. It goes with­out say­ing that I’m in­cred­i­bly grate­ful to Erik for all his hard work and sup­port. And I know many of you will feel the same (if so, please reach out and tell him!)

Erik’s a die-hard Exercism fan, and he’s go­ing to con­tinue as a se­nior main­tainer of a few tracks, and he’ll hold onto his su­per-ad­min priv­i­leges, but the plethora of hid­den (and of­ten a bit bor­ing) things that he does day-to-day need to get spread across the or­gan­i­sa­tion.

The one key thing we’re en­forc­ing is that every PR in a live Exercism repos­i­tory should get a re­view be­fore it can be merged (with only one ex­cep­tion out­lined be­low). This has gen­er­ally been the case any­way for a long time, but there are places where it’s fallen through the cracks, so we’ve now scripted things to en­sure this is al­ways the case.

To do this, we’ve come up with a new clas­si­fi­ca­tion sys­tem for re­pos, and spe­cific rules for each type:

main­tained: A repo that has mul­ti­ple main­tain­ers. All PRs re­quire re­views from a track main­tainer.

main­tained-soli­tary: A repo that has one main­tainer. A new cross-track-main­tain­ers team will get pinged to re­view all PRs.

un­main­tained: A repo that has no main­tain­ers. The cross-track-main­tain­ers team will get pinged here too.

main­tained-au­tonomous: A repo where all main­tain­ers are also in the cross-track-main­tainer team. This is the ex­cep­tion, where they can merge their own PRs.

wip-track: An un­launched track. As it’s not “live” yet, it does­n’t have re­stric­tions.

We’ve cre­ated two new GitHub teams that en­force this.

@exercism/guardians: A team to check the safety of PRs to tool­ing repos­i­to­ries (test run­ners, an­a­lyz­ers, etc). Made up of a few long­stand­ing poly­glots.

@exercism/cross-track-maintainers: A new team made up of long­stand­ing poly­glots who are ac­tive on the site on a day-to-day ba­sis, and who have the same level of re­view­ing-pedan­ti­cism that I do (ie they’re not more strict or more flex­i­ble than me). This is im­por­tant, as I want a con­sis­tent, re­spon­sive ex­pe­ri­ence from this team.

Both teams are in­vite-only. I’ll re­view them spo­rad­i­cally.

We’ve also in­vited new main­tain­ers and “pruned” a lot of in­ac­tive main­tain­ers as part of this. To those peo­ple who have been re­moved - thank you for all you’ve done, and please know you’re very wel­come back if you find the time/​de­sire to con­tribute in earnest to Exercism again!

So this has all been a bit gloom and doom so far. Things don’t al­ways go as you hope in life, but you have to make lemon­ade from the lemons!

Right now, we have about 800 monthly donors and about $7,500 in monthly do­na­tions. That cov­ers our server costs pretty much ex­actly. So if you’re do­nat­ing right now, thank you. You are lit­er­ally keep­ing our servers on. Our donor base is gen­er­ally quite sta­ble, so I’m not too wor­ried about Exercism’s ex­is­ten­tial prospects.

We also have an amaz­ing com­mu­nity, main­tainer team, and group of men­tors who keep adding new ex­er­cises (and tracks!), help­ing stu­dents, and nu­mer­ous other things. Exercism has prob­a­bly never been health­ier as an or­gan­i­sa­tion. It’s grow­ing faster than ever, more peo­ple are us­ing it than ever, and I think the prod­uct and ed­u­ca­tional ex­pe­ri­ence is bet­ter than ever. So I’m still deeply ded­i­cated to grow­ing and nur­tur­ing Exercism.

For the last few months, I’ve been work­ing on a new ed­u­ca­tional prod­uct teach­ing cod­ing fun­da­men­tals that I’m go­ing to launch in 2025. 96% of peo­ple who try to learn cod­ing give up - which I find un­ac­cept­able, so I’m aim­ing to change that. My plan is to give be­gin­ners a rock-solid base, then fun­nel them into Exercism. I’m cre­at­ing a new for-profit com­pany for the new com­pany, and go­ing to use pro­ceeds from that to keep Exercism grow­ing. I’ve raised a lit­tle in­vest­ment for this, which means I can con­tinue to pay Aron’s salary, so he’ll be stay­ing around, work­ing on that with me, and tweak­ing Exercism as needed.

I’m also plan­ning (probably 90% cer­tain) of run­ning a ded­i­cated learn-to-code course from Jan-March 2025, where I can test out some of what we’ve been build­ing, and I can get my hands dirty work­ing with the stu­dents who ex­ist­ing plat­forms don’t serve. So keep out for an an­nounce­ment about this soon.

I’m ex­plor­ing launch­ing a ba­sic ver­sion of Exercism Teams, as a way of mak­ing some ex­tra rev­enue. There’s a fo­rum post here where you can leave thoughts. I’d re­ally ap­pre­ci­ate any you have!

But first, I need a breather!

I’ll be tak­ing the next two weeks off, un­plug­ging and re­cov­er­ing a lit­tle.

Thanks for all your sup­port - emo­tional and fi­nan­cial. Exercism’s com­mu­nity is phe­nom­e­nal and I’m deeply grate­ful to every­one in­volved in the pro­ject.

More from our blog

Thank you every­one!

A re­flec­tion on #12in23 from some­one who com­pleted it

By WitherOrNot

Edited by May, Lyssa, & ech­nobas

In our on­go­ing work to by­pass Windows li­cens­ing checks, we oc­ca­sion­ally stum­ble upon bugs that we choose to keep se­cret. This de­ci­sion al­lows us to pre­serve po­ten­tial fu­ture ac­ti­va­tion meth­ods by avoid­ing bug fixes, while also giv­ing us valu­able tools for test­ing or de­vel­op­ing new meth­ods.

One such dis­cov­ery, which we’ve named “Keyhole”, turned out to be a highly ef­fec­tive DRM by­pass. It gave users the abil­ity to li­cense any Microsoft Store app or any mod­ern Windows edi­tion with ease.

Following the dis­clo­sure of CVE-2024-38184 by Cisco TALOS, we have de­cided to share our find­ings on Keyhole, which we in­de­pen­dently un­cov­ered around the same time it was re­ported to Microsoft.

To un­der­stand this ex­ploit, we must first un­der­stand CLiP, the Client Licensing Platform. This sys­tem was in­tro­duced with Windows 10, pri­mar­ily as a way to im­ple­ment DRM for Microsoft Store apps, and in­te­grated with Windows ac­ti­va­tion, al­low­ing users to buy dig­i­tal li­censes for Windows on the Microsoft Store.

CLiP is com­prised of a few dif­fer­ent main bi­na­ries within Windows:

* clipc.dll - API used by ap­pli­ca­tions to in­ter­act with CLiP

* clip­winrt.dll - Similar to clipc.dll but for UWP ap­pli­ca­tions uti­liz­ing Windows Runtime.

Whenever a CLiP-licensed app is in­stalled, a signed XML file con­tain­ing the li­cense in­for­ma­tion is sent to clipsvc.dll; once the XML sig­na­ture is ver­i­fied, the XML data is stored in ClipSVC’s “token store” at %PROGRAMDATA%\Microsoft\Windows\ClipSVC\tokens.dat.

The signed li­cense block is then ex­tracted from the SPLicenseBlock tag and sent to clipsp.sys for ver­i­fi­ca­tion. After ver­i­fi­ca­tion, the li­cense block is de­posited in the CLiP li­cense store at HKLM\SYSTEM\CurrentControlSet\Control\{7746D80F-97E0-4E26-9543-26B41FC22F79}. From there, clipsp.sys can then re-val­i­date the li­cense in the fu­ture if an app re­quests it us­ing the CLiP API.

As de­signed, this sys­tem forms a rather strong chain-of-trust that trans­mits only signed data from user­mode ap­pli­ca­tions all the way to the ker­nel, mak­ing it seem­ingly dif­fi­cult to tam­per with. As we will see soon, how­ever, this is not at all the case.

So far, one bi­nary failed to re­ceive any men­tion: clipup.exe. This is be­cause it is­n’t no­table when talk­ing about Keyhole it­self. However, it holds the key to mess­ing with CLiP:

Yes, lit­er­ally. A valid ECDSA key to sign XML li­censes is stored in un­ob­fus­cated form, al­low­ing any­one to very eas­ily sign or re­sign XML li­censes. This key is nor­mally meant to sign tem­po­rary li­censes sent to the Microsoft store to get dig­i­tal li­censes, but ClipSvc will hap­pily ac­cept it for app li­censes as well.

This al­lows us to by­pass ClipSvc’s gate­keep­ing and ef­fec­tively send any li­cense blocks we want straight to ClipSp. With this, we en­tirely by­pass the user­mode level of the chain-of-trust, and now all that’s left is to try and trick ClipSp.

ClipSp, from our analy­sis, is not a very well-writ­ten dri­ver. It’s full of copy-pasted code (from where will be shown soon), and seems to be rife with odd choices and com­pro­mises. In other words, it’s a per­fect en­vi­ron­ment for some­one look­ing for a by­pass. There’s only one big is­sue: most of the in­ter­est­ing dri­ver code is hid­den us­ing Microsoft’s pro­pri­etary ob­fus­ca­tor, known as Warbird. In or­der to find and un­der­stand it, we need to “unpack” it, a.k.a. un­do­ing the ob­fus­ca­tion. Luckily, this is rather straight­for­ward thanks to some sym­bols for clipsp.sys that were avail­able on Microsoft’s servers.

Similar to how Warbird works in user-mode pro­grams, ClipSp wraps any calls to ob­fus­cated code with an de­cryp­tion and en­cryp­tion func­tion, as shown be­low:

So, if we can man­u­ally run these de­cryp­tion func­tions, we could ac­cess all of the hid­den code. Luckily, this is quite sim­ple to do based on a method by KiFilterFiberContext, and with it, we are now able to fi­nally find some bugs.

License blocks, men­tioned pre­vi­ously, are what ac­tu­ally hold the im­por­tant li­cense in­for­ma­tion in CLiP. Their for­mat is well-doc­u­mented and can store many kinds of data, so we fig­ured they were a good place to start look­ing for bugs.

License blocks hold their data in a tag-length-value (TLV) for­mat, where sev­eral smaller blocks are stored to­gether with each hold­ing val­ues for their data type, the length of their data, and the data it­self. For ex­am­ple, the TLV block high­lighted be­low has a type of 0xC9 (License Information), a length of 0xA (10 bytes), and 10 bytes of data.

At the very end of a li­cense block, there will al­ways be a sig­na­ture block, with a type of 0xCC. This block holds the sig­na­ture of all the data be­fore it, as well as in­di­cat­ing which key it was signed with. And of course, since it sits af­ter all the data be­ing signed, there’s no way to al­ter any of it… right?

In the mid­dle of ex­per­i­ment­ing with this data for­mat, one of our mem­bers, May, had a very sim­ple ques­tion. If the sig­na­ture block signs all the data be­fore it, what hap­pens to the data put af­ter it?

Above, you can see a li­cense block for Minecraft Bedrock edi­tion with some new data placed af­ter it (highlighted), con­tain­ing blocks copied from a Windows li­cense. What hap­pens if we try to in­stall such a li­cense?

As it turns out, data af­ter the sig­na­ture block isnt checked at all… and it can even over­ride data that came be­fore it. Whenever two blocks of the same type are stored to­gether, the last one over­rides all the oth­ers be­fore it. So, if we want to change any li­cense data, we can just make a block for it and put it af­ter the sig­na­ture block!

This method lets us make li­censes for any­thing sold on the Microsoft Store, in­clud­ing Windows, from any other Microsoft Store li­cense. And since there are so many free apps with li­censes, we now had the abil­ity to make as many as we wanted for what­ever we wanted. This bug es­sen­tially punched a hole straight through CLiP’s DRM, so we de­cided to name it “Keyhole”.

There is only one catch: li­censes that are bound to a spe­cific de­vice, known as “device-locked” li­censes, can­not be made from de­vice-un­locked li­censes. Since Windows dig­i­tal li­censes are de­vice-locked, this meant that we needed to make them from de­vice-locked app li­censes. Luckily, many apps, in­clud­ing games like Roblox fit this cri­te­ria.

The steps to make any Windows li­cense you want were now dead sim­ple. First, in­stall an app with a de­vice-locked li­cense, like Roblox.

Then, us­ing a HTTPS traf­fic cap­ture tool like Fiddler, in­ter­cept the li­cense that comes from https://​li­cens­ing.mp.mi­crosoft.com/​v7.0/​li­censes/​con­tent.

Decode the li­cense, then ex­tract its li­cense block.

Now, add what­ever new data you need to make a new li­cense.

Then, we just pack­age our li­cense block into a new XML file, sign the XML, and copy it into the folder C:\ProgramData\Microsoft\Windows\ClipSVC\Install\Migration.

Finally, we get ClipSvc to in­stall our li­cense, ei­ther by restart­ing it, or with the com­mand clipup -p.

When we check our ac­ti­va­tion sta­tus, Windows is now per­ma­nently ac­ti­vated.

With this, we were able to do things that were pre­vi­ously im­pos­si­ble, like ac­ti­vat­ing Enterprise LTSC with a dig­i­tal li­cense, or even ac­ti­vat­ing a le­git­i­mate KMS server with a generic key:

From here, it’s pretty easy to see that this sim­ple bug com­pletely an­ni­hi­lates CLiP’s DRM sys­tem.

Having found this bug, we were quite happy that CLiP was now ef­fec­tively dead. This hap­pi­ness did­n’t last very long, though, as we re­cently found a vul­ner­a­bil­ity re­port from Cisco TALOS that re­ported this ex­act bug. It was re­ported to Microsoft on April 8, right around when we first found it.

This raises a ques­tion though: why was a DRM bug re­ported as a se­cu­rity vul­ner­a­bil­ity? At first, CLiP li­censes don’t seem to have any­thing to do with ex­ploita­tion, which caused us to think the bug had been re­ported for no rea­son other than to fix Microsoft’s DRM. However, Keyhole can be used as an en­try point for more se­ri­ous bugs in ClipSp, which prompted TALOS to make it part of their dis­clo­sure.

As for the fix it­self, it’s rather straight­for­ward. As shown be­low, the cur­rent li­cense block parser code im­me­di­ately ex­its af­ter en­coun­ter­ing a sig­na­ture block. This pre­vents it from pro­cess­ing blocks af­ter the sig­na­ture, com­pletely patch­ing Keyhole.

After mourn­ing the loss of our beloved ex­ploit, we de­cided that it would only be fair to pub­li­cize our own dis­cov­er­ies on CLiP. So, we’ve re­leased the code to gen­er­ate Keyhole li­censes and our col­lec­tion of CLiP bi­na­ries with sym­bols for eas­ier analy­sis. We in­vite you to go forth and dis­cover more funny things in CLiP! (and re­port them to us in­stead of MS)

I men­tioned that ClipSp’s buggy code was copy-pasted, but from where? Well, the “SP” part just hap­pens to ref­er­ence a cer­tain Microsoft game con­sole: the Xbox One!

The Xbox One con­tains a chip known as the SP, or “secure proces­sor”, based on the TPMs in mod­ern PCs. The main job of the SP is to en­force code sign­ing, but it also han­dles li­cense ver­i­fi­ca­tion. During our re­search on Keyhole, we found many as­so­ci­a­tions be­tween CLiP and the Xbox One, and be­gan won­der­ing how they were ac­tu­ally re­lated. While look­ing through some leaked source code, we stum­bled upon this:

Well, this looks oddly fa­mil­iar…

And there’s the same bug that’s in CLiP, but in Xbox code. In fact, we weren’t too sur­prised to find this, as we found that al­most all of CLiP, from the XML for­mat of the li­censes to the TLV-based li­cense blocks, is mostly copy-pasted straight from the Xbox One’s DRM sys­tem.

So, to those with a con­sole that’s been col­lat­er­ally dam­aged, I won­der what hap­pens if you mess with those funny-look­ing XML files in S:\clip ;)

The re­search cov­ered in this blog­post was made pos­si­ble by the fol­low­ing peo­ple/​groups: