MSC2228: Self destructing events

[ara4n]

A new proposal for self-destructing events via redactions, based on lessons learned from matrix-org/matrix-spec-proposals#1763.

Rendered

[ara4n]

I think this is good for review; if people think it's on the right track, I'll propose FCP (although N.B. we have no urgent plans to implement this in synapse - just wanted to rescue the content from matrix-org/matrix-spec-proposals#1763 and make it saner, particularly if anyone else wanted to implement it in their server or contribute it)

[ara4n]

@mscbot fcp merge

[mscbot]

This FCP proposal has been cancelled by https://github.com/matrix-org/matrix-doc/pull/2228#issuecomment-804620554.

Team member @mscbot has proposed to merge this. The next step is review by the rest of the tagged people:

• [ ] @dbkr
• [ ] @uhoreg
• [x] @turt2live
• [x] @ara4n
• [ ] @anoadragon453
• [ ] @richvdh
• [ ] @erikjohnston
• [ ] @KitsuneRal

Concerns:

• Edits to the timeout field are currently undefined behaviour. See https://github.com/matrix-org/matrix-doc/pull/2228/files#r315175179 (https://github.com/matrix-org/matrix-doc/issues/2228#issuecomment-522654985)
• Should have a mention of self-destructing redactions (https://github.com/matrix-org/matrix-doc/issues/2228#issuecomment-525998411)
• Unclear if m.synthetic is actually part of this proposal (https://github.com/matrix-org/matrix-doc/issues/2228#issuecomment-525998536)

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

[ara4n]

(it feels premature to suggest fcp on this without having checked whether the impl works though - if we have to change it based on the impl, are we going to have to fcp it again?)

[turt2live]

Theory is we don't design a system that sucks to implement. Minor changes don't need approval (they're at the discretion of the person reviewing the spec PR), however major changes need a MSC against the MSC to be incorporated in the spec.

[joepie91]

Something that I'm missing in the MSC: what's the concrete threat model that this MSC is meant to address? The referenced MSC 1763 has a lengthy list of goals, but those also encompass general message retention goals, and it's not clear which of those points are meant to be addressed by this derived MSC, or whether there might even be any new ones.

This is especially important because "self-destructing messages" is a topic that's fraught with potential design mistakes in general.

For example, if the intention is to only expose a given piece of information to recipients for a limited period of time because the recipients are not trusted to behave in good faith, such a feature could actually make things worse by suggesting a reliable auto-deletion mechanism where none exists (as a malicious recipient could simply run their own HS and refuse to implement the server-side component of this MSC).

On the other hand, if the purpose is to opportunistically protect information from being disclosed in a future server compromise, self-destructing events could be a reasonable approach; though at that point, the question should be asked whether this is not better solved through opportunistic E2EE.

In summary: as it stands, it's not clear what threat model this MSC is meant to address, and as such its effectiveness from a security perspective can't really be meaningfully reviewed by third parties.

[Half-Shot]

@mscbot concern Edits to the timeout field are currently undefined behaviour. See https://github.com/matrix-org/matrix-doc/pull/2228/files#r315175179

[Half-Shot]

I can't raise concerns because I am a mere observer, but it feels premature to call FCP on a MSC with open questions inside the proposal document.

[turt2live]

raising on half-shot's behalf:

@mscbot concern Edits to the timeout field are currently undefined behaviour. See https://github.com/matrix-org/matrix-doc/pull/2228/files#r315175179

[turt2live]

@mscbot concern Should have a mention of self-destructing redactions

[turt2live]

@mscbot concern Unclear if m.synthetic is actually part of this proposal

[ara4n]

@joepie91 have tried to incorporate your threat model concerns in b8f172e5. (please use threads for comments rather than the main linear comment list, for ease of threaded responses :)

[Half-Shot]

I am wondering if it would be helpful for the server to stick in a lifetime value in unsigned as we do already for age.

Given the server should be the authority on how long an event has left to live rather than the client (which is almost certainly out of sync with the server's time)

[ghost]

Given the server should be the authority on how long an event has left to live rather than the client (which is almost certainly out of sync with the server's time)

Is this the case in Signal too?

[SoftwareSchlosser]

I'm currently trying to use this nice new feature because I have a python script that sends messages automatically which should be deleted after a few days.

The script uses matrix-nio and here's what my message sending looks like:

_content={
	"msgtype": "m.text",
	"body": "Test",
	"m.self_destruct_after": 30000
}

client.room_send(room_id=_dstRoom, message_type="m.room.message", content=_content)

Unfortunately it doesn't work or I didn't do it right.

Server version is 1.9.1

Also tried to add "m.self_destruct": "True" and putting quotation marks around the time value.

What am I doing wrong?

Oh, and what about media? I'm actually sending jpeg images and it would be great if those would also be deleted upon the message self destruction.

[richvdh]

@SoftwareSchlosser if you're having trouble with the experimental implementation of this in synapse, https://github.com/matrix-org/synapse and #synapse:matrix.org is the place to go. Note that it isn't enabled on the matrix.org server.

Deletion of media on message redaction is https://github.com/matrix-org/synapse/issues/1263.

[SoftwareSchlosser]

I see, sorry! Thank you for pointing me to the right direction.

[lrq3000]

Note that it isn't enabled on the matrix.org server.

Why isn't it enabled on matrix.org?

[neilisfragile]

I'm confused by the expected behaviour of m.self_destruct.

In the section on server side behaviour, it seems like the server should redact the event on a per user basis based on when it receives a read receipt from that user. So the server ends up performing multiple synthetic redactions for a given event.

Once a given server has received a read receipt for this message from a member in the room (other than the sender), then the message's self-destruct timer should be started for that user. Once the timer is complete, the server should redact the event from that member's perspective, and send the user a synthetic m.redaction event in the room to the reader's clients on behalf of the sender.

but in the Proposal section it says

m.self_destruct: the duration in milliseconds after which the participating servers should redact this event on behalf of the sender, after seeing an explicit read receipt delivered for the message from all users in the room.

Which is something quite different, in that it if a given user never sees the message or their client does not send a read receipt the event will never be synthetically redacted.

The former seem preferable to me, thinking in terms of how this sort of feature works in other services. Separately it will be much hard to implement the latter in a robust manner.

@ara4n what was your intention?

[neilisfragile]

After irl chat we agreed that expiry messages from the client's perspective is the right way forward. We could even consider not sending the synthetic redaction and trust the client to handle it, though my sense is that we should.

So from the previous comment we will implement this:-

Once a given server has received a read receipt for this message from a member in the room (other than the sender), then the message's self-destruct timer should be started for that user. Once the timer is complete, the server should redact the event from that member's perspective, and send the user a synthetic m.redaction event in the room to the reader's clients on behalf of the sender.

[richvdh]

After irl chat we agreed that expiry messages from the client's perspective is the right way forward.

It would be great if the error in the definition of m.self_destruct could be rectified...

@timokoesters please could you make your comments on the document, so that there is some semblance of threading rather than everything getting mashed together in a linear conversation?

[cyanlemons]

@joepie91 Here's a simple threat model for you: either you or your recipient are trusted at the time of (and shortly after) the exchange of messages, but not in the future.

For instance, a whistleblower sends some confidential information to a journalist. Sometime after, the journalist is legally compelled to unlock his or her phone after landing in Sydney, Australia. The journalist complies with their archaic laws and the customs agents do not find any valuable information as all the confidential messages have already been automatically deleted.

Or, an individual is planning the exchange of cannabis for fiat currency through Matrix. The consensual exchange of goods takes place and everyone is satisfied. Sometime in the future, a law enforcement agent compels at least one of the two to unlock his or her phone – only to find nothing of relevance to the investigation as the messages pertaining to the exchange are long gone.

Or, an individual is sending explicit messages to his mistress. Later on, his wife takes a look at his unlocked phone whilst he is showering – only to find that he is the perfect husband who was, in fact, not sending anyone any inappropriate messages.

There are many situations wherein you, or your recipient, are trusted NOW, but this trust may expire at a moment's notice. The best way to reduce the attack surface is by periodically deleting the messages.

[jplatte]

I'd like to raise a concern about the place the new fields m.self_destruct and m.self_destruct_after are being introduced: By putting them in the content, statically-typed APIs for matrix have to update lots of type definitions to include them.

I probably don't know the full implications of instead having them on the event object root and updating the event sending endpoints to have them as additional (query) paremters. What I can come up with right now is that this would mean that try to create a self-destructing event on a homeserver that doesn't implement them would result in a non-self-destructing event being created, which seems bad. On the other hand, with the current version of this MSC, that case also wouldn't be handled that well – other clients would see a self-destructing event but the server would never redact it or send synthesized redaction events. Maybe sending a self-destructing event to a homeserver that doesn't have this feature should be made an error in some way?

Furthermore, I'd like to suggest that these new fields be valid for any message event, not for any event at all. I don't see what the value of this feature would be for non-message events and reducing the scope to message events should make implementing the MSC easier.

[pit711]

please enable in room7 on matrix

[jplatte]

I withdraw my concern about adding this to lots of events at once. We already have that in the form of m.relates_to.

Still I would prefer if this would be limited to message events (like m.relates_to maybe is too? at least its current uses don't make sense for state or non-DAG events AFAICT).

[turt2live]

This doesn't seem to be in a state where modern definitions of FCP qualify - pulling it back to the general review queue.

@mscbot fcp cancel

[jakewb-b]

@ara4n @richvdh Is this MSC intended to support:

• Redacting a message individually for each user as they read it.
• Redacting a message for everybody in a room, only once everybody has read it.
• Both

The proposal says that

m.self_destruct: the duration in milliseconds after which the participating servers should redact this event on behalf of the sender, after seeing an explicit read receipt delivered for the message from all users in the room

If it's counting from the moment when a read receipt is delivered from all users in the room, then I interpret that to mean that the counter only starts once everyone has read it, so it's then redacted for all users simultaneously.

But further on, it says

Once a given server has received a read receipt for this message from a member in the room (other than the sender), then the message's self-destruct timer should be started for that user. Once the timer is complete, the server should redact the event from that member's perspective

Which, to me, implies it's redacting on a per-user basis. That's reinforced by the point about potential shoulder-surfing.

Am I mis-reading/mis-interpreting this, or is there an inconsistency? Or is it that both scenarios are catered for?

[sundbry]

@jakewb-b @ara4n @richvdh

m.self_destruct: the duration in milliseconds after which the participating servers should redact this event on behalf of the sender, after seeing an explicit read receipt delivered for the message from all users in the room

Hi all. I think the second clause of this proposal makes the whole chat vulnerable to a bad client not sending message acknowledgements. self_destruct should just be a straight timeout when all clients and servers should delete the data. This should make the self destruct implementation simpler for everyone and less prone to data security bugs that way.

[jakewb-b]

Hi all. I think the second clause of this proposal makes the whole chat vulnerable to a bad client not sending message acknowledgements.

This is true, however there are a number of use cases for this that expect internal use within an organisation/agency/network, where everyone can be presumed to be on a compliant client.

Simple deletion after a fixed time period is also a desirable feature, but ideally I would want both.

[DMRobertson]

https://github.com/matrix-org/synapse/issues/12524 requests that support for this MSC be visible in the capabilities response.