On 12/14/2017 02:31 AM, sajolida wrote:
>
> Thanks for starting this discussion!
Great conversation, Loic, thanks also for getting the ball rolling.
>
>> First of all this is not something new: people asked for it long ago
>> but Qubes was not mature enough. The upcoming Qubes version 4
>> changes that and motivated new development in the SecureDrop team. As
>> a result of this effort, started a few months ago, the pro and cons
>> of using tails vs Qubes appear more clearly.
> NB, Conor's talk at LibrePlanet 17 who explains this in details already:
>
> https://media.libreplanet.org/u/libreplanet/m/securedrop-leaking-safely-to-modern-news-organizations/
Yes, at a high level that's approximately the plan we're looking at.
Realistically we'll need to scope our efforts in 2018 more narrowly than
what was discussed there—for instance, it's highly unlikely we'll be
able to rewrite and QA both the journalist experience and the backend
server story—but having conversations about the feasibility of
approaches is precisely the goal.
> Given that Tails will probably remain relevant in the SecureDrop
> ecosystem for a while (for example on the source's side), my intention
> with this thread is to:
>
> * Have more feedback from SecureDrop about the Tails in general,
> hopefully opening communication channels that can be fruitful for the
> future. I don't remember much discussion on public channels between
> Tails and SecureDrop in the past.
Agreed. The SecureDrop team has done a poor job historically in
collaborating closely with some of the groups we depend most upon. Let's
change that. We've already started following your pre-release
announcements more closely so that we can perform vigorous QA before
releases go stable. With timely QA and engagement on your bug tracker,
hopefully we can avoid problems like our clunky response to the Nautilus
desktop icon issue being resolved:
https://github.com/freedomofpress/securedrop/issues/2586
> * Understand what Tails should do to be more relevant in similar
> contexts ("Tails for journalists and their sources").
>
>> IMHO the most prominent ones are>
>> * Qubes is not amnesic and the user can customize it more easily than
>> Tails
>> * Tails is amnesic, usable with an airgap workstation and more
>> secure than Qubes
>>
>> * Adding a software distribution channel to a Qubes workstation is
>> easy while creating and distributing tails derivatives is
>> challenging and discouraged
> I agree with "challenging". I partly disagree with "discouraged".
>
> Sure, we've been discouraging people to shot themselves in the foot by
> customizing Tails to the point of breaking it.
Fair points. With the (Tails-based) SecureDrop Journalist Workstation,
we're already shoehorning a lot of persistence into the environment,
which I count as going against the grain of the primary use case of
Tails. For instance, we're setting network-manager hooks to update the
system torrc with hidservauth cookies, so authenticated Onion Services
are accessible in Tor Browser.
This works! But distributing updates to the various workstations out in
the wild is quite challenging, and currently requires that Admins or
Journalists pull from git, verify a tag, and run a script. A strategy
that supports unattended upgrades would enable us to be more confident
in iterating on the workstation tooling.
> But we're also aware of the need for more customization and flexibility
> withing Tails and have made steps in this direction:
>
> - We published a statement in 2015 on how Tails derivatives should
> work and how to collaborate:
>
> https://tails.boum.org/contribute/derivatives/
>
> - We got funding this year to work on a better support for storing
> additional software in persistence which is so far only possible from
> the command line and not on air-gapped machines:
>
> https://labs.riseup.net/code/issues/14568
>
> - We documented how to configure additional APT repositories:
>
> https://tails.boum.org/doc/advanced_topics/additional_software/
Great news, and congratulations! Those are some great sources you
shared, thanks. I'd actually been under the impression that we'd need to
get packages into Debian in order for them to be apt-installable, and
having a lower bar that would enable us to ship our own packages (as we
do with the SecureDrop servers) is worth a closer look.
>
>> * Tails is already mature while Qubes reaches maturity in 2018
>>
>> * Qubes is based on Xen and runs on a limited range of hardware
>> compared to tails
>>
>> On a personal note I'd like to work on improving the tails
>> experience for all existing SecureDrop users. Migrating to Qubes or
>> not will eventually be their decision, they won't be forced. In 2018
>> there will be a significant SecureDrop effort to improve the tails
>> journalist user experience.
> I'd be interested in hearing Jen and Conor's take on this.
> Would it make sense to have two options for the journalist workstation?
> And I would totally understand if it doesn't make sense for them :)
Right now we're just prototyping with Qubes, to evaluate if we can build
a "better" experience for journalists. Loic summarized most of the
details already, but I'll list some further goals that make Qubes
attractive:
* isolation for potentially malicious submissions
* automatic sanitization of submissions, e.g. PDFs
* use of split-gpg to integrate the Journalist Workstation (networked)
and the Secure Viewing Station (airgapped)
We've been working on an updated threat model that should be ready for
public consumption in early 2018. The current SecureDrop
architecture—including the multiple Tails devices per instance—was
designed several years ago, and we've learned a lot since then. Having a
more modern threat model will enable us to make informed decisions about
major changes such as trusting hypervisor isolation in place of a
hardware airgap.
To be sure, Tails remains extremely relevant for the Source use case. We
have not ever written a software client for Sources, depending instead
on Tor Browser. We also, all of us, use Tails devices for storing
sensitive secrets of various kinds, and have copious internal
documentation on the process. Publishing much of that documentation may
be of benefit to both projects.
