[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABMkiz5Fh9tiBgJFD8g4nZWOAz5PLGYDVuXXEa6FGWds6QY7KA@mail.gmail.com>
Date: Thu, 12 Sep 2019 17:17:26 +0100
From: Ben Tasker <ben@...tasker.co.uk>
To: oss-security@...ts.openwall.com
Subject: Re: Telegram privacy fails again.
On Thu, Sep 12, 2019 at 4:43 PM Solar Designer <solar@...nwall.com> wrote:
> Sender-imposed message deletion or expiry is necessarily unreliable: the
> recipient might have taken a copy of the message prior to deletion e.g.
> by taking a picture of the device's screen. This should be clearly
> communicated to users of such features.
>
> However, it gets worse. Sure, a reasonably informed sender knows they
> effectively trust the recipient not to bypass the message deletion
> or/and knowingly accepts the risk. But do they also realize the deleted
> message can possibly be extracted from the device(s) by a third-party
> later? This, too, should be clearly communicated.
>
> And, speaking of intended behavior, a question is: to what extent should
> the messenger app protect deleted messages from possible recovery?
> Another question is: to what extent such protection is even possible?
>
>
Just as a practical example - this happens automatically on my phone. I
have the nextcloud app set up to watch various directories for new images -
including the one that Whatsapp writes images into.
So if you send me an image and immediately use the delete functionality,
it's probably already too late. If it's reached my phone then Nextcloud
already has a file handle open on it and will be busily sending a copy up
to my server.
So there needn't be a deliberate per-image/file action by the receiver
either, nor need there necessarily be bad faith involved.
IMO, If Whatsapp/Telegram wanted to take this functionality more seriously,
they'd need to be writing the images to disk in an encrypted form from the
outset. It increases the overhead of display, and wouldn't necessarily stop
forensic recovery etc, but it would mean that other apps couldn't simply
watch the directory and upload anything which appears in it in a usable
form. That's a whole other can of worms though as it's another set of keys
to manage.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
