Skip to main content


There’s been some chatter about Signal desktop recently, so let’s clear the air. Three points:

1. The reported issues rely on an attacker already having *full access to your device* — either physically, through a malware compromise, or via a malicious application running on the same device. This is not something that Signal, or any other app, can fully protect against. Nor do we ever claim to.

reshared this

in reply to Meredith Whittaker

2. We continue working to harden our desktop build across supported operating systems and take advantage of new platform capabilities as they emerge. Those of you following our repo can follow this work there.

3. The posters who raised this issue did so without contacting us directly. Instead, they went straight to social media, in some cases using inflammatory language. And they dropped these claims over a US holiday weekend. This is the opposite of responsible disclosure.

This entry was edited (4 months ago)
in reply to Meredith Whittaker

We ask those who are serious about security and privacy to please engage us directly in the future, instead of resorting first to online claims that can confuse non-experts and lead people to make unsafe choices and develop inaccurate mental models based on scary language. We monitor security@signal.org carefully and respond to all legitimate reports.
in reply to Meredith Whittaker

After reading "trust me I'm lying" asking for this feels like asking water to not be wet. Anyone that knows security would realize that an exploit that requires full system access isn't really an exploit but non-news. So it feels like emotional click farming, with no regards whatsoever for actual fact checking.
in reply to Meredith Whittaker

Hi Meredith, let me address your points:

1) The issue we highlighted does not require “full” access to the device. Signal desktop stores the chat database in an unprotected area of the file system that’s accessible by any user process. This would allow any program without any special permissions or user prompts to access the database in full. This can be solved by sandboxing, which relies on the OS to prevent any process from accessing data within the sandbox.

… 🧵 1/4

in reply to Meredith Whittaker

Seems like the only difference between "Mysk" and "Musk" is one letter off.
in reply to Meredith Whittaker

Wasnt this first disclosed in 2018?

bleepingcomputer.com/news/secu…

Seems like its been on the back burner for a while and just recently resurfaced.

in reply to Meredith Whittaker

There are mentions of this security issue in your issue tracker, going back as far as 2015.
in reply to Meredith Whittaker

I am deeply worried by how you are trying to misrepresent and distort this situation. Your words are damaging my trust in Signal a lot more than the actual security issue at hand.

You claim that the attack "requires full access" (it only requires read-only access), that it cannot be avoided (other messaging clients protect against this particular scenario), and that is was disclosed irresponsibly (the issue was mentioned and circulated on twitter a year or two ago).

in reply to Meredith Whittaker

"US holiday weekend"? sorry to say, but such a thing is irrelevant to ~95% of the world popoluation.
in reply to Meredith Whittaker

Thanks for your reaction.
If I'm not mistaken, it's not "full access" that is required though (i.e., no root password is necessary to access the sqlite database and the password).
Leaving such a sensitive information accessible to *any* process is sloppy.
in reply to Meredith Whittaker

Since mobile OSes have much stronger sandboxing, and Signal on desktop OSes will always be more likely vulnerable to malware, would you consider at least indicating that I’m talking to someone that has Signal on PC vs not?
This entry was edited (4 months ago)
in reply to Meredith Whittaker

The scenario that has been mentioned lately is "an attacker with temporary read-only access to the filesystem can copy session data and hijack the session indefinitely without any indication".

This CAN be mitigated, and plenty of other messaging applications have done so for many years. The most obvious solution to this particular problem is using the platform-specific keyring to store the session token so that it is encrypted at rest.

in reply to Meredith Whittaker

I want to make it clear that it is theoretically possible to prevent this attack, that many other messaging clients prevent against it, and even alternative clients to Signal's network prevent it.

Flare (an alternative Signal client) DOES protect against this specific attack: gitlab.com/Schmiddiii/flare/

Your claims of "This is not something that Signal [...] can protect against" is complete BS.

in reply to Meredith Whittaker

Well, the logic doesn't make sense as to why you encrypt local messages but not media then, does it?
in reply to Meredith Whittaker

Yeah no, this post is a big miss and reeks of sh*t. Just because OSes already have disk encryption that can be enabled, doesn't mean Signal shouldn't also at the very least, give the option to also encrypt the files that are saved/cached/whatever.

Maybe some missed the option to encrypt their system and can't be arsed to reflash their entire OS again - like me, I didn't see any option in the Debian installer to encrypt the disk or the home folder, and forgot about it, so now I'm currently not in the mood to literally reinstall the system again to manually encrypt it.

I know very well that this is risky if someone had access to the hardware, but I would have felt better if Signal Desktop was also encrypting the files.

I stopped using Signal, mostly due to its centralised manner, and the phone number requirement, and this issue that apparently has been known for years and not getting fixed, is certainly not pushing me to use Signal again. Do better.