Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Periodically send email notifications to journalists #544

Closed
garrettr opened this issue Sep 8, 2014 · 7 comments
Closed

Periodically send email notifications to journalists #544

garrettr opened this issue Sep 8, 2014 · 7 comments

Comments

@garrettr
Copy link
Contributor

garrettr commented Sep 8, 2014

Some deployers have requested email alerts for when they receive submissions, or for other similar events. The current recommendation is to periodically check the Journalist Interface manually, which is cumbersome.

Such a feature would have to be carefully designed to avoid leaking information about submissions. For example, it's easy to see how sending an email immediately for every submission leaks useful information to adversaries that could be used to identify sources.

An alternative approach would be to send an alert at a regular interval, say every day or week, with a digest of events that occurred. This email should also be padded to avoid leaking information about the number of type of events that occurred in the interval.

Finally, any such email should be encrypted to a key provided by the journalist who wants to receive these notifications.

@garrettr garrettr added this to the 0.4 milestone Sep 8, 2014
@runasand
Copy link
Contributor

runasand commented Sep 8, 2014

I think that having separate notifications for different actions within the SecureDrop system will be most useful to the journalists, e.g. "new source has uploaded documents," "existing source has uploaded documents," "existing source has replied to your comment." That said, it would be far easier to just send a daily or weekly notification telling the journalists to check the Document Interface without being more specific.

@Taipo
Copy link

Taipo commented Sep 9, 2014

The fixed 24hr notification would be the better option ( in my view ) especially from the perspective of a new source wanting a reply.

They then know that someone will be notified of their contact within a 24 hour period, saves them checking back in regularly to see if they have received a reply until at least after a 24 hour period even though potentially their message/upload could have been processed much sooner than this.

This would also lower the detection signature somewhat of a new source.

Perhaps a weekly digest then could pick up only instances where replies are still unread regardless of whether its a new or existing source to press the journalist to check for new documents.

A very simple generic message without any specifics would safest although that would not very informative to the journalist.

@trevortimm
Copy link
Contributor

So I'm open to other opinions here, but I don't think we should do this. It's not that big of a burden for journalists to sign in once or twice a day to check. Besides the whole problem of an email notification being another avenue for an adversary to get information about a source, the logging in every day serves a different purpose: practice. If they are only getting occasional submissions (say once every 2-3 weeks), the journalist will get out of practice and may fuck up the steps they need to go through to access SD and decrypt the files when they finally do get something. If they are forced to do it every day, it keeps them familiar not only with SD, but all the corresponding security practices that they can use elsewhere.

@runasand
Copy link
Contributor

While I agree with @trevortimm that journalists should check SecureDrop once a day or so, we all know this is unlikely to happen within some organizations. Issue #479 covers the need to tell the source what the next steps are, but I think we should come up with a way to notify journalists without giving away too much information.

@stevepimen
Copy link

Setup a trigger in DB would be more "deep-root" ;) solution that would complain with any security requirements.

@garrettr
Copy link
Contributor Author

garrettr commented Nov 7, 2015

@stevepimen DB triggers are a bad idea in general, and especially in this context. We do not want to have a signal (such as sending email) that leaks timing information about the behavior of sources. A DB trigger on recording a new submission in the database obviously fails to achieve this security goal.

@psivesely psivesely removed this from the 0.4 milestone Mar 2, 2017
@eloquence eloquence added this to the 0.6 milestone Feb 21, 2018
@redshiftzero redshiftzero modified the milestones: 0.6, 0.7 Feb 27, 2018
@eloquence eloquence removed this from the 0.7 milestone Apr 5, 2018
@eloquence
Copy link
Member

Submission email notifications are described in #1195 and being implemented (as a simple yes/no notification) in #2803. Other types of notifications should be filed as separate issues, ideally tightly scoped. Closing this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants