Censorship implications of mandatory centralized add-on signing

[Botond Ballo]

(Cross-posting to addons-user-experience and dev-security-policy)

Today I learned for the first time about the proposal to introduce
mandatory centralized add-on signing for Firefox [1].

Many have shared concerns about this in the comments to that blog post
and the ensuing thread on addon-user-experience [2], most of which I
share.

One concern which I don't feel has been sufficiently emphasized, is
the way in which this proposal would make our users vulnerable to
censorship.

Mozilla giving itself a mechanism of centralized control, and building
that into software distributed to hundreds of millions of users
worldwide with no opt-out, opens up a significant potential for abuse.

Specifically, it opens the door to the possibility of entities with
legal leverage over Mozilla (such as the U.S. government) using that
leverage to prevent Mozilla from signing add-ons they don't like (for
example, add-ons that they deem to be "circumvention tools" according
to their latest flavour of oppressive copyright legislation). In the
absence of a user-friendly opt-out mechanism, users who are not savvy
enough to know to use an unbranded build to get around this, would be
effectively censored from using such add-ons.

I find this very worrisome, and I believe that for this reason it's
very important to keep a user-friendly mechanism to override the
signing enforcement. Having such a mechanism ensures that users stay
in control, and that Firefox respects their explicit choice to run a
particular add-on.

I realize that that there are security considerations with having such
an override - for example, that if the override is a simple pref, then
any add-on can flip it. I believe that technical solutions to such
problems can be found (for example, introducing a new category of
prefs which can only be set by explicit user action). I would like to
urge us to tackle such technical problems, and not settle for a
solution that leaves users without choice and exposes them to the
possibility of censorship.

Regards,
Botond

[1] https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experience
[2] https://groups.google.com/forum/#!topic/mozilla.addons.user-experience/slaKs943n4c

[Kurt Roeckx]

On 2015-02-13 01:14, Botond Ballo wrote:
> One concern which I don't feel has been sufficiently emphasized, is
> the way in which this proposal would make our users vulnerable to
> censorship.

What I've been wondering is who can sign? Is Mozilla the only one that
can sign it or can a signature from a code signing certificate that is
in the trust store be used? I think since we're signing code, we should
rely on any code signing certificate. But for people that find that
expensive Mozilla could sign it for them.

I think that should address all concerns I've seen so far. It should
allow the signing to be checked in all versions and developers could add
their test certificate to the browser.


Kurt

[Matt Palmer]

On Fri, Feb 13, 2015 at 09:54:25AM +0100, Kurt Roeckx wrote:
> On 2015-02-13 01:14, Botond Ballo wrote:

> >One concern which I don't feel has been sufficiently emphasized, is
> >the way in which this proposal would make our users vulnerable to
> >censorship.
>

> What I've been wondering is who can sign? Is Mozilla the only one that can
> sign it or can a signature from a code signing certificate that is in the
> trust store be used? I think since we're signing code, we should rely on
> any code signing certificate. But for people that find that expensive
> Mozilla could sign it for them.

The linked post indicates that only Mozilla will be signing, and the
attestation is not as to the identity of the originator, but as to the fact
that the code is not malicious. This scheme is one of code whitelisting,
not identity management, thus identity certificates, code signing or
otherwise, are irrelevant.

I too believe that the browser should allow the installation of
locally-trusted keys for distribution of locally signed extensions within an
enterprise or for local development or testing. However, it's not my
codebase, so I'm not going to beat my chest and demand that Something Be
Done (as many of the commenters on the post did). Having to run an
unbranded build just to do extension development seems a bit over the top,
and it re-exposes the user up to the security risks of malicious extensions.

As to censorship, Mozilla already has that capability with its addon
blacklisting, as was mentioned by the article author in the comments.
Whether the censorship could be "quieter" in an extension signing world, by
simply not issuing a signature, as opposed to publishing a blacklist, is
something worth discussing further.

- Matt

--
I tend to think of "solution" as just a pretentious term for "thingy".
Doing that word substitution in my head makes IT marketing literature
somewhat more tolerable.
-- lutchann, in http://lwn.net/Articles/124703/