411–420 of 474 posts
Note: this person is the same 15-year old who found the Zendesk Slack takeover exploit a few months ago [1]. [1]: https://news.ycombinator.com/item?id=41818459
And that bug report to Adobe was made when they would have been five years old: https://hackerone.com/daniel?type=user
Earlier quoted context omitted.
> 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 ti…
I agree that having it in the header for everyone is maybe too obvious. But you could otherwise infer that from timing.
Why is that even the case? I had understood that (binary) attachments are embedded into the encrypted message and hence transferred directly from sender to receiver.
Obviously, retrieving media from an external location saves bandwidth at multiple positions. I am not a security expert, but it seems almost trivial to see how storing message data on an external server conceptually facilitates attacks like this one. Isn't that the same reason a link preview is generated at the sender first and then embedded into the message as an image?
Note: this person is the same 15-year old who found the Zendesk Slack takeover exploit a few months ago [1]. [1]: https://news.ycombinator.com/item?id=41818459
Given the twitter account was made in 2017, they would have been eight: https://x.com/hackermondev And that bug report to Adobe was made when they would have been five years old: https://hackerone.com/daniel?type=user
CDNs do not choose datacenters for users based on a geographic distance. The number one metric is latency but latency != physical distance. Second metric is optimizations of price of data transfer between peers and IXPs which results in very dynamic routing rules. Then consider also network/software hickups/maintanance and distribution of datacenters' load...
Would also work without anycast (and thus probably able to use a very dense botnet) and long list of NS entries for your domain.
For being 15 year old, cool work! But calling this de-anonymization is a stretch, if it can possibly pinpoint you within 250 miles (that's assuming geoip is correct too, which it rarely is). In their GeoGuesser demonstration video, the higlighted area is densely populated and you still would need to match millions of people vs the online user. It does provide some hints as to the location of the targeted user, and th…
The list of suspects would be fairly small when US officials cross-check individuals that travelled US-UK on Jan 4 and Germany-US on Jan 21.
Earlier quoted context omitted.
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.
The problem here is avatar URLs.
[0] https://www.bleepingcomputer.com/news/security/discord-will-...