Assuming local client-side caching, the total number of requests for that resource should be very small, probably one in the vast majority of cases.
On an unrelated note, it seems like CloudFront could very easily fix this by not returning the cf-ray header, or at least having an option for the customer to remove it. Although, it might still be possible to get that information based on timing information...
The Cache-Control http header has a `private` directive specifically to inform CDNs and similar not to cache the response.
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
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?
"For that server" is the other number-of-requests..
Theirt defaults are set so they can get mass market addoption, whilst beeing a big step up in privacy compared to the usual players in the space (like whatsapp and telegram). You simply won't be able to get the average user on apps that make use more complicated and apps like simplex doe exactly that.
If you want Signal to be more secure, you can circumvent this attack vector by disableing auto downloads for media.
I'm not saying Signal is perfect, there has been a bunch to critisize over the years.
But why argue about use cases they never claimed to solve?