Alternate proposal to require signed add-ons

[Daniel Veditz]

I've put together an alternative to the add-on signing proposal that was
floated earlier. The main differences are

* does not invent a new signature format
* signatures can work for unpacked add-ons
* eliminates the on-line whitelisting service requirement
* AMO-hosted add-ons will be signed by us (saves bother
for most developers)
* installs are limited to AMO by default (but prefs are
available for users who know what they're doing)

https://docs.google.com/a/mozilla.com/document/d/1KhpDteoHFmVRkzlrT8v0N3F-KrPxLoZFM3mWmEmOses/edit#

-Dan Veditz

[Philipp Kewisch]

When I first read your email it sounded like all that would be required
is any SSL certificate to be able to install addons. In the docs link in
the section "Obtaining Certificates for Non-hosted Add-ons", it rather
sounds like a Mozilla-issued certificate is REQUIRED for installing
non-AMO addons. Two questions on that:

* Is this really the case, or can I just use my own SSL certificate that
is verifiable in Firefox, i.e. from startssl?
* Can I instead get an AMO certificate by uploading an extension with
preliminary review, then use that certificate for all future versions
that I do NOT upload to AMO?
* How often do these certificates expire?

I am also concerned that charging for these certificates will require a
strong public statement as to why Mozilla is doing this, especially if
you go with the developer model of charging $99 for a few certificates.
Especially since Marketplace addons can be distributed from any app
store, centralizing on AMO like this might cause a certain uproar,
especially from companies that use internal addons for their customers
and do like the idea of paying extra to continue to be able to push
their addons to their customers.

Philipp

(Note for press: I believe none of this is final yet, please don't draw
any wrong conclusions from my post)

[Daniel Veditz]

On 6/24/2014 12:08 AM, Philipp Kewisch wrote:
> When I first read your email it sounded like all that would be
> required is any SSL certificate to be able to install addons.

You cannot today sign add-ons with SSL certificates, they must be
"object signing" certificates. I'm not proposing to change that. The
proposal is that signing will now be required, and that the cert must be
issued by Mozilla rather than a random CA.

> it rather sounds like a Mozilla-issued certificate is REQUIRED for
> installing non-AMO addons. Two questions on that:

A Mozilla-issued certificate is required for installing ALL addons, but
if you go through AMO review Mozilla will take care of the signing for
you for free.

> * Can I instead get an AMO certificate by uploading an extension
> with preliminary review, then use that certificate for all future
> versions that I do NOT upload to AMO?

Signing through the review process will yield a signed add-on, but not a
certificate that will let you sign additional things AMO hasn't seen.

> * How often do these certificates expire?

TBD, but a year or two is typical for certs. signed code doesn't expire,
only the ability to sign new code. Once a developer is signed up cert
renewals will be free.

> I am also concerned that charging for these certificates will require
> a strong public statement as to why Mozilla is doing this,

We're doing this because every time any of us visits our family their
Firefox is a toolbar laden crapfest that we have to clean up, and
because the resulting bad performance is causing us to lose users. To
get a cert you will have to agree to our Terms of Service for a
well-behaved add-on. Not proposing any change to those, just adding an
enforcement mechanism for add-ons not distributed through AMO
https://addons.mozilla.org/en-US/developers/docs/policies/reviews#section-policies

> Especially since Marketplace addons can be distributed from any app
> store, centralizing on AMO like this might cause a certain uproar,

Argh. This is the problem. Marketplace APPS are NOTHING LIKE add-ons,
but people think of them the same. The Firefox OS apps you can get
"anywhere" are glorified bookmarks and cannot do anything that a web
page cannot do. "Privileged" apps must be signed by the One True Mozilla
Marketplace, and even if one of those apps had every possible privilege
it still wouldn't be as powerful as an add-on. [off topic: I think it is
a terrible, no-good, horrible thing that we don't show the privileges an
app is being granted, making this distinction completely mysterious to
people.]

> especially from companies that use internal addons for their
> customers and do like the idea of paying extra to continue to be able
> to push their addons to their customers.

If it's internal as in Enterprise stuff, and they don't want to get a
certificate then they can always build and distribute their own internal
Firefox with the signature checking disabled. If they're distributing
the add-on to public customers then they have to get a cert. I'm not
worried about companies, the cost of a cert (whatever model) is less
than the cost of a "business lunch".

> (Note for press: I believe none of this is final yet, please don't
> draw any wrong conclusions from my post)

This is no more final than Jorge's previous proposals to which I offer
mine as an alternative. I ran this by a couple of colleagues as a sanity
check before posting but no one with decision-making authority over
Firefox has commented or agreed to do this.

-Dan Veditz

[Gijs Kruitbosch]

Concurring with Philipp here - and for a more fundamental question, why
are we picking the "charge for certificates" option to verifying users /
protecting against abuse? Is there no other way we can do this?

I'd probably be more OK with, say, storing scans of people's ID and
their full legal name + password document number (destroying the actual
IDs after verification) as a substitute. AirBNB has a process for this,
for instance.

(I realize that people might disagree here for privacy reasons, but when
I was a student without a credit card, I would have happily told Mozilla
who I was, but would have had trouble paying even a nominal sum in USD
over the internet)

~ Gijs

[Wesley Hardman]

I like the idea in general, however:

1. What about developers? It sounds like there will be a preference to disable it. Whats to stop installers from changing the preference?
2. Are themes included? I am frequently fixing my theme (thanks dev tools) every release. I alter the theme and restart Firefox sometimes 20+ times.
(More below)

Info: I have my own private theme and addon that I maintain. I have no intention on uploading it to AMO or purchasing a certificate. It is currently installed on 5 computers, one of which I would like to keep cert checking on. The other 3 I don't care as much about.

On 2014-06-24 11:03, Daniel Veditz wrote:
> On 6/24/2014 12:08 AM, Philipp Kewisch wrote:
>> When I first read your email it sounded like all that would be
>> required is any SSL certificate to be able to install addons.
>
> You cannot today sign add-ons with SSL certificates, they must be
> "object signing" certificates. I'm not proposing to change that. The
> proposal is that signing will now be required, and that the cert must be
> issued by Mozilla rather than a random CA.

3. Can user defined certs (roots) be added (if nothing else, at compile time)? I would rather use my own cert (private root server, not self-signed) as opposed to disabling the checking.

>
>> it rather sounds like a Mozilla-issued certificate is REQUIRED for
>> installing non-AMO addons. Two questions on that:
>
> A Mozilla-issued certificate is required for installing ALL addons, but
> if you go through AMO review Mozilla will take care of the signing for
> you for free.
>
>> * Can I instead get an AMO certificate by uploading an extension
>> with preliminary review, then use that certificate for all future
>> versions that I do NOT upload to AMO?
>
> Signing through the review process will yield a signed add-on, but not a
> certificate that will let you sign additional things AMO hasn't seen.
>
>> * How often do these certificates expire?
>
> TBD, but a year or two is typical for certs. signed code doesn't expire,
> only the ability to sign new code. Once a developer is signed up cert
> renewals will be free.
>
>> I am also concerned that charging for these certificates will require
>> a strong public statement as to why Mozilla is doing this,
>
> We're doing this because every time any of us visits our family their
> Firefox is a toolbar laden crapfest that we have to clean up, and
> because the resulting bad performance is causing us to lose users. To

This is becoming more and more common as programs are bundling crapware (malware?) with their "installers", with the default to ON. Even SourceForge is doing this.

> get a cert you will have to agree to our Terms of Service for a
> well-behaved add-on. Not proposing any change to those, just adding an
> enforcement mechanism for add-ons not distributed through AMO
> https://addons.mozilla.org/en-US/developers/docs/policies/reviews#section-policies
>
>> Especially since Marketplace addons can be distributed from any app
>> store, centralizing on AMO like this might cause a certain uproar,
>
> Argh. This is the problem. Marketplace APPS are NOTHING LIKE add-ons,
> but people think of them the same. The Firefox OS apps you can get
> "anywhere" are glorified bookmarks and cannot do anything that a web
> page cannot do. "Privileged" apps must be signed by the One True Mozilla
> Marketplace, and even if one of those apps had every possible privilege
> it still wouldn't be as powerful as an add-on. [off topic: I think it is
> a terrible, no-good, horrible thing that we don't show the privileges an
> app is being granted, making this distinction completely mysterious to
> people.]
>
>> especially from companies that use internal addons for their
>> customers and do like the idea of paying extra to continue to be able
>> to push their addons to their customers.
>
> If it's internal as in Enterprise stuff, and they don't want to get a
> certificate then they can always build and distribute their own internal
> Firefox with the signature checking disabled. If they're distributing
> the add-on to public customers then they have to get a cert. I'm not
> worried about companies, the cost of a cert (whatever model) is less
> than the cost of a "business lunch".

4. See 3. above. I think most enterprises would prefer to install their own root.

[Benjamin Smedberg]

On 6/24/2014 2:36 PM, Wesley Hardman wrote:
> I like the idea in general, however:
>
> 1. What about developers? It sounds like there will be a preference to disable it. Whats to stop installers from changing the preference?

As the proposal is currently written, the preference to disable this is
only available in nightly/aurora and is specifically not available in
beta/release.

> 2. Are themes included? I am frequently fixing my theme (thanks dev tools) every release. I alter the theme and restart Firefox sometimes 20+ times.
> (More below)

That's a good question. I think that lightweight themes aren't or
shouldn't be part of this discussion, but heavyweight themes should be,
since they can do pretty much anything a normal extension can do,
including own the user's system.

>
> 3. Can user defined certs (roots) be added (if nothing else, at compile time)?

Certainly at compile time. I don't know whether we'd want to support
this at runtime, because it basically becomes just another kind of pref.

--BDS

[Philip Chee]

On 25/06/2014 03:05, Benjamin Smedberg wrote:

> That's a good question. I think that lightweight themes aren't or
> shouldn't be part of this discussion, but heavyweight themes should be,
> since they can do pretty much anything a normal extension can do,
> including own the user's system.

I believe you are mistaken. "Full" themes can't execute JavaScript (not
even from XBL). There may be unfixed loop-holes, but they are loop-holes
not intentional features.

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.

[Wesley Hardman]

I was thinking the same thing. Themes can only hide DOM elements not add them or add functionality.

If it *is* possible to include overlays and js within a theme (or theme within an addon) please let me know. I would prefer to have one addon as opposed to two.

[Philipp Kewisch]

On 6/24/14 5:03 PM, Daniel Veditz wrote:
> On 6/24/2014 12:08 AM, Philipp Kewisch wrote:
>> When I first read your email it sounded like all that would be
>> required is any SSL certificate to be able to install addons.
>
> You cannot today sign add-ons with SSL certificates, they must be
> "object signing" certificates. I'm not proposing to change that. The
> proposal is that signing will now be required, and that the cert must be
> issued by Mozilla rather than a random CA.

Sorry, wrong term on my side. I was aware an object signing cert is
required, I guess I wrongly generalized to SSL cert.

>
> TBD, but a year or two is typical for certs. signed code doesn't expire,
> only the ability to sign new code. Once a developer is signed up cert
> renewals will be free.

Ok, so lets say we go with the $99 model, this means pay $99 once and be
able to sign a certain amount of addons forever? I think thats
acceptable. I was concerned about a $99 per year deal. Of course its not
a lot, but its still a new cost to consider.

