The test scenarios for the Client's offline mode suggest that:
when you log in to the Client, you're actually logging in to the Server, so that the Client can update from it; and
when you enter the Client's offline mode, you're actually just skipping logging in to the Server and instead using whatever data is available locally without further authentication.
This is fine on the Server's shared-inbox model...
...but it leads to edge cases like #1190 at the leaky interface between the Server's shared-inbox model and the Client's login model.
Defining these properties and behavior will be important for:
being more explicit about the security properties of the Client in online versus offline mode; and
defining a more-consistent conceptual model and UX for downloads, replies, etc. under different network conditions.
Description
The test scenarios for the Client's offline mode suggest that:
Defining these properties and behavior will be important for:
How will this impact SecureDrop users?
TBD. If we don't have a clear conceptual model here, then we can't present a consistent UX.
How would this affect the SecureDrop Workstation threat model?
TBD. See also:
1190
User Stories
As a journalist, I want to understand what I'm logging into, what data will and won't be available, and what operations will and won't be possible.