mstdn.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
A general-purpose Mastodon server with a 500 character limit. All languages are welcome.

Administered by:

Server stats:

16K
active users

There's a "Signal deanonymized" thing going around:
gist.github.com/hackermondev/4

Stay calm. Deep breaths.

👉 while this is a real consideration, the only thing the attacker gets from this is a very rough (kilometers or tens of kilometers radius) location

👉 other communication platforms that use any kind of caching CDN to deliver attachments are just as affected

👉 you almost certainly should continue to use Signal, unless you specifically know that this is a big problem for you.

Unique 0-click deanonymization attack targeting Signal, Discord and hundreds of platform - research.md
GistUnique 0-click deanonymization attack targeting Signal, Discord and hundreds of platformUnique 0-click deanonymization attack targeting Signal, Discord and hundreds of platform - research.md

In other words, it's not great that this is possible, but nowhere near an immediate and present danger to anyone except a very very small group of people doing very very specific things.

If you're in that group, you'd already known you are. You'd have someone to ask about this. And you'd almost certainly be using some other tools to anonymize yourself anyway.

If that's not the case, then this is almost certainly not something to lose sleep over. Signal remains a safe choice of a secure IM. 👍

If you are still worried about this, my read of it is that these things might make the attack more difficult:

👉 turn off automatic downloading of media files

This makes this attack rely on you clicking the image to download it, making it very difficult for the attacker to know when to check for the cached status of the resource.

This is important, because for each attachment the attacker can only ask this question once per the period Cloudflare caches these resources (not sure exactly).

You can also:

👉 turn off push notifications – this makes the attack rely on you clicking the chat to download the image

👉 turn off read receipts – again, this makes it more difficult for the attacker to know when to ask the question they can only ask once per a specific period of time

👉 use Signal over Tor or a VPN to obscure your actual location – the attacker would get the rough location of the exit node

Technical details tl;dr:

- Signal (and other communication platforms) uses Cloudflare with caching enabled for media

- one can check on which Cloudflare endpoints a given attachment URL got cached (one can use a VPN for this), giving them the ability to roughly geolocate users whose Signal downloaded the file

- a doctored version of Signal (or whatever app) allows the attacker to send the message with an image, and extract the attachment URL to know what URL to check for having been cached

Michał "rysiek" Woźniak · 🇺🇦

- images usually get downloaded automatically (and thus get cached on Cloudflare side)

- push notifications make this a 0-click thing, as the targeted user doesn't even have to click on a conversation to have the image downloaded

I believe this technique would work against any communication app that uses any global CDN that does endpoint caching and provides the caching status in HTTP headers of the response.

I'd like to hear what @signalapp has to say about all this. There is a claimed response from Signal in that gist file, but I'd like to see it come directly from Signal before I form an opinion.

@rysiek

Didn't they already give a responding statement? That's what 404Media are reporting.

@signalapp

@jrredho @rysiek

I'd like to see a public statement from @signalapp too. Too many people ate this clickbait already, and they start being annoying.

Otoh, why would one need a caching CDN for one time delivery of an encrypted payload? #signalapp is a private messaging app, not a content broadcasting tool. Or is it?

@rysiek @signalapp excellent analysis. Fully agree that this attack doesn't match the average user's threat model and great suggestion that the probe can be eliminated by disabling read notifications. I would add that this is more of a Cloudflare bug. They should fix this.

@freddy @signalapp I tend to agree, but I would expect Signal to push on them to fix this.

And by "fix this" I mean "stop broadcasting cache status and POP site location in HTTP response headers all the time".

@rysiek Which is why my expectation until now was that they just simply don't outsource that. And if they did, that they made sure that it passes a basic laugh-test. But to use clownflare? And declare it to be out of scope because it is "up to users to hide their identity" (from a company that hard-verifies your phone number no less!) wtaf. But eh... one trust-us-pinkie-promise-company hand in hand with another pinkie-promise-company.
Very entertaining, from an outside perspective 🍿

@rysiek@mstdn.social CDNs confirmed once more to be a liability if anything. Stop using garbage like Cloudflare, stuff like this keeps happening. Its a shame that Signal uses it and doesn't see an issue.

@rysiek this would work even without the cache status in the response.

you can infer the status from latency observations.

@rysiek

I'll also note that apps don't have to use CDNs for images and thus could get REALLY, REALLY specific information about your location. The fact that CDNs are prevalent is a privacy feature.

Of course, any app on your device of choice could report all sorts of information about your device and you. Use a web version when you can. They're not perfect, by any stretch, but it requires more effort and devs are lazy.