[jonathanKingston]

Raw HTML could forge permitted footnote IDs and expose their original names on window; host extensions could also reopen arbitrary named properties through image name attributes. Apply a shared user-content- namespace policy to both sanitizers, rewrite matching fragment and ARIA references together, and strip name attributes even when host extensions admit or add them.

Footnote navigation, backreferences, message-specific prefixes, and repeated sanitization remain consistent across string and streaming DOM sinks. Sanitized IDs now carry user-content-; raw renderMarkdownUnsafe output retains its existing IDs. Document the reserved namespace and the remaining possibility of duplicate IDs within untrusted content.

Validation:

• npm test: 1,462 passed, 1 skipped.
• Full Chromium end-to-end suite: 22 passed, including 10 DOM-clobbering regression checks across DOMPurify and the native Sanitizer API.
• npm run typecheck and git diff --check passed.

---

Note

High risk
This changes the security boundary in src/sanitize.ts for both sanitizer backends and string/streaming DOM sinks, altering how untrusted IDs, names, and references are handled.

Overview

• The shared sanitizer gate now removes name attributes, including those admitted or added by host extensions, and places accepted footnote IDs in the reserved user-content- namespace.
• Fragment links and ARIA ID-reference tokens are rewritten to match isolated IDs, preserving footnote navigation and accessibility across repeated sanitization.
• Chromium end-to-end coverage now exercises DOM-clobbering cases across both backends and sinks; the e2e script includes the new suite.
• Security documentation and config comments describe the namespace policy, its host integration implications, and the unchanged raw renderMarkdownUnsafe output.

^{Summary by Copse Reviewer for commit 23c44d2. The review reported no issues. copse-review 0.1.0}