Users in short-lived incognito tabs may never be able to share megolm keys, unless they can dehydrate/rehydrate their device somehow.

[ara4n]

Split out from https://github.com/vector-im/riot-web/issues/2286#issuecomment-299532155:

Consider the edge case that Alice and Bob are both pretty paranoid, and only ever use Matrix by firing up an incognito window, logging in, sending a message, and closing the tab (not implausible). As a result, at any given point they probably wouldn't have any devices live. Therefore when Alice sends a message to Bob, she won't know how to encrypt for him, and when Bob gets a UISI, there won't be any devices from Alice he can query for the megolm keys (unless Alice happens to be logged in and having re-imported her megolm keys at the moment that Bob requests history, or perhaps later). We concluded that there were two possible solutions to this:

1. Introduce the concept of 'virtual devices' so that Alice & Bob can maintain a virtual device which is stored encrypted on the server, and is passed between physical logins, letting them pick up conversations when desired - this would almost act as an 'identity key'.
2. Introduce the concept of deliberately 'dehydrating' and 'rehydrating' devices, so that when Bob stops using his Incognito window, he could explicitly export that device intact onto a USB stick or whatever, and subsequently rehydrate it next time he opens an incognito tab - effectively deliberately backing up & unbacking up the device.

In the end, both of these are tantamount to the same idea, whether the device is stored encrypted on the server or on a USB stick. Both suffer from #3822 - that if two identical devices ever exist concurrently Olm will completely wedge and E2E will break. So the conclusion there was to educate users that they need to keep at least one device active if they expect E2E to work, unless we ever get as far as dehydrating/rehydrating devices (i.e. this bug).

One question for @richvdh: if Bob sends a send_missing_keys to_device "*" message to Alice whilst Alice has no devices, i wonder if we can queue it up so that when Alice returns she can send the megolm keys to Bob and (assuming Bob's device still exists) solve the UISI?

[richvdh]

if Bob sends a send_missing_keys to_device "*" message to Alice whilst Alice has no devices

The server will struggle to tell the difference between "Alice fired up an incognito tab and closed it without logging out" and "Alice started a new device, which she will return to in future".

[richvdh]

Anyway, I think that in the course of our conversations on element-hq/element-meta#647 we concluded that having Alice's device share keys with Bob for messages that it didn't send was flawed, so the question is moot.

[ara4n]

This could probably be solved more elegantly by #3661, which amounts fo pretty much the same thing. So i'm going to close this one.

[ara4n]

actually, #3661 doesn't fix this, as the problem is that Bob will still never have any devices available when Alice tries to set up an olm session to send him the megolm keys for her messages, and so Bob will never receive the keys and thus never be able to back them up serverside.

Instead, the problem is more similar to #2713 and https://docs.google.com/document/d/1_wDoDQ02JLZwYeVb-QVPylnJUXJVTZ9bNoGHd_Go6Zg/edit - we need a way to be able to share megolm keys with a device which doesn't even exist yet. Except if both the sender and receiver keep deleting their devices, i'm not sure what we can really do short of the whole dehydrated device idea.

[ara4n]

There was some interesting discussion about finally solving this in #e2e today: https://matrix.to/#/!vlnjqGLpLJlFmBSkfQ:matrix.org/$uV4AnKXX38fVrdKAn9Dv0m-k8Ny7YySoie8noxTy1uc?via=matrix.org&via=hacklab.fi&via=privacytools.io and friends

[uhoreg]

Fixed by matrix-org/matrix-js-sdk#1436, matrix-org/matrix-react-sdk#5239, and matrix-org/synapse#8380. Currently requires a feature flag to be enabled.