Enable multiple organizations to share one SecureDrop

[redshiftzero]

Description

This would be a big change and would require careful thought and planning, but I think this feature could be safely used primarily in the case of a media conglomerate (there might be others but this is the use case it would be designed for). They have a central legal department and admin staff. They have several media properties all of which have journalists that want SecureDrops. As is standard with SecureDrop, they would host the SecureDrop servers on prem. Only the administrators of the central media conglomerate would have SSH access to the servers. All other users would access the journalist interface only.

There would need to be a per-media conglomerate submission key. Journalists from each news organization would access a separate inbox for that news organization.

Much of this could be done in the web application (we would obviously need to do a schema migration). On the ops side, we'd probably want to shift away from Ansible entirely for the submission key management and manage the submission key(s) instead via the admin interface. Management of the news organizations would also come up: what if an organization wants to join or leave SecureDrop? We'd need to enable the deletion of media organizations. Via the admin interface there should be a way for each new news organization in the conglomerate that wants SecureDrop access to add:

• The name of the org
• A logo
• The public key that submissions should be encrypted to

For each journalist user, the admin should specify which news organization submissions they should have access to. This would also be configured via the admin interface.

Possible flow

1. Source signs in, they are taken to a page with the logos of all news organizations.
2. They select the organization they wish to leak to. Submissions will be encrypted to that news organization's key.
3. Journalists sign in, see only the documents intended for the organization they are a part of, and they download them and decrypt them on their per-organization SVS using their per-organization key.

Landing pages

The landing page at each news organization of the conglomerate would point to the onion address. There could also be a new route on the source interface that specifies the org, e.g. https://blah.onion/organization/exampletimes - this could enable sources to skip the organization selection page.

User Stories

As a media conglomerate with multiple news organizations interested in SecureDrop (not all with skilled administrators) I want to safely allow all my news organizations to securely receive leaked documents and messages.

[redshiftzero]

General comment: this comes up all the time and news organizations really want this.

[ghost]

@redshiftzero I confirm that it is a very common request from all orgs/journalists I talked to. In some cases they even assumed it was possible and surprised when I told them it was not the case. I think it would be a great opportunity to conduct interviews because sharing SecureDrop instances:

• did not come up once in interviews with journalists who do not use SecureDrop. The interview is about tools they use to communicate with sources and the idea of sharing resources with other organizations does not come up.
• did not come up once in interviews with journalists who use SecureDrop because well... they already have one
• goes against a culture to keep information to themselves whenever possible to have an exclusive story

There surely are a number of reasons explaining this apparent contradiction between formal interviews and prospective chats about getting a SecureDrop. It could be:

• we don't want to handle a complex system, it is too costly, we would rather share the load/cost with friend organizations (like filtrala, publeaks, sourcesure, ...)
• we are already working with a federation of news orgs/journalist (ICIJ, CIJ, ...) but for some reason we did not ask them to host and share such an shared instance
• we are a federation of news orgs/journalist but for some reason we do not respond to our member request to have a secure and anonymous communication infrastructure with sources
• the mental model of the person asking for a shared SecureDrop does not match the SecureDrop conceptual model at all and what they mean is actually something different (that's my favorite explanation)

[heartsucker]

lol whoops disregard that 😐😐😐

[heartsucker]

The specific use case that I have been contacted about isn't multiple orgs in a conglomerate, but multiple independent people either in a collective, or just friends who want to pool resources. This doesn't change the technical implementation much, but it's something to consider.

[redshiftzero]

Following up from engineering meeting earlier today:

Source signs in, they are taken to a page with the logos of all news organizations.

I'm imagining something like this (example conglomerate randomly selected):

Note: Implementation of per-organization inboxes and per-journalist inboxes should be done separately (even though they will be similar implementations).

If we ever implemented this, in my view, it is absolutely critical that we continue to strongly discourage third party organizations from running SecureDrops on behalf of others (note that in the current architecture people can still do this, it just is more annoying). Third parties can be subject to court orders just as an email provider or other telecommunications company can. Instead, this should be used to ease the workflow of organizations that are already sharing one SecureDrop (despite the awkward workflow), want separate inboxes for groups within the organizations, and want sources to be able select which groups within the organization get which documents.

Allowing third parties to safely host SecureDrops will require other significant changes to the architecture, this includes enabling E2E encrypted submissions. Note however that E2E alone is not sufficient to de-privilege the server and allow third party hosting because precise timing information of when documents were submitted is extremely valuable in a leak investigation for a nation state adversary that has access to internet metadata.

[heartsucker]

@redshiftzero Thanks for writing some of this up. I had something different in mind.

The main landing page (/) would be replaced by a selection screen above. The reason being is that would make it more obvious IMO that there are separate keys and separate accounts. The source would get the idea that they are interacting with one news org at a time. Also, because sub-orgs would presumable want to have completely separate inboxes, there would then be two conversation threads that the source would need to know to check.

This is also a problem because a source would have to memorize multiple codenames. Codenames could be recycled across sub-orgs, but I'm not sure if that's a good idea. I'd have to think on it a bit more.

To these ends, what the inbox structure look like your proposal?

[redshiftzero]

Hm, indeed - allowing sources to submit to multiple at the same time may introduce confusion. What about the following, which combines the two approaches:

1. Sign in as usual (this way sources don't need to generate multiple codenames, which I think would be a unnecessary burden on sources).

2. Source selects one organization only.

3. Source is taken to /lookup, which clearly shows the org logo (or name if the organization doesn't upload a logo):

I think from the user-side this makes the most sense. What do you think @heartsucker?

From the implementation side, here's one approach:

• Keep only filesystem_id in Source table (for sources logging in)
• Migrate the remaining columns in the old Source table (journalist_designation, flagged, last_updated, star, pending, interaction_count) to a new table that is foreign keyed to an Organization table (that would need to be created (this is indeed a Big Migration)

At this time we would stop using filesystem_id as a slug on the journalist interface (which has always been a bit odd given it's the hash of the source's codename/passphrase) and instead generate a slug based on the journalist designation

[heartsucker]

I think that makes sense.

As an addition, I think orgs would also want to have a way to funnel sources directly toward them, that is /orgs/foo-org would be identical to the current / but sources that land there would skip the org selection in the flow.

Why would the source table need to have any change other than adding a column/fk that points to the organizations table?