I've been seeing a few requests for Vanishing Message (or "self-destructing messages") for the fediverse. So I think it's important to say this, as simply and clearly as possible...
Vanishing Messages are Privacy Theatre:
What's Privacy Theatre? Like Security Theatre for privacy:
https://flameeyes.blog/2014/07/22/privacy-theatre/
Why do I say that Vanishing Messages are Privacy Theatre?
Let's unpack this a bit...
(1/?)
First, let's talk a bit about end-to-encryption (E2EE).
The reason for using E2EE is that you don't trust the people operating the servers you're using. In a centralised service (eg WhatSapp, TellMeGram, Wire, Signal), you have to trust the operators to roll out the E2EE competently, and to *not* backdoor it. So unless there's some way to independently confirm that the server operators have done that, using E2EE on a centralised service is pure privacy theatre:
(2/?)
The same things that's true of End-to-End Encryption (E2EE) on a centralised service is also true of Vanishing Messages. You have to trust the service operators to honour the promises made by the app. But if you trust the service operators , why do you need E2EE or Vanishing Messages? So again, adding these features to centralised services is just privacy theatre. Nothing more.
So what about decentralised networks?
(3/?)
In a decentralised network, unlike a centralised service, it is possible to confirm that End-to-End Encryption (E2EE) is working.
Because if two servers aren't both implementing the E2EE protocol properly, it just won't work. The messages won't be sent, or they won't be delivered, or they won't be decrypted, or whatever. The need to communicate between two servers keeps the operators of both honest.
So what about Vanishing Messages then?
(4/?)
One problem with Vanishing Messages in decentralised networks is that you have to trust that the server(s) you're sending messages to will honour whatever requests you send them later about those messages. Including requests to delete them.
A server could send back a receipt claiming to have deleted the message, but how do you really know? Maybe it did delete the message from the chat, but kept a copy in the database? Or copied it to another database.
You just have to trust it.
(5/)
In summary, if you trust the server, there's no need to worry about making your messages vanish. If you don't trust the server, there's no way to be sure that it doesn't keep your messages, except to not send them in the first place.
Vanishing Messages add pointless complications to decentralised networks, for no real privacy gain. We don't need them and they're a waste of developer time and resources, and network resources.
So that's why I say Vanishing Messages are Privacy Theatre.
(6/6)
@mensrea
> assuming a trusted server
... which you can't really, unless it's yours (or operated by someone you know and trust) and not federated with one that isn't.
> to keep your inbox tidy
This doesn't require the message to be deleted anywhere but in the UI.
> the vanishing messages feature was for: if the device was compromised after sending
Fair point, I'll have to think about that one. That might actually be a legitimate use case.
Disclaimer: I'm not saying that Vanishing Messages are bad, or wrong. Nor am I saying that app developer, like the Wire or Element teams, ought to be criticised for adding them. There may be uses for them that I haven't considered, such as one given by @mensrea upthread.
What I am saying is they do not and cannot do what a lot of people concerned about their message privacy seem to think they can do. So apps developers ought *not* to be criticised for not adding them.
@mensrea
> the vanishing messages feature was for: if the device was compromised after sending
Me:
> Fair point, I'll have to think about that one
So I thought about it. I think I addressed in the comment here about the theoretical possibility of end-to-end deletion?
@[email protected] > cannot by forgetfulness leave more than n days of our chat history on their device This presumes that both the server *and* the client app respect the deletion request. My point is that there is no obvious way to guarantee a message deletion or to confirm it (without asking your contact). That said, if there's a way to do end-to-end deletion - such that your trusted contact's app receives the delete request and does it regardless of the server - that would be a different matter.
@strypey
Yes, agree 100%.
There are far more important things to do for #privacy, #I2P integration being an obvious one, including recognition of '.i2p' URLs.
Really basic stuff.
I2P integration is a must — even argueably the slowest moving project on the planet, bitcoin, has had I2P support for over a year now!
(EDIT scope fix)
@strypey it's not privacy/security theater, it's just targeting a completely different threat model than the one you are describing.
I might trust the server, but not my family, partner, the cops, or others who I share my device with, or who could gain access to my device.
For this threat model, e2ee is mostly irrelevant, but vanishing messages are much more useful.
e.g. if I trust a server to delete messages, they don't need to be e2e-encrypted so the police can't find them anymore.
@strypey personally, I don't need the fediverse to support this. There are e.g. bots which people use to delete their old posts.
But it's the main reason why in most of my security trainings I can't recommend Matrix or XMPP apps, and why @delta is the better option for many threat models/security-relevant use cases.
So it depends a lot on the exact threat model or use case, as in any security topic.
@compl4xx
> targeting a completely different threat model
Your thoughts on:
https://mastodon.nzoss.nz/@strypey/110865589026707378
?
> if I trust a server to delete messages
So you're talking about someone using the same server you are, one that you both trust? In which case, an XMPP or matrix homserver could be perfectly suitable, as long as your accounts are on the same one, and you trust the operator.
Doesn't delta.chat create exactly the same issues? You'd need to be using it with accounts on the same mailserver.
@[email protected] > cannot by forgetfulness leave more than n days of our chat history on their device This presumes that both the server *and* the client app respect the deletion request. My point is that there is no obvious way to guarantee a message deletion or to confirm it (without asking your contact). That said, if there's a way to do end-to-end deletion - such that your trusted contact's app receives the delete request and does it regardless of the server - that would be a different matter.
@strypey the deletion is executed by the app, not by the server. But yes, both apps need to be trusted. The server just needs to be trusted that it respects the IMAP delete command of an e2e-encrypted email.
Anyway, in the threat models I described you can indeed trust all involved apps and server. Like in most real world cases, the threat is a social challenge, not a technical one. Technology just has to offer the means to defend against the social threat.
@compl4xx
> in most real world cases, the threat is a social challenge, not a technical one. Technology just has to offer the means to defend against the social threat
I totally agree. In fact, you could say that was a subtext in my rant to which you were replying. There are many things devs could spend their time on that would bring much greater benefits.
@Brendanjones
> What about not trusting the network over which your messages are sent? Or the service where your chat backups are stored? E2EE also good there
It's not bad. But it's also not required. SSL/TLS takes care of encrypting connections between client and server, and server-to-server. What it *doesn't* do, is encrypt the payload in a way that stops any server operators in the chain from reading it in plaintext.
@dick_turpin
> It allows people to do harm without fear of the offending Toot being produced
Screenshots?
@dick_turpin
> Most users are not as technically skilled as you or I
I thank you for your assumption that I am technically skilled : )
> they would expect to be able to go to the offender's profile and go, "There! SEE!"
The fediverse has post deletion. It federates, but we have to trust every server that's received it to honour it. Some people have tools that auto-delete their posts after X time. Trolls can also use Block (on accounts and whole servers) to revoke access to their posts.
@dick_turpin So now that I think about it, my whole thread was kind of nonsense. But when I said Vanishing Messages, I was thinking of some of the particular implementations from other apps like Wire, that some people like, and want fedi apps to add.
As I said in my conclusion, this is a lot of effort for minimal return, and IMNSHO we have much higher dev priorities (eg portable accounts, better moderation and opt-in search tools).
@strypey LOL
You obviously don't know my stance on Moderation?
The moment someone says we need a moderator, you need to say to yourself: "There goes my Freedom."
Personally, I'd prefer EVERYONE to have their own instance thus making everyone responsible for their own moderation.
Mute & Block are your friends. 🙂
@dick_turpin
> The moment someone says we need a moderator, you need to say to yourself: "There goes my Freedom."
You'd get on well with @jeffcliff ; )
I really can't be bothered debating this again. Forget I mentioned moderation and focus on the point of the post, which was not that.
Strypey
cuan_knaggs
Dick Smiths Fair Go Supporters
Nami
Brendan Jones
dick_turpin 
