Product Meeting: Trash, Deletion, and Spam
Allie Crevier edited this page Jun 10, 2021
·
3 revisions
Here are some brainstorming notes from our product meeting on May 27, 2021.
- Quarantining, or separating into some sort of intermediate folder, rather than auto-deleting. +1
- This helps reduce journalist trauma
- Adding implementation complexity gives me the fear, stuff like queues getting wiped etc
- Competing goals at play: immediate deletion important for source security in event machines get popped/seized, operational concerns re: store/backup size
- Just having more efficient navigation in the Client would help a lot -- keyboard shortcuts for deletion, automatically navigate to the next source in the list, etc.
- Deletion performance matters a lot -- both perceived and actual -- so the user feels like they are progressing quickly through deletion tasks
- allow users to define phrases, match for them in message and flag sources when found +1 (e.g., I don't need to read any further than "Illuminatis") +1 (good simple approach) +1
- "mark as junk" button -> extract words -> use for Tanimoto coefficient comparison
- encrypt to submission key to prevent leakage? not useful in current JI.
- manual banned-words list probably better +1
- Captcha (to prevent automated bots) +1+1+1+1 (when optional for admins)
- Proof of work client side (have uploader client side solve a math problem prior to allowing uploads, potentially do during periods of high load)
- We could reuse what mozilla has already built and run it locally in a qube
- Federated learning
- "The No no hash": a hash block list for specific files (on a per instance basis)Probably per-workstation - I would not share that hash list upwards to servers (tru, could encrypt and store on server so can share between at least securedrop-client workstations)also truteehee
- Maybe an aside: Can we display metadata in the client UI (perhaps in the "tear" text) marking which user did the most recent delete? Thinking that some newrooms with a larger journalist group would want a transparent "chain of custody" if a legit submission/msg is accidentally lost in safe deletion.
- An audit log feature is something we've discussed and could definitely be useful for a bunch of purposes!
- Add per-user permissions? Read only, Delete submission/files, Delete account
- In some cases, would we want to assign "no read" access permission to someone in the Admin role?