Expected UTDs: Hide device-relative historical UTDs

BillCarsonFr commented 4 months ago

A freshly logged in session will have access to event in the joined rooms, but not to the keys for the messages as the device didn't exist when the event were sent. The new device has to go through the verification process in order to get access to the keys and properly display history.

We are talking here about Device-Relative history:

Currently EIX is hiding such history until the device has access to backup:

Technical Inputs

How to detect when an event is historical to the current device?

Currently EIX is using events origin_server_ts of events (isItemInEncryptionHistory). It's comparing the local creation date of the device ( since the unix epoch) to the event origin_server_ts (Timestamp in milliseconds since the unix epoch on originating homeserver when this event was sent.)

Some downside on this approach is that if the device local time or server local time is wrong it could messed up things.

Another approach could be to use the API end-point used to get the messages?

From sync: If not an initial sync it's not an historical message.
From sync: If an initial sync, could be a mix of it, but mainly historical? (unless a clear cache is done)
From /message (back pagination). Would be mostly historical to the current device (unless there was a clear cache?)
From /relation (threads?). Would be mostly historical?

It's anyhow hard to see if something is really device relative history, as the process of sending is inherently racy. There might be some events that are shown were they shouldn't (sent around the same time the device is logged in but before propagated to anyone)

Proposal

Hide historical messages (expected UTD) until the user has access to backup
Hide historical messages (expected UTD) while keys are beeing downoaled.
Once the keys have been downloaded, show the events.

If an UTD has not be displayed on screen, it should not be reported to analytics.

Tasks

### Tasks
- [x] EX Hide device relative historical messages until the device has access to backup.
- [x] WebR: Hide device relative historical messages until the backup has been downloaded.
- [x] WebR: make sure that UTDs due to this are reported separately in Posthog

Known possible issues

If we hide the device relative historical messages, and the users manually import keys from a file, what should we do?
After the backup import, some messages might still be in UTDs (key was not in the used backup). That's fine, we should just display the UTD and report to analytics

richvdh commented 4 months ago

Probably requires a fix to https://github.com/element-hq/element-web/issues/27009?

Edit: not really. The two are orthogonal.

richvdh commented 3 months ago

There might be some events that are shown were they shouldn't (sent around the same time the device is logged in but before propagated to anyone)

This is somewhat related to https://github.com/element-hq/element-meta/issues/2314, and dealing with the race condition might have a similar solution.

richvdh commented 3 months ago

As a first step, we will not hide the events altogether, but display a placeholder.

BillCarsonFr commented 3 months ago

Note: we should ensure that it's also hiding historical UTDs in thread view.

richvdh commented 3 months ago

Rough idea for approach here:

Add a new code value to DecryptionError which reflects a message that is older than the device, when we don't have backup enabled.
Update DecryptionFailureBody to display the failure differently to the user
Update DecryptionFailureTracker to report the failure differently to posthog.

More detailed work:

[x] Move DecryptionError out of legacy crypto code and into crypto-api. Replace its code with an enum: https://github.com/matrix-org/matrix-js-sdk/pull/4126
[x] Refactor EventDecryptor.attemptEventDecryption so that all the logic isn't inside a catch block. https://github.com/matrix-org/matrix-js-sdk/pull/4138
[x] Expose a new method PerSessionKeyBackupDownloader.isBackupConfigured().
[x] When we get a MissingRoomKey or UnknownMessageIndex, compare the timestamp on the event with the creation time of our own device (available via Device.firstTimeSeen), and check isBackupConfigured. If it's an old event, and backup is not configured, use different codes on DecryptionError. https://github.com/matrix-org/matrix-js-sdk/pull/4139
[x] DecryptionFailureBody: use different text for new error codes. https://github.com/matrix-org/matrix-react-sdk/pull/12391
[x] DecryptionFailureTracker: use different error code. https://github.com/matrix-org/matrix-react-sdk/pull/12389
[x] Playwright tests (some may exist and just need updates). https://github.com/matrix-org/matrix-react-sdk/pull/12391
- [x] Old event, with backup disabled.
- [x] Enabling backup changes the UI for the event even if the key isn't in the backup.

BillCarsonFr commented 3 months ago

Some design exploration https://www.figma.com/file/a1NWmg6mOi2VZuSgaJx6nD/Displaying-UISI?type=design&node-id=1-12313&mode=design&t=6hb0XIH9Ftv5SI46-0

richvdh commented 3 months ago

Decision tree for the text to be displayed:

flowchart TD
A{Timestamp on the message\npostdates the creation of our device}
A -- Yes --> X
A -- No --> B
B{Is there a backup}
B -- No --> Y
B -- Yes --> C
C{Is the device verified}
C -- No --> Z
C -- Yes --> X

X([Normal UTD error])
Y([History is not available on this device])
Z([You need to verify this device])

element-hq / element-meta