5 ms·

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 th

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.

quotemstr 2y ago
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
- scottydelta 2y ago
  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-me-datacenter-ips-for-some-reason-instead-of-real-user-ips/728910 https://community.cloudflare.com/t/cloudflare-is-forwarding-...
0xCMP 2y ago
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.
iforgot22 2y ago
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.

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.

quotemstr 2y ago

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

scottydelta 2y ago
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-me-datacenter-ips-for-some-reason-instead-of-real-user-ips/728910 https://community.cloudflare.com/t/cloudflare-is-forwarding-...

0xCMP 2y ago

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.

iforgot22 2y ago

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.