Hacker News Reader

Comment by JumpCrisscross | Hacker News Reader

> But a central design decision for constructing URLs has made the links easy to discover. As a result, researchers from security firm Claroc said they were able to enumerate 6,800 links Muse users created for sharing conversations with others.

To be clear, did the users intended for these conversations to be shared with someone? Meta just created a guessable capability URL?

Or were all Muse users' conversations by default public, just behind an obscure URL?

View on HN

It seems that Meta assigns a unique hostname to each shared conversation. For example:

> fiscal-review-b4a5ff.cf.metaaiusercontent.com

So when someone opens the link, the DNS resolution exposes the unique hostname. The original bug reporter found dozens of these URLs in passive DNS logs.

That is remarkably amateur. I'm not a software engineer by trade nor have worked at a billion dollar company, but knew that to be a bad design within seconds.

It doesn’t strike me as inherently bad. Using a new domain for each conversation is novel, but it certainly enables many techniques. For example what if the shared conversations can contain AI-generated interactive code? Then the browser will enforce isolation (cookies, CORS etc) if you just put the parent domain into the public suffix list. It’s a tradeoff that isn’t clear cut. And it’s definitely more work doing it this way.

You can have all the benefits of both if you use a different magic name for the domain--a random domain, no english from the chat--and then also have the unguessable url path. Expose nothing without valid unguessable stuff in the url.

> It doesn’t strike me as inherently bad

It should! DNS is mostly public and therefore shouldn't be used to hold non-public information. Everyone (should) know TLS-protected paths are superior for privacy. The secondary issue is they used low-entropy guessable DNS records at that.

The domain-isolation advantages you mention are easily accomplished by using both a unique, high-entropy subdomain and a long unique path, but rach problem should be addressed individually with explicit goals and not just vibed. Also, aggressively rate-limit probers.

You are just describing more tradeoffs. Look we all agree that there’s insufficient consideration of tradeoffs and there are strictly better solutions.

> DNS is mostly public and therefore shouldn't be used to hold non-public information.

This is just not true if someone is coming from enterprise IT, where DNS requests stay within the corporate network, or if MDM solutions enforce the use of DNS over TLS/HTTPS. I could see it as an honest mistake when someone came to implement this from a different background.

> The secondary issue is they used low-entropy guessable DNS records at that.

The DNS records do contain an unguessable part and they aren’t low entropy.

I get the sense that people on HN just like to dunk on the guy who came up with the design. We should always blame the processes such as insufficient review that lead to this bad outcome. Next time when you make an honest mistake because you didn’t know about something, you should also be treated with respect.

> I get the sense that people on HN just like to dunk on the guy who came up with the design

I can't speak for anyone else - but I'm dunking on the organization that failed to catch this - at multiple stages - before it was rolled out.

Bad prompting plus a weak review process?

I remember back when Facebook was still .edu email addresses only (2004 or 2005 maybe), and my university got access, we discovered you could just grab the user id of another user from their public profile, and paste it in place of your own user id on your own profile, and get access to their profile as if it was your own.

A lot of early 2000s websites are like that. I remember a chat site has something similar: you can view DMs between two other users if you log in with your own account, get a valid cookie, and then substitute parts of the URL.

Sounds like it's the former: URLs are guessable/easily enumerable but their contents protected by auth unless they're "published" using the share feature

Imagine I have a link of this format:

https://cf.metaaiusercontent.com/q3-revenue-review-7b1e42f0

No one can guess that URL. The q3-revenue-review-7b1e42f0 part is only ever shared with the Meta's server (protected by TLS).

Now imagine the URL is instead:

https://q3-revenue-review-7b1e42f0.cf.metaaiusercontent.com/

The first step for my computer to open that link is to do a DNS query, which immediately shares the entire URL (minus the `https://` and the `/`) with my ISP's DNS server (and anyone sniffing traffic along the path, as DNS queries are usually sent in plain text).

Thanks. It wasn't clear to me what the actual issue was from the headline.

Reply on news.ycombinator.com