Alternative to File Registration

[Jorge Villalobos]

Hello,

So, we've gotten lots of push-back for the File Registration proposal,
mainly because it exerts too much control over add-on developers and
would be difficult (but not impossible) to implement or override in
enterprise settings or other situations where the developer doesn't want
the add-on code to be leaked outside of their control.

The alternative being proposed is a system where we use code signing to
determine if an add-on should be installed or not. There are many
variables to this, so I'll try to explain what I think would work best:

* All developers would need to register themselves on AMO and give us
their public key for signature verification, and the IDs they will be
signing with this key. So, effectively, we would be registering
developers and add-on IDs, but not files.

* We would enforce add-on ID integrity through an API, just like with
file registration, but in this case the signature info and ID are sent
instead of a file hash. Just to verify the ID is registered and
corresponds to the right developer.

* This means all add-ons would need to be signed in order to be
installed, eventually. For old / abandoned add-ons we would need to
determine if it is worthwhile to have some fallback mechanism, even
something like the original File Registration proposal.

* Determining if a developer is legitimate is one of the trickier parts
of this. Since we will only have their registration info and no files to
check, there isn't much to work with. We should still implement the
spamming counter measures that the original proposal includes, so we can
block malicious developers by IP addresses / ranges.

This approach will get us the wins in ID integrity, and more reliable
contact information for greyware devs. What we lose is add-on code
validation, post-upload code analysis, malware prevention in general,
and a reliable way to validate new developer accounts.

As discussed in the meeting we just had, this doesn't mean that we're
going this way or File Registration has been dropped entirely. We need
to discuss the pro and cons of this alternative approach and see if it
is sufficient for our purposes.

I'll come up with a new PRD for this alternate proposal so they are
easier to compare next to each other. However, due to the timing, we
probably won't see much progress in this area until January. However,
it's ideal that we iron our the kinks of this proposal as soon a possible.

Jorge

[john.a.s...@gmail.com]

Jorge,

Glad to hear you're rethinking the File Registration proposal. Would the developer registration + code signing be in place of the current manual review process, or in addition to it? If code signing could be done simply and quickly through the sdk, that sounds like a better plan than File Registration. It would also scale well and address a lot of the concerns raised on the other thread. Personally, I don't mind spending the time/money on a certificate as it's a knowable, finite amount of time and money - as long as it speeds up the whole process of getting legitimate add-ons in the hands of users.

John

[Monica Chew]

Hello Jorge,

> This approach will get us the wins in ID integrity, and more reliable
> contact information for greyware devs. What we lose is add-on code
> validation, post-upload code analysis, malware prevention in general,
> and a reliable way to validate new developer accounts.

Losing malware prevention means losing one of the main reasons to do File Registration in the first place.

I would add to the cons list, dependency on a CA system whose economic model and implementation are known to be unreliable and broken

Latest example: https://blog.mozilla.org/security/2013/12/09/revoking-trust-in-one-anssi-certificate/
Good overview: http://www.computer.org/csdl/mags/ic/2013/03/mic2013030018.html

What was the argument for enterprise users to block pings to the file registration server and therefore bypass the whole thing?

Thanks,
Monica

[Daniel Veditz]

On 12/9/2013 6:34 PM, Monica Chew wrote:
> What was the argument for enterprise users to block pings to the file
> registration server and therefore bypass the whole thing?

I'm guessing that they don't want to share their proprietary internal
addons which in addition to the code itself might reveal all kinds of
trade secrets including the projects they're working on and partners
they're working with.

Those are absolutely valid concerns, but what's wrong with such
enterprises turning off or blocking pings to the registration server?
Presumably they have a managed network and shouldn't suffer from
crapware addons to the same degree as the general public. Perhaps we
could even let enterprises customize the registration server URL (as we
do with the update URL) so they can control their own list of acceptable
addons.

-Dan Veditz

[Benjamin Smedberg]

On 12/9/2013 4:54 PM, Jorge Villalobos wrote:
> The alternative being proposed is a system where we use code signing to
> determine if an add-on should be installed or not. There are many
> variables to this, so I'll try to explain what I think would work best:

I think we need to be clear about the goals. As I understand it, we have
the following potential goals, and we need to understand which technical
solution meets which goals:

A. Have useful contact information for addons installed into Firefox, so
that if they are causing problems we can reach the authors
B. Be able to block addons after the fact which are determined to not
meet our policies
C. Verify before they are installed that addons meet our policies
D. Use analysis of addon files to help determine whether Firefox updates
will break particular addons, even if they aren't hosted on AMO

== Jorge's Proposal ==

The solution that Jorge has proposed doesn't rely on any global CA
infrastructure: addons are signed by the developer with a certificate
that is self-signed and doesn't necessarily chain to anything. The
developer must provide the cert fingerprint to AMO and the addon IDs
they will be signing. The Firefox, at addon install, checks for correct
signing and also asks AMO to verify that the addon ID and cert
fingerprint are known, and allows installation.

Presumably we'd hook up some sort of revocation system and integrate
this with the blocklist so that we can block things by certificate/ID.

This proposal solves A/B but not C/D. It does require that the computer
have a connection to AMO at the time an addon is installed. The system
does not cost developers anything.

== no-network alternate ==

An alternate system here would be to have AMO be a root certificate for
signing addons.

* Build an AMO root certificate into Firefox.
* When the developer has a new addon, they create an intermediate
certificate specific to that addon's ID and ask AMO to sign it via the
developer UI.
* The developer can then sign multiple versions of that specific addon
with their local certificate.

This would solve the same problems as Jorge's proposal, but would not
require an active connection to AMO at install time. There are some
details to work out, such as how we upgrade the root certificate and
still maintain the offline-install promise.

I'm not sure this is actually worth it, since the problem it solves (AMO
is down or and the user is starting Firefox with a new extension) is not
critical.

The critical difference between both of these proposals and file
registration is that we don't get to do malware checking in advance: we
can block malicious addons much more effectively later, but because we
don't have the files up front we can't do any kind of preemptive review.

I still think this is a pretty big win.

However, we could consider making the install process more complicated
for un-reviewed addons. That is: if the developer has not submitted the
actual addon files to AMO for validation, the install UI could require
more steps or be scarier. For addons that are fully reviewed, we could
streamline the install process. Perhaps we wouldn't even show the system
install prompt for unreviewed addons, so that the only way to enable
these addons would be in the addon manager UI.

--BDS

[Wesley Hardman]

This approach seems much more open, while still being secure.

Is there going to be a developer override, or will developers have to repackage and resign the addon each time?
When would the check be done, during install? What about side-loaded addons?

I think a combination of Jorge's proposal and Benjamin's no-network proposal would be the best approach.

Addons that are signed by a trusted certificate get installed, then attempt to contact AMO. If AMO is available verify the addon and certificate against the blocklist, if not install anyway.
Addons that are not signed by a trusted certificate do not get installed unless AMO can be contacted and the addon and certificate verified.
An AMO root certificate can be setup and recommended as the root for all AMO hosted addons. The AMO root would be trusted and these addons could be installed offline.

> C. Verify before they are installed that addons meet our policies

Reviewed and verified addons should be given a simpler install path. Why do I have to go through multiple steps and wait 3 seconds for an addon that is reviewed and verified?

> Perhaps we wouldn't even show the system install prompt for unreviewed addons, so that the only way to enable these addons would be in the addon manager UI.

How many unreviewed addons would standard users be legitimately wanting installed? My thought would be very few. This would push unreviewed addons to be an "advanced" user option (this would be a good thing; they would be able to make judgements as to the safety of an addon).

[Chris Peterson]

On 12/11/13, 6:31 AM, Wesley Hardman wrote:
>> >C. Verify before they are installed that addons meet our policies
> Reviewed and verified addons should be given a simpler install path. Why do I have to go through multiple steps and wait 3 seconds for an addon that is reviewed and verified?

That is an interesting idea. AMO-reviewed addons could get an install
dialog without the annoying/confusing 3 second countdown. Signed but not
AMO-reviewed addons would get the install dialog with the 3 second
countdown. Unsigned addons would only be installed by manually importing
an .xpi file in about:addons.


chris

[Jorge Villalobos]

Neither File Registration nor this alternative would change anything
about the manual review process on AMO.

If we code with the code signing plan, we would definitely need to
invest some resources in creating good tools that generate signed XPIs
with as little developer effort as possible. I agree that we would need
to integrate this into the SDK build tool as part of that plan.

Jorge

[Jorge Villalobos]

On 12/11/13 6:31 AM, Wesley Hardman wrote:
> This approach seems much more open, while still being secure.
>
> Is there going to be a developer override, or will developers have to repackage and resign the addon each time?

We would still need to support developer overrides, like we do in the
original File Reg proposal.

> When would the check be done, during install? What about side-loaded addons?

The checks would also be similar to File Reg: check on install, allow if
there are network problems during install, and then do regular checks of
installed add-ons (every 24 hours or something like that).

>
> I think a combination of Jorge's proposal and Benjamin's no-network proposal would be the best approach.
>
> Addons that are signed by a trusted certificate get installed, then attempt to contact AMO. If AMO is available verify the addon and certificate against the blocklist, if not install anyway.
> Addons that are not signed by a trusted certificate do not get installed unless AMO can be contacted and the addon and certificate verified.
> An AMO root certificate can be setup and recommended as the root for all AMO hosted addons. The AMO root would be trusted and these addons could be installed offline.
>
>> C. Verify before they are installed that addons meet our policies
> Reviewed and verified addons should be given a simpler install path. Why do I have to go through multiple steps and wait 3 seconds for an addon that is reviewed and verified?

The 3 second wait is there to protect users against click jacking, I
think, and it's something that we have been wanting to remove for a
while. Even if we wanted to have different trust levels for installs, I
don't know if we really want to keep the counter for any of those cases.

[Jeff Griffiths]

Jorge Villalobos wrote:
> On 12/11/13 6:31 AM, Wesley Hardman wrote:

>> This approach seems much more open, while still being secure.
>>
>> Is there going to be a developer override, or will developers have to repackage and resign the addon each time?
>

> We would still need to support developer overrides, like we do in the
> original File Reg proposal.

I'd like to add to this a hint of some work the Jetpack team is working
on. We're making some changes to the add-on manager to allow SDK-style
add-ons to be loaded from a local directory, similar to how chrome
works. Additionally, the add-on manager would be able to load an
SDK-style add-on from a zip file. In both cases all that is needed is
the usual unpacked SDK directory layout and a package.json file.

Regardless of which proposal we go with, this will be the preferred
method to use for developing SDK-style extensions going forward, and we
hope is much more streamlined for developers than the current state.

Jeff

[Philip Chee]

How would this affect XULRunner applications like Instantbird which has
it's own addons.instantbird. I think Pale Moon is moving towards having
their own addons site as well.

Phil

--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.

[Jorge Villalobos]

This would be implemented for Firefox, and I suppose other XUL-based
applications could replicate the code for their own purposes.
Applications that are essentially Firefox clones would either need to
adopt this or fork/disable the relevant code.

Jorge

[Gijs Kruitbosch]

Actually, a lot of the add-on manager code lives in toolkit. I suspect
this would require SM/Thunderbird/... to disable the code or fork the UI
bits so it'd work correctly. How much they'd get for free would depend
on how much of this work can happen in toolkit.

~ Gijs

[Philip Chee]

On 26/06/2014 16:16, Gijs Kruitbosch wrote:

>> This would be implemented for Firefox, and I suppose other XUL-based
>> applications could replicate the code for their own purposes.
>> Applications that are essentially Firefox clones would either need to
>> adopt this or fork/disable the relevant code.
>>
>> Jorge
>
> Actually, a lot of the add-on manager code lives in toolkit. I suspect
> this would require SM/Thunderbird/... to disable the code or fork the UI
> bits so it'd work correctly. How much they'd get for free would depend
> on how much of this work can happen in toolkit.
>
> ~ Gijs

Actually *all* the add-on manager code lives in toolkit. Perhaps a build
time mozconfig switch?