>
>> I am also concerned that charging for these certificates will require
>> a strong public statement as to why Mozilla is doing this,
>
> We're doing this because every time any of us visits our family their
> Firefox is a toolbar laden crapfest that we have to clean up, and
> because the resulting bad performance is causing us to lose users. To
> get a cert you will have to agree to our Terms of Service for a
> well-behaved add-on. Not proposing any change to those, just adding an
> enforcement mechanism for add-ons not distributed through AMO
> https://addons.mozilla.org/en-US/developers/docs/policies/reviews#section-policies

I was rather aiming at "why Mozilla is charging money", but reading over
my argumentation again, maybe I am just overly concerned.


Thanks for addressing my concerns, I think I am good with this proposal
and will see how things develop.

Philipp

[Jorge Villalobos]

Here are my notes about the new proposal (sorry if I missed something in
the newer version):

* Overall I like the idea. Tying the ID to the cert makes it easier to
verify it and remove the necessity of the API.

* I don't see the purpose of limiting installation to AMO. The
overwhelming majority of non-AMO installs are side-installs anyway, and
most direct installs I've seen elsewhere are legitimate. The majority of
harm for users comes from side-installs. We already have a whitelisting
mechanism for unknown domains, so I'd like to know what about it is
considered bad.

* There are legitimate reasons for not hosting add-ons on AMO. We have
some content restrictions like adult content, online gambling and a few
other things that in some cases only make sense in the US, but we need
to follow them because we're a US company. I don't want us to become a
walled garden like Google, which has drawn lots of criticism their way
and would make us lose a lot of credibility with our developer community.

* If we're going to reuse our old signing system, we need to renovate
our toolchain. It is currently really hard to deal with and we need to
make it as smooth to use as possible, even if its users are only going
to be a minority.

* I'm opposed to charging non-AMO devs. While it may prevent *some*
spamming (I don't think it'll stop the problematic devs), it represents
a significant barrier for some of the people we want working on add-ons.
Say, if a student in India implements some little add-on for a school
project and because of its nature we can't accept it on AMO. $5-$10 is a
lot of money for someone like that, and just having a payment system
that works reliably worldwide is a huge challenge. Having an alternative
path where we can manually vet developers who can't pay is a must IMO.

Regards,

Jorge

[Kris Maglione]

On Wed, Jun 25, 2014 at 11:37:12AM +0800, Philip Chee wrote:
>On 25/06/2014 03:05, Benjamin Smedberg wrote:
>

>> That's a good question. I think that lightweight themes aren't or
>> shouldn't be part of this discussion, but heavyweight themes should be,
>> since they can do pretty much anything a normal extension can do,
>> including own the user's system.
>

>I believe you are mistaken. "Full" themes can't execute JavaScript (not
>even from XBL). There may be unfixed loop-holes, but they are loop-holes
>not intentional features.

Agree. This should only apply to extensions. There may be
unclosed loopholes in themes that allow code execution, but they
seem a much less likely avenue for sneaking in extension code
than the more obvious options of directly evading the signature
checking.

--
Kris Maglione
Add-ons Technical Editor
Mozilla Corporation

Everything you add to the truth subtracts from the truth.
--Alexander Solzhenitsyn

[Archaeopteryx]

-------- Original-Nachricht --------
Betreff: Alternate proposal to require signed add-ons
Von: Daniel Veditz <dve...@mozilla.com>
Datum: 2014-06-24 2:48

The biggest issue I have with this: For add-on localization, translators
usually have to repack add-ons developed by someone else with their
translation and test it. This won't work anymore with release builds in
the current proposal.

Other notes:

"When an unsigned add-on is submitted for review if it passes basic
automated sanity tests a certificate will be generated for that ID and
the file will be signed so reviewers can more easily test it."
If a malicious developer uses try and error for writing and uploading a
malicious extension to AMO until it passes theses automated tests and he
deletes it from AMO afterwards, does he still have a malicious extension
he can use for distribution?

"From a logged-in AMO account the developer can register their add-on ID
and request a certificate for it. We must charge a nominal amount for
these certificates, say $5 or $10, to discourage spamming of the
registration process."
$5 or $10 will be negligible for people who earn money by selling
browser history, adding affiliate code to links, sniffing online banking
data, etc. That's likely cheaper than paying strawmen to obtain a
developer certificate. Malicious unreviewed, signed extensions which got
side-loaded will likely download a patch which removes the certification
requirement. And as there is money in this business, a new certificate
every working day is affordable and effective when combined with a
dynamical generated and downloaded signed .xpi (loaded by the
side-installer).

Someone new to addon development on the other side will be reluctant to
pay for being allowed to do add-on development. Fast iterations make
uploading each build cumbersome, and people will work on release because
they use that and target it. Would it be possible to provide unbranded
release builds which ofter the same design and internals like a release
Firefox, but allow running extensions without signing?

Are they plans to make the installations of these malicious extensions
financially less attractive by e.g. legal action against computer
sabotage and trying to freeze the income, or convincing the advertisers
(legally?) to not use these partners?

Sebastian

[Mook]

On 06/24/2014 12:05 PM, Benjamin Smedberg wrote:
>
> On 6/24/2014 2:36 PM, Wesley Hardman wrote:
>> I like the idea in general, however:
>>
>> 1. What about developers? It sounds like there will be a preference
>> to disable it. Whats to stop installers from changing the preference?
>
> As the proposal is currently written, the preference to disable this is
> only available in nightly/aurora and is specifically not available in
> beta/release.

(Replying to the general point about no development in beta/release, not
this message in particular)

Does that mean that if a change lands on beta, the addon developer will
not be able to debug it? Pushing to AMO is fairly clearly the wrong
thing to do in this situation. Similarly, if a user on a release
reports a bug.

--
Mook

[Wesley Hardman]

Agreed here. I do all of my development against the release version. (Its the only one I generally care about.)

What about testing? How would you test to make sure your change doesn't break in the current released version? There are often breaking changes from version to version.

[Robert Kaiser]

Replying to Jorge, because my thoughts match his in most points.

Jorge Villalobos schrieb:

> * Overall I like the idea.

Yes, I like it much better than the other proposal that was on the
table! Thanks for this!

> * I don't see the purpose of limiting installation to AMO. The
> overwhelming majority of non-AMO installs are side-installs anyway, and
> most direct installs I've seen elsewhere are legitimate. The majority of
> harm for users comes from side-installs.

I mostly agree here, though an actual equivalent of the Android "Unknown
sources" pref may be useful (if non-AMO sources, including
side-installs, are off by default but just a pref away to enable).

Also given that the ID being tied to a cert we issued is a prerequisite,
along with an agreement to our terms, we can work with the blocklist way
more efficiently. That alone is a big improvement to the current
situation with randomly-changing IDs and a whack-a-mole game of
blocklisting at best.

> * If we're going to reuse our old signing system, we need to renovate
> our toolchain.

Yes, definitely. IMHO, we should have an official add-on that signs
add-ons with the certs. :)

> * I'm opposed to charging non-AMO devs.

Yes, let's please see that we do not have to take that action, it sounds
very un-Mozilla and deters the student that wants to learn how to make
stuff on their own. We want to encourage that behavior, IMHO.


The only other concern I have is around the developer story. I think we
need to have the ability to test add-ons on Beta and Release before
shipping them. If that means I need to load a Mozilla-issued cert for
that ID into the browser (without actually signing the add-on code I
develop), so be it. Or if we find some other way that makes it
unattractive as an attack surface. But please let me test my add-ons on
Beta (and Release) before I push it to AMO and debug the issues I find
there.

As for the full themes discussion, that's where my
most-development-active add-on (LCARStrek) falls into and due to the
version-to-version churn we have in the UI, it's impossible to ship it
at any point without some debugging against Beta. That said, an add-on
actually marked for the theme category correctly is very restricted in
what it can do (no script, no overlays, no overrides, you get the
picture) so we could exclude them possibly - but if developing and
testing against beta and release is possible, I don't think we even need
to exclude them.
Lightweight themes I think we could exclude either way.

KaiRo

[Daniel Veditz]

On 6/25/2014 9:38 PM, Mook wrote:
> Does that mean that if a change lands on beta, the addon developer will
> not be able to debug it? Pushing to AMO is fairly clearly the wrong
> thing to do in this situation. Similarly, if a user on a release
> reports a bug.

In my proposal they will be able to debug in debug builds, which are
available at ftp.mozilla.org. They could also build their own opt-builds
with the appropriate config flags (but I acknowledge that's unlikely).

If this turns into a major sticking point we can look into making
special test builds available, perhaps un-branded.

-Dan Veditz

[Jeff Griffiths]

Daniel Veditz wrote:
> On 6/25/2014 9:38 PM, Mook wrote:

>> Does that mean that if a change lands on beta, the addon developer will
>> not be able to debug it? Pushing to AMO is fairly clearly the wrong
>> thing to do in this situation. Similarly, if a user on a release
>> reports a bug.
>

> In my proposal they will be able to debug in debug builds, which are
> available at ftp.mozilla.org. They could also build their own opt-builds
> with the appropriate config flags (but I acknowledge that's unlikely).
>
> If this turns into a major sticking point we can look into making
> special test builds available, perhaps un-branded.

This is a major sticking point as far as I can see - add-on developers
need a convenient way to test their code in release builds. Even with an
api as conservative as the add-on sdk's 'high-level apis' you could see
an issue where release issues a deprecation warning for an api, but the
developer won't see that as a problem until review because they are
developing using Nightly where that warning is no longer issued. With
platform apis or lower-level sdk or devtools apis the rate of change and
guarantees for compatibility would make this much worse.

Doing a separate build isn't a terrible idea - it means that the upside
for exploiting that build is very small. We could promote the builds as
part of a larger tooling effort for add-on developers?

I would also be interested in some well-documented but intentionally
manual way of kicking a release build into 'developer mode', something
like what you need to do to reveal the developer options in Android
these days ( if you're not familiar, you need to tap the phone build in
Settings / About Phone 10(?) times )

Jeff

[Daniel Veditz]

On 6/26/2014 7:04 AM, Archaeopteryx wrote:
> The biggest issue I have with this: For add-on localization, translators
> usually have to repack add-ons developed by someone else with their
> translation and test it. This won't work anymore with release builds in
> the current proposal.

Yes, they'd have to use debug builds for testing, e.g.
https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-release-win32-debug/latest/

> "When an unsigned add-on is submitted for review if it passes basic
> automated sanity tests a certificate will be generated for that ID and
> the file will be signed so reviewers can more easily test it."
> If a malicious developer uses try and error for writing and uploading a
> malicious extension to AMO until it passes theses automated tests and he
> deletes it from AMO afterwards, does he still have a malicious extension
> he can use for distribution?

We don't have to make that signed version available on the site until
it's passed full review. Or we delay signing and have reviewers use
debug builds (or maybe we'll have to make un-branded opt-builds
available for testing as you suggested).

Yes, we can't set up a magic signing oracle.

> $5 or $10 will be negligible for people who earn money by selling

> browser history, [...]

> Someone new to addon development on the other side will be reluctant to
> pay for being allowed to do add-on development.

Yes, complaints on both sides that it's too much and too little. What I
really want is for it to be a non-automatic process so we can try to get
an idea who's trying to hitch a ride on our success and make sure
they're not abusing people.

Someone new to add-on development should NOT be the people wanting
certs. If you're new then play with development builds, you shouldn't
worry about releasing your new toy.

-Dan Veditz

[Daniel Veditz]

On 6/27/2014 9:22 AM, Jeff Griffiths wrote:
> This is a major sticking point as far as I can see - add-on developers
> need a convenient way to test their code in release builds.

Why wouldn't a debug build of the shipping release be good enough for
testing? I end up browsing a fair amount of the time in debug builds and
hardly notice the difference.

-Dan Veditz

[Jeff Griffiths]

Daniel Veditz wrote:
> On 6/27/2014 9:22 AM, Jeff Griffiths wrote:

>> This is a major sticking point as far as I can see - add-on developers
>> need a convenient way to test their code in release builds.
>

> Why wouldn't a debug build of the shipping release be good enough for
> testing? I end up browsing a fair amount of the time in debug builds and
> hardly notice the difference.

That depends greatly on your browsing habits, I expect. Whenever I run a
debug try build ( on OS X, on an Air ) I definitely notice the difference.

One major difference with debug builds is that they spam stdout, and we
rely on printing to stdout in our tools as well. Maybe there is a way
our runner could turn off all the platform debug info.

Jeff

[Philipp Kewisch]

On 6/27/14 9:03 PM, Jeff Griffiths wrote:
> Daniel Veditz wrote:
>> On 6/27/2014 9:22 AM, Jeff Griffiths wrote:
>>> This is a major sticking point as far as I can see - add-on developers
>>> need a convenient way to test their code in release builds.
>>
>> Why wouldn't a debug build of the shipping release be good enough for
>> testing? I end up browsing a fair amount of the time in debug builds and
>> hardly notice the difference.

Also, I've heard of certain situations in the past where debug builds
behave differently than non-debug builds.

For testers this does mean yet another build to try out. While for me
its perfectly clear, a new developer might get confused by yet another
build to test with.

I know this is not in the Mozilla focus, but I'm a little concerned that
relying on debug builds means extra work for Thunderbird too, where I
believe there are no debug builds for these branches. I see the folders
created, but no builds in there.

Out of curiosity, how easy will it be to circumvent the checking after
the build has been done? Changing a text file or database? Hacking a
binary? I'm sure its just a matter of time before someone will figure
this out and make evil use of it, but I'd be interested in a quick way
of turning this off as a developer.

Philipp

[Kris Maglione]

On Thu, Jun 26, 2014 at 04:04:43PM +0200, Archaeopteryx wrote:
>-------- Original-Nachricht --------
>Betreff: Alternate proposal to require signed add-ons
>Von: Daniel Veditz <dve...@mozilla.com>
>Datum: 2014-06-24 2:48

>The biggest issue I have with this: For add-on localization,
>translators usually have to repack add-ons developed by someone else
>with their translation and test it. This won't work anymore with
>release builds in the current proposal.

This boils down to the developer use case, which means
localizers will probably need to run developer builds. On the
other hand, for traditional chrome: locale extensions, they can
just make secondary language pack add-ons, which we can waive
signature verification for.

>"When an unsigned add-on is submitted for review if it passes basic
>automated sanity tests a certificate will be generated for that ID and
>the file will be signed so reviewers can more easily test it."
>
>If a malicious developer uses try and error for writing and uploading
>a malicious extension to AMO until it passes theses automated tests
>and he deletes it from AMO afterwards, does he still have a malicious
>extension he can use for distribution?

Yes, but this is really no more of an issue than a developer
just buying a signing cert and using it to develop malicious
extensions. In any case, we should probably restrict the
download of XPIs for unreviewed extensions to editors.

>"From a logged-in AMO account the developer can register their add-on
>ID and request a certificate for it. We must charge a nominal amount
>for these certificates, say $5 or $10, to discourage spamming of the
>registration process."
>

>$5 or $10 will be negligible for people who earn money by selling

>browser history, adding affiliate code to links, sniffing online
>banking data, etc.

The point is to prevent developers from generating thousands of
certs for different IDs. $5/instance would be a serious hit to
most of these people.

>Are they plans to make the installations of these malicious extensions
>financially less attractive by e.g. legal action against computer
>sabotage and trying to freeze the income, or convincing the
>advertisers (legally?) to not use these partners?

This is, unfortunately, not terribly feasible.

--
Kris Maglione
Add-ons Technical Editor
Mozilla Corporation

If you want to make peace with your enemy, you have to work with your
enemy. Then he becomes your partner.
--Nelson Mandela

[Kris Maglione]

On Fri, Jun 27, 2014 at 02:31:41AM +0200, Robert Kaiser wrote:
>Replying to Jorge, because my thoughts match his in most points.
>
>Jorge Villalobos schrieb:

>>* Overall I like the idea.
>

>Yes, I like it much better than the other proposal that was on the
>table! Thanks for this!
>
>

>>* I don't see the purpose of limiting installation to AMO. The
>>overwhelming majority of non-AMO installs are side-installs anyway, and
>>most direct installs I've seen elsewhere are legitimate. The majority of
>>harm for users comes from side-installs.
>

>I mostly agree here, though an actual equivalent of the Android
>"Unknown sources" pref may be useful (if non-AMO sources, including
>side-installs, are off by default but just a pref away to enable).
>
>Also given that the ID being tied to a cert we issued is a
>prerequisite, along with an agreement to our terms, we can work with
>the blocklist way more efficiently. That alone is a big improvement to
>the current situation with randomly-changing IDs and a whack-a-mole
>game of blocklisting at best.
>

>>* If we're going to reuse our old signing system, we need to renovate
>>our toolchain.
>

>Yes, definitely. IMHO, we should have an official add-on that signs
>add-ons with the certs. :)
>

>>* I'm opposed to charging non-AMO devs.
>

>Yes, let's please see that we do not have to take that action, it
>sounds very un-Mozilla and deters the student that wants to learn how
>to make stuff on their own. We want to encourage that behavior, IMHO.
>
>
>The only other concern I have is around the developer story. I think
>we need to have the ability to test add-ons on Beta and Release before
>shipping them.

I agree. We definitely need to make it easy to test on beta and
release, even if that means distributing special developer
builds, probably with special branding.

--
Kris Maglione
Add-ons Technical Editor
Mozilla Corporation

Real misanthropes are not found in solitude, but in the world; since
it is experience of life, and not philosophy, which produces real
hatred of mankind.
--Giacomo Leopardi

[Kris Maglione]

On Fri, Jun 27, 2014 at 10:00:01AM -0700, Daniel Veditz wrote:
>Someone new to add-on development should NOT be the people wanting
>certs. If you're new then play with development builds, you shouldn't
>worry about releasing your new toy.

I mostly agree, but there's still valid concern about young
developers playing around with code, who want to share their
add-ons with a small group of friends, for instance. I think we
need to cater to these people in some manner or other, but I'm
not sure how. The best I can think of would be to allow
unindexed listings on AMO with a very light, ideally automated,
review process.

--
Kris Maglione
Add-ons Technical Editor
Mozilla Corporation

Several excuses are always less convincing than one.
--Aldous Huxley

[Kris Maglione]

On Fri, Jun 27, 2014 at 09:44:01PM +0200, Philipp Kewisch wrote:
>Out of curiosity, how easy will it be to circumvent the checking after
>the build has been done? Changing a text file or database? Hacking a
>binary? I'm sure its just a matter of time before someone will figure
>this out and make evil use of it, but I'd be interested in a quick way
>of turning this off as a developer.

It should be extremely difficult. There definitely will not be a
simple pref to flip in release builds. There will certainly be
people who circumvent it, but when they do, they will be
indisputably malware, and we'll react accordingly.

[Jorge Villalobos]

On 6/27/14, 3:33 PM, Kris Maglione wrote:
> On Fri, Jun 27, 2014 at 10:00:01AM -0700, Daniel Veditz wrote:
>> Someone new to add-on development should NOT be the people wanting
>> certs. If you're new then play with development builds, you shouldn't
>> worry about releasing your new toy.
>
> I mostly agree, but there's still valid concern about young developers
> playing around with code, who want to share their add-ons with a small
> group of friends, for instance. I think we need to cater to these
> people in some manner or other, but I'm not sure how. The best I can
> think of would be to allow unindexed listings on AMO with a very
> light, ideally automated, review process.
>

The Chrome store now allows you to create private listings, which behave
pretty much as unreviewed add-ons now on AMO (you can only find the
listing with a direct link). We could consider implementing something
like that, but we also need to figure out how it would fit within our
policies.

Jorge

[Daniel Veditz]

On 6/27/2014 12:44 PM, Philipp Kewisch wrote:
> I know this is not in the Mozilla focus, but I'm a little concerned that
> relying on debug builds means extra work for Thunderbird too, where I
> believe there are no debug builds for these branches. I see the folders
> created, but no builds in there.

This is planned as a build configure switch and I had imagined that
Thunderbird and SeaMonkey would not be interested in using it. Do they
need the protection from scumware, too?

Given the much smaller user-bases it's probably OK to keep the pref
active in at least Beta, if not Release, for those products. If there's
no pref to flip for Firefox users the malicious ones might not bother to
code it in just for Tb and SM.

If that's a bad assumption then I guess we'll have to build extra builds
for Thunderbird, too.

> Out of curiosity, how easy will it be to circumvent the checking after
> the build has been done? Changing a text file or database? Hacking a
> binary? I'm sure its just a matter of time before someone will figure
> this out and make evil use of it

Not easy -- hacking the binary. Not that hard, either, but such software
certainly can't try to pretend it's a legitimate thing to do. This will
invalidate the signature on the executable (on Windows and Mac). It will
break partial updates and then get overwritten by the fallback full
update. We should work with anti-virus vendors to make sure their
heuristic detection of badness includes attempting to write to a signed
executable.

-Dan Veditz

[Philipp Kewisch]

On 6/28/14 12:35 AM, Daniel Veditz wrote:
> On 6/27/2014 12:44 PM, Philipp Kewisch wrote:
>> I know this is not in the Mozilla focus, but I'm a little concerned that
>> relying on debug builds means extra work for Thunderbird too, where I
>> believe there are no debug builds for these branches. I see the folders
>> created, but no builds in there.
>
> This is planned as a build configure switch and I had imagined that
> Thunderbird and SeaMonkey would not be interested in using it. Do they
> need the protection from scumware, too?
>
> Given the much smaller user-bases it's probably OK to keep the pref
> active in at least Beta, if not Release, for those products. If there's
> no pref to flip for Firefox users the malicious ones might not bother to
> code it in just for Tb and SM.
>
> If that's a bad assumption then I guess we'll have to build extra builds
> for Thunderbird, too.

I can't speak for the Thunderbird team, but given it can be disabled
using a build switch I think it will be fine. I'd guess this feature
won't be enabled for beta at least.

Thanks for the clarification.

[wsha...@gmail.com]

My add-ons are all on AMO, so I am mostly affected by this proposal as a developer, and it seems like many are already advocating for that use case....

I am interested in more thought going into the private add-on listings suggested by others. I do use a few add-ons I wrote myself for personal use (functionality too specific to myself to be useful to anyone else) that aren't really worth posting publicly on AMO. Also, I still use some old add-ons developed by others that were never uploaded to AMO and are no longer maintained. I don't think it's my place to upload them to AMO publicly. It would be nice if there were a registration mechanism other than paying for a certificate for both these kinds of add-ons.

One thing I couldn't tell from the proposal -- what happens when a computer is offline? Can add-ons be installed? Will they be enabled on restart? Some add-ons are closer to standalone programs than to web browser enhancements and provide a lot of functionality without an internet connection.

On Monday, June 23, 2014 8:48:44 PM UTC-4, Daniel Veditz wrote:

[testnu...@gmail.com]

Overall, this proposal is slight improvement, although it is still full of what I consider show-stoppers. And I still generally oppose the walled-garden that this effectively creates, and the fact that any and all add-ons would be under US jurisdiction because you'd always need to get into a contract with mozilla, be it to use AMO or to acquire a certificate, among other legal implications.


First of all, certificates (or an automated registration, or whatever) will not really hinder dedicated, malicious actors. If it is any indication, the Google stores (Chrome, Play) are full of "bad" apps. Apple *seems* to fare a bit better for whatever reason, but not really by much.

Following this proposal, once a certificate gets revoked, the badware author would just get another stooge obtaining another certificate. If you're making big enough bucks with your badware, you won't mind the additional $5 + whatever you pay your stooge, and since it takes at least a couple of days, if not weeks or months, from the time you start shipping your badware to the time mozilla will figure out there is a problem, diagnose the problem, revoke the cert and get the updated CRL to the users... Why would you stop? (unless you run out of stooges)

Meaning this whole proposal is still just a blacklist/blocklist and can be gamed, although it might be a bit harder to do so now.

Obtaining certificates by paying money is a good way to discourage motivated individuals to develop for Firefox. If you're Apple you may pull this shit because of the nice market share and network effects of your platform and because people cannot just buy an iPhone from a different vendor.
I see the Firefox situation a little differently: For a lot of users powerful extensions are the reason to keep using Firefox. By driving developers away you'll drive users away. And you'll be driving developers away; those without credit cards, those living in places where even $5 is a sizable amount of money, or those objecting to the very idea of paying an organization money just to provide free stuff that eventually will increase the value of the products of said organization, among others.
Free AMO signing is not a full substitute, because there is a large class of add-ons you cannot publish there, either due to AMO polices or because not all code can be legally shared or because the author might want to keep the add-on private to a certain group of people or just doesn't want to enter a contract with mozilla.

Also, how would I pay or otherwise authenticate from Iran or Cuba?
If the US congress passed new laws and authorities would order mozilla to revoke all certificates from e.g. residents of Russia, how could mozilla react?


The "developer mode" is a true show-stopper.
First on the technical merits: Nightlies, Aurora and Debug builds are simply not good enough to test and debug stuff, let alone dog-food add-ons prior to release.
E.g. If there are reports of a particular performance regression in Firefox Stable, then I'd need to be able to debug that. Nightly/Aurora may not show the same issue, Debug builds have different performance metrics, and building your own release build is too big a hurdle for most people, or not even feasible if you don't have access to the same toolchain.

Then it hinders participation: Even special "developer" builds are too much of a hurdle, really. If the add-on developer community where professional-grade developers, then this might work, but in reality the community largely consists of amateurs and hobbyists where only few folks make their living on developing Firefox add-ons.
This will discourage a lot of folks before they even start, and discourage a bunch of existing developers from continuing to maintain their add-ons.

Before now, everybody tried to make it easy to get started with add-on development (one of the goals for creating Jetpack/SDK in the first place).
This proposal does the opposite: Make it harder to even get started or at least keep going:
* Much steeper learning curve to even get an environment in place to develop add-ons.
* Much more bureaucracy.
* Much more legal considerations.
* Excluding some folks altogether.

As an added bonus, it might also drive amo-editors insane, because of the amount of "test" add-ons uploaded you might expect because "they won't open in the browser otherwise, you know?!"


Then I don't really get why online installation should be limited to AMO, but sideloading is still allowed. This would only encourage all actors to switch to side loading by providing "installer" programs instead of an XPI, at least on Desktop. So MSI and DMG/PKG it is and maybe an RPM and DEB for those linux people. You could counter that with a policy change, but that would mean to disallow sideloading retroactively.
So this bit of the proposal might actually worsen the situation. Once you go "installer" why not do a silent install when your at it already?


The transition period of one or two release cycles with immediate warnings doesn't really sound reasonable.
At least have a release circle or two not showing warnings just notices, so add-on developers can learn about it before users start to fill up their mailboxes.


I still don't understand how the proposal, if implemented, could significantly improve the situation compared to regular blacklisting (with or without some improved capabilities).
After all, the process is more or less the same:
- Get notice that an add-on might be bad.
- Determine if it is indeed bad.
- Put it on a list (right now, blacklist, later CRL)
So, really, the only difference to current blocklisting is that you revoke certificates instead of blocking by id, so actors will have to get another certificate instead of just changing the id.
OTOH, you'd still need to keep regular blocklisting around, because there needs to be a way to blocklist only particular versions of an add-on for stability problems or known vulnerabilities.


Last point: mozilla says it is all about "open". Standard, technologies, but also open participation, excluding nobody.
A walled garden, even one with good intensions, appears to be very much contrary to that "open" to me.


Given the strong technical, legal, procedural, community-related and even moral drawbacks, how exactly does this (and/or the previous proposals) really improve the "problem", why is it superior to blocklisting (with improved processes and technology) and what is the "problem" exactly in the first place and how big is it really?


Our current blacklist isn't particularly "full" it seems, and not even entirely composed of bad add-ons in the widest possible way of interpreting that term.


Cheers
Nils

[Mike Kaply]

The more I think about this problem, the more it seems like we're trying to build giant solutions to solve a very specific problem. Simply stated, the problem is this:

How do we prevent the sideloading of extensions on Windows while still allowing enterprises to have full control of their add-on experience and allow developers to do what they need?

Given that problem space, it seems much more logical to do what Chrome has done.

1. Do nothing on platforms other than Windows. As a side benefit, this helps with the developer problem since I would argue that a lot of developers are on Linux and Mac.

2. Completely disable sideloading of extensions on Windows. All extensions on Windows must be explicitly installed by the user, whether by clicking on an XPI or explicitly doing a File->Open on an XPI. Any extension that arrives on the user's system by any other mechanism is disabled (and cannot be enabled). Perhaps even go the Chrome route where the extension must be on AMO to be installed, but provide an option to hide the extension so that a developer could given an add-on to their friend by simply uploading it to AMO as hidden and then giving it to the friend.

3. Provide a way for enterprises to change these options that exists outside of Firefox and cannot be used by malware. This can be done via group policy. This is the only mechanism that a malware author cannot take advantage of because simply writing registry keys isn't enough. It requires a policy server. I would wager this would cover 99% of enterprises. For the 1%, provide a way to enable the extensions via AutoConfig. While this could be used by malware, it would be much easier to detect (and prevent) because it would require modifying the user's Firefox install (which would invoke UAC), not just their profile.

4. Provide a developer mode in Firefox such that when Firefox is running in this mode (and only when Firefox is running in this mode), allow extensions to be loaded from a path (similar to Chrome). Make something about this developer mode be obvious (similar to private mode), such that a user would know that they were somehow running in this mode. Perhaps even reset the developer mode at every startup (annoying I know, but effective).

All of these actions can be taken without affecting existing add-ons or users much at all.

Mike Kaply

[Kris Maglione]

On Mon, Jul 28, 2014 at 12:14:38PM -0700, Mike Kaply wrote:
>Given that problem space, it seems much more logical to do what Chrome has done.

The main thing that Chrome has done is to require that add-ons
only be installed from the Chrome store. That extreme is what
we're attempting to avoid with the signing system.

I'm still opposed to preventing side-loads entirely, since it
will hurt a class of legitimate add-ons, and simply cause
malware authors to bypass the restrictions entirely. I think
requires owners of signing keys to accept a usage policy and
requiring a clear and consistent opt-in process is the right
solution to this problem.

Clearly we need to give enterprises and developers a way to
bypass these restrictions. That will probably mean a special
developer build, as has been discussed. I'm still in favor of a
separate enterprise build as well, but GPO might also be an
acceptable solution.

--
Kris Maglione
Add-ons Technical Editor
Mozilla Corporation

If debugging is the process of removing bugs, then programming must be
the process of putting them in.
--Edsger W. Dijkstra

[Mike Kaply]

On Monday, July 28, 2014 5:23:44 PM UTC-5, Kris Maglione wrote:
> On Mon, Jul 28, 2014 at 12:14:38PM -0700, Mike Kaply wrote:
>
> >Given that problem space, it seems much more logical to do what Chrome has done.
>
> The main thing that Chrome has done is to require that add-ons
> only be installed from the Chrome store. That extreme is what
> we're attempting to avoid with the signing system.

That was their last resort. They did a lot of things before they finally gave up and resorted to that. In the end, they realized that anything they did on the client could be subverted by an executable (and it was, repeatedly). So the only solution was to have everything on a check against the server. If you follow the chain of events, there were a lot of things they tried first. And again, everything they've done is Windows only (even the store check). On Mac, you can load any extension without it being in the store.

> I'm still opposed to preventing side-loads entirely, since it
> will hurt a class of legitimate add-ons, and simply cause
> malware authors to bypass the restrictions entirely. I think
> requires owners of signing keys to accept a usage policy and
> requiring a clear and consistent opt-in process is the right
> solution to this problem.

I'm not opposed to side loading, but I think that legitimate consumer side loaded add-ons shouldn't have a reason not to submit their code to AMO (even if it is hidden, similar to Chrome). Then those add-ons would be allowed to be side loaded.

> Clearly we need to give enterprises and developers a way to
> bypass these restrictions. That will probably mean a special >
> developer build, as has been discussed.

Which I think is an really bad idea. The beauty of Firefox is that you can download it and hack with it. Requiring a special build will be a maintenance nightmare and a barrier.

> I'm still in favor of a
> separate enterprise build as well,

Again, very bad idea. The whole point of what we're doing with enterprise is to encourage them to use the same code as the rest of the world. Even with ESR, we still try to encourage them to use the mainline Firefox if they can.

Having a separate build just to make custom add-ons work would be a nightmare (unless we're going to do a real enterprise version of Firefox with enterprise fixes and features, not just the ESR).

> but GPO might also be an
> acceptable solution.

Mike Kaply

[rory....@gmail.com]

> > The main thing that Chrome has done is to require that add-ons
> > only be installed from the Chrome store. That extreme is what
> > we're attempting to avoid with the signing system.
>
> That was their last resort. They did a lot of things before they finally gave up and resorted to that. In the end, they realized that anything they did on the client could be subverted by an executable (and it was, repeatedly). So the only solution was to have everything on a check against the server. If you follow the chain of events, there were a lot of things they tried first. And again, everything they've done is Windows only (even the store check). On Mac, you can load any extension without it being in the store.
>

Chrome does allow for add-ons in enterprise environments to be loaded without being on the store if they're installed via GPO on a windows domain-joined machine. That would seem like a good and quite straightforward way of catering for enterprises: loosen the requirements for GPO-installed addons for machines on a windows domain.

Rory