The locked room with no door
Constructed opening claim. “Only the right people can read this manuscript.”
The sentence may name a worthy aim. It also hides the question that makes the aim operational: who are the right people, how did they become members, what can each person do, how can a legitimate person recover access, and what happens when a role changes?
An encrypted editorial space is often imagined as a locked room. The image is useful until it becomes too simple. A manuscript review is not a static object sealed once and left untouched. Editors arrive, authors leave, a legal reader may be invited for one issue, a copyeditor may need to see one chapter but not another, and a lost device or inaccessible login can make a permitted participant unable to work. The more carefully access is protected, the more consequential these transitions become.
The design task is therefore not to choose between confidentiality and collaboration. It is to describe an arrangement in which both are made answerable. Strong privacy controls may support sensitive editorial work. They may also introduce membership, key, recovery, role, permission, accessibility, and handoff burdens. Declaring a system “secure” or “frictionless” before those conditions are named hides the work that makes either word meaningful.
Knabenhans, Maradni, and Troncoso’s 2026 work on end-to-end encrypted collaborative documents is useful because it treats security and functional requirements together, then demonstrates a real-time prototype for a defined journalism setting. [1] It does not certify a product or establish the best workflow for editors. It gives this paper a formal restraint: encrypted collaboration is not just encrypted text. It is a system of group membership, edit reconciliation, and deployment requirements in a particular setting.
This paper introduces the Editorial Access Arrangement Canvas, an original Wexley teaching instrument for one bounded collaboration group. It records a review purpose, material boundary, member and role conditions, access path, change path, recovery condition, accessibility condition, record and metadata questions, and unresolved risk. It cannot guarantee confidentiality, select a service, approve a person, certify compliance, or decide whether a group is safe enough. Its task is smaller: make the relations inside “only the right people” visible.
Encryption does not settle membership
End-to-end encryption concerns who can access protected content at the communication endpoints. It does not independently decide who ought to be an endpoint. This distinction is vital in editorial work because the phrase “the team” can conceal different responsibilities: author, coauthor, developmental editor, copyeditor, researcher, sensitivity reader, fact-checker, legal adviser, designer, translator, archivist, or temporary reviewer.
The Messaging Layer Security protocol describes groups whose members share changing cryptographic state, with membership evolving through epochs. [2] Its technical detail is not a governance model for a magazine, press, or author collective. It does, however, foreground an important question that a simple locked-room metaphor misses: membership is a process. Adding, removing, and recovering a member are not exceptional events tacked on after privacy; they are conditions through which privacy is enacted.
An editorial group should therefore state:
- the material boundary: which manuscript, folder, comment set, attachment, or conversation is within the arrangement;
- the review purpose: what collaboration is being enabled, for whom, and for how long;
- the member boundary: which roles are currently included and why;
- the change path: how role entry, exit, and correction are recognized;
- the recovery condition: how a legitimate participant can regain usable access without silently widening access; and
- the non-conclusion: what the arrangement does not establish about trust, legality, authorship, or safety.
These statements do not make an arrangement secure. They prevent an access design from being treated as self-explanatory.
A permission is not the same as a usable path
Suppose a reviewer is formally authorized to read a manuscript. If the person cannot use the authentication flow, cannot obtain a required recovery code, cannot operate a key-management step with their assistive technology, or cannot understand an unexplained access request, the formal permission has not created a workable collaboration path.
The accessibility point is not a request to weaken confidentiality. W3C’s guidance on accessible authentication warns that authentication and recovery paths can impose cognitive-function burdens, and it emphasizes available methods that do not rely solely on remembering or transcribing information. [6] The guidance applies to web content and does not certify a private editing system. Its narrow relevance here is that security-sensitive steps remain interface steps. A path can be carefully protected yet unusable for a legitimate editor.
Whitten and Tygar’s historic evaluation of PGP 5.0 supplied a durable warning that technically strong encryption can fail in practice when ordinary users cannot perform the relevant security actions successfully. [5] It is not evidence about current tools, accessibility, or editorial groups. It does not support the claim that encryption is inherently unusable. It supports a more careful question: what does this arrangement ask a real participant to understand, keep, choose, recover, and verify?
No answer should be inferred from a feature name such as “encrypted,” “private,” or “zero knowledge.” The Canvas asks instead for observable role and path conditions.
Recovery creates an editorial tension, not an automatic exception
Loss, device replacement, role transition, illness, travel, and accessibility needs make recovery an editorial reality. A design that offers easy recovery may introduce another holder, channel, or process. A design that refuses recovery may make a legitimate contributor unable to participate or leave the group without a usable record. The proper response is not to assume that one side always wins. It is to name the recovery purpose and its boundary.
NIST’s key-management guidance discusses key protection, access control, authentication, continuity, and the possible need for key recovery. [4] It is federal guidance and cannot dictate an author’s practice. It gives one restrained lesson: loss and recovery are management concerns that should be described before an incident, not invented after one.
The important word here is condition, not solution. A Canvas entry might say:
A named steward may assist a departing editor to recover a copy of comments needed for the current review purpose. The arrangement does not establish that the steward can read all manuscript content, retain a permanent key, or resolve an authorship dispute.
That statement is not a protocol. It simply separates the reason for recovery from permissions that have not been granted.
The Editorial Access Arrangement Canvas
The Canvas is a non-validated Wexley teaching instrument. It does not perform a cryptographic audit or a human-resources decision. Its unit is one defined editorial collaboration group, not an organization, a platform, or a permanent account system.
| Field | Record this | Do not infer |
|---|---|---|
| 1. Review purpose and material boundary | The editorial task, materials, time horizon, and facts excluded from the arrangement. | That all work by the same people belongs in the same protected space. |
| 2. Member and role boundary | Named roles, current members, and the reason each role needs access. | Personal trust, employment authority, or legal entitlement. |
| 3. Access path | How a participant gets readable, editable, comment, or view-only access. | That a formal role automatically yields a usable path. |
| 4. Membership-change path | How entry, removal, scope reduction, or role change is recognized and recorded. | That past or future content treatment is settled without evidence. |
| 5. Recovery condition | What loss, transition, or access problem is contemplated and which bounded assistance path exists. | A key-escrow policy, emergency entitlement, or future recovery result. |
| 6. Editorial permission relation | Which acts are needed: read, comment, suggest, edit, export, invite, or administer. | That a technical permission determines editorial authority. |
| 7. Accessibility and usability condition | Authentication, device, assistive-technology, language, or support factors that could prevent participation. | That an interface is accessible or inaccessible without testing. |
| 8. Record and metadata condition | What access, membership, or activity information is retained, visible to whom, and for what purpose. | That records prove intent, conduct, or authorship. |
| 9. Delivery and dependency condition | Needed transport, notification, identity, or service dependencies and known unknowns. | That encryption conceals every form of metadata or system dependency. |
| 10. Next evidence and non-conclusion | The smallest validation or conversation needed and what the Canvas cannot decide. | A confidentiality guarantee, system approval, or risk verdict. |
Use Field 1 before inviting anyone. “Sensitive manuscript” is not a material boundary. Is the group reviewing a draft chapter, the full submission, a fact-check file, a comment thread, a contact list, or an attached legal note? The answer changes the access arrangement.
Use Fields 2 and 6 separately. A role may have a legitimate reason to see material without needing to edit it; an author may need to accept a change without being an administrator. Technical access and editorial authority overlap, but they are not the same relation.
A constructed editorial group
The following example is fictional. It does not describe a real newsroom, book project, contributor, system, or incident.
Initial claim: “The review group is encrypted, so confidential collaboration is solved.”
Bounded arrangement: A fictional literary journal convenes an eight-week review group for one reported essay. The group includes the author, a developmental editor, a fact checker who needs selected source notes, and a temporary legal reader who needs one attachment but not the complete source archive.
| Canvas field | Constructed record | What remains open |
|---|---|---|
| Purpose and material | Eight-week review of one essay and selected evidence files. | Any future archive or production access. |
| Members and roles | Four defined roles with distinct reading needs. | Whether roles need a broader organizational account. |
| Access path | Each role is offered a protected invitation path; actual completion has not been tested. | Assistive-technology compatibility and device constraints. |
| Membership change | The legal reader’s access ends when the issue is resolved; the arrangement notes that removal must be confirmed. | Treatment of material previously viewed or exported. |
| Recovery | A lost access path may be reviewed by the editor and author for the stated eight-week purpose. | Whether an outside administrator can or should recover content. |
| Editorial permissions | Author can review suggestions; editor can comment; fact checker sees selected source notes; legal reader sees one attachment. | A determination of authority beyond this review. |
| Accessibility condition | The group must verify that each participant can complete invitation, authentication, and reading steps. | A conformance claim or universal usability result. |
| Records and metadata | The group records why access was granted and the planned end date; no conclusion is made about all operational metadata. | Whether any system log is sufficient or appropriate evidence. |
| Delivery and dependency | The group depends on a device, an identity path, notifications, and a service-delivery relation. | That delivery layers or notifications reveal nothing. |
| Next evidence | Run a pre-review access check with each role. The Canvas cannot certify confidentiality. | Any platform, policy, or security decision. |
The example has not demonstrated privacy. It has made a practical failure more visible: if the fact checker cannot access the allowed source notes, or the legal reader retains broader access than the task requires, an encrypted transport label does not explain the problem.
Identity, authority, and membership should not collapse into one label
An interface may identify a person through an account, a device credential, an invitation, or a recovery process. Editorial authority is a different question: what task has that person been asked to perform, and what bounded access is appropriate for that task? Group membership is another: which protected material can the person presently receive or alter?
These relations often travel together in a small team, which is why they are easily collapsed. But the collapse creates avoidable ambiguity. A contributor may be the author of a manuscript but not need administrative rights. A fact checker may need a defined set of source materials but not a discussion about unrelated submissions. A former editor may remain a trusted person yet no longer belong to the active review group. An outside administrator may be able to restore an account without having editorial authority to read a manuscript.
The Canvas does not resolve these questions by itself. It asks a group to write them separately. A useful member record states the role, material scope, allowed acts, review period, and change path. It does not use a vague label such as “editor” to grant unexamined access across every material and phase.
This separation also stops a dangerous reverse inference: an encrypted invitation does not make a recipient an appropriate reviewer, and a legitimate editorial role does not prove that a particular access method is usable or sufficiently bounded. The arrangement requires both sides to be considered.
Metadata belongs in the arrangement, even when content is protected
Encryption can protect application content in a particular design. It does not make every surrounding relation invisible. RFC 9750 describes application-level identities, delivery services, group identifiers, policy, and membership state as part of the architecture around protected messages. [3] The technical standard does not tell an editorial group exactly what data a service retains. Its narrow lesson is to avoid treating “encrypted” as the only word needed to describe a collaboration system.
For editorial purposes, a group may ask modest questions: Is the presence of a reviewer visible to all members? Does a notification expose a manuscript title? Is a change history retained? Does an access record exist, and for what purpose? Can a participant understand who will see a record? What happens to that record when the review ends?
The Canvas does not require exhaustive logging or a complete privacy analysis. It explicitly avoids turning a small editorial arrangement into a surveillance system. The record-and-metadata field can be completed with an honest unknown. “Retention of delivery and access metadata not verified” is better than a claim of total secrecy.
Use the Canvas before, during, and after a review
Before a review, use Fields 1–4 to identify the material, roles, access path, and membership-change condition. A group that cannot say why a person needs access should not let encryption supply an answer.
During a review, use Fields 5–7 when a real participant encounters a problem: a lost device, inaccessible authentication step, new temporary role, or question about whether a comment can be exported. Record the actual condition and the smallest remedy to test. Avoid turning a one-time workaround into a permanent access entitlement.
After a review, use Fields 8–10 to inspect what should remain, what should end, which dependencies became visible, and what the Canvas still cannot establish. The final account should be short enough to support the next group, not a total history of every person’s editorial activity.
Confidentiality needs a purpose boundary
Confidential material is not one category. An unpublished essay, a source contact list, a copyediting note, a legal question, a reader report, a draft address, and a payment record may all require different handling. A group that says “keep everything confidential” may still need to distinguish what is necessary for a particular review and what should never enter the space at all.
The material-boundary field is therefore a restraint against convenience expansion. If a participant needs one attachment, the arrangement should not silently make the rest of a contributor’s archive available merely because it is easier to share one folder. If an author must respond to an edit, the group should not assume that administrative access is needed. Scope can be reduced without turning a participant into a suspect.
This is not a claim that minimization is always technically possible or sufficient. It is an editorial question of proportion: what does the defined task require the group to hold and share? A useful answer can be provisional. The group may discover that a missing context file is needed for fair review and expand the boundary with a recorded reason. The point is to make expansion a conscious revision rather than an invisible default.
The same logic applies to time. A review may end while a publication still needs a correction path. The Canvas asks the group to name the planned horizon and acknowledge what it has not settled about later access. It does not force deletion or permanent retention. It refuses the easier story that a protected space has no lifecycle.
Collaboration has a commons without becoming public
“Editorial commons” does not mean that a manuscript should be public. It means that editorial collaboration creates a shared working relation: people have to understand what they can see, what they can do, how they enter, how they leave, and how the group responds when an access path fails. Confidentiality has to coexist with that legibility.
RFC 9750 describes E2EE messaging architecture as involving application-level identity, delivery, policy, and group state in addition to protected application data. [3] It is not a writing-workflow standard. Still, it supplies a useful counterweight to the fantasy that cryptography makes every surrounding relation disappear. A protected message can travel through a larger system. A membership change can matter. A notification can be operationally necessary. An editor can be authorized yet unable to work.
The Canvas therefore does not rank the most private arrangement. A design that makes everyone an administrator may be too broad for the material. A design that makes recovery impossible may be too brittle for an eight-week collaborative project. A design that forces an inaccessible authentication step may exclude the very editor who needs to review the work. These are not a single axis.
Let the arrangement state its limits
Return to the opening claim: “Only the right people can read this manuscript.” After the Canvas, a more responsible claim is possible:
For this defined review period, four roles need bounded access to specified materials. The group has recorded its purpose, membership, permissions, change path, recovery question, and access-testing need; it has not certified confidentiality, accessibility, or trust.
That is not a weaker ambition. It is an editorially usable one. It recognizes that a protected collaboration space is made of people, roles, transitions, recovery, and interfaces as well as encryption. The next action is specific: clarify one role, test one access path, state one recovery boundary, or decide what record is appropriate for the review purpose.
Encrypted collaboration becomes more credible when it does not pretend to solve the human work around encryption.
References
[1] Christian Knabenhans, Zayd Maradni, and Carmela Troncoso, “End-to-End Encrypted Collaborative Documents,” USENIX Security 2026, https://www.usenix.org/conference/usenixsecurity26/presentation/knabenhans.
[2] R. Barnes et al., The Messaging Layer Security (MLS) Protocol, RFC 9420 (2023), https://www.rfc-editor.org/info/rfc9420.
[3] R. Barnes et al., The Messaging Layer Security (MLS) Architecture, RFC 9750 (2025), https://www.rfc-editor.org/rfc/rfc9750.html.
[4] National Institute of Standards and Technology, Recommendation for Key Management: Part 1—General, SP 800-57 Part 1 Rev. 5 (2020), https://doi.org/10.6028/NIST.SP.800-57pt1r5.
[5] Alma Whitten and J. D. Tygar, “Why Johnny Can’t Encrypt: A Usability Evaluation of PGP 5.0,” USENIX Security Symposium (1999), https://www.usenix.org/legacy/events/sec99/full_papers/whitten/whitten.pdf.
[6] W3C Web Accessibility Initiative, “Understanding Success Criterion 3.3.8: Accessible Authentication (Minimum),” WCAG 2.2, https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum.