On Saturday 17 October 2026, a researcher going by Wayne ran a scan over a corpus of certificate-authority certificates. At 16:27 UTC it flagged “a break in the EC keys” (Mozilla bug 2083449, comment 2). The keys belonged to eMudhra, an Indian certificate authority whose root sits in the trust lists of Chrome, Firefox, Safari and Windows.

Quick note: this piece was drafted with help from an AI writing tool. Every number in it was checked against the original sources, which are linked inline.

Eight intermediate certificates, each meant to carry a random 384-bit private key. The actual keys were 156, 230, 115, 56, 155, 4, 66 and 237 (Scott Helme).

Four. The number after three.

The keys were created on 30 April 2025 and sat in the browser trust stores for about 18 months, through two independent audit cycles, before anyone noticed (eMudhra). This week the company filed its full incident report, and the explanation is more ordinary, and more instructive, than the headlines. This piece covers why a small private key is catastrophic, what the script actually did, and why the usual safety nets never fired.

Why a small number is a broken lock

A certificate authority (CA) vouches for websites. The padlock on your bank’s site is there because a CA signed a certificate saying “yes, this really is the bank”, and your browser trusts that CA’s signature.

The signature comes from a private key, here an elliptic-curve key on the P-384 curve. There is a fixed starting point G on the curve. The private key is a number d. The public key, visible to everyone in the certificate, is d multiplied by G (source).

Going forwards is easy. Going backwards, from the public point to d, is hopeless, but only because d is supposed to be a random number with about 10 to the power 115 possibilities.

If d is 4, you try 1, 2, 3, 4 and you are done.

Think of a bank locker whose combination is supposed to be 115 digits long, and the locksmith set it to a single digit. A bored teenager with 255 guesses opens every locker in the building. That is what happened: all eight keys were recovered from public certificates in under a second (Helme). Mozilla’s engineers recovered them independently that evening, without knowing how Wayne had done it (bug 2083449, comment 0).

With the private key of an intermediate CA, you can sign a certificate for any domain on earth and clients that trust the chain will believe you. Mozilla put it plainly: “These keys could allow attackers to issue fraudulent HTTPS certificates for websites they do not control” (Mozilla).

What the script actually did

This is the part that only appeared this week, in comment 82 of the Mozilla bug, eMudhra’s full incident report (source).

The keys were generated inside Utimaco hardware security modules (HSMs, locked boxes built so a private key never leaves them). So far, textbook. eMudhra says the devices “are not at fault”, and nobody has disputed that.

The problem was what happened next. eMudhra had customers who needed certificates issued from hardware physically in the United States and Europe. It ordered HSMs for the US facility in April 2025, from a different vendor, Crypto4A, and delivery slipped because of “global supply-chain constraints”. A browser policy change taking effect on 15 June 2025 meant the new keys had to exist before the end of May.

So the keys were generated in India on the Utimaco boxes, to be moved once the new boxes arrived. Vendor tooling does not cover moving keys between two HSM brands, so the team wrote a custom Python script to wrap the key (encrypt it for export), unwrap it, and re-import it. FIPS-approved mode, the locked-down setting on the HSM, was switched off for the wrap step as an “approved deviation”.

The script had a bug on the read-back. A P-384 private key is 48 bytes. The import code “truncated the private value to its leading byte”. The HSM then faithfully rebuilt a key object from that single byte, and the public key derived from it went into the certificate signing request that the root signed.

That is the whole mechanism. 47 of 48 bytes dropped on the floor. The surviving byte can only be a number from 0 to 255, which is why every one of the eight keys lands in that range (bug 2083449, comment 5).

Two sets of keys now sat on the device with near-identical labels, the strong originals and the truncated copies. The PKCS#11 interface that HSMs speak does not even require labels to be unique (comment 99). The weak set got picked. Nobody ran a key-strength check, because, per the report, no such check existed in the ceremony.

ps: there was a warning sign. Between 29 May and 6 June 2025, a revocation list came out signed with the wrong key. It got a “symptom-level fix” and nobody dug further. Keep that in mind for the caveats.

Why the internet’s immune system missed it

You would think somebody scans public CA certificates for keys this bad. Google does, with a tool called paranoid_crypto, and after this incident it re-ran the tool across the public databases and found no other weak CA keys (bug 2083449, comment 50). Two gaps, by Chrome’s own account:

• The standard certificate linters CAs and root programs run had no small-scalar check for elliptic-curve keys.
• Chrome’s scanning pipeline worked off Certificate Transparency logs (public ledgers of issued certificates), and these intermediates were dormant. Seven of the eight were never used in production; the one that was had issued zero certificates (eMudhra). A certificate that never signs anything never appears in the logs that get scanned.

How fast the response was, in minutes

Once the report landed, the numbers are legit impressive.

• 18:05 UTC, 17 October: Wayne emails Apple, Chrome, Microsoft, Mozilla and eMudhra (comment 2).
• 19:45 UTC: Chrome ships a blocklist update that stops trusting the eight public keys, without users updating or restarting. 1 hour 40 minutes (Google).
• 20:06 UTC: Mozilla receives the report. 22:59 UTC: its blocklist has finished reaching Firefox users. Under 3 hours (Mozilla).
• 09:24 to 09:38 UTC, 18 October: eMudhra revokes all eight certificates (comment 82).
• 22 October: eMudhra’s board decides to exit the public TLS certificate business entirely. It had been about 1% of the company’s revenue (The Register).

Roughly 30,800 certificates under the affected hierarchy are being migrated to other providers, and Apple stops trusting eMudhra’s remaining root on 30 November 2026 (eMudhra).

The part that should bother you

Browsers were never really the exposure. Chrome refuses certificates missing from the public transparency logs, and Google confirmed no certificate chaining to these intermediates was ever logged before the block (Google).

Everything else on your machine is a different story. Helme set up a local server with a forged certificate for api.stripe.com, signed with a recovered key, and pointed common tools at it. curl, with default settings, printed “SSL certificate verify ok”. Python completed the handshake. Node reported “authorized: true”. On every Linux and macOS machine he tested (Helme).

Those tools trust a file of root certificates on disk, do not check revocation lists by default, and do not check transparency logs. A CI pipeline, a server-to-server API call, a curl-pipe-to-bash installer, an IoT device with a frozen certificate bundle: all would have accepted a forged certificate until their trust bundle got updated.

And the window was 17 months. ik that sounds alarming. Read the next section before deciding how alarmed to be.

Where this story gets weaker

• There is no evidence anyone exploited the keys. eMudhra says it has found none, and Google’s transparency logs show no certificates from these intermediates before the block. Absence of evidence in CT only covers clients that enforce CT, tho.
• The “one byte” explanation is eMudhra’s own account, filed late. The report was promised for 9 November and landed around 11 November. An independent review by KPMG is not due until 4 December 2026, and people on the bug thread are still asking why keys were exported at all rather than regenerated on the new hardware (comments 88 to 97).
• The May 2025 wrong-key signing of a revocation list was a chance to catch this a year and a half early. The report admits it. Uncomfortable reading for anyone who has ever closed a ticket with a symptom fix.
• Nobody broke P-384 and nobody breached an HSM. The failure was a script between two boxes, written under a deadline because a shipment was late.

Do this today

1. If you run anything that makes TLS connections outside a browser (a server, a CI runner, a Raspberry Pi in a cupboard), update its OS certificate bundle. Cost: five minutes.
2. If you generate keys in a ceremony, add one test: check the private value you are about to publish is not laughably small. Google’s paranoid_crypto is open source and does this. Cost: an afternoon.

