[Sites] Public site URLs can unexpectedly expose account-linked identifiers

What issue are you seeing?

Publishing a Site creates a public hostname in the form:

https://<site-slug>.<account-linked-namespace>.chatgpt.site

The account-linked namespace can match a user's ChatGPT username or another account/profile identifier. A user who chooses to publish a site may reasonably expect the selected site slug and the site content to become public; they may not expect an account identifier to be embedded in the hostname. The publication flow does not give a sufficiently prominent warning or separate consent for that identity disclosure.

This creates an unexpected correlation between an otherwise independent project and the user's ChatGPT identity. It may also allow separate public Sites to be correlated with one another. This is a privacy-by-default problem even when the site's content contains no personal information.

What steps can reproduce the bug?

1. Use a ChatGPT account whose username/profile identifier is not intended for publication.
2. Create a Site and choose a neutral site slug unrelated to the account identity.
3. Select public publication.
4. Inspect the generated chatgpt.site hostname.
5. Observe that the hostname includes an account-linked namespace, without a clear pre-publication warning that this identifier will become public.

What is the expected behavior?

Publishing a Site should not silently expose an account-, login-, username-, or email-derived identifier in its public URL.

Safer options include:

• Use a random, opaque, non-identifying tenant namespace.
• Let users choose a separate public publishing handle.
• Display the exact public hostname and an explicit privacy warning before publication.
• Allow the generated hostname to be changed or disabled, especially when a custom domain is active.
• Ensure deletion fully retires the generated hostname and its identity association.

Additional information

This report intentionally omits all real usernames, email addresses, site hostnames, project IDs, and screenshots. Private evidence can be provided through a secure support channel if needed.

Related to #35112, which concerns URL stability after username changes. This report concerns unexpected identity disclosure at initial publication and lack of informed consent.

Start by tracing the Sites public-publication flow and hostname generation described in the reproduction steps, then compare the behavior with related issue #35112. Verify whether the account-linked namespace is exposed and whether publication shows the exact hostname with a clear privacy warning or consent step. Done means the unexpected identity disclosure is addressed and the resulting behavior matches an explicit safer publication policy.