Description
Description
SecureDrop Client has performance issues with large numbers of sources, in the 500+ range. Based on profiling results (and ignoring network I/O), updating the source list after a server sync takes about 75% of elapsed time, and within that, checking the seen status of sources takes over 50%. This manifests in the UX as a noticeable freeze in updates to the source list immediately following a sync.
Currently, seen status for a source is checked by looping through a collection of a source's submissions and replies, checking if each has been seen by any journalist, and if any item has not been seen, returning False, otherwise True. This happens for every source in the list.
Replies always count as seen (because the sending journalist saw them), so only messages and file submissions matter. If a boolean was set to False when a source first submits something, that value could be used, instead of looping through the collection. This would effectively eliminate a large chunk of the GUI freeze, improving user experience for instances with large numbers of sources
Server-side changes would be required to:
- add a new
update_seenfield in the database - update it to
falseon source submissions - update it to
truewhen journalist seen_by entries are added for files and messages. - add the field to the relevant endpoints in the journalist API
Client-side changes would be required to:
- drop the
seenproperty in the db model - add the new field in the db and sdk
- deal with possible edge cases where a source submits while their conversation is being viewed.
How will this impact SecureDrop users?
- Improvement in UX for users on high-volume instances
How would this affect SecureDrop's threat model?
The value of the field could be inferred by an adversary with database access just by looking at the seen_by statuses available in the database already - so no change.
Metadata
Metadata
Assignees
Type
Projects
Status