The second device is the whole problem

The Double Ratchet specification — revision 4, dated 4 November 2025 — describes a protocol “used by two parties to exchange encrypted messages based on a shared secret key.” Two parties. Read the whole document and you will not find a laptop in it, or a tablet, or the phone you replaced last year. That is not an oversight; it is a scope, and everything difficult about modern messaging lives just outside it.

The document that picks up where it stops is Sesame, published by Signal in 2017. Its data model is the honest answer: each device keeps “a set of UserRecords for its correspondents”, and each of those contains “a set of DeviceRecords, indexed by DeviceID”. There is no session with a person. There is one with every device that person owns, and another with every device you own, including the ones you have forgotten about.

Fan-out, or one key for everybody

Meta's engineering post announcing multi-device WhatsApp puts the change in one sentence: “With multi-device, each device now has its own identity key.” Sending then means fetching a device list and encrypting once per entry — which does not scale to groups, so groups use a sender key. WhatsApp's security whitepaper describes it plainly: a Sender Key is “generated and distributed to each member device of the group, using the pairwise encrypted sessions”, after which the message itself is encrypted once and the server does the copying. The key is fanned out; the message is not. Forward secrecy comes from ratcheting the chain key forward — and the price is printed right there in the same document: “Whenever a group member leaves, all group participants clear their Sender Key and start over.”

Under fan-out, removing a device means not encrypting to it. Under a sender key, the removed device still holds the key, so the key has to be replaced for everyone.

The device list is the key material

Once identity is per device, the security of the conversation rests on a list — and therefore on whoever is trusted to write it. Sesame is explicit that the list is served by the infrastructure: “the server informs the sending device of the old DeviceIDs and new DeviceIDs needed to make the sending device's records current, and the identity public keys corresponding to any new DeviceIDs.” If nothing binds that list to you, the operator decides who your endpoints are.

This is not hypothetical. In More is Less (IEEE EuroS&P 2018), Rösler, Mainka and Schwenk showed that group membership messages were “only encrypted on the transport layer”, so whoever controlled the server could forge one and “become a member of the group … without any interaction of the other users” — after which the members politely sent the newcomer their sender keys. Months later two GCHQ officials proposed doing that on purpose, and described the result with unusual candour: “You end up with everything still being end-to-end encrypted, but there's an extra ‘end’ on this particular communication.”

The defence is to make the list a signed object owned by a device rather than a server row. WhatsApp's current whitepaper defines “Signed Device List Data” as a list of linked companions “signed by the primary device's Identity Key”, with cross-signatures at link time and — the part worth copying — an expiry: “a Time to Live of 35 days or less”, past which clients speak only to the primary. A stale list fails closed. The 60-digit safety number is computed over every device identity key of both parties, so it changes when the device set does.

Recovery is where it leaks

Now the hard one. A user who has lost every device and an attacker who has everything except a device make the operator the same request, and what separates them is usually a short secret a human can remember. Every deployed answer is the same trick: put the escrowed key behind hardware that refuses to be brute-forced, and keep the guesses few.

Apple prints its number: for iCloud Keychain escrow, “the escrow service allows only 10 attempts”, after which the cluster destroys the record and “the keychain is lost forever.” Signal's Secure Value Recovery puts an enclave in charge of the count; its successor, published at OSDI 2024, splits trust across enclaves run by different cloud providers and states the bound as a formula rather than a figure. WhatsApp's backup vault uses OPAQUE so the password never reaches the server, and says the key becomes permanently inaccessible after “a certain number of unsuccessful attempts” — the document does not print the number, and neither will I. It also notes that encrypted backups are “only supported on a user's primary device.” Recovery is not a hole in these designs; it is the deliberate, bounded, documented one. Ask any messenger how wide it is and who is counting.

Where OSHI is

OSHI links web sessions by QR code, the same primitive as everyone else. Until 13 September 2026 nothing told the user a device had been linked; the list was correct and silent. That shipped fixed on iOS 1.0.45 and on Android the same day.

What is still open is a device-list problem of exactly the kind above. GET /api/web/sessions answers without a signature: anyone who knows a user's public address can enumerate that user's linked devices. Chained with the revoke endpoint, it is a remote denial of service against someone else's desktop session. A server-side owner gate is deployed but running in permissive mode while unsigned traffic is measured — it records what it would refuse and refuses nothing. The relay WebSocket also accepts {"type":"mobile_auth","publicKey":…} with no signature. None of it exposes message content. All of it is the list, unowned.

Four questions worth asking

Of any messenger, this one included. When a device is added, does the app tell you, or wait to be asked? Is the device list signed by something you hold, or asserted by a server? Does removing a device change keys, or only a row? And if you lose everything, what is the smallest secret that brings it back — and who counts the guesses?