globaleaks
Ability to notify Whistleblowers if they decide to give out their own email contact
It has been requested by an Adopter, working in corporate whistleblowing environment, the ability to provide notifications functionalities to the Whistleblower when a Receiver ask him something.
The idea is that, if the whistleblower gives out his email address as a contact detail in the submission field, he need to be notified as the Receiver is.
In such use-scenario the Whistleblower is given the choice always gives out his email address to be notified.
This ticket can be implemented only after #185
It's interesting how https://www.integritycounts.ca has done:
As agreed with Amnesty, the email must not report any kind of reference to GlobaLeaks and/or to Amnesty and/or clickable links.
@giorgiofraschini @larrykind @maxmois @schris-dk: i just had a discussion on this topic with @elbill that is recommending to implement this feature in relation to the EU directive.
I consider this a very sensitive feature for which i've expressed many points that i consider critical in the context of secure whistleblowing but i will like to have your all feedback on the discussion ( #3078) and your evaluations given your analysis of your national laws. thank you
I think that this could an option given to the reporting person. It is absolutely necessary that the option to select an email notification by the reporting person for the only delivery of an alert (with no information on the report). I think that this should not be in form of an ordinary question but something like a pop up/double question to the reporting person in order to validate what he is doing. I am not sure if there is an easy way to implement this.
Thank you @giorgiofraschini
Among all i think that with your suggestion we could implement a quite reasonably secure option.
I think we we could implement a feature like the following:
- Propose the whistleblower an icon like the one recipients with a popover text "Enable notifications"
- When the user click the icon propose a modal "Enable notifications" with the possibility to enter an email address and a text. "Enter an email address to get notifed about updates. For security reason we advise to not use any email address that could lead back to you."
In this way we could correclty inform the user about the risks, make this optional and offer the possibility to disable the feature. Implementing proper information i think we could accept to store the email address in plaintext for the time limited to the mail notification considering in fact that anyhow in any case that email address wont be so much protected unfortunately and avoiding to be incoherent.
What do you think? Do you all have suggestions or revisions for the texts that should be proposed to the user in the modal?
Hello everyone, thank you for involving me in this discussion. As @evilaliv3 already wrote, I think that email exchange with the whistleblower should be considered generally as a confidentiality downgrade, but effectiverly useful in the use case. So I could suggest these features to accomplish the task:
- in admins advanced options there should be given the possibility to receivers to send free text emails or state change notifications emails to whistleblowers
- whistleblower can choose to receive emails or not
- email address of the whistleblower left to receive emails should be separated from the one left in the identity form and it will be never shown to receivers
- whislteblower could left his public pgp key when he chooses to receive emails so system can encrypt free text sent by receiver
As alternative, according to @giorgiofraschini, when report state is changed or new chat message is sent from the receiver, an automatic generic notification email will be sent to the whistleblower, that could be encrypted with pgp key provided by the whistleblower.
Clearly, when whistleblower choses to receive emails, it should be alerted about the security risks.
I agree that the feature should be different from the email address provided to recipients and protected by encryption and 'm in favour of generic notification; I consider that adding the PGP key possibility would be just a complication that is not necessary and would confuse users. In any case we should not send any confidential information to the email or the user. In case of recipients this is useful to protect account recovery tokens.
Which of the following options would you prefer?
- Option 1: keep the email encrypted and manage notifications in RAM accepting that the notification could be lost in case the system is restarted before the email is delivered and implementing retries in cases of single email failures
- Options 2: keep the email in plaintext accepting that the email will be anyhow exposed on the network and implementing a reliable mail notification even in case the system could be restarted.
I would suggest: Against free text . Just notifications. PGP encryption is welcome, (however 99% will not use it).
@evilaliv3 I would go for something in between Option 1 and 2. Decrypt the email when status changes, keep it in plaintext, then delete it when notification is sent. When system is rebooted and task not completed the email will stay on the system decrypted and will be deleted after system recovers and email is sent. This is the case for named reports (recipient key would be used to decrypt). Not sure how this would work for anonymous reports that the recipient is not supposed to see the email. What key would be used to decrypt the email in such case? I hope I'm making sense. The whistleblower information regarding risks could be discussed after deciding the technical approach.
If i understood well, with the fact that the "content of the notification" does not have anything confidential into it, then the only data to be protected is the notification identifier (here the email address, but it maybe a phone number for SMS in future), that lead me to think that Option 1 could provide anyhow reliable notifications with:
- keep the email encrypted and manage notification as they are now, but provide a function that handle the "encrypted destination address" only after a in-RAM unlocking has been done at least once in the application restart (i.e. revealing the specific key to decrypt it)
That could happen when at least one of the recipient having access to the report login to the system.
Given that a Whistleblower is highly likely to be notified when there's a new interaction with a receiver, and given that when a receiver does that interaction the key to decrypt his email address should be available in RAM, then those two events could be intertwined achieving the storage of notification in encrypted format with message notification resliency?
Yes, this is the scenario 1 described @fpietrosanti
The issue with that is that:
- email won't be reliable as it will not possible to implement retries resilient to reboot.
- it will not possible to notify the whistleblower about an actual automatic deletion of the report due to expiration of the submission
I suspect that clients that requires this feature requires a reliable email notification and notification upon deletion that are both two features that could implemented only maintaining the email address in plaintext.
What do you think?
I think that, when a reporting person decides to activate this notification, it should be super easy for him to receive it. So I think that it should be a plain notification (no encryption, etc). Based on this I would consider:
- notification only as an alert to go on the platform (I would exclude links, too)
- make it super redundant for the reporting person the fact that he is exposing his email address (with all the consequences).