Hacker News Reader

Comment by scottydelta | Hacker News Reader

How is it different than sending someone an image hosted on your server which is a tracking pixel and just get their IP+location?

This will be more accurate than the cloudflare approach.

View on HN

You can't instruct a random Signal client to fetch a random URL. Here's how this attack works:

1. Attacker sends novel image to Signal

2. Signal hosts the image on their core servers

3. Signal instructs victim to fetch preview of the image

4. Victim asks the CDN for the image

5. CDN gets the image from Signal core servers and caches it

6. Victim gets the image from the CDN and displays the preview normally

7. Attacker hits every one of the CDN cache servers

8. The CDN cache server that say "yep, saw that already" is the one closest to the victim

Can't you already see the IP of the datacenter that requested the image from your server/pixel and map it to the data center+location?

This is assuming the data center is directly requesting the source server which it might be given a few searches on Google [1].

[1] https://community.cloudflare.com/t/cloudflare-is-forwarding-...

Well, unlike with tracking pixels, you are not in the direct request path and cannot block it. You also have no way monitor/log if it is happening (like you can in theory with a packet capture).

It's obvious in hindsight, but I bet no one would have mentioned this possibility as why you should disable notification previews or that simply receiving a notification would possibly reveal this information.

If your target is savvy enough not to click random links sent by strangers, it's hard to get them to load it. Many apps have caught onto the tracking pixel technique. It used to work for iMessage long ago.

Reply on news.ycombinator.com