DP24 - Cross-Layer Resilience and Compromise Containment

Changes to the anchored passage

DP24 decides whether the Meta-Layer is a trustworthy coordination layer or simply the web’sweb's weaknesses reproduced one level higher.

Changes to the anchored passage

- Which lower-layer compromises should the Meta-Layer be expected to withstand, and which are outside its protection boundary?
- What minimum guarantees should every conforming extension, SDK, web embed, and federated service provide?
- How can communities verify one another’sanother's security claims without a central certification authority?
- How can security improvements spread quickly across the federation while respecting local autonomy?
- What evidence is enough to claim that an implementation satisfies DP24?
- Can the shared launcher be standardized at the browser level, so the page cannot imitate it at all?
- How should the launcher behave on mobile and in-app browsers, where screen space is smallest?
- Should the Meta-Layer honor a signal from a site that does not want to be annotated, and if so, which signal, and with what exceptions?
- When participants at the same address see different content, whose version does an anchor describe?
- Who maintains the page behavior registry, and how is a site’ssite's listing contested?

Changes to the anchored passage

An implementation must not claim DP24 alignment if a webpage can trigger a privileged action, if credentials are readable from the page, if its client draws over or imitates another client’sclient's launcher entry, or if it moves annotations to different text without telling readers.

Changes to the anchored passage

- Meta-Layer services MUST authorize privileged actions independently of webpage content and client-supplied claims.
- Meta-Layer clients MUST keep credentials out of any context readable by host-page scripts or other extensions.
- Meta-Layer services MUST check agent actions against authenticated, scoped, and revocable delegation.
- Federated services MUST NOT accept privileges from another community without verifying them.
- Implementations MUST produce tamper-protected audit evidence for security-critical operations.
- Implementations MUST define and test containment and recovery procedures, including participant notification.
- Meta-Layer clients MUST fail closed for privileged actions when a security check cannot complete, and MUST tell participants.
- Meta-Layer clients MUST register with a shared launcher when one is present, and MUST NOT cover, reorder, or imitate another client’sclient's entry.
- Meta-Layer clients MUST perform authority-bearing actions only in surfaces the host page cannot draw over or read.
- Meta-Layer clients MUST detect when an anchored passage has changed, MUST NOT silently reattach an annotation to different text, and MUST show detached annotations with their original quote.
- Meta-Layer clients MUST tell participants what the current page supports before they write.
- Implementations MUST publish their threat model, protection boundary, limitations, and evidence of adversarial testing.

If any of these is missing, the implementation’simplementation's security depends on the honesty of the systems beneath it.

Changes to the anchored passage

- promise that the Meta-Layer stays secure or available when every layer beneath it is compromised
- protect participants on a device whose operating system is compromised
- prevent a host page from drawing lookalike elements inside its own area; it requires that authority-bearing actions happen where the page cannot
- mandate a browser, extension framework, attestation technology, or security vendor
- create a central certification authority
- guarantee that every page can be annotated; it requires that participants are told when one cannot
- replace DP13’sDP13's containment dimensions or DP15’sDP15's supply-chain and provenance requirements

Changes to the anchored passage

- **DP1 (Federated Authentication & Accountability)** establishes who can act and how actions are attributed; DP24 keeps that attribution intact when adjacent systems are compromised.
- **DP2 (Participant Agency and Empowerment)** gives participants real controls; DP24 makes sure the controls they see are genuinely the Meta-Layer’s.Meta-Layer's.
- **DP4 (Data Sovereignty and Privacy)** gives participants control of their information; DP24 keeps that control from being bypassed through lower layers.
- **DP7 (Simplicity and Interoperability)** lets tools plug in freely; DP24 ensures that interoperability does not transfer authority, and that plugged-in clients share the screen by rule.
- **DP11 (Safe and Ethical AI)** and **DP13 (AI Containment)** define acceptable agent behavior and its enforceable limits; DP24 makes sure those limits survive manipulation from lower-trust environments.
- **DP12 (Community-based AI Governance)** decides who sets the rules; DP24 keeps compromised layers from changing them.
- **DP14 (Trust and Transparency)** and **DP15 (Security and Provenance)** make information and software verifiable; DP24 adds isolation, containment, and recovery across the architecture.
- **DP21 (Multi-modal)** and **DP23 (Universal Participation & Linguistic Interoperability)** set access requirements that shared overlays must meet.
- **DP22 (Civic Memory & Epistemic Continuity)** preserves accountable records; DP24 keeps them reconstructable after compromise, and keeps annotations attached to what their authors actually saw.

