Signatures make forgery impossible, but two places in the spec let a malicious or compromised server change what readers see by rearranging or withholding individually-authentic data, undetectably.
1. Post timeline (§10)
seqts — the ordering and pagination backbone — is server-assigned and explicitly excluded from the signature (§10.1, §10.3).createts, the only authenticated timestamp, is optional.- The "no gaps between oldest and youngest returned item" guarantee and the
more flag (§10.4) are pure server assertions.
A hostile server can therefore reorder a profile's history, silently drop posts, or serve different subsets to different readers (split view), without breaking any signature. Suggestions:
- Make
createts required and require clients to display/order by it (or at least flag large seqts/createts divergence). This is cheap and removes the server's ability to rewrite history order.
- Consider an optional integrity chain for detection of withholding: e.g. each signed post includes the hash of the profile's previous post, or the profile periodically publishes a signed timeline digest. Either turns "silently dropped post" from undetectable into detectable by any client (or any two readers comparing notes).
2. Private-array merge order (§11/§11.3/§11.4)
The private array is necessarily stripped from the outer signature (§11.4), and §11 merges decrypted blocks "in the order they appear in the private array" (merge mechanics defined in §11.3) with last-write-wins semantics. The composition is therefore unauthenticated: a server can swap the positions of two individually valid encrypted blocks and change the merged result (e.g. flip which of two email values a reader sees). Suggestion: require an authenticated ordering criterion inside the signed plaintext (sequence number or timestamp per block) and define the merge over that, rather than over array position.
Related clarification request
§10.2 computes the post-reference hash over the object after merging whatever private blocks the reading client could decrypt. Two readers with different access levels then compute different hashes for the same post, so a comment's ref may validate for one audience and fail for another. If intentional, it deserves a note; it currently reads like an unintended consequence.
*Disclosure: these findings came out of an AI-assisted review of the spec; I have verified the cited sections against the current master text.*
Signatures make forgery impossible, but two places in the spec let a malicious or compromised server change what readers see by rearranging or withholding individually-authentic data, undetectably.
1. Post timeline (§10)
seqts— the ordering and pagination backbone — is server-assigned and explicitly excluded from the signature (§10.1, §10.3).createts, the only authenticated timestamp, is optional.moreflag (§10.4) are pure server assertions.A hostile server can therefore reorder a profile's history, silently drop posts, or serve different subsets to different readers (split view), without breaking any signature. Suggestions:
createtsrequired and require clients to display/order by it (or at least flag largeseqts/createtsdivergence). This is cheap and removes the server's ability to rewrite history order.2. Private-array merge order (§11/§11.3/§11.4)
The
privatearray is necessarily stripped from the outer signature (§11.4), and §11 merges decrypted blocks "in the order they appear in theprivatearray" (merge mechanics defined in §11.3) with last-write-wins semantics. The composition is therefore unauthenticated: a server can swap the positions of two individually valid encrypted blocks and change the merged result (e.g. flip which of twoemailvalues a reader sees). Suggestion: require an authenticated ordering criterion inside the signed plaintext (sequence number or timestamp per block) and define the merge over that, rather than over array position.Related clarification request
§10.2 computes the post-reference hash over the object after merging whatever private blocks the reading client could decrypt. Two readers with different access levels then compute different hashes for the same post, so a comment's
*Disclosure: these findings came out of an AI-assisted review of the spec; I have verified the cited sections against the current master text.*refmay validate for one audience and fail for another. If intentional, it deserves a note; it currently reads like an unintended consequence.