Cool writeup with some interesting techniques and approaches!
I'll echo the other comments and say "deanonymization" is stretching the definition of the word, along with "grab the user's location", as it isn't anything near precise. 150 miles is approx. a 2-hour drive on the highway from Atlanta, GA to Augusta, GA. In that radius, there's probably 700,000+ people.
I do think the auto-retrieve attachment feature of Signal is slightly concerning, as for a private messenger I'd expect there to be an option to turn it off (like turning off JS in Tor). I don't know if I'm not looking deep enough, but there doesn't seem to be a feature for that.
Signal appears to take a useful-by-default approach that balances privacy and ease-of-use in order to encourage adoption by the masses, I'd assume most people that are really concerned are hardening Signal, similar to what is in this guide: https://www.privacyguides.org/articles/2022/07/07/signal-con... . They've always recommended a VPN / proxy + a modification of settings for more high-security scenarios.
Caching isn't going anywhere, and neither is CloudFlare. The DoSing days of old in P2P multiplayer lobbies with exposed IPs seemed to carry more of a threat than this, CloudFlare's response seems to be the best out of the 3. Caching sensitive information is never recommended and the onus is on the application doing the communicating to tell their CDN / middle-service to not cache specific items.
> "deanonymization" is stretching the definition of the word, along with "grab the user's location", as it isn't anything near precise.
You'd think so, but you would be surprised how quickly this adds up to other details people share, like "oh I just drove 15 minutes to get Starbucks" or something to that effect, small things that eventually add up to a precise location over time.
Yes, but if social engineering is involved and tracing back through user conversations across a platform, it's hardly a vulnerability, let alone one deserving of a bounty. The way this is currently functioning is intended functionality, and can be further locked down depending on the user's threat model.
This can essentially be classified as opsec failure for the Signal user. If they're trying to hide from a hit in a 300 mile radius, they've got bigger problems to worry about, and should already be using a VPN setup.
Every time you click on a link your external IP addresses is exposed, is this a vulnerability? Being online without a VPN / proxy is inherent consent to have your external IP & other required items to be shared with services / middlemen.
When it comes to Discord, if you have this strict of a threat model and you're still using it, idk what to tell you.
Blaming the user is sometimes what it boils down to. Security includes a balancing act that involves usability, and Signal is firstly targeting the masses, but includes settings that can be configured for high-risk scenarios.
This "vulnerability" requires the user to have none of the normal things a person with a more extreme threat model would have already configured. EZPZ guides online on locking down Signal.
It's just like an iPhone. They don't ship with Lockdown Mode enabled by default, as it hurts the average consumer's usability. Signal at minimum will ensure no one is snooping on your messages, and it's up to the user whether they want to take that further.
If your definition of not providing security is allowing someone to know they exist on a continent, then that user's ISP has performed terribly as well since they aren't bouncing their signal around the world by default.
> Blaming the user is sometimes what it boils down to.
At least we agree about your argument. :)
> Signal at minimum will ensure no one is snooping on your messages, and it's up to the user whether they want to take that further.
Signal also secures metadata, including the participants in the conversation. That is undeniable - they have gone through considerable development investment to provide that feature.
> that user's ISP has performed terribly
Now we're blaming the ISP. If your app doesn't work with your users and ISPs, who does it work for? And how does a non-technical end-user know whether or when to trust you?
The comment says:
Every time you click on a link your external IP addresses is exposed, is this a vulnerability? Being online without a VPN / proxy is inherent consent to have your external IP & other required items to be shared with services / middlemen.
The fact that a user's IP is exposed when they click on a link is only relevant to the original post if a user would do this automatically and without realizing. The original post alleges that they can send someone a message on Signal and have the user automatically and somewhat unknowingly load a resource from a server. Sure, the author doesn't claim they have much control over the resource or the server, but they do show how you can check which server the user accessed and how that leaks information about the location of the user to a certain extent.
> When it comes to Discord, if you have this strict of a threat model and you're still using it, idk what to tell you.
I mean, you just never know... I've seen a lot of wild things, I've seen what drives people to doing crazy things. Just look up the "Deadly Runescape E Dater" who flew from the US to the UK to stab the girl he e-dated.
You can disable the auto-download. Settings > Data and storage > Media auto-download, you can choose what to auto download for mobile data/wifi/roaming.
Thank you! That's what I get for quick scrolling through the settings. I for sure thought it would have been under Privacy (for this concern), but that makes sense too.
So, just to confirm my understanding, if one goes into those settings and disables all auto-download, that helps- but, then a user will manually download images, correct? Are they still vulnerable to this issue then at that time?
A user might download images and yes, if they download images Cloudflare will show which datacenters have cached that image. They might also install an APK you give them or run that taylor_swift_concert.mp4.exe as well.
If I host an image on Cloudflare and put the URL here, I'll know which CF datacenters are near HN users who bother clicking the link as well.
I'll echo the other comments and say "deanonymization" is stretching the definition of the word, along with "grab the user's location", as it isn't anything near precise. 150 miles is approx. a 2-hour drive on the highway from Atlanta, GA to Augusta, GA. In that radius, there's probably 700,000+ people.
I do think the auto-retrieve attachment feature of Signal is slightly concerning, as for a private messenger I'd expect there to be an option to turn it off (like turning off JS in Tor). I don't know if I'm not looking deep enough, but there doesn't seem to be a feature for that.
Signal appears to take a useful-by-default approach that balances privacy and ease-of-use in order to encourage adoption by the masses, I'd assume most people that are really concerned are hardening Signal, similar to what is in this guide: https://www.privacyguides.org/articles/2022/07/07/signal-con... . They've always recommended a VPN / proxy + a modification of settings for more high-security scenarios.
Caching isn't going anywhere, and neither is CloudFlare. The DoSing days of old in P2P multiplayer lobbies with exposed IPs seemed to carry more of a threat than this, CloudFlare's response seems to be the best out of the 3. Caching sensitive information is never recommended and the onus is on the application doing the communicating to tell their CDN / middle-service to not cache specific items.