Changes to the anchored passage

Each privileged request carries a short-lived, scoped capability that the service verifies. The client’sclient's own view of its permissions is never trusted.

Changes to the anchored passage

- With three conforming clients loaded on one page, does any launch icon cover another or a host-declared reserved region?
- Can a sibling extension place an icon over a conforming client’sclient's launcher entry, or imitate it, without being detected?
- Can every authority-bearing action be completed only from a surface the host page cannot draw over?

Changes to the anchored passage

- overlay launch icons from different extensions stacking on and covering one another and the host site’ssite's own controls
- uncertainty about whether a sign-in prompt belongs to the overlay or to the page
- concern that AI agents can be steered by content on the pages they read
- distrust of security claims that cannot be checked
- worry that one compromised community or extension could reach all of a participant’sparticipant's communities
- annotations failing to stay attached on pages without stable anchors

Changes to the anchored passage

- **placement capture:** a client vendor pays or negotiates for a better position in the launcher or overrides the participant’sparticipant's arrangement
- **certification capture:** a single reviewer becomes the gatekeeper for what counts as secure
- **security as lock-in:** a platform uses resilience requirements to exclude independent clients
- **advisory weaponization:** a community issues false advisories to quarantine a competitor

Changes to the anchored passage

**Example:** A participant sees an unfamiliar entry in the launcher claiming to be their community client. They open the browser’sbrowser's side panel, which shows that the entry’sentry's signature does not match the community client’sclient's publisher. They report it in one action, and the community quarantines the impersonating extension for its members.

Changes to the anchored passage

- see which Meta-Layer clients and agents are active on the current page, who publishes them, and what authority each holds
- confirm that a surface asking for a sign-in or approval is genuine
- arrange, hide, or remove any client’sclient's launcher entry
- revoke a client’s,client's, session’s,session's, or agent’sagent's authority immediately
- see when protections are reduced and which ones
- see what the current page supports – passage notes, page-level notes, reading only, or nothing – and why
- see when a note’snote's passage has changed or its anchor has detached, and read the original quote
- report a suspected compromise and receive a traceable response

Changes to the anchored passage

### 9.5 Annotation and the host site’ssite's autonomy

Annotating a page without its owner’sowner's permission is part of what makes the Meta-Layer independent. It also means the Meta-Layer depends on pages that owe it nothing and may change, block, or resist it. Showing a detached note honestly, or declining to anchor at all, is preferred to anchoring that only appears to work.

Changes to the anchored passage

An anchor records more than one way of finding its passage – the quoted text with words before and after it, its position, its place in the page’spage's structure – following the selector model of the W3C Web Annotation Data Model ([W3C, 2017](https://www.w3.org/TR/annotation-model/)). It also records a fingerprint of the passage at the time of writing.

Changes to the anchored passage

**Example:** A participant opens a design tool that draws its text on a canvas. The overlay shows “Notes"Notes on this page attach to the page, not a passage”passage" before the participant starts typing, instead of accepting a passage anchor that will fail for every reader.

Changes to the anchored passage

- **re-rendered pages:** application frameworks replace page elements on every update, and generated class names change between releases, so anchors based on page structure stop matching
- **partially loaded pages:** long lists and feeds keep only the visible rows on the page, and collapsed or lazily loaded sections are absent until opened, so the anchored passage may not exist when the client looks for it
- **changing text:** relative timestamps, counters, rotating content, experiments, and personalized or regional versions mean two participants at the same address may not see the same words
- **edits and repeats:** the passage is revised, or the same words appear more than once on the page, so a quote alone cannot say which occurrence was meant
- **navigation without reloading:** single-page applications change the address without loading a new page, and a client that does not notice keeps showing the previous page’spage's annotations
- **reflow:** resizing, zoom, reader modes, and translation or theming extensions rewrite or move text, breaking any anchor based on screen position
- **no text to anchor:** text drawn on a canvas, content inside closed components or cross-origin frames, and media such as PDFs, images, and video need region or time anchors, not text anchors

