Who else sees their deleted messages on WhatsApp that shouldn't be there?(twitter.com)
twitter.com
Who else sees their deleted messages on WhatsApp that shouldn't be there?
https://twitter.com/Pytlicek/status/1445072626729242637
19 comments
FWIW, WhatsApp doesn't know what is in your messages... including your messages that are telling other users to delete messages. They are just an event queue. Personally I don't think they should have implemented "delete" at all as it implies that other users are going to play along with your deletion requests, which is not only totally out of their control but morally shouldn't even be a thing: once you send me a message it is MY data, not your data, and you don't get to delete it unless I agree. It maybe seems awkward that a re-delivery of a deleted message is causing it to resurrect temporarily until the delete event is also re-delivered, but if they "actually delete it"--which I imagine you want--then they might also forget any unique identifier stored with the message, which likely makes it hard to know that this message was both already received and deleted in the past.
Right, I'm not familiar with their data model or even features, since I don't use it, but bottom line is that users are probably not in control of the data, and what you see in the app is just a client app reconstruction based on your actions and preferences. It sounds that's what you're alluding to.
> but if they "actually delete it"--which I imagine you want--then they might also forget any unique identifier stored with the message, which likely makes it hard to know that this message was both already received and deleted in the past.
I would expect any messaging app to work like email, where you're also in control of the email server. Once you receive someone else's message, it's in your inbox, and you can delete it forever as well. The email message model is more intuitive, and I would love for modern instant messaging clients to work the same way except in real time. Of course when you have that level of control, you would need to make it paywalled or subscription of some kind.
> but if they "actually delete it"--which I imagine you want--then they might also forget any unique identifier stored with the message, which likely makes it hard to know that this message was both already received and deleted in the past.
I would expect any messaging app to work like email, where you're also in control of the email server. Once you receive someone else's message, it's in your inbox, and you can delete it forever as well. The email message model is more intuitive, and I would love for modern instant messaging clients to work the same way except in real time. Of course when you have that level of control, you would need to make it paywalled or subscription of some kind.
I think you might be mixing up two features here. One is deleting a message from your own inbox (this part about your email example makes sense).
The other is deleting a message that was sent to someone else from _their_ inbox. Which email does not allow you to do.
Except some clever people tried to implement this (notably Outlook and/or Microsoft Exchange has such a feature IIRC) where it sends another email to "recall" the earlier message. It's funny when you receive those recall messages in a non-Microsoft email client and on a different server than the Exchange sever they're using. I.e. you just ignore their request to recall and now you _really_ go read the message they're trying to recall, because it makes it _more_ interesting. Also googling this quickly it seems even if you stay completely within the Microsoft ecosystem it only works if the recipients didn't open the original email yet:
The other is deleting a message that was sent to someone else from _their_ inbox. Which email does not allow you to do.
Except some clever people tried to implement this (notably Outlook and/or Microsoft Exchange has such a feature IIRC) where it sends another email to "recall" the earlier message. It's funny when you receive those recall messages in a non-Microsoft email client and on a different server than the Exchange sever they're using. I.e. you just ignore their request to recall and now you _really_ go read the message they're trying to recall, because it makes it _more_ interesting. Also googling this quickly it seems even if you stay completely within the Microsoft ecosystem it only works if the recipients didn't open the original email yet:
With message recall, a message that you sent is retrieved from the mailboxes of the recipients who haven’t yet opened it.
Right, well in concept that feature is silly. It would be like paying USPS to remove some letter from a physical mailbox. At some point you need to commit to the message.
Regardless what I'm really saying is that it's all probably smoke and mirrors on the client server (plus client UI). The server is probably configured to keep all messages anyway, and it gets "tombstoned" and not sent by the middle tier server. I don't know of course, but I was talking about how users are not really in control as they think they are.
Regardless what I'm really saying is that it's all probably smoke and mirrors on the client server (plus client UI). The server is probably configured to keep all messages anyway, and it gets "tombstoned" and not sent by the middle tier server. I don't know of course, but I was talking about how users are not really in control as they think they are.
To map this to e-mail: if you receive an e-mail from me, and you delete it, but my e-mail infrastructure--the part on my end, not on your end--isn't sure I really sent it because the servers are flaking out and having tons of errors, and it retries the delivery, what would normally be an idempotent operation (because of how the e-mail you received twice will have the same message identifier) will cause the e-mail to re-appear... specifically because you have no record of having received it; and to make this even "cooler": if you use one of those dishonest "recall e-mail" features that people keep wishing existed (but not only can not should not), and the other side has already received both the e-mail and the recall, but the sender's SMTP server is still attempting to retry the messages, you will receive the e-mail, see it deleted, and then later see the e-mail again and see it deleted again. Is this really so hard to understanding? WhatsApp is nothing but an e2e event queue: it isn't a server that is storing data on your behalf... all of your messages are local to your phone, and with the exception of the shitty "delete for everyone" feature that WhatsApp implemented, your data is your data and the server knows nothing because it is just trying to deliver encrypted events on behalf of other people (who would, of course, own those queues, just like e-mail... but it is encrypted, so whatever weird mental model you have where this is somehow a bad thing terrifies me as to fix the weird issue you have would involve removing the encryption by adding permanent identifiers to queue objects that were visible to WhatsApp and then exposing to their server all of your otherwise-local message storage intentions).
> your data is your data and the server knows nothing because it is just trying to deliver encrypted events on behalf of other people
Yes I'm sure that is the feature on paper. There's no way to know (unless there's a leak or something) but I'm willing to bet this isn't really the case and there are backdoor keys to this encryption, if anything to comply with whatever government wants, as has been the case with Apple and iPhone encryption in the past already.
The email model was just an example of how, in my opinion, it should be simple and straight forward. We're just talking about people sending text to other people, just like email. The only difference is on the client side, so how fast it happens and what kind of interface is presented with features to interact with the data. Ideally like owning your own email server, you would control not just the interface but the database with the data as well. This could mean some redundant messaging if the other server decides to send it again, but that isn't really a problem.
Yes I'm sure that is the feature on paper. There's no way to know (unless there's a leak or something) but I'm willing to bet this isn't really the case and there are backdoor keys to this encryption, if anything to comply with whatever government wants, as has been the case with Apple and iPhone encryption in the past already.
The email model was just an example of how, in my opinion, it should be simple and straight forward. We're just talking about people sending text to other people, just like email. The only difference is on the client side, so how fast it happens and what kind of interface is presented with features to interact with the data. Ideally like owning your own email server, you would control not just the interface but the database with the data as well. This could mean some redundant messaging if the other server decides to send it again, but that isn't really a problem.
Don't you think this is some sort of caching or something in your WhatsApp client?
Since WhatsApp is unreachable, how would your client "retrieve" your deleted messages?
Who knows. I use PiHole where all DNS records are cached (not chats, nor messages). Maybe this is the reason why it happens to me. And regards Twitter (obviously), I'm not the only one who is facing this weird behaviour.
Wow this is a massive breach of trust if true. I am assuming it is some unintentional side effect or bug rather than intentional deception, but still, for a privacy oriented service this is bad.
Look here: https://twitter.com/Pytlicek/status/1445085177475223559
I made a few screenshots. This is really really weird :/
I recommend sharing this on some of the other prominent threads about the Facebook outage, here and on Reddit, so that it gets attention and a response.
I mean... It's some screenshot of white boxes. I'll believe him but I think the messages were stored on his phone (with a flag to say "message expired, don't show to user"), but to make a believable claim for more people you're going to need to show more than white boxes.
If you really trust whatsapp to "delete" things, that's probably the problem.
Oh shit. This is BIG!!!
This whole industry is meant to harvest user information. Richard Stallman tried to warn us. Jaron Lanier called it "siren servers", because they hypnotized people into using their services. I hope this encourages people to question this and and to look for alternatives.