Posthog: Add more properties to unable to decrypt errors to allow more filtering options

[BillCarsonFr]

Currently the captured Error events for unable to decrypt errors do not contain much information.
This lack of information is preventing us from getting interesting insights from the raw data.

Goal: We want to add some new properties that will allow us to better filter out Posthog insights.

List of needed properties:

• eventLocalAgeAtDecryptionFailure (numeric, time in millis). An heuristic based on event origin_server_ts and the current device creation time. This would be used to get the source of the event scrollback/live/initialSync. This would be used in Posthog by creating filter to group events in buckets (e.g <0 (historical), <60s, <5min, <1h, >1h)
• userTrustsOwnIdentity (boolean). Would allow to know if the current session was trusted at the time of decryption
• isFederated (boolean). true if userDomain != senderDomain. Would allow to filter UTDs where federation is involved.
• timeToDecryptMillis (numeric, time in millis) : Currently there is a grace period of 4s, after that UTDs are reported. We would like to improve the existing mecanism by adding a timeToDecrypt properties when an event is decrypted late. We should track decryption errors for 1mn (TBD), if events are decrypted during this period we still report an UTD with the time it took to decrypt, after 1mn we report anyhow. Would allow to filter on posthog temporary vs definitive UTD.
• isMatrixDotOrg (boolean). True if the current user is using Matrix.org. Combined with isFederated would allow to create a filter where we are sure that both users are running a recent synapse.
• wasVisibleToUser (boolean). True if that unable to decrypt error was visible to the user. For example, some clients can hide part of the history and only show it after verification. In that case the UTDs won't be displayed on screen and we want to filter that.

Tasks

Beta Give feedback

1. Update Error schema to support the new timeToDecryptMillis and cryptoSDK matrix-org/matrix-analytics-events#92
   +0
2. Add new E2E error for expected UTD matrix-org/matrix-analytics-events#93
   +0
3. Add new properties to UTD errors matrix-org/matrix-analytics-events#97
   +0
   
4. Crypto | Add more properties to unable to decrypt Posthog events to allow more filtering element-web#27168
   A-E2EE T-Task Team: Crypto +3
   
5. Crypto | Add more properties to unable to decrypt Posthog events to allow more filtering element-android#8779
   A-E2EE T-Task Team: Crypto +3
   
6. Crypto | Add more properties to unable to decrypt Posthog events to allow more filtering element-ios#7767
   7 of 7
   +0
   

[BillCarsonFr]

These will also be improvements/addition to #2300

[richvdh]

eventLocalAgeAtDecryptionFailure

Is it better to log the age relative to the session, or to log the session-creation-time and the timestamp on the event as separate fields (and then do the calculation on the posthog side)?

[BillCarsonFr]

eventLocalAgeAtDecryptionFailure

Is it better to log the age relative to the session, or to log the session-creation-time and the timestamp on the event as separate fields (and then do the calculation on the posthog side)?

AFAIK There is no easy way to do that on posthog side (not in the query to display graphs), maybe a posthog plugin where you can pre-process and decorate events.

[richvdh]

isFedarated

isFederated

[richvdh]

• eventLocalAgeAtDecryptionFailure (numeric, time in seconds)
• timeToDecrypt (numeric, time in seconds)

It looks like other "time" fields in the analytics events measure time in milliseconds. Please let's try to be consistent.

[richvdh]

• timeToDecrypt (numeric, time in seconds) : Currently there is a grace period of 4s, after that UTDs are reported. We would like to improve the existing mecanism by adding a timeToDecrypt properties when an event is decrypted late. We should track decryption errors for 1mn (TBD), if events are decrypted during this period we still report an UTD with the time it took to decrypt, after 1mn we report anyhow. Would allow to filter on posthog temporary vs definitive UTD.

Trying to understand this a bit better. Could you explain what will happen under this plan for each of:

• An event decrypted in more than 0s but less than 4s (it is not reported to posthog at all?)
• An event decrypted in more than 4s but less than 60s (it is reported to posthog, but with an appropriate timeToDecrypt ? How does this relate to Posthog | Increase decryption failure grace period #2303?)
• An event which is still not decrypted after 60s (we give up waiting, and report it to posthog with timeToDecrypt set to ... +inf ?)

[BillCarsonFr]

• timeToDecrypt (numeric, time in seconds) : Currently there is a grace period of 4s, after that UTDs are reported. We would like to improve the existing mecanism by adding a timeToDecrypt properties when an event is decrypted late. We should track decryption errors for 1mn (TBD), if events are decrypted during this period we still report an UTD with the time it took to decrypt, after 1mn we report anyhow. Would allow to filter on posthog temporary vs definitive UTD.

Trying to understand this a bit better. Could you explain what will happen under this plan for each of:

* An event decrypted in more than 0s but less than 4s (it is not reported to posthog at all?)

* An event decrypted in more than 4s but less than 60s (it is reported to posthog, but with an appropriate `timeToDecrypt` ? How does this relate to [Posthog | Increase decryption failure grace period #2303](https://github.com/element-hq/element-meta/issues/2303)?)

* An event which is still not decrypted after 60s (we give up waiting, and report it to posthog with `timeToDecrypt` set to ... `+inf` ?)

Yes so far I think:

• Decrypted under 4s not reported (mostly to be a bit backward compatible)
• Decrypted before Max Wait time (60s) Report with timeToDecrypt it took
• If after Max wait time it's still not decrypted we report with a timeTodecrypt > MAX (we could put some +inf value also)

The max wait period has to be defined, the main risk is that this wait time is too long and the client is closed meanwhile and the error not reported at all.

So maybe it should be 30s and not 60s

[BillCarsonFr]

• eventLocalAgeAtDecryptionFailure (numeric, time in seconds)
• timeToDecrypt (numeric, time in seconds)

It looks like other "time" fields in the analytics events measure time in milliseconds. Please let's try to be consistent.

Yes, updated

[richvdh]

Yes so far I think:

• Decrypted under 4s not reported (mostly to be a bit backward compatible)
• Decrypted before Max Wait time (60s) Report with timeToDecrypt it took
• If after Max wait time it's still not decrypted we report with a timeTodecrypt > MAX (we could put some +inf value also)

The max wait period has to be defined, the main risk is that this wait time is too long and the client is closed meanwhile and the error not reported at all.

So maybe it should be 30s and not 60s

So do we do this instead of #2303?

[BillCarsonFr]

So do we do this instead of #2303?

I think so, let's confirm at the daily

[BillCarsonFr]

Closed #2303 and do this task instead

[BillCarsonFr]

For UTD that are not resolved after the max_time, we might want to report timeToDecypt=-1
That would allow to filter more easilly

[andybalaam]

@BillCarsonFr will break into separate tasks.

[uhoreg]

@BillCarsonFr All the tasks in this issue are marked as done. Can this issue be closed, or is there more work to do here?

[BillCarsonFr]

yes let's close there is a roundoff for EX