3.11.5 Privacy Limitations

From a privacy perspective, in addition to the identifiers displayed in the user interface, our solution provides some limited extra information about a user to other users they interact with: the sigchains reveal the history of the user’s devices, including when they were added and revoked (but not their names, which are protected behind a commitment), as well as which device was used to sign any specific E2E-encrypted communication. Similarly, the number of times that a user changes their email address or account is visible (but not the previous emails or account IDs). Moreover, since the server might report the timestamps of sigchain statements (and, once deployed, the ZTT will also necessarily reveal the same information), time correlations between different statements might be exploited to infer, for example, that two users swapped their email addresses, or that two users are in the same account. While this information is not displayed in the user interface, the client needs this data to perform the sigchain validation and therefore a motivated attacker might extract such information. We believe that this is acceptable; it is similar to the security code change warnings in applications like Signal and WhatsApp. Note that sigchains are not publicly available and are subject to server-side access control: they are provided as needed to users. For example, if Bob is a Zoom Mail Service user and knows Alice’s email address, they can ask the server for the sigchain associated with that address in order to encrypt an email. We currently rate limit requests for users’ sigchains and other personal data as a partial mitigation for this leakage. In the future, we are considering a different mechanism that allows the server to offer “randomized” versions of a user’s encryption keys, in a way that trades the opportunity to check a user’s fingerprints (while still being able to detect impersonation after the fact) for increased privacy.