The locker combination was supposed to be 115 digits long. Somebody wrote down one digit, two auditors checked the lock was installed, and for 18 months it opened to the number 4.

The interesting part is not that a model did maths. It is what the run looked like from the inside: it dug up an old lemma that a PhD student who spent years on this problem had never heard of, wrote a complete proof on day three, and when told to keep going, tightened its own answer twice.

In 2008, Scott Aaronson put a conjecture on a slide at a workshop in Banff. In 2009 he and Andris Ambainis wrote it up properly. For 18 years grad students built research programmes around it, the best general bounds stayed exponentially bad, and a celebrated 2019 proof attempt was withdrawn (paper, Aaronson’s post).

Quick note: this piece was drafted with help from an AI writing tool. Every number in it was checked against the original sources, which are linked inline.

On 6 November 2026 a startup called Physical Superintelligence announced that instances of a non-public Anthropic model, running inside the company’s own research harness, had proved it. The first complete proof was written down during the third day of the run. A 60-page paper and a machine-checked Lean proof (Lean is software that refuses to accept a proof unless every step is formally justified) went up the same day (PSI).

Two days later Aaronson blogged: “I haven’t yet understood the proof, although I hope to.”

The conjecture has his name on it. :’)

Most coverage stopped at “AI solves 18-year-old quantum problem”, and a fair amount of it got the meaning backwards. This piece explains what the conjecture says in plain words, walks through the run as the paper itself reports it, and lists what the result does not mean.

What the conjecture says, without the symbols

Picture a wedding with a guest list of a million names, and a yes-or-no verdict: did it go well?

A quantum algorithm is a planner who peeks at only T names, in a strange superposed way, and outputs a probability that the wedding was good. A 1998 result by Beals and colleagues says that probability is always a polynomial (a sum of simple products of the input bits) of degree at most 2T, with values between 0 and 1 (paper, section 1.3).

The conjecture says: if that verdict genuinely varies from guest list to guest list, at least one single name must sway it by a noticeable amount. Not a tiny amount that shrinks exponentially as T grows. At least 1 over some power of the degree.

Why that matters: a boring classical planner can then ask about that one influential name, fix it, find the next most influential name, and repeat. The paper works out that this planner needs at most (4T) to the power 8 questions, times some factors for the allowed error, to match the quantum planner on most guest lists (paper, section 1.3).

Translation: for yes-or-no questions about random, structureless inputs, quantum computers cannot be more than polynomially faster than classical ones. Exponential speedups need structure in the input. Hold that word “structure”, it comes back at the end.

Why it took 18 years

People kept proving pieces of it.

• It was known for polynomials that only ever output exactly 0 or 1. Real quantum algorithms output probabilities in between, so that did not settle it.
• For general bounded polynomials, the best known bounds decayed like e to the power 4d in the degree d. Exponential, when the conjecture asks for polynomial (paper, section 1.4).
• Special classes fell one by one, most recently in August 2026, when a Stanford group proved it for quantum algorithms that ask their questions in a fixed number of parallel rounds (source).
• A 2019 attempt that Aaronson blogged about with excitement turned out to have a fatal flaw and was withdrawn.

Aaronson also wrote that he was surprised the problem was missing from OpenAI’s recent dump of AI-solved open problems. Surely they tried it.

What happened inside the run

This part is in Appendix A of the paper, and the press skipped it.

Before any new statement was proposed, model instances went to the literature and pulled out two old tools: David Reimer’s Butterfly Lemma, and a dual inequality by Kahn, Saks and Smyth. They set themselves the goal of proving a fractional-certificate version of those inequalities. That starting point was the move (paper, Appendix A).

How non-obvious was it? In the comments under Aaronson’s post, a PhD student who had spent a large fraction of their doctorate on this exact conjecture said they knew the overall plan the proof follows but had never come across either lemma. Guy Blanc, one of the Stanford authors, doubted he would have found this proof even knowing every relevant result (source, comments 2 and 11).

The paper then prints a small table of its seven main statements with two columns: the order each was first proposed, and the order each was actually proved. They do not match. The statement proposed first was proved third. The one proposed fifth was proved first. It reads like a notebook of a mind guessing the shape of the argument before it could fill in the pieces.

The first complete proof, on day three, was weaker than the final one: exponent 22 where the final paper gets 7. Then the instances were asked to push on open problems using the intermediate results. They went back and polished their own lemmas instead, bringing the exponent to 11 and then to 7. Each version was checked in Lean before the next.

So it was not “prove it and stop”. It was prove it, get told to keep going, improve it twice. ik that sounds like a small detail. It is the detail.

The human in the loop, David Turturean, scoped the problem, built and ran the harness, prompted a model instance to write a first draft, and reviewed and edited it. The paper’s AI disclosure says the mathematical statements were produced by AI models (paper, page 2).

How we know it is not nonsense

Paranoid checking.

1. The Lean library has 84 modules and 648 theorems, with zero “sorry” placeholders (a sorry is Lean’s way of saying “trust me on this one”) (repo).
2. The whole thing was replayed through Lean’s own kernel, then through two independent reimplementations of the checker, lean4lean and nanoda.
3. As a sanity test, the comparator was fed one correct small solution and four deliberately wrong ones. It accepted the one and rejected the four.

Aaronson says he believes the proof for exactly two reasons: the Lean certificate, and that human experts have already gone through it and written an exposition (exposition, posted 8 November by Blanc, Docter, Strassle and Tan).

What it does not mean

Within a day, a well-known machine learning professor told his 137,000 followers that the proof meant the dream of quantum supremacy was dead. He later posted a partial correction. Aaronson added a “for dummies” section to his post because of takes like this (source).

Here is the honest version.

• It rules out one specific kind of quantum speedup: superpolynomial speedups for yes-or-no questions about random, structureless inputs. Most researchers already believed this kind did not exist.
• It has zero effect on Shor’s algorithm, because factoring feeds the quantum computer a highly structured, periodic input. Structure. Told you it would come back.
• It has zero effect on simulating molecules and materials, the thing most people actually want quantum computers for.
• Even for random inputs, if you switch from yes-or-no questions to search problems, a 2022 result by Yamakawa and Zhandry already showed exponential quantum speedups are possible.

It is like telling a chai stall it cannot beat a kettle at boiling plain water. Fine. Nobody goes there for plain water. The masala is the structure.

Where this gets weaker

- Lean checked the formal statement. Whether it faithfully matches the printed conjecture is a human job, and the repo says so itself. The 60-page paper is not machine-checked. Nothing is peer reviewed yet.

- The model is non-public and the harness is proprietary. No compute, cost, or instance count has been published. Aaronson writes that he does not know how much credit belongs to the harness versus the model. Neither do you.

- The bound is not tight. The exponent 7 and the tiny constant in front of it are what the argument gave, not what is true. The exposition authors got even weaker exponents because they did not optimise parameters.

- It stood on human shoulders, recent ones. The plan comes from a 2023 Lovett-Zhang paper, a crucial lemma from a 2026 Agarwal and Ben-David paper. Aaronson and Blanc both think humans would have finished it within some years. The machine’s edge, per the people closest to it, was knowing the entire literature at once.

- Another group already claims a 5-page proof built on one of the new inequalities. If it holds up, the 60 pages were a first draft.

The short version

A problem that sat on a conference slide in 2008 got a complete, machine-checked proof on day three of a run, then got improved twice because someone typed “keep going”.

