Web shareable read links #67
Labels
No labels
area:docs
area:identity
area:ops
area:plugin
area:server
channel:community
channel:direct
channel:owned
channel:press
channel:social
e2ee-constrained
gate:at-ga
gate:pre-ga
marketing
parity
relay:absent
relay:planned
relay:requested
relay:supported
risk:additive
risk:contract
risk:none
usability
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
Nectenda/nectenda#67
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Part of #37.
What Relay does
Not shipped. "Web content access — browser access with shareable links" sits
under Considering.
Why this is hard for us and easy for them
Their server holds plaintext, so a share link is a URL and a permission check.
Ours cannot be: the server holds ciphertext and no keys, so a link must carry
the key material — typically in the URL fragment, which never reaches the
server.
That is a well-understood construction, but it changes the threat model in ways
docs/security-model.mdcurrently does not cover: a link in someone's browserhistory or a chat log is the key. Anyone who has it can read, and rotation means
re-sharing.
If it is ever built
of client code that must be as auditable as the plugin — see the
unminified-client issue.
Recommendation
Do not build this speculatively. It is the one item on the list that could
quietly weaken the central claim, and it should only be taken with the security
model rewritten first.
Risk
risk:additivemechanically; the real cost is to the security model.Moved to the Vikunja board as NEC-44: https://projectron.nerchure.com/tasks/44