This visibility option will use a simple symmetric key cipher to store salted, encrypted blobs as statement report data but not certain report metadata, at least initially. Initially, the encrypted fields would be:
report_title
report_text
contactable
In the GUI, encrypted statements would simply show up as "[Encrypted]" and, when accessed, they would prompt the user to enter a password. This password is chosen by the reporter and could therefore be shared on a per-person basis, with privacy assured equal to the care taken to prevent the password's exposure.
Regardless of the value of the contactable field, password-protected statements would include a link to send a notification from the user to the reporter to ask for the password, just like other statements which are isntructed to "Keep my identity hidden."
This proposal addresses some vulnerabilities of possible system administrator abuse raised in Issue #72 by giving the reporting end user a familiar data protection option, i.e., a pass phrase.
This is not a perfect system but it is modest enough to attempt implementation. Are there any concerns or objections from collaborators?
As a modest enhancement proposal inspired by Praxis Journal's paper, "Mapping Sexual Assault: Deploying Additively Homomorphic Encryption With Peer To Peer Networking To Confidentially Discover Links Between Perpetrators and Survivors," I suggest adding a new "Statement Visibility" option: "password protected."
This visibility option will use a simple symmetric key cipher to store salted, encrypted blobs as statement report data but not certain report metadata, at least initially. Initially, the encrypted fields would be:
report_titlereport_textcontactableIn the GUI, encrypted statements would simply show up as "[Encrypted]" and, when accessed, they would prompt the user to enter a password. This password is chosen by the reporter and could therefore be shared on a per-person basis, with privacy assured equal to the care taken to prevent the password's exposure.
Regardless of the value of the
contactablefield, password-protected statements would include a link to send a notification from the user to the reporter to ask for the password, just like other statements which are isntructed to "Keep my identity hidden."This proposal addresses some vulnerabilities of possible system administrator abuse raised in Issue #72 by giving the reporting end user a familiar data protection option, i.e., a pass phrase.
This is not a perfect system but it is modest enough to attempt implementation. Are there any concerns or objections from collaborators?
CC: @unquietpirate