A hosted subdomain a member gives up can be claimed by anyone the same minute #109

Open
opened 2026-09-21 07:18:32 +00:00 by cgalo5758 · 0 comments
Owner

What a person cannot do today

Release a member claim (a subdomain carved under the operator's shared domain, such as alice.<shared-domain>) without handing its audience to the next claimant. A claim can only be released once it has no placements (the rows that wire a domain to a site), so no content is exposed, but everything pointing at the domain survives: inbound links, other wikis' references, bookmarks, search results. The next holder inherits all of it, and the console issues them a certificate for that exact domain, by design.

External claims (a member's own domain) are not affected: re-claiming one means proving control of its DNS zone, and DNS is the tombstone. The exposure is only member claims, where the registry is the sole authority.

What they should be able to do

Release a domain and know it stays unclaimable for a quarantine period afterwards.

Why it matters

Inheriting a domain's audience is impersonation and traffic capture, and it needs no attack, only patience.

Where

internal/domains/registry.go, the occupancy check on claiming.

Done when

A member claim that ever carried a servable placement stays unclaimable for a configurable number of days after release. The data for it already exists, since terminal claims keep their status and timestamps. Decide explicitly whether the previous holder is exempt: re-claiming your own just-released domain is a plausible recovery from a mistake, and exempting them costs nothing because they already held it.

Migrated from status/issues.md at b7a0e15

## What a person cannot do today Release a member claim (a subdomain carved under the operator's shared domain, such as `alice.<shared-domain>`) without handing its audience to the next claimant. A claim can only be released once it has no placements (the rows that wire a domain to a site), so no content is exposed, but everything pointing at the domain survives: inbound links, other wikis' references, bookmarks, search results. The next holder inherits all of it, and the console issues them a certificate for that exact domain, by design. External claims (a member's own domain) are not affected: re-claiming one means proving control of its DNS zone, and DNS is the tombstone. The exposure is only member claims, where the registry is the sole authority. ## What they should be able to do Release a domain and know it stays unclaimable for a quarantine period afterwards. ## Why it matters Inheriting a domain's audience is impersonation and traffic capture, and it needs no attack, only patience. ## Where [`internal/domains/registry.go`](https://git.coopcloud.tech/wiki-cafe/member-console/src/commit/b7a0e15/internal/domains/registry.go), the occupancy check on claiming. ## Done when A member claim that ever carried a servable placement stays unclaimable for a configurable number of days after release. The data for it already exists, since terminal claims keep their status and timestamps. Decide explicitly whether the previous holder is exempt: re-claiming your own just-released domain is a plausible recovery from a mistake, and exempting them costs nothing because they already held it. Migrated from status/issues.md at b7a0e15
cgalo5758 added the
kind
enhancement
area/domainssecurity
labels 2026-09-21 07:18:32 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: wiki-cafe/member-console#109