It isn't caching, it's CDNing. It is just an artefact of CDNs that they act as caches for the original content, and for improved distribution response time they cache to the nearest server from the response. ('Nearest' being an approximate heuristic, it is property of the anycast route tables in the BGP routers the request passes through, it is actually a 'best route'.)

> it seems like CloudFront could very easily fix this by not returning the cf-ray header

Then you just look at the response time. If the resource needs to be fetched from another continent, this is probably reliably measurable

Same for websites trying to hide which users exist: do a login request for an existing username and it'll do the password hashing (usually adds at least 50 ms to the response time), whereas for an invalid username it early exits. The fix is to always run the same code, so always do the hashing, which very few sites do. (Or not care about revealing this and telling people straight out that their username is unknown, if that fits with your threat model.) So to get back to Cloudflare's case: it won't help unless they delay responses, which is the opposite of what they're supposed to do

I dont' believe the Signal app/network is choosing to cacheimages in a CDN?

But any user can send anyone other user a message that includes a link to a CDN-cached resource. Isn't that the "attack" here? Or am I misunderstanding?

Yes, Cloudflare should allow customers to disable that header, and Signal shouldn't cache images sent to a single person, or even groups of less than a few hundred people.

> the total number of requests for that resource should be very small

"For that server" is the other number-of-requests..

So that law enforcement can ask Cloudflare for the IP logs... Signal is a joke.

https://simplex.chat/