[honestjohn]

Multi-device mode is new enough that I might be wrong about this, but afaik the web client still needs to get the priv key from your phone, so they can't authorize a new client unilaterally. Or it'd be a really silly hole if they could.

Edit: Meant to say, the web client needs to somehow be authorized by the phone, not that it takes the privkey exactly. Probably gets a new key that the phone stores, so the phone is still the "master" device. I wouldn't expect the phone client to happily send the chat history to a new device it didn't authorize locally.

[bsaul]

Maybe the phone transfers a secret to the webclient, and that secret is then used by the other participant to certify it is indeed an "authorized" device, but i was under the impression that you had to rely on the server to correctly give you a list of correct devices for a given participant.

i'm happy to know more about that topic if you've got some documentation.

[honestjohn]

Someone else here probably knows more than me. I don't want to speculate too much about what it actually does, I just know that the original device takes part in authorizing a new one, so it seems like they can't do it on their own.

[bsaul]

i guess it depends if the authorization process reaches the other participants in some way or another ( such as a key derivation mechanism that can be verified by everyone) or if it's just a security feature to strengthen the login process.

[honestjohn]

Maybe it's similar to adding a new chat participant, except your client says "btw this is also me." I used that way when designing a toy e2ee app a while back. Or maybe there is a central repo of each user's per-device pub keys, and your client signs its updates to it using the original pub key so it's tamper-evident.

Maybe there's some key derivation mechanism so the new pubkey is self-evidently owned by the first one, never heard of one though.