An Unguessable AI Share Link Can Still Be Found

You ask an AI assistant to share a conversation with a colleague. It gives you a long link with a random ID. You send it privately and move on.

The link may be hard to guess. That does not mean it is hard to discover.

Claroc's GhostShares research describes this gap in Meta Muse's sharing design. The important detail is where the conversation title and random ID appeared: inside a hostname that DNS infrastructure could observe.

Shared pages, not private-chat access

Claroc says users had asked Muse to create these shares. The resulting pages generally opened without a login for anyone holding the link.

That is a link-sharing model, not evidence of a broken account password or access to conversations that were never shared. But deliberately sharing with one colleague does not necessarily mean understanding how strangers might discover the address.

Claroc did not contact the people involved, so it cannot establish their intended audiences.

After filtering scan noise, the researchers counted more than 6,800 share hostnames in one commercial passive-DNS dataset. They opened a few hundred pages, finding mostly ordinary content and a minority containing sensitive personal or business material.

That is not 6,800 confirmed sensitive conversations or affected users. It is a hostname count from one discovery channel. Quartz's reporting describes the same research, not a separate forensic investigation.

There is also an important update. Claroc says Meta told Ars Technica on October 20 that it was suspending the feature. Claroc rechecked 40 previously accessible shares that day; none opened, and their content hostnames returned errors. The researchers say the hostnames, including titles, remained in DNS history.

That supports a limited follow-up observation, not proof that every copy disappeared or every underlying design issue was fixed. Claroc reports no evidence of misuse. I have not independently reproduced its findings or accessed the user shares.

How a link crosses into DNS

DNS helps a browser find the server for a hostname. It does not need the URL path or the conversation text.

According to Claroc, Muse's content hostnames contained both the conversation title and the random ID. Those same parts were enough to reconstruct the share link.

Here is an invented example using reserved .example domains:

Share link:
https://assistant.example/s/project-plan-RANDOM_ID

Content hostname:
project-plan-RANDOM_ID.content.example

The top-level link keeps the title and ID in a path. But loading its content can still trigger a DNS lookup for a hostname containing both.

A resolver observing that lookup sees the hostname. If observations reach a passive-DNS dataset, someone with access to that dataset may find it later. The random ID has not been cracked. It has been recorded.

DNS is not a universal public directory of every page. Collection depends on which systems observe queries, their data-sharing practices, and the dataset's coverage. Some services are commercial rather than freely searchable.

Still, the DNS privacy analysis in RFC 9076 explains why query names deserve careful treatment. A normal page load can generate DNS requests for embedded content as well as the address in the browser bar.

Why familiar protections do not solve this

HTTPS encrypts the HTTP request, including its path, in transit. It does not stop the selected DNS resolver from seeing the name it must resolve.

Encrypted DNS, such as DNS over HTTPS, protects the connection to that resolver. It does not hide the queried name from the resolver itself.

Long random IDs resist guessing. They cannot help if the full identifier appears in an observable hostname.

Crawler controls address another layer. Claroc says Muse used robots.txt to discourage crawling, but its discovery method did not need a search engine.

Google's noindex documentation explains how to keep pages out of supported search results. Neither noindex nor robots.txt authenticates a visitor or removes passive-DNS records. Blocking a crawler can also prevent it from seeing a page's noindex instruction.

The lesson is not that these controls are useless. It is that they protect different things.

Safer URL design starts with less information

Do not put conversation titles, email addresses, customer names, or bearer secrets in hostnames. A title can reveal a sensitive subject even after the page stops loading.

For a conventional share service, a less revealing shape is:

https://share.example/s/OPAQUE_TOKEN

DNS sees share.example, not the token. This closes that particular discovery route, but the full URL can still reach browser history, application logs, analytics, screenshots, or link-preview systems.

If the page renders untrusted generated content, do not casually sacrifice browser-origin isolation to simplify the URL. Per-share hostnames can use opaque labels that reveal no title and are not themselves sufficient to authorize access. Protect the underlying content separately.

For sensitive conversations, prefer authenticated, named recipients. The server should check the viewer, the share's scope, expiry, and revocation on every relevant request, including backing APIs and attachments. A login screen over an otherwise public content endpoint is not enough.

If anonymous links are necessary, treat them as credentials: narrowly scoped, revocable, and short-lived. Make the audience explicit before publication and show exactly which messages and attachments will be shared.

Headers help, but they are not the lock

For sensitive share responses, useful supporting headers include:

Referrer-Policy: no-referrer
Cache-Control: no-store
X-Robots-Tag: noindex

Referrer-Policy controls what the browser sends in its Referer header. Modern defaults usually limit cross-origin referrals to the origin, but an origin already contains the hostname. A title embedded there can therefore leak even without a full-path referrer.

no-referrer reduces that channel; it does not alter DNS. no-store tells compliant caches not to store the response; it cannot recall screenshots or copies. noindex remains a request to supporting crawlers, not access control.

Keep share tokens out of telemetry, avoid unnecessary third-party scripts, and check what preview bots and scanning integrations retain. Do not submit sensitive share links to public scanning services.

Test the audience, not just the button

Use a synthetic conversation you own, with a harmless unique marker. Create a share and inspect the top-level URL, generated resource hostnames, and network requests.

Then test it logged out, as an unintended account, and after expiry or revocation. Check attachment and API endpoints too. Confirm that the server denies access rather than merely hiding the content in the interface.

If a title escaped into DNS history, revoking the share can stop new requests from retrieving the page, but it cannot guarantee removal from third-party records. Disabling sharing on managed devices also does not revoke pages already published.

A better sharing promise is concrete: these people can read these messages until this time, and access can be withdrawn.

"Anyone with the link" is a different promise. Its security depends on every place that link, and anything needed to reconstruct it, can travel.

Sources

• Claroc: GhostShares, including the October 20 update
• Quartz: Shared Meta Muse links found through DNS records
• RFC 9076: DNS Privacy Considerations
• Google Search Central: Blocking indexing with noindex
• MDN: Referrer-Policy

Hero photo: PO boxes at the historic Chico Post Office (2024)-L1005460, photographed by Frank Schulenburg on May 13, 2024. CC BY-SA 4.0. Resized from 8312 x 5937 to 1920 x 1371 pixels and JPEG-compressed; the adapted image remains under the same license. Illustrative photograph of physical mailboxes, not Meta infrastructure or evidence from the research. No endorsement is implied.