Hacker News Reader

Comment by cloudbonsai | Hacker News Reader

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.

View on HN

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?

Reply on news.ycombinator.com