If you want to actually understand it, do this today: read the four “for dummies” bullets at the top of Aaronson’s post, then the first two pages of the Stanford exposition. Twenty minutes, and you will know more about what quantum computers cannot do than most people posting about it, frr.

Last week Google and a handful of partners pulled the plug on a botnet that lived inside more than 1.3 million Android TV set-top boxes. Not boxes that got infected later by some dodgy app. Boxes that left the factory with the backdoor already sitting in the firmware (source).

Quick note: this piece was drafted with help from an AI writing tool. Every number in it was checked against the original sources, which are linked inline.

The twist is who put it there. Google says, “with high confidence”, that the backdoor was built, deployed and operated by Videostrong Technology Co., the Shenzhen company that designed and manufactured the boxes. Then Videostrong sold access to those boxes to other criminals, who loaded their own money-making modules on top.

The manufacturer was the malware vendor.

Most coverage stopped at “1.3 million boxes, company banned”. The actual report has stranger stuff in it: a box that kept running three different proxy networks at once, malware downloads served as GitHub releases, and a note that the same backdoor turned up inside karaoke machines and telehealth devices. This piece walks through how the thing worked, what it was doing with your internet, and why “just uninstall it” did nothing.

What a TV box was doing at 2 a.m.

The main product being sold was not your data. It was your IP address.

A residential proxy (a service that routes someone else’s web traffic through a real home connection so it looks like a normal person browsing) is worth money because websites trust home IPs far more than they trust data-centre IPs. Ticket scalpers, ad fraud rings, credential-stuffing crews (people trying leaked passwords on thousands of sites) and scrapers all pay for that trust.

So each infected box was quietly enrolled as an exit node. Partner firm TrendAI counted 3,849,226 distinct home IP addresses showing up as exits between June 3 and October 1, with an average of 182,025 of them available for rent on any given day, peaking at 366,562 (source).

Think of a builder who hands you the keys to your new flat, keeps a master key, and every night sublets your spare room to strangers. Their parcels arrive at your address. Their names go on your doorbell. You just notice the electricity bill is a bit higher.

Google found that a single box could be running as many as three residential-proxy SDKs at the same time, from three different proxy companies. The operators capped each module’s share of the CPU at 70 percent and memory at 50 percent in the config, so the box would still play your shows. Ofc. Can’t have the customer rebooting the golden goose.

How the backdoor actually worked

The report names the core package x.cpe (it shows up as com.oemservice on some builds). Here is the chain, step by step.

1. A small stub ships in the firmware’s system partition with android.uid.system privileges, the same level as Android itself.
2. On boot, the stub checks the /oem/ partition for the real x.cpe package and installs it. If you ever uninstall x.cpe, the stub puts it back on the next reboot.
3. x.cpe sends an encrypted HTTP request with the box’s serial, MAC and firmware version to a bootstrap server, which replies with credentials for an MQTT broker (a lightweight publish-and-subscribe messaging system normally used for IoT sensors).
4. The box opens a persistent MQTT connection and waits for commands: silently install an app, run a shell command, run a script, take a screenshot, probe the home network.
5. Before installing anything, it flips Google Play Protect’s verification setting to -1, switching off the one on-device check that might have complained.
6. A loader called com.abc.nexus receives the module list and starts the money-makers: proxy SDKs, ad-fraud modules, and further backdoors that load yet more modules.

Hold that step 5 detail about Play Protect; it comes back when we get to what you can do.

The silent-install part was not theoretical. TrendAI’s telemetry logged more than 187,000 install commands reaching devices over four months, out of about 2.36 billion control messages captured.

And the payloads themselves? Google writes that “a significant majority” of the module files were hosted as GitHub releases on operator-owned GitHub pages. The botnet’s app store was a free code-hosting site.

How it passed Google’s own tests

Every certified Android TV device has to go through Google’s compatibility and security suite before it can ship with the Play Store and YouTube on it. Videostrong’s boxes passed.

The trick, per Google, was timing. The malicious code was obfuscated and only loaded after the device’s first boot, so the clean image that got tested was not the thing that ran in your living room a day later.

Google says it has now changed its review process and tightened firmware integrity checks on certified Android TV devices. It did not say what changed, and its head of disruption operations declined to say when Google first learned about the botnet (source).

There is a small history lesson in the timeline too. Google says that in late 2024, “possibly as a response to earlier Google enforcement related to BadBox” (a separate pre-installed botnet that hit more than 10 million devices before a March 2025 takedown, per The Register), Videostrong moved the dirty modules out of x.cpe into a separate loader so the core package would look cleaner. Then from August 2026 it started shipping droppers disguised as system apps with names like com.android.system.ntp, which restart the debug daemon as root, remount the system partition, and copy themselves into the privileged-apps folder. They even backdate their own install timestamps to match the other system apps.

That is not an oversight. That is a product roadmap.

Who bought these boxes

TrendAI puts its own count at 1,472,554 infected devices across 206 models in more than 170 countries, with Malaysia, Brazil, Iraq, Mexico and Taiwan at the top. The US, Germany, UK, Australia and Canada each had roughly 26,000 to 42,000.

Synthient, another partner, bought a MECOOL KM9PRO Max box in late 2025 and found the backdoor signed by Skyworth Digital Technology, a listed Chinese company. Its heartbeat message to the broker included the logged-in user’s email address (source). Synthient has published a list of 182 affected model strings on GitHub, with the warning that a model name alone does not confirm a box is compromised.

And it was not only TV boxes. Google says the same backdoor turned up in telehealth devices, karaoke machines and digital signage, because Videostrong is an ODM (a company that designs hardware for other brands to sell under their own name). Whatever ran their firmware, got their backdoor.

Where this story gets weaker

Every number here is a lower bound, and the partners do not agree on them. Google says “more than 1.3 million”. TrendAI counted 1,472,554. Synthient estimates at least 1.3 million with “around half a million actively online”. The gap is about who could see what, and when.

Google’s claim that the takedown cuts off “at least 10 million additional compromised devices” is an assessment, not a count. Those are devices infected through other routes that happened to talk to the same affiliate servers.

Videostrong has not publicly responded, so the attribution rests on Google’s and Synthient’s evidence: signing emails, an open directory with a signed company declaration, and a company domain resolving to the botnet’s admin panel. Strong, but one-sided so far.

And the most honest caveat: the takedown killed the servers, not the implant. TrendAI says owners cannot remove it themselves because it is a system app signed with the manufacturer’s key. Every one of those boxes still has the door built in. Someone just changed the locks on the other end.

What to do about it

1. If you own a cheap no-name Android TV box, check the model against Synthient’s list. If it is there, or if it is a MECOOL or YOKATV branded unit, unplug it. Synthient’s advice is to dispose of it, not reset it. Cost: the price of a box that was cheap for a reason.
2. Open Settings on any Android TV device and confirm Google Play Protect is on. Remember step 5: the backdoor switched it off. If it keeps switching itself off, that is your answer. Cost: two minutes.
3. Put TV boxes, cameras and anything with “smart” in the name on your router’s guest network, away from your laptop and phone. Cost: ten minutes, once.
4. Never install an app that pays you for “sharing unused bandwidth”. Google’s report is blunt that these are how proxy networks grow. Cost: nothing, you were earning pennies anyway.

The builder-with-a-master-key story usually ends with changing the locks. Here the locks were never yours. The box was.

