Document that presence has no built-in access control (eavesdrop/inject/hijack via channels) #738

Summary

Presence has no built-in binding between a presence channel and a document a client is authorized to read or write, and the docs don't spell out what receivePresence/sendPresence middleware must enforce. Three behaviours surprised me during a security review; all are controllable by middleware, but only if you know to, so this is primarily a documentation request (with one optional hardening).

For a doc-coupled presence the channel is collection + '.' + id, but nothing in core checks that a client subscribing to, or publishing on, that channel is allowed to read the underlying document.

Observed (see scratchpad/server/poc7-presence.js / poc7b-presence-inject.js)

1. Eavesdropping. A client that is denied fetch of docs/secret (via readSnapshots) can still ps the docs.secret presence channel and receive other clients' presence (e.g. cursor positions) for that document. Presence subscription runs no read check against the document.

2. Injection. A client can publish presence on docs.secret while supplying the c/d of a different document it is allowed to read. The server transforms/broadcasts it, and victims' DocPresence accepts it — neither server nor client verifies that c/d match the channel.

3. Hijacking. Remote presences are keyed only by the client-chosen presence id and ordered by the sender-chosen pv (lib/client/presence/presence.js, remote-presence.js). Anyone who learns a presence id (broadcast with every update) can overwrite another user's presence permanently by sending a higher pv (e.g. 1e15), and suppress the victim's real updates. The spoofed message also reaches the victim's own LocalPresence._ack, so a predictable pv can fire the victim's pending callbacks early.

Requests

• Docs: state clearly that presence has no implicit access control — subscribing to / publishing on a doc presence channel is not gated by document read/write permission — and that apps must enforce this in receivePresence/sendPresence middleware (verify presence.c/presence.d match the channel, and that the agent may read that doc). An example would help.
• Optional hardening: server-side, verify that a doc-channel presence's c/d are consistent with its channel; and consider namespacing remote presence keys by the sender's src so one client cannot overwrite another's presence id (relates to the src spoofing issue).