On architectural security as a strategy for making good on privacy promises

[Gregory Maxwell]

With the recent unfortunate revelations about the NSA PRISM program, there
have been a number of people making note of Mozilla not being one of the
named participating parties. While the overall situation is horrible,
personally I think it's fantastic to see Mozilla's greater-than-usual
commitment to privacy acknowledged.

One of the things that has disappointed me, however, is that many people are
not really aware of the degree that Mozilla's actions are protective:

"Although there's nothing in theory stopping the NSA from
getting data from Mozilla Corp. the way it does from
other companies, Mozilla has taken a fairly structured
stand against encroachments on civil liberties in the past"
( http://www.bizjournals.com/sanjose/news/2013/06/07/Protect-yourself-from-prism.html )

I'm sad to see this because "you can trust us because we have not, yet,
been observed to betray you" is something that a third party should not
regard as a useful commitment: betrayals of confidentiality are, by their
nature, rarely observable. That is all the author credits Mozilla for and
you could have easily made the same statement using just about any of the
PRISM-named companies in place of "Mozilla" there a short time ago.

But, in reality, what Mozilla has done is often much stronger: compared
to the alternatives, the design of services like Firefox Sync and Persona
or the very fact that Firefox itself is open-source fundamentally curtails
the amount of damage Mozilla could do if it were to act against its users'
interest. Deep in the protocol-bowels of the Internet, people working
with Mozilla have advanced things that make undetectable surveillance
hard, such as mandatory DTLS-SRTP as part of WebRTC, etc.

It's my opinion that Mozilla has the freedom to build architecturally
secure systems because it doesn't have a business model that is predicated
on mining users' data, so making the data unavailable—even to Mozilla
itself—isn't disruptive. The fact that Mozilla develops its software
openly also makes using secrecy as a architectural tool simply more
expensive than it is for other organizations which are secret by
default and open by exception.

(As Jacob Appelbaum recently wrote:
"if the architecture of a system, even a mostly *technically* secure
system, is optimized for surveillance to the company's benefit - it
*will* almost certainly be forced to hand your data over when ordered.
Simply because it *is able to do so* at all,"
https://mailman.stanford.edu/pipermail/liberationtech/2013-April/008250.html )

Architectural security reduces the problem of making promises we
cannot keep: should Mozilla have to make a decision between
upholding privacy promises in a strong sense and continuing to exist
as an organization, I don't think there is much ambiguity about what
would happen, as romantic as it might be to think otherwise. It may
someday be the case that people inside Mozilla with privileged access
might be secretly serving other interests—perhaps with the belief
that qualified immunity would shield them from liability (or, perhaps,
against their will). There is realistically no hope that Mozilla—or
anyone else—could screen for this kind of subterfuge. When our
concerns include shielding people from misconduct by entities as powerful
as major nation-states, or just simply wealthy parties who are willing
to ignore the law, there is little we can assume is not within the
attacker's capability.

So I believe that one major reason people should trust Mozilla
is because we prove our trustworthiness by building systems where trust
isn't required. But this point is subtle. If we want people to choose
Firefox over the alternatives so they can benefit from it, we will
eventually have to educate people about the difference between "trust us
because we say so" and "trust us because you don't have to"—because
everyone can (and does) promise to be trustworthy, at least until people
get the bad and always too-late news that the trust was broken.

But what about services which we don't know how to provide in
a manner where they architecturally simply can't cheat? Cryptographic
tools are becoming more powerful constantly but confidentiality is
especially tricky, especially when people want 'social software' whose
whole basis is sharing data (but only with the "right" people!).

I don't believe that advertising a commitment to architectural security
precludes offering less-secure alternatives in areas where we aren't yet
able to do better, but having services with different privacy commitments
makes educating people complicated:

How do we tell people that our privacy commitment is better than someone
else's because we are maximally transparent and build systems where its
harder for us to cheat… except where we aren't and don't?

If we don't make architectural security part of how we promote our privacy
and security commitment, how do we make it clear that our promises are
better than someone else's when everyone else makes similar sounding
promises?

How can we tell people how important these goals are for us without
understating the realistic limitations on our ability to achieve them for
our services which are not based on cryptographic reduced-trust? ("We
won't betray you! /Unless someone makes us/" sounds pretty lame, but
it's truthful)

But I suspect these trade-off questions can't be intelligently
navigated unless architectural security is first viewed as the aspirational
gold standard for upholding individuals’ security and privacy on
the Internet.

[Henri Sivonen]

On Mon, Jun 10, 2013 at 5:44 AM, Gregory Maxwell <gmax...@mozilla.com> wrote:
> One of the things that has disappointed me, however, is that many people are
> not really aware of the degree that Mozilla's actions are protective:

...

> But, in reality, what Mozilla has done is often much stronger: compared
> to the alternatives, the design of services like Firefox Sync

Advertising the design of Firefox Sync at this point would make
Mozilla look pretty bad when PICL replaces Sync with a weaker design
(by default) in the name of usability and user expectations.

Or put the other way: If the design of Firefox Sync is advertised now,
it would make sense to commit to PICL having the same level of
security by default.

--
Henri Sivonen
hsiv...@hsivonen.fi
http://hsivonen.iki.fi/

[Ken Saunders]

Will Mozilla be making any kind of reassuring, public statement directed at Mozilla product and services users?

I understand that this will need to be very carefully thought out, but those concerned about these matters (hopefully everyone), are asking questions and it would be nice to have an official statement or reference.

I did my best, but an official line, or some guidance as to how to respond would be greatly appreciated (via direct email if more appropriate).

Mozilla Firefox (Wall) on Facebook
Fulcanelli Aequitasposted > Mozilla Firefox
"Does your company submit to the NSA surveillance program? I'd like an answer, because I'm looking to choose a browser that's not looking to put a leash up my ass."

"Hi Fulcanelli,
The short answer is no. Mozilla is -not- one of the companies mentioned in the recent news about the NSA and the Prism surveillance program.
You can review Mozilla's current privacy policy at the following.
-Ken
http://www.mozilla.org/privacy/"




Ken Saunders
------------------
http://www.AccessFirefox.org

[Asa Dotzler]

On 6/9/2013 7:44 PM, Gregory Maxwell wrote:

> It's my opinion that Mozilla has the freedom to build architecturally
> secure systems because it doesn't have a business model that is predicated
> on mining users' data, so making the data unavailable—even to Mozilla
> itself—isn't disruptive.

This is an awful assumption. Our business model doesn't afford us the
freedom to ignore what most Internet users want.

Users want easy access to their content from a variety of devices and
services, and to be able to share content in a variety of ways.

These are not business models, they are requirements from our users.

We can bake in crypto and other security measures to make our features
more secure only up until the point that it gets in the way of what
users want from those features (and can easily get by launching the
competitor browser(s) they all have sitting right next to ours.)

- A

[David Rajchenbach-Teller]

While I have never used it, I know of tahoe-lafs and a few related cloud
storage solutions that are supposed to "guarantee" privacy by ensuring
that data is spread among servers and that no single server has enough
information to be able to compromise the data.

Could this perhaps provide an element of solution, if said servers were
spread among several countries?

Cheers,
David

On 6/10/13 9:32 PM, Asa Dotzler wrote:
> This is an awful assumption. Our business model doesn't afford us the
> freedom to ignore what most Internet users want.
>
> Users want easy access to their content from a variety of devices and
> services, and to be able to share content in a variety of ways.
>
> These are not business models, they are requirements from our users.
>
> We can bake in crypto and other security measures to make our features
> more secure only up until the point that it gets in the way of what
> users want from those features (and can easily get by launching the
> competitor browser(s) they all have sitting right next to ours.)
>
> - A
>

> _______________________________________________
> governance mailing list
> gover...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance


--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla

[David Dahl]

----- Original Message -----
> From: "Asa Dotzler" <a...@mozilla.com>
> To: mozilla-g...@lists.mozilla.org
> Sent: Monday, June 10, 2013 2:32:31 PM
> Subject: Re: On architectural security as a strategy for making good on privacy promises
>
> We can bake in crypto and other security measures to make our
> features
> more secure only up until the point that it gets in the way of what
> users want from those features (and can easily get by launching the
> competitor browser(s) they all have sitting right next to ours.)

This is not just an issue of baking features into our browser or Firefox OS. We also build services and could start an effort to build services that enable private user communication and sharing, support existing efforts through contribution and step up the enduser privacy education we already do.

We have the smartest people in the industry, and frankly, aside from obvious content JS security issues, building software around crypto (instead of bolting it on) is primarily a UX problem.

Mozilla is one of the few 'honest brokers' here, and privacy is already a differentiator for us.

Cheers,

David

[Mike Lee]

FYI: 4 UX Problems Holding Back Crypto And Anti-Wiretapping Technology

http://falkvinge.net/2013/06/08/4-ux-problems-holding-back-crypto-and-anti-wiretapping-technology/

Mike

[Robert O'Callahan]

bOn Tue, Jun 11, 2013 at 7:32 AM, Asa Dotzler <a...@mozilla.com> wrote:

> On 6/9/2013 7:44 PM, Gregory Maxwell wrote:
>

> It's my opinion that Mozilla has the freedom to build architecturally
>> secure systems because it doesn't have a business model that is predicated
>> on mining users' data, so making the data unavailable—even to Mozilla
>> itself—isn't disruptive.
>>
>

> This is an awful assumption. Our business model doesn't afford us the
> freedom to ignore what most Internet users want.
>

I would amend Greg's statement to say "Mozilla has *more* freedom to build
..." Then I wholeheartedly agree that we have the opportunity to take a
unique role here.

Rob
--
q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq
qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq
qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq
qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q
qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq
qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"

[Robert O'Callahan]

On Mon, Jun 10, 2013 at 6:28 PM, Henri Sivonen <hsiv...@hsivonen.fi> wrote:

> On Mon, Jun 10, 2013 at 5:44 AM, Gregory Maxwell <gmax...@mozilla.com>
> wrote:
> > One of the things that has disappointed me, however, is that many people
> are
> > not really aware of the degree that Mozilla's actions are protective:
> ...
> > But, in reality, what Mozilla has done is often much stronger: compared
> > to the alternatives, the design of services like Firefox Sync
>
> Advertising the design of Firefox Sync at this point would make
> Mozilla look pretty bad when PICL replaces Sync with a weaker design
> (by default) in the name of usability and user expectations.
>

Yes, but... PICL could offer both the "Mozilla has keys" and "Mozilla
doesn't have keys" options. PICL could allow users to switch between them
easily. We can continuously tune how those options are presented even to
the point of changing the defaults if it became advisable. We can offer
users the gold standard even if it's not the default, and explain why they
should choose it. Our story there still seems pretty strong to me.

The tricky, but essential, part is to build services that work even when
Mozilla doesn't have keys. People are worried about supporting sharing when
Mozilla doesn't have keys, but I think we can go quite far. For example,
since URLs contain a field that doesn't get sent to the server, you can
share URLs containing the keys needed to decrypt content, e.g.
http://0bin.net/paste/b3dc50ec2a278741399c6b0860beb78fc704c2e2#P8ZXJ0Kn6IhP0vXECm7G/F4qa16XMGUVeZ9lpvNowjc=

We have really great client technology now to help us "dumb down the cloud"
--- WebRTC, IndexedDB, fast JS. We can add whatever else is helpful ---
some kind of Web Crypto, and http+aes with the bugs fixed. We have Persona.
We have PICL. We have transparency and a trusted brand. We are
geographically diverse. Greg's right, there's a big opportunity for us here.

[Mats Palmgren]

On 06/10/2013 02:44 AM, Gregory Maxwell wrote:
> How can we tell people how important these goals are for us without
> understating the realistic limitations on our ability to achieve them for
> our services which are not based on cryptographic reduced-trust? ("We
> won't betray you! /Unless someone makes us/" sounds pretty lame, but
> it's truthful)

I don't think that any amount words will regain the trust that has been
lost. Companies under U.S. jurisdiction cannot be trusted, period.

Action speak louder than words though. So I think we should create
a separate company, outside of U.S. jurisdiction, that run all services.

Iceland seems like a good candidate.

[Mats Palmgren]

On 06/10/2013 02:44 AM, Gregory Maxwell wrote:

> How can we tell people how important these goals are for us without
> understating the realistic limitations on our ability to achieve them for
> our services which are not based on cryptographic reduced-trust? ("We
> won't betray you! /Unless someone makes us/" sounds pretty lame, but
> it's truthful)

[Mats Palmgren]

On 06/10/2013 02:44 AM, Gregory Maxwell wrote:

> How can we tell people how important these goals are for us without
> understating the realistic limitations on our ability to achieve them for
> our services which are not based on cryptographic reduced-trust? ("We
> won't betray you! /Unless someone makes us/" sounds pretty lame, but
> it's truthful)