On 3 November, a security researcher named Ozgun Kultekin built the SSH login server (sshd, the thing you connect to when you type “ssh root@server”) about a dozen different ways and threw roughly 17,600 weird login attempts at them. Odd hashes, broken accounts, absurdly long passwords. Every build agreed on every attempt except one combination, which kept saying yes when it should have said no (source).

The yes was this: on Alpine Linux, and any other Linux built on the musl C library, a password of 256 characters is rejected and a password of 257 characters logs you in. To any account that has no password set. Including, on some cloud images, a user who can become root with one command.

frr.

Quick note: this piece was drafted with help from an AI writing tool. Every number in it was checked against the original sources, which are linked inline.

Two days later OpenSSH shipped an emergency release. Within nine hours of the CVE going public, someone was using it to get root on a honeypot. The bug had been there since July 2016. This is how two correct decisions, made four years apart by two projects, added up to a skeleton key, and why a decade of experts walked past it.

What a star means in a password file

Linux stores password hashes (a scrambled fingerprint of your password, not the password itself) in a file called shadow. When an account is not meant to have a password at all, the field holds a single asterisk. Just: *.

That convention is old. BSD was using * for the daemon account in 1980 (source). The logic is simple. The server hashes whatever password you typed and compares the result to the stored field. A real hash is a long string of letters and numbers. A single * can never equal a hash. So a * account can never be logged into with a password. Key-only users and service accounts all get a *.

Hold that thought, because the entire bug is about what else can produce a *.

Decision one: musl, 2012

musl is a small, clean C library used by Alpine, OpenWrt, Buildroot, Yocto and a huge number of Docker images. In August 2012 its author made two changes to crypt(), the function that does the hashing (timeline).

First: the POSIX standard says crypt() should return NULL when it fails. In practice lots of programs forget to check for NULL and crash. So musl’s crypt() returns the string “*” instead. An “unmatchable hash”. It can never equal a real stored hash, so returning it is safe. Sensible.

Second: musl’s SHA-256 and SHA-512 hashing refuses passwords longer than 256 bytes, to stop someone tying up your CPU with a megabyte of password. If the input is too long, it fails. And failure, as of three weeks earlier, means it returns “*”.

So on musl, a 257-character password hashes to the literal string *. Which is exactly what the shadow file says for every account that has no password.

Still not a bug yet, tho. sshd only ran the comparison when the stored field looked like a real hash. A lone * has no salt (the random seasoning mixed into a hash), so sshd skipped it.

Decision two: OpenSSH, 2016

In July 2016 OpenSSH fixed a timing attack, CVE-2016–6210. Attackers could tell whether a username existed by measuring how long the server took to reply, because for accounts with no usable hash sshd skipped the slow hashing step and answered fast.

The fix: when an account has no usable salt, borrow a salt from some other account on the machine, run the hash anyway so the timing matches, and then compare the result to the stored field as usual (timeline). It shipped in OpenSSH 7.3p1.

Read that slowly. Before 2016, a * account never reached the comparison. After 2016, it did. And on musl, with a long enough password, the thing being compared was * against *.

Match. Welcome in.

Think of a hostel watchman with a register. Rooms nobody may enter are marked with a star. His key-scanner prints a star when a key is too long to fit, meaning “error”. For years he skipped scanning keys for starred rooms. Then he was told the skipping let people guess which rooms were empty, so now he scans every key. A too-long key prints a star, the register says star, and he waves you through. Both rules were reasonable. Together they open the door.

Why it took ten years

The conditions have to line up, and on Alpine they line up by default (Alpine advisory):

• sshd built without PAM (the pluggable authentication layer most big distros use). Alpine’s default openssh-server package is built without it.
• Password login enabled. That is OpenSSH’s default.
• At least one account with * in the password field. On Alpine, root ships that way.
• At least one other local account with a real hash, so there is a salt to borrow.

That last point is the sneaky one. A fresh Alpine box is safe. The moment an admin sets a password on any account, every passwordless account on the machine becomes enterable with 257 characters of anything. Alpine’s official cloud images from 3.18.11 to 3.24.3 ship an “alpine” user with a * and passwordless doas (Alpine’s sudo). Safe on first boot. One console password later, an attacker logs in as alpine and is root one command later.

And why did nobody see it? OpenSSH’s test suite runs on OpenBSD and glibc, not on musl. Debian, Ubuntu and Fedora use glibc, whose crypt() behaves differently, and they route passwords through PAM anyway, which never calls crypt() for a * account (source). The bug only existed on the one combination almost nobody tested.

ps: in December 2024 someone on the musl list reported that passwd crashed on a 257-byte password. The limit and the * return came up. Nobody mentioned sshd.

And the detail I can’t get over: on 30 October 2026, an OpenSSH security review fixed a salt-handling edge case in the exact function, four lines above the bug. Four days before it was found.

How fast it moved once someone looked

Kultekin reported it to OpenSSH on 3 November. OpenSSH had a patch back in under an hour. 10.6p2 shipped on 5 November, and Alpine published fixed packages for every release from 3.16 to 3.24 the same minute, including 3.21, which had gone end-of-life four days earlier (source).

In the release announcement, Damien Miller explained why there was no embargo: the project has watched AI agents rediscover bugs within hours of a fix landing, and it now treats long embargoes as something that mainly helps attackers.

He was right to hurry. Previdian, a threat intelligence firm running an Alpine honeypot, saw the first exploitation attempt less than nine hours after the CVE was published. Eight tries from a single IP in Japan, root access confirmed, and the attacker ran id, uname and hostname to look around (source).

The fix itself is 34 lines added and 17 removed across three files. The part that closes the hole is one new rule: if the stored password field is shorter than 4 characters, it is not a hash, so refuse to compare against it at all.

Ten years. Four characters. lmao.

Whose bug is it, actually?

Nobody’s, according to everyone. OpenSSH’s commit message says the root cause is not in OpenSSH, but sshd is well placed to block it. musl’s author posted an advisory saying it is “not a bug in musl just an erroneous use by the caller”, while also noting the * behaviour was already slated to change (source).

Both are correct. That is the uncomfortable part. Every component passed its own review. The failure was a property of the system, and nobody owns the system.

Where this gets weaker

It is a narrower hole than the headline suggests. Only Linux on musl, only OpenSSH built without PAM, only with password login on, only once some account has a real hash, and only for accounts marked *. Locked accounts marked with ! are not affected. Dropbear, the SSH server OpenWrt actually ships by default, is not affected. glibc distros, macOS and the BSDs are not affected.

Root on a default Alpine install is also protected by PermitRootLogin prohibit-password. The realistic path is a key-only or cloud user plus doas or sudo.

And the exploitation evidence is one vendor’s honeypot and eight attempts from one IP. Real, but small so far. Nobody has published a count of exposed hosts.

If you run anything on Alpine

1. Update openssh and then restart sshd. Upgrading the package does not replace the running daemon, which is the mistake Alpine’s advisory calls out first. Cost: five minutes.
2. If you cannot update today, set PasswordAuthentication no, check that your key login works, restart sshd. This closes the hole completely on its own. Cost: five minutes and one careful test before you close your session.
3. Grep /var/log/messages for “Accepted password” on accounts that have no password. If you find one, treat the box as compromised. Cost: an uncomfortable afternoon, but better than the alternative.

Back to that register. Somewhere right now there is still a watchman scanning a too-long key, reading a star, seeing a star, and opening the door. He has been doing it since 2016. He thinks he is being careful.

It is 11:50 at night. Your watch says 9,100. You know exactly what happens next: you walk laps around the bedroom, phone in hand, until the little ring closes and the watch buzzes.

Quick note: this piece was drafted with help from an AI writing tool. Every number in it was checked against the original sources, which are linked inline.

Here is the thing nobody tells you while you are pacing. Those last 900 steps have never been shown to matter. Not in the biggest study of older adults, not in a 15-cohort meta-analysis, not anywhere.

The 10,000 figure did not come from a lab. It came from the name of a pedometer that went on sale in Japan in 1965. legit.

Where the number actually came from

The 2019 JAMA Internal Medicine paper that first put a real curve under this question opens with the origin story. The goal “likely derives from the trade name of a pedometer sold in 1965 by Yamasa Clock and Instrument Company in Japan called Manpo-kei,” which the authors translate as “10,000 steps meter”. (source)

Manpo-kei. Ten thousand step meter. That is the product name. The number was picked before anyone measured anything.

A 2022 Lancet Public Health meta-analysis puts it even more bluntly: the target “is not based on evidence, but instead originates from a marketing campaign in Japan.” (source)

Fitness trackers then adopted it as the default goal, and a round number with a nice ring got treated as a medical threshold for sixty years. Which, ofc, is how most “rules” about the body get made.

What happened when someone finally measured it

In 2019, I-Min Lee and colleagues at Harvard did the obvious experiment that nobody had done at scale. They mailed hip-worn accelerometers (a research-grade step counter) to women in the Women’s Health Study and asked them to wear the device for seven days.

The setup, in plain words:

• 16,741 women, average age 72, range 62 to 101
• seven days of measured steps, between 2011 and 2015
• then followed for an average of 4.3 years, during which 504 of them died

The group averaged about 5,500 steps a day. Only 3.1% of their waking time was spent stepping at 40 steps a minute or faster, which the paper counts as “purposeful” walking. These were not marathoners. They were normal older women going about their day.

The researchers split them into four groups by daily steps and compared death rates after adjusting for age, smoking, diet, alcohol, existing disease and a long list of other things. The medians of the four groups were 2,718, 4,363, 5,905 and 8,442 steps.

Compared with the lowest group, the risk of dying during follow-up was:

• about 41% lower at roughly 4,400 steps
• about 46% lower at roughly 5,900 steps
• about 58% lower at roughly 8,400 steps

Then they drew the full curve instead of four buckets. Death rates kept falling with every extra thousand steps, about 15% per thousand, until approximately 7,500 steps a day. After that, the curve went flat.

Flat. Not “slightly better”. Flat.

Remember that 7,500. For anyone over 60 it is close to the finish line, and for everyone younger it is roughly the starting line.

The bigger study said the same thing, with one twist

One cohort of older American women is a narrow slice of humanity. So in 2022 a group called the Steps for Health Collaborative pooled 15 cohorts from the US, Europe, Japan and Australia: 47,471 adults, 3,013 deaths, a median of 7.1 years of follow-up. (source)

Eight of the 15 studies were unpublished when they were pooled. That matters, because unpublished studies tend to carry the less exciting results, and including them makes the final number harder to inflate.

The result had the same L-shape. Compared with the least active quarter (median 3,553 steps), the most active quarter (median 10,901) had a 53% lower risk of dying during follow-up. The twist is where the curve flattened:

• adults 60 and over: somewhere around 6,000 to 8,000 steps a day
• adults under 60: somewhere around 8,000 to 10,000 steps a day

So for a 35-year-old, 10,000 sits at the top of the plateau. That is the kindest thing you can say about the number. It is a fine place to be, not a line you fall off if you miss it.

And the researchers checked for the opposite problem too. Walking a lot more than the plateau was not linked to any increase in risk. The curve just stops rewarding you.

Why “fast” matters less than you think

Both studies also looked at intensity (how quickly you step, measured as cadence in steps per minute). On its own, faster stepping looked protective. But faster walkers also walk more, so the two are tangled.

Once Lee’s team adjusted for total steps, nearly every intensity measure stopped being significant. The meta-analysis found the same for most of its intensity measures and called the evidence “inconsistent”. Volume did the work. Pace mostly came along for the ride.

Think of it like splitting a restaurant bill four ways. Whoever paid faster did not pay more. The total is what the waiter cares about.

Where this gets weaker

Three honest caveats, because this is observational data, not a trial.

First, nobody was assigned a step count. Women who walked more were also younger, lighter and healthier to begin with. The authors adjusted for that and ran extra checks that dropped the first year of deaths and anyone already ill, and the pattern held. But “adjusted for” is not the same as “ruled out”. Some of the gap is almost certainly people who were already well being able to walk.

Second, the women in the 2019 study were mostly white, mostly well-off, and more active than the national average for their age. The meta-analysis is broader but still drew entirely from high-income countries and was over 70% white. Nobody has drawn this curve for a 40-year-old in Pune yet.

Third, your watch is not their device. The research counters sat on the hip. Most consumer wearables sit on the wrist, and the meta-analysis notes counts between devices can differ by 20% or more. In one comparison cited by Lee’s team, a Fitbit read about 8,100 steps on a day the research device read 7,400. So your 7,500 may be their 6,900, or their 8,200. The plateau is a zone, not a line.

Also: both studies only looked at whether people died. They say nothing about whether 10,000 steps helps you sleep, keeps your knees happy or clears your head after a bad meeting. It might. That is a different question with different data.

What to do about it

1. If you currently do under 4,000 steps, this is the one group with a huge, cheap win. In Lee’s data the biggest drop in risk happened between roughly 2,700 and 4,400 steps. That is one 15-minute walk. Cost: 15 minutes.
2. If you are over 60, treat 7,000 to 8,000 as the target and stop feeling guilty about 10,000. Costs you: nothing. You get your evenings back.
3. If you are under 60, aim at 8,000 and let anything above it be a bonus, not a debt. Cost: resetting the goal in your watch app, about 40 seconds.
4. Stop paying for pace. Walk at whatever speed you will actually keep doing. Cost: zero, and it probably makes the habit stick longer.

Back to 11:50 pm and the 900 missing steps. Both papers say the same thing about those laps round the bedroom: the curve had already gone flat somewhere around step 7,500. The watch is counting. The data stopped counting a while ago.

ps: a Japanese clock company picked the number because it sounded good. You are allowed to pick yours because the evidence does.

You know that one gym friend. Six meals a day, an alarm every three hours, a steel tiffin with exactly 30g of protein inside. Ask why and you get the same line every time: “bro, the body can only absorb 30g at once. The rest is wasted.”

Quick note: this piece was drafted with help from an AI writing tool. Every number in it was checked against the original papers, which are linked inline.

In December 2023, a team at Maastricht University decided to actually test that. They gave young men either nothing, 25g, or 100g of protein in one shake after a full-body workout, then followed where that protein went for 12 hours.

The 100g group never hit a ceiling. Their muscles kept building for the entire 12 hours, and the response still hadn’t come back down when the measurements stopped.

So where did “30g max” come from? From a much smaller study that watched for a much shorter time. ofc.

First, “absorb” is the wrong word

Your gut absorbs almost all of the protein you eat. 25g, 60g, 100g, it gets broken down into amino acids (the small building blocks protein is made of) and pulled into your blood. It doesn’t sit in your intestine waiting for a token number.

What the myth really means is “used for building muscle”. That’s a different question.

The thing gym people care about is muscle protein synthesis (your muscle making new protein to repair and grow). Every study in this article measures that.

Hold onto that distinction. The original number was about synthesis, not absorption, and the distinction got lost somewhere between the paper and your friend’s Instagram feed.

Where the 30g number came from

2009, McMaster University. Daniel Moore and his colleagues gave six young men 0, 5, 10, 20 or 40g of egg protein after a leg workout, then measured muscle building for four hours.

Synthesis went up until 20g and then flattened. 40g didn’t add much for the muscle. More of the extra protein got oxidised (burned as fuel instead of being built into tissue). (source)

That’s a real result. It’s also:

• six people
• a workout that trained only the legs
• a four-hour window
• one type of protein

A 2014 study with whey found something similar, and the internet compressed “20g, in young men, after leg day, measured for four hours” into “the body can only use 30g. Ever.” The number drifts between 20, 25 and 30 depending on which fitness page you read, which tells you nobody is reading the paper.

The first crack: train more muscle, use more protein

In 2016 a group at the University of Stirling changed one thing. Instead of leg day, trained young men did a whole-body workout. Then they drank either 20g or 40g of whey.

This time 40g won. Muscle protein synthesis came out roughly 20% higher than with 20g. (source)

Which kind of makes sense? If you only trained your legs, your back and chest weren’t asking for anything. Work more muscle, and more muscle shows up hungry.

Then someone tried 100g

Back to Maastricht. The study is Trommelen and colleagues, published in Cell Reports Medicine. Here’s what they did, in plain words:

• 36 healthy young men, 12 per group
• one hour of full-body lifting: leg press, leg extension, lat pulldown, chest press
• then one shake with 0g, 25g or 100g of milk protein
• blood and muscle samples for the next 12 hours

And the protein itself was traceable. To make it, the researchers infused a dairy cow with tagged amino acids for four days, so the protein in her milk carried a marker they could follow through the human body. Science is unhinged sometimes, legit.

What they found:

• Muscle building after 100g was about 20% higher than after 25g in the first four hours, and about 40% higher from hour four to hour twelve.
• The 100g response hadn’t returned to baseline by hour twelve.
• Very little was “wasted”. The authors estimate less than 15% of the extra protein was oxidised. Over 85% went into building protein somewhere in the body.
• After 12 hours, the 100g group was still digesting. Only about 53g of it had shown up in the blood by then.

That last point is my favourite. The “rest gets wasted” crowd pictures protein hitting a wall half an hour after you eat. A big dose just takes longer. Your body runs it like a slow drip instead of a flood.

The authors’ own conclusion: the belief in a short response with an upper limit “lacks scientific proof”. (source)

So should you eat 100g in one sitting?

Not the point. How much you eat in a day matters far more than per-meal maths.

The most practical number I’ve found is from a 2018 review by Brad Schoenfeld and Alan Aragon: about 0.4g per kg of body weight per meal, across at least four meals, which lands you at 1.6g/kg a day if you’re trying to build muscle. (source)

For a 70kg person that’s around 28g a meal, four times a day, roughly 112g in total.

Notice what kind of number that is. It’s a way to spread things out, not a cap. If your day only allows two big meals, you are not flushing protein down the drain.

Where this argument gets weaker

• All 36 people were healthy young men. No women, no older adults. Older adults, in other studies, seem to need more protein per meal for the same effect, not less.
• It was one workout and one day. Nobody has shown yet that 100g once a day builds more actual muscle over months than the same total spread out. The study measured synthesis, not biceps.
• Only three doses were tested: 0, 25 and 100g. “No upper limit” really means “no limit found up to 100g”.
• They used milk protein, which digests fairly slowly. A fast whey shake might peak and flatten differently.
• If you have kidney disease or any condition that limits protein, none of this is advice for you. Ask your doctor.

The ten-minute version

1. Hit your daily number first. Around 1.6g per kg if you lift. Cost: tracking what you eat for one honest week.
2. Spread it over three or four meals if your life allows. Cost: basically nothing. Eggs, paneer, dal, curd, chicken, a scoop of whey, pick two.
3. If you can only manage two big meals, eat two big meals. Cost: one argument with your gym friend.
4. Delete the protein alarm. Cost: the tiffin collection loses its purpose :’)

So next time someone tells you 30g is the max, tell them about the cow. She spent four days getting infused so we could learn that 100g of protein was still being put to work twelve hours later.

Every AI model you have ever used was made the same way. Nobody writes it. You grow it. Billions of numbers get nudged, a tiny bit at a time, until the thing starts working. And then nobody can read those numbers. That’s why people call these models black boxes.

Quick note: this piece was drafted with help from an AI writing tool. Every number in it was checked against the original source, which is linked inline.

On November 2, a team at MIT CSAIL posted something that breaks that rule. They gave GPT-6 Astra the raw weights of a small open model, Qwen3.5–0.8B, and asked it to make the model better at maths.

Astra read the numbers, found what was wrong, and rewrote 131,072 of them. That’s 0.016% of the model. Its score on the MATH-500 benchmark went from 7.9% to 48.1%.

No training run. No new data. Just one model editing another one’s brain directly. lmao what.

First, what “weights” are and why nobody reads them

A model is basically a giant pile of numbers called weights. This one has about 0.8 billion of them. Training sets them using gradient descent (nudging every number slightly in whichever direction reduces the error, millions of times over).

No human ever picks a single number. It’s like the lanes of an old city. Everything connects and it mostly works, but nobody designed it, and there’s no map.

So when a model misbehaves, the normal fix is more training: more data, more GPUs, more days. Nobody opens the weights and edits them by hand, because nobody can read them.

The MIT team (Rikiya Takehi, Jayden Teoh, Alex Zhang and Omar Khattab) calls their idea Weight-Space Programming: a language model reading and writing a network’s weights directly, the way a developer reads and edits code. (source)

The bug: a model that couldn’t stop thinking

Qwen3.5–0.8B has a “thinking” mode, and it has a problem. It gets stuck in loops, thinking the same thoughts over and over until it runs out of space. Qwen’s own model card warns about this.

How bad? On its first 96 practice problems, 85 answers ran all the way to the 32,768-token limit. In the team’s evaluation, 93% of its answers hit that wall. It wasn’t failing the maths so much as never reaching the end of it.

Astra got three things: a Python environment to inspect the weights, a pile of practice maths problems (not the test sets), and a budget of 10, 25 or 50 forward passes (one forward pass means actually running the model on one input and watching what happens inside).

With 50 passes, it found the culprit. The looping came from one specific direction (think of it as one particular pattern of activity, almost like a single knob) written by the MLP blocks in layers 15 and 19 of the model’s 24 layers.

The fix: subtract that direction from 64 output columns in each of those two layers. 131,072 numbers. Done.

The results:

• MATH-500: 7.9% to 48.1%
• GSM8K (school-level word problems): 13.8% to 67.1%
• IFEval (how well it follows instructions): 21.0% to 62.3%
• answers hitting the token limit: 93.0% to 33.1%

Look at IFEval. That’s not even a maths test. Removing the loop made the model better at following instructions in general, which tells you the loop was quietly ruining everything, not just the maths.

Also notice: with only 10 or 25 forward passes, Astra barely moved the looping rate (87.2% and 86.4%). It needed enough looks inside the running model before it could find the knob. Even a weight-reading AI needs its print statements, ofc.

The part that broke my brain: it wrote a network from zero

Fixing a model is one thing. In another experiment, the team gave Astra an empty neural network, every single weight set to 0, plus the rules and source code of the Atari-style game Breakout.

The instruction was basically: write the weights yourself, in one reply, no training, no tools.

Astra’s answer was 3,739 tokens long. It just wrote the numbers.

That hand-written network scored 517.4 on average. A network trained the normal way with PPO (a standard reinforcement learning method) scored 15.8 after 100 million steps of practice, and 25.3 after 500 million. Astra’s version was about 20 times better without playing a single game. legit unreal.

How? Its first layer works out where the ball is going to land, including bounces off the walls. The second layer moves the paddle there. It’s a little program, written in weights instead of code.

To be fair, Breakout is a geometry game, and geometry is easy to write by hand. In Seaquest, the 500-million-step network still won, 88.9 to 53.1. In Asterix it was close, 55.2 to 53.2.

A few more things it pulled off

• Named the game from the numbers. Given only the raw weights of four game-playing networks, it correctly said which was Breakout, Pong, Pac-Man and Freeway.
• Fixed a robot car that always failed. A trained policy for driving a car up a ramp failed in all 256 test episodes. After one edit to 3.5% of its weights, it succeeded in all 1,024. Astra added a small side path that backs the car up and then switches itself off.
• Wrote a Go player. Starting from all zeros, it wrote the 1.48 million weights of a 9x9 Go network using one 336-line Python script, and won more than half its games against two smaller trained networks.
• Guessed the language from the middle of a brain. Given only the middle layers of three small text models, it said which one was trained on Python, English and romaji (Japanese written in English letters). One of its clues: the romaji model’s last layer writes in fewer directions, consistent with romaji never using q, l, v or x.

Where it failed, which is the most useful part

The team built two copies of Google’s small Gemma 3 270M model. One was trained to be honest. The other was trained to be a suck-up: it agreed with the user’s wrong answer 100% of the time, while the honest one did that 1 to 3% of the time.

From the weights alone, Astra could not tell which was which, in four attempts. Once it was allowed to look at where the models paid attention while reading text, it picked the sycophant correctly in all three test pairs.

And the maths trick didn’t work on Gemma at all. Gemma rarely loops (8.5% of answers hit the limit), and Astra’s best edit moved its MATH-500 score from 6.8% to 7.7%. Basically nothing.

The authors’ explanation is the cleanest sentence in the whole post: editing weights could “remove an obstacle that hid an ability”, but it could not add one the model never had.

Think of a student who actually knows the answers but keeps rewriting the first line of the exam until time runs out. Stop the rewriting and the marks show up. That was Qwen. Gemma was a student who just hadn’t studied.

Where this gets weaker

• It’s a blog post, not a peer-reviewed paper. The authors themselves call it very early.
• The models are tiny. 0.8 billion weights is small next to the frontier models people actually use, and nobody knows yet if this works at that scale.
• The Qwen fix worked because the bug was one clean, local knob. Most problems in real models are not that tidy.
• The post doesn’t report the cost or time for most experiments, so it’s hard to compare this with just training more.
• The good news: the logs are on GitHub and the edited Qwen model is on Hugging Face, so anyone can check the work.

Why this matters even if you never touch a model

Right now, if a model has a bad habit, the fix is expensive retraining. The authors list things this could lead to: fixing specific bugs without retraining, auditing a model for hidden behaviour by reading it, and removing skills or knowledge without any data.

They also list self-improvement as a possible future use. They didn’t show that, and it’s worth saying clearly. But a model that can edit another model’s weights is, in principle, a model that could one day edit its own. That’s the line everyone will be watching now.

For ten years, “black box” was just the honest description of these systems. On November 2, one black box opened another, found a loop inside, and turned it off by changing 131,072 numbers out of 800 million.

ps: the edited model is public. Somewhere right now, someone is diffing the weights to see exactly which 131,072 numbers changed :’)

Day 22. You did the whole 21-day challenge. Gym at 6am, every single morning, three straight weeks, tick tick tick on the tracker. The habit was supposed to be installed by now. Instead the alarm goes off and you lie there negotiating with the ceiling fan.

Quick note: this piece was drafted with help from an AI writing tool. Every number in it was checked against the original sources, which are linked inline.

Here’s the thing. Researchers at University College London actually measured how long it takes for a new daily behaviour to feel automatic. They followed 96 people for 12 weeks.

The answer wasn’t 21 days. It was anywhere from 18 to 254. The median was 66.

So your challenge didn’t fail. It just ended about six weeks early. lol

So where did 21 come from?

The usual origin story points to Maxwell Maltz, a plastic surgeon who wrote a self-help book called Psycho-Cybernetics in 1960. He noticed that his patients seemed to need at least about three weeks to get used to a new face, or to the loss of a limb.

That’s it. That’s the study. One surgeon’s observation about people adjusting to a changed body, written up as a minimum, not a deadline.

Then the book sold millions of copies, the “at least” quietly fell off as the idea got retold, and “it takes 21 days to form a habit” became the kind of fact that sits on gym walls and app onboarding screens. Nobody had timed a single habit.

First, what “habit” even means here

A habit isn’t “something I did 21 times”. Researchers care about automaticity (doing something without having to decide to do it).

Brushing your teeth is automatic. You don’t wake up and hold a little meeting with yourself about it. The gym at 6am, on day 22, clearly still needs a meeting.

So instead of counting days, the UCL team measured that feeling directly, every day, with a short questionnaire called the self-report habit index (a set of statements like “I do it without thinking”, rated by the person).

What they actually did

The study is Phillippa Lally and colleagues, published in the European Journal of Social Psychology. In plain words:

• 96 volunteers each picked one eating, drinking or activity behaviour to do daily
• each one tied it to a fixed cue, like “after breakfast”
• they did it for 12 weeks and filled in the questionnaire every day
• 82 people gave enough data to analyse

Then the researchers drew a curve for each person. And the curve had a very specific shape. Automaticity shot up in the early days, then slowed down, then flattened into a plateau. Kind of like your phone charging: fast to 80%, then crawling for the last bit.

They asked one question of each curve: how long until this person hit 95% of their own plateau?

The model fitted 62 people well enough to answer, and 39 of them fitted it well. Among those, the time ranged from 18 days to 254 days, with a median of 66. (source)

18 days for the fastest person. More than eight months for the slowest. One number for everyone was never going to work.

The part that should make you feel better

This line from the paper deserves to be on a poster more than “21 days” ever did: missing one opportunity to do the behaviour “did not materially affect the habit formation process”.

One missed day did not reset anyone to zero. Your streak app is stricter than the science, legit.

What did matter was consistency overall. People who did the behaviour more consistently got cleaner, stronger curves. So skip a day if life happens, just don’t make skipping the new habit.

Fifteen years later, the answer held up

In December 2024 a team in Australia published a systematic review in the journal Healthcare, pulling together 20 studies with 2,601 participants. The habits ranged from exercise and healthy eating to flossing, drinking water and, in two studies, microwaving a kitchen dishcloth to kill germs. Peak science. (source)

Only four of those studies measured time to form a habit. Their medians landed between 59 and 66 days. Their means were higher, 106 to 154 days, and individual people ranged from 4 days to 335.

When the average is much higher than the median, it means a few people take a very long time and drag the average up. Most people sit around two months. Some take most of a year.

The review also found that habits people picked for themselves tended to get stronger, and morning habits often did better than evening ones.

Where this gets weaker

• The UCL study was small. The 66-day median rests on the 39 people whose curves fitted well, and volunteers for a habit study are probably keener than average.
• The study ran for 84 days. Anything above that, including the 254, is the curve extended forward, not someone actually observed for eight months.
• Everything is self-reported. “I do it without thinking” is a feeling, and feelings are noisy.
• The review admits its own limits: most of the 20 studies had a high risk of bias, and only four measured time at all.

None of this rescues 21 days, though. Nobody found a reason to believe in it. They just found that the real answer is longer and messier.

What to do with this

1. Plan for about 66 days, not 21. Cost: changing one number in your tracker, and your expectations.
2. Tie it to something that already happens every day. “After I brush my teeth”, “after my first chai”. Cost: choosing one sentence.
3. Make it small enough to survive a bad day. Ten push-ups beats an hour you’ll skip. Cost: a little ego.
4. Missed a day? Just do the next one. Cost: nothing. The data says one miss doesn’t send you back to zero.
5. Pick it yourself, and do it in the morning if you can. Cost: being honest about what you actually want, not what the internet said.

Back to day 22 and the ceiling fan. You’re not failing at a habit. You’re about a third of the way into building one. Get up. It’s day 22 of roughly 66.

Authentication is the process of ascertaining that somebody really is who they claim to be.

in basic words, login + password (who you are)

What Is Stateful Authentication?

Stateful authentication means the server stores session data after a user logs in. Unlike stateless systems (where tokens carry all necessary data), the server maintains an active record of each session, usually in a database or cache.

A server acts as a digital bouncer. It first authenticates you (confirms your identity) and then authorizes you (grants specific access based on who you are).

A session is your active, temporary connection with a server after logging in, where the server remembers you. A cache is a fast, temporary storage for frequently used data, speeding up access.

How Stateful Authentication Works?

1. User Logs In

• The user submits their username and password.
• The server checks the credentials against a database.

2. Server Creates a Session

• If login is successful, the server generates a unique session ID (e.g., abc123).
• Stores this ID along with user data in a database (SQL, Redis, etc.).

3. Session ID Sent to Client

• The server sends the session ID back to the client, usually as an HTTP cookie:

Set-Cookie: session_id=abc123; Path=/; HttpOnly; Secure

4. Subsequent Requests Include the Session ID

• With every new request, the browser automatically sends the cookie:

Cookie: session_id=abc123

• The server checks if the session ID exists in its database.
• If valid, the request is processed; if not, the user is logged out.

5. Logging Out Destroys the Session

• When the user logs out, the server deletes the session record.
• Even if the cookie remains, the session ID becomes invalid.

How can we achieve stateful authentication?

1. Session-Based (Cookie-Based) Authentication

In session-based authentication, when a user successfully logs in with their credentials (e.g., username and password), the server generates a unique session ID and stores it in a database (like Redis or a session store) along with the user’s ID and other relevant data. The server then sends this session ID to the client (browser) as a cookie , typically named something like session_id. For example, after logging into an app, your browser might receive a cookie like Set-Cookie: session_id=abc123xyz; HttpOnly; Secure; Path=/. On subsequent requests, the browser automatically includes this cookie in the request headers, allowing the server to look up the session and authenticate the user without re-entering credentials. The session can have an expiration time, and it can be destroyed when the user logs out or remains idle for too long. This method is widely used in traditional web apps built with frameworks like Express.js, Django, or Ruby on Rails.

A Session ID is a unique, server-generated identifier used to distinguish a specific user’s interaction session with a web application. This ID acts as a pointer to user-specific data and state, which is stored server-side in a Session Store, a dedicated database or memory cache (e.g., Redis) responsible for maintaining session information across stateless HTTP requests. To enable the browser to present this Session ID on subsequent requests, the server embeds it into an HTTP Cookie, a small text file sent to the client’s browser, which then automatically includes it in future requests to the same domain, allowing the server to retrieve the correct session data and maintain user authentication.

2. Token-Based

The general concept behind a token-based authentication system is simple. Allow users to enter their username and password in order to obtain a token which allows them to fetch a specific resource — without using their username and password. Once their token has been obtained, the user can offer the token — which offers access to a specific resource for a time period — to the remote site.

A token is a piece of data which only Server X could possibly have created, and which contains enough data to identify a particular user.

You might present your login information and ask Server X for a token; and then you might present your token and ask Server X to perform some user-specific action.

Token are created using various combinations of various techniques from the field of cryptography as well as with input from the wider field of security research. If you decide to go and create your own token system, you had best be really smart.

3. Cached Sessions (Redis/Memcached)

Cached Sessions are a way to store user login information using fast, in-memory data stores like Redis or Memcached , instead of slower databases like MySQL. When a user logs in, the server creates a session ID or token , and stores the user’s data (like their user ID and when the session expires) in Redis or Memcached. This data is kept in memory, so it can be accessed very quickly — much faster than reading from a disk-based database. The session ID is then sent to the client, usually as a cookie or in an API response, and the client includes it with every request.

On each request, the server takes the session ID from the cookie or header and looks it up in Redis or Memcached. If it finds a match, the user is authenticated. If not (maybe it expired or was deleted), the user must log in again. This method improves performance and allows multiple servers to share session data easily, making it great for large apps that run on many servers. However, because the session data lives in memory and isn’t stored permanently, it can be lost if the cache server restarts — though Redis offers options to save data to disk for better reliability.

Like a cache, Redis stores key-value pairs. But unlike a cache, Redis lets you operate on the values. There are 5 data types in Redis — Strings, Sets, Hashs, Lists and Sorted Sets. Each data type exposes various operations.

The best way to understand Redis is to model an application without thinking about how you are going to store it in a database.

Hey everyone!

So, you clicked on this blog because you’re tired of typing slow, and let’s face it, that’s just super unproductive. Especially in this AI-driven world, where the faster you can prompt ChatGPT, the more you can get done!

I’m here to explain everything and give you the ultimate guide on how to seriously boost your typing speed.

Do You Really Need a Mechanical Keyboard?

Short answer: Nope! I’ve got a mechanical keyboard, and while it feels like I type faster than on my MacBook, the actual speed difference is tiny. Some folks do see a bigger boost, so you might need to put in some serious typing time to truly know if a mechanical keyboard is your jam. Plus, let’s be honest, mechanical keyboards just look and sound awesome. Sometimes, “cool” is the best metric because it keeps you coming back, ultimately making you more productive!

Where to start ?!

If you don’t do touch typing — that is, you only type with two fingers — then you should first learn how to use all your fingers for typing. This will drastically slow down your typing speed. But with time, you will be much faster than the traditional way of typing with two fingers. Try hard to stick with typing with all your fingers, and you will eventually gain speed.

Some of the best websites that i used for learning touch typing are

• https://www.typing.com/
• https://www.keybr.com/
• https://www.typingmaster.com/ (personally favourite; i used the paid tier)

You can start off with any keyboard at first; it doesn’t matter.

Okay, I Learned Touch Typing. Now How Should I Increase My Speed?

Use https://play.typeracer.com/. This is the best website that will help you increase your speed. This will, of course, bring down your confidence if you already started off with Monkeytype, because Monkeytype is known for boosting your confidence since the default words are very easy to type. But surely, it’s a good way to increase your burst speed, and that’s what most folks need when they are doing online chatting.

Try to stick with these websites, since they are very reliable and give you a very solid idea of where you are lacking.

Alright, I Used All These Websites, Still I’m Stuck. What to Do?

The answer is practice. Increasing your typing speed is a slow process, just like getting muscles. Some people might improve way faster than you, but everyone has a different curve. Don’t get disheartened if your friends started with you and are faster than you at typing.

Make it a habit to practice every day for 30 minutes on TypeRacer, and eventually you will be fast and super productive.