The same content can also live at many addresses, through tracking parameters and mirrors, and different content can live at one address. A page’spage's declared canonical address helps, but it is a claim made by the page.

Changes to the anchored passage

- Actions that carry authority – signing in, approving, posting as the participant, granting agent permissions – happen in surfaces the host page cannot draw over or read, such as the browser’sbrowser's own side panel or toolbar.
- Clients give participants a way to confirm that a surface is genuine, such as a check reachable only from the browser’sbrowser's own interface.
- Launcher registrations are signed by the client’sclient's publisher, so a lookalike entry can be detected and flagged.

Changes to the anchored passage

- Each client declares the screen regions it intends to occupy. Clients do not overlap another client’sclient's declared region.
- Host pages can declare reserved regions, such as their own chat, consent, or checkout controls. Clients keep out of them.
- When regions conflict and cannot be negotiated, clients fall back to a deterministic order: the participant’sparticipant's arrangement first, then registration order. Raising one’sone's own stacking order to win a conflict is non-conforming.
- When no conforming launcher is present, a client places its icon away from occupied regions and offers to join a launcher as soon as one appears.

Changes to the anchored passage

- The participant chooses the launcher’slauncher's edge and position, the order of entries, and which clients are shown, hidden, or pinned.
- The arrangement persists per participant and, where the participant chooses, per site.
- No client can move itself ahead of others, enlarge its own entry, or hide another client’sclient's entry.

Changes to the anchored passage

- The first conforming client on a page hosts the launcher. Clients loaded later find it and register with it instead of drawing their own.
- Each registration declares the client’sclient's name, icon, publisher, and requested actions.
- If the hosting client unloads, another registered client takes over hosting without losing the participant’sparticipant's arrangement.

Changes to the anchored passage

Meta-Layer clients share two scarce things: the participant’sparticipant's screen and the participant’sparticipant's trust in what appears on it. This section sets rules so that several clients can coexist on one page without covering, crowding, or imitating one another.

Changes to the anchored passage

- Meta-Layer clients do not break, alter, or slow the host page beyond what rendering the overlay requires.
- Meta-Layer clients do not carry data from one site into another site’ssite's context without the participant’sparticipant's explicit action.
- Meta-Layer clients respect regions the host page declares as reserved for its own controls (Section 7.3).

Changes to the anchored passage

- Peers coordinate through declared interfaces only. No client reads another client’sclient's interface, storage, or messages.
- Peers do not imitate one another. A client that copies another’sanother's icon, name, or visual identity is non-conforming.
- Coordination conveniences between peers, such as the shared launcher in Section 7, never become trust anchors.

Changes to the anchored passage

| Relationship | The upper layer may rely on | The upper layer must never inherit |
|---|---|---|
| Client ← device and OS | Execution and display, which cannot be avoided | Assurance that a compromised device is safe (declared out of scope) |
| Client ← browser | Sandboxing and origin isolation | Assumptions beyond the browser’sbrowser's documented guarantees |
| Client ← host website | The page’spage's content, as data | Any authority, credential access, or ability to speak for the participant |
| Services ← client | Authenticated requests | Trust in client-supplied claims about permissions or identity |
| Community ← federated community | Signed assertions that can be verified | Privileges the other community cannot prove under its own policies |
| Agent ← content | Information to summarize or analyze | Instructions or expanded authority |

Changes to the anchored passage

**Example:** A host page sends a message to an overlay claiming the participant has approved a post. The overlay treats it as a request and asks the participant, because only the participant’sparticipant's own action, verified by Meta-Layer services, can approve it.

Changes to the anchored passage

- Federated services MUST NOT accept privileges asserted by another community without verifying them against that community’scommunity's published keys and policies.
- Implementations MUST define containment and recovery procedures for detected compromise: isolate, revoke, notify affected participants, restore.
- Security-critical operations MUST produce audit evidence protected against tampering and disclosed in proportion to privacy (DP4).

Changes to the anchored passage

- Meta-Layer services MUST check every agent action against the agent’sagent's authenticated delegation at the point of execution.
- A malicious page, compromised service, or manipulated model MUST NOT be able to expand an agent’sagent's authority beyond its legitimate delegation.

Changes to the anchored passage

- Meta-Layer clients MUST keep credentials and session material out of any context the host page’spage's scripts can read.
- Meta-Layer clients SHOULD bind sessions to the device or client instance, so a copied token cannot be replayed elsewhere.
- Meta-Layer services MUST be able to revoke a session, key, or delegation within minutes, and clients MUST honor revocation.

Changes to the anchored passage

- Meta-Layer services MUST authorize every privileged action on the server side, independently of webpage content and of claims supplied by the client.
- Meta-Layer clients MUST NOT grant privileges to content because it was displayed, interpreted, or relayed.
- Agent runtimes MUST treat page content and tool outputs as untrusted data, separate from the instructions of the agent’sagent's accountable principal.

Changes to the anchored passage

**Example:** A participant visits a compromised news site while taking part in a signed-in Meta-Layer conversation about the page. The site tries to impersonate other participants, extract credentials, alter the overlay, and steer an AI agent. It remains an untrusted source of content. Its scripts gain no authority over the participant’sparticipant's identity, private conversations, community resources, or agent permissions. Where one attempt does succeed against a component, the damage is contained, evidence is preserved, and recovery begins.

Changes to the anchored passage

**Example:** A participant anchors “this"this claim is false”false" to a sentence on a product page. The site later replaces the sentence with a competitor’scompetitor's claim, keeping the same wording at the start and end so the anchor still matches. Readers now see the participant appearing to call the competitor a liar.

**Why this matters:** An anchor is a statement about someone else’selse's page. If the page can change what the anchor points at without anyone noticing, the page can put words in a participant’sparticipant's mouth.

Changes to the anchored passage

**Example:** An overlay copies the page’spage's form contents into a shared context visible on other sites the participant visits.

Changes to the anchored passage

Several well-behaved overlays each place a launch icon in the same screen region, covering one another and the host page’spage's own controls. This failure is not malicious.

**Example:** A participant runs three Meta-Layer clients. All three place their icon in the bottom-right corner, over each other and over the site’ssite's chat button, and the participant can reach only the top one.

Changes to the anchored passage

**Why this matters:** Federation multiplies reach. Without boundaries, one community’scommunity's compromise becomes everyone’s.everyone's.

Changes to the anchored passage

**Example:** An overlay extension’sextension's publisher account is phished, and a new version that forwards every message the participant reads is pushed to all installations overnight.

Changes to the anchored passage

**Example:** A coupon extension places its launch icon exactly over a community overlay’soverlay's icon and opens its own panel when the participant meant to open their community conversation.

Changes to the anchored passage

**Example:** An overlay stores a session token where the host page’spage's scripts can read it. A compromised advertising script on that page copies it and replays it from elsewhere.

**Why this matters:** Stolen credentials turn a single compromised page into persistent control over a participant’sparticipant's identity across every community they belong to.

Changes to the anchored passage

**Example:** A product review contains hidden text telling any summarizing agent to post the participant’sparticipant's private notes to a public thread.

**Why this matters:** An agent that treats encountered content as instruction lets any page author borrow the agent’sagent's authority.

Changes to the anchored passage

**Example:** A news page renders a fake sign-in prompt styled exactly like the participant’sparticipant's overlay and collects their recovery phrase.

**Why this matters:** If participants cannot tell the Meta-Layer’sMeta-Layer's surfaces from the page’s,page's, every protection behind those surfaces can be bypassed by asking the participant directly.