Create Message Backup Requests XIP #31
Conversation
|
|
||
| ## Specification | ||
|
|
||
| This specification offers the user two modes of message backup, which accomodate different use-cases: Remote Message Backups and Backup Account Files. Remote Message Backups are the lowest friction solution, provided the blockchain account has access to another existing installation. Backup Account Files are an emergency solution for cases where the user has lost access to all of their XMTP applications (for example, if they lost the only device they have used to connect to XMTP). |
There was a problem hiding this comment.
I may be splitting hairs, but some social media users have preconceptions about the term "backup account". Suggest we consider naming our 2nd use case "Account Backup File" to avoid concept collision with the above.
There was a problem hiding this comment.
I worry "Account Backup File" might lead developers astray. This process is creating a secondary XMTP account just for backups, and then saving it to a file. When I hear "Account Backup File" it's easy to assume that it is a backup of your regular account.
We can workshop the name a bit. I'm not married to "Backup Account File".
|
|
||
| Once a backup account's contact has been published to the network, their installation messaging topic will receive a copy of all new messages sent to the associated blockchain account. | ||
|
|
||
| The newly generated XMTP keys are encrypted and downloaded to the user's device. They may be encrypted by either a passphrase or a wallet signature. Users or applications may decide to store the Backup Account File in a private cloud storage provider (iCloud, Google Drive, etc). Or the file could simply be stored on-device with the risk of loss if the device was inaccessible. |
There was a problem hiding this comment.
There is some tension here between minimizing user friction/developer support, and ensuring the backups' availability. The minimal friction case is storing the backup on the same device as the app - but this would not be accessible either if the device is lost. On the flip-side, the cloud hosting case requires significant user or developer friction, as a preventive measure for a somewhat rare scenario.
For simplicity, I wonder if the backup account file (or similar solutions) are a case of diminishing returns on top of remote message backups, that would be acceptable to omit from initial versions. In the event that someone loses access to all XMTP applications, they would only have messages going forward. For those truly fearful of this scenario and willing to tolerate some friction, they can set up a client (whether branded as a backup app or just a regular messaging app) on a secondary backup device.
There was a problem hiding this comment.
The minimal friction case is storing the backup on the same device as the app - but this would not be accessible either if the device is lost. On the flip-side, the cloud hosting case requires significant user or developer friction, as a preventive measure for a somewhat rare scenario.
In the case of mobile apps, storing the data locally and persisting to the cloud can be very similar. iOS and Android both give app developers built-in cloud-synced storage to work with. The lift might not be so bad.
For those truly fearful of this scenario and willing to tolerate some friction, they can set up a client (whether branded as a backup app or just a regular messaging app) on a secondary backup device.
Definitely an option, although there are large parts of the world where most users have a single device. It feels like this would only be an option as a temporary means of scope-cutting, but wouldn't work as a complete long-term solution.
|
|
||
| Backup account files are designed as a solution for users who have lost access to all of their XMTP applications. To create a Backup Account File, an application will generate a new set of XMTP keys and register the installation on the XMTP network. The installation contact published to the network will be set with a type of `backup`, which instructs all well-behaved clients to disregard any messages from this installation other than `MessageHistoryBackupResponse`s. This means that a compromised backup installation cannot be used to send messages on the user's behalf, which makes these files a less valuable target for attack. | ||
|
|
||
| Once a backup account's contact has been published to the network, their installation messaging topic will receive a copy of all new messages sent to the associated blockchain account. |
There was a problem hiding this comment.
One thing to mention is that the backup client doesn't have access to historical messages. We would have to introduce new payload formats to retransmit all existing history to the backup client over the XMTP network
There was a problem hiding this comment.
That's true. It will only have a complete history of your XMTP messaging if it is created as part of your first interaction with the XMTP network. If you create it later, it will only have history starting at the time of it's creation.
|
|
||
| - Developers of the Message Backup Provider could implement the consent flow in a way that confuses users into accepting backup requests from malicious applications. PIN verification may not be implemented across all providers | ||
| - A malicious Message Backup Provider could choose to censor messages in the backup, or add spoofed messages, since the messages in the backup are unauthenticated. | ||
| - Bugs in the validation of requests in Message Backup Providers would be very very bad. This would need to be very well tested code, since a compromise here would effectively be a 0-click exploit of someone's XMTP account. |
There was a problem hiding this comment.
Given the sensitivity, it might make sense to structure this code as a separate crate/extension/package, to clearly separate it from the mainline protocol, but included as a default. This would allow people to examine it with a higher degree of scrutiny, as well as for extremely sensitive apps to strip it at compile time.
| - Developers of the Message Backup Provider could implement the consent flow in a way that confuses users into accepting backup requests from malicious applications. PIN verification may not be implemented across all providers | ||
| - A malicious Message Backup Provider could choose to censor messages in the backup, or add spoofed messages, since the messages in the backup are unauthenticated. |
There was a problem hiding this comment.
If we want to add defense in depth:
-
We could consider requiring a wallet signature in the backup provider before sending the backup response. This allows the application layer to prove to the SDK layer that the correct information (including PIN) was surfaced to the user and consent was provided, minimizing implementation error, and requiring less context from app developers. In the current design, the security of remote backups is only as strong as the weakest app in the system.
-
We could consider requiring a wallet signature in the backup requester (optionally rolled into the same signature for installation key provisioning), to be validated on the provider before surfacing the consent flow. A particular area of potential weakness is the behavior with revoked installations. With the current design, any bug or momentary lapse in revocation logic (for example if a revocation payload was hidden from an installation for a brief moment in time) could allow a revoked installation to issue backup requests, or allow backup spoofing from a revoked installation. Additionally, in some cases a user may not actually want their message history on a new app, but there is nothing stopping a backup request from being issued regardless.
Arguable if these are worth the extra friction, mentioning here to provoke discussion
There was a problem hiding this comment.
It would also be nice to restrict the situations in which a backup can be requested - ideally only when creating a new installation, and at no other time.
There was a problem hiding this comment.
We could consider requiring a wallet signature in the backup provider before sending the backup response. This allows the application layer to prove to the SDK layer that the correct information (including PIN) was surfaced to the user and consent was provided
While I guess it would lower the risk of developer error, the backup provider by definition already has all the messages. Why would they go through the trouble of using the backup service to exfiltrate messages without user consent when they can just use the SDK directly to get them?
A particular area of potential weakness is the behavior with revoked installations. With the current design, any bug or momentary lapse in revocation logic (for example if a revocation payload was hidden from an installation for a brief moment in time) could allow a revoked installation to issue backup requests, or allow backup spoofing from a revoked installation.
I'd like to go deeper on what the concerns with revocation are. It seems like we should address those head-on before we make any decisions that try to compensate for perceived weaknesses. Having access to the installation keys should be a strong assurance that the installation is controlled by the wallet owner given we are trusting this for message authentication. As part of the implementation we can (and should) force the Backup Provider to refresh the wallet address's contact topic to see if there are any recent revocation messages.
Additionally, in some cases a user may not actually want their message history on a new app, but there is nothing stopping a backup request from being issued regardless.
I wonder if we can handle this point through strong UX guidance, rather than relying on wallet signatures. I worry that if we have too many wallet signatures as part of sign-in we will induce signature-blindness in the user, risking them clicking through signature dialogs carelessly. I do see the benefit in making backup requests an explicit user action, rather than an implicit part of sign-up. It could be annoying to receive a bunch of push notifications any time you access an XMTP app. Especially if apps don't explain what is happening to the user clearly.
It would also be nice to restrict the situations in which a backup can be requested - ideally only when creating a new installation, and at no other time.
I like this. We should figure out how to enforce it, but it's a sensible idea.
There was a problem hiding this comment.
Why would they go through the trouble of using the backup service to exfiltrate messages without user consent when they can just use the SDK directly to get them?
To clarify, the goal is not to protect against malicious backup providers, just careless ones which may then serve backups to a malicious requester.
We should figure out how to enforce it, but it's a sensible idea.
A possible idea is to include this as part of the signing step for a new installation. For example, signing step looks like this:
XMTP: Grant Messaging Access
Current Time: <current time and local timezone>
Installation Key: <Curve25519PublicKey:Ed25519PublicKey>
Permissions:
- Full message history
When a provider receives a backup request, they can look for this signature, verify that 'full message history' has been granted, and only surface the backup request to the user if the local clock is within 10 mins of what the user signed for.
Co-authored-by: Richard Hua <rich@rkhua.com>
|
|
||
| ## Rationale | ||
|
|
||
| There are many other potential solutions to message portability listed below. I am proposing this particular solution because it solves the key user problems stated above with the minimal amount of developer friction. Many of the alternatives require substantial cooperation from application developers, who may care more about shipping new features than supporting competing applications. Developers have strong incentives to receive backups, but limited incentives to provide them. |
There was a problem hiding this comment.
Any potential network fees would be the responsibility of the Remote Message Backup provider as the sender?
An opinionated proposal for Portable Inbox on top of XMTP V3.