Hacker News Reader

Hacker News

Comment by ipaddr | Hacker News Reader

Parent Full thread

ipaddr

Going forward uploaded content should never go through cloudflaire and it never really needed to.

Add unique urls.

Maybe just avoid it altogether.

View on HN

> Going forward uploaded content should never go through cloudflaire and it never really needed to.

The problem in this case isn't cloudflare. The problem is that these images load without the user's interaction and the person sending it gets to choose if it's cloudflare or not. So your statement within this context doesn't really work.

The person receiving it chooses to download images or whatever automatically though.

I dunno, I'd still say the problem is at least 50% cloudflare. Why should they make which datacenters have a resource cached be obvious public knowledge? I do agree though, one could still end up inferring this information noisily by sending an attachment, waiting a while, and then somehow querying a lot of DCs and trying to infer times to see if it's cached or not.

Personally, I've never been a fan about so many things like URLs being so public. I get the benefits of things like CDNs and what not and the odds of guessing a snowflake value and what not, but still...all attachments in Discord are public. If you have a URL, you have the attachment. And they're not the only ones with this kind of access model.

Isn’t that because the URL parameters are so long that by design they effectively _are_ the password protection for the resource ? They shouldn’t be able to ‘leak’ to unintended recipients.

Personally, like you I’m also not a huge fan of this, but URLs like that basically should be treated as the passwords. Don’t post them publicly / don’t give them out to people you don’t trust.

There's a part of me that's fine with it for a short-lived URL which contains a temporary access key but for a forever URL with a forever access key I'm not entirely happy with it.

I use it to share memes and shitpost but definitely not something to share sensitive content IMO.

For signal then the issue becomes saving who owns what image (so that you can re-issue “passwords”) and THAT is much more dangerous to the users than simply allowing users to grab semi-anonymous links into their cdn with enough of a url to be nearly impossible to iterate through every combination without hitting tons of rate limits. (Ignoring this location cache timing issue.)

Edit: Actually... (in signal's case) it might be possible to provide the user's device 2 tokens, 1 to access the url and 1 to issue new access links. Then the user can request a new access link with their second token when their url access token expires. Signatures would help prevent it from needing to be stored in the database. It would be interesting to try.

Edit2: Also I am now curious... does this mean only text messages are e2ee? yikes.

Discord doesn't do forever URLs for attachments any more, they changed that a while back.[0]

The problem here is avatar URLs.

[0] https://www.bleepingcomputer.com/news/security/discord-will-...

This is good to know, thanks for sharing this knowledge.

My main gripe is that if someone finds a vulnerability that gives you a list of urls the model falls apart. I’ve seen this happen in organisations :/

But agree with your statement here and others about the lifetime of the data - if something is sensitive or secret you want proper access controls applied, not just openssl rand -hex 8

> Why should they make which datacenters have a resource cached be obvious public knowledge?

I agree that having it in the header for everyone is maybe too obvious. But you could otherwise infer that from timing.

Would removing cloudflare fix the issue? Then the problem is cloudflare related.

Your defense doesn't really work. Sure many entities could share blame but the one fix is getting rid of cloudflare.

Reply on news.ycombinator.com