Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crypto | Posthog analytics for to-device decryption errors #234

Open
6 tasks
BillCarsonFr opened this issue Apr 25, 2022 · 3 comments
Open
6 tasks

Crypto | Posthog analytics for to-device decryption errors #234

BillCarsonFr opened this issue Apr 25, 2022 · 3 comments
Labels
A-E2EE A-Telemetry Telemetry / analytics to understand usage T-Feature Request to add a new feature which does not exist right now Team: Crypto

Comments

@BillCarsonFr
Copy link
Member

BillCarsonFr commented Apr 25, 2022

There are various failure modes that can lead to failures to decrypt to-device messages, which will then almost inevitably lead to UTD errors of some sort. Currently, these are not reported in Posthog, so we lack visibility into how often they happen.

See also #2409 which covers analytics for the sending side.


Implementation design

matrix-org/matrix-analytics-events#56 did some groundwork here, by adding a new domain of TO_DEVICE, and a name of ToDeviceFailedToDecrypt, to the properties of the current Error event. However, ToDeviceFailedToDecrypt seems insufficiently specific, and instead we need a number of new names.

As a first pass, I suggest adding a new name for each type of OlmError in matrix-crypto-sdk (https://github.com/matrix-org/matrix-rust-sdk/blob/main/crates/matrix-sdk-crypto/src/error.rs), with a prefix of ToDeviceFailedToDecrypt_.

There is also an optional freeform string field context, though its purpose seems a bit unclear. I suggest not using it for now.

So an example event would be:

{
    "event": "Error",
    "properties": {
        "domain": "TO_DEVICE",
        "name": "ToDeviceFailedToDecrypt_SessionWedged",
        "cryptoSDK": "Rust",
    }
}

I think probably the best way to implement this is to add a method OlmMachine::to_device_decryption_failure_stream, which returns a Stream, and each time OlmMachine::decrypt_to_device_event fails, we write a new entry to the stream. The stream could then be wrapped in both (Rust) matrix-sdk and matrix-js-sdk, for turning into Posthog events.

Sub-tasks

@BillCarsonFr
Copy link
Member Author

Moved to qualification again following new discussions during rust meeting

@BillCarsonFr BillCarsonFr changed the title Crypto | Posthog analytics for to device encryption/decryption erros Crypto | Posthog analytics for to device encryption/decryption errors Feb 29, 2024
@BillCarsonFr BillCarsonFr removed their assignment Feb 29, 2024
@richvdh

This comment was marked as outdated.

@uhoreg uhoreg changed the title Crypto | Posthog analytics for to device encryption/decryption errors Crypto | Posthog analytics for to-device encryption/decryption errors Mar 13, 2024
@richvdh richvdh removed this from the Crypto Q4 2022 milestone Apr 29, 2024
@richvdh richvdh changed the title Crypto | Posthog analytics for to-device encryption/decryption errors Crypto | Posthog analytics for to-device decryption errors Apr 29, 2024
@richvdh richvdh added A-Telemetry Telemetry / analytics to understand usage T-Feature Request to add a new feature which does not exist right now A-E2EE and removed T-Epic Issue is at Epic level labels Apr 29, 2024
@richvdh
Copy link
Member

richvdh commented Apr 29, 2024

I have split the sending side of this out to #2409, and updated the description of this issue for clarity and to include design notes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-E2EE A-Telemetry Telemetry / analytics to understand usage T-Feature Request to add a new feature which does not exist right now Team: Crypto
Projects
None yet
Development

No branches or pull requests

2 participants