Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Update on Signed Add-ons proposal

1,009 views
Skip to first unread message

Jorge Villalobos

unread,
Aug 19, 2014, 1:49:36 PM8/19/14
to mozilla-addons-...@lists.mozilla.org, Wil Clouser
Hello everyone,

After discussing the proposal internally, we have agreed that we want to
move forward with it. Some bugs have been filed for it already [1], so
please give them a look and provide feedback if you have any. There are
still some open problems that are better discussed on this list, so I'm
opening this thread to iron them out before we move this discussion to a
broader audience.

1) It's more difficult for developers to get started, since it requires
a special Firefox build to even work on a trivial add-on.

This is something I think we can mitigate leveraging the developer
tools. Just like app developers can easily install the Firefox OS
Simulator to test their apps, we can make it easy for add-on developers
to install and launch the special add-on tester Firefox build.

2) Require non-AMO developers to pay and sign an agreement in order to
obtain self-signing certs.

I think signing the agreement is necessary, but it needs to be focused
on following our guidelines [2] and avoid being too US-centric (this is
one of the reasons for not hosting add-ons on AMO after all). As for the
payment, I think it should be low (say, $5) and we should also provide a
free alternative, strictly limited to cases where payment isn't possible
(due to location and/or economic status plus reasons for not using AMO).
I think the required payment should be low in order to minimize the
amount of exceptions we need to give. We might need to do a study of
non-AMO add-on developers to determine where to draw this line.

3) Don't allow non-AMO web installs and only allow side-loading.

This one I just disagree with. The evidence we have points to silent
side-loading as the main culprit for add-on problems. Web installs
provide some hurdles for installation, and if we need to discuss how to
refine that install experience to make it safer, it should be a separate
discussion.

If I'm missing anything, please bring it up.

Thanks.

Jorge

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=signed-addons
[2] https://developer.mozilla.org/en-US/Add-ons/Add-on_guidelines

Jeff Griffiths

unread,
Aug 19, 2014, 1:59:26 PM8/19/14
to Jorge Villalobos, mozilla-addons-...@lists.mozilla.org, Wil Clouser


Jorge Villalobos wrote:
> Hello everyone,
>
> After discussing the proposal internally, we have agreed that we want to
> move forward with it. Some bugs have been filed for it already [1], so
> please give them a look and provide feedback if you have any. There are
> still some open problems that are better discussed on this list, so I'm
> opening this thread to iron them out before we move this discussion to a
> broader audience.
>
> 1) It's more difficult for developers to get started, since it requires
> a special Firefox build to even work on a trivial add-on.
>
> This is something I think we can mitigate leveraging the developer
> tools. Just like app developers can easily install the Firefox OS
> Simulator to test their apps, we can make it easy for add-on developers
> to install and launch the special add-on tester Firefox build.

We're already doing something similar for the adb add-on and are
considering it for things like iOS / chrome debugging support. Firefox
34 also has some new devtools-specific extension apis that might help (
with more coming in 35 ). It should be very easy to create a new
devtools pane that is essentially a web app.

> 2) Require non-AMO developers to pay and sign an agreement in order to
> obtain self-signing certs.
>
> I think signing the agreement is necessary, but it needs to be focused
> on following our guidelines [2] and avoid being too US-centric (this is
> one of the reasons for not hosting add-ons on AMO after all). As for the
> payment, I think it should be low (say, $5) and we should also provide a
> free alternative, strictly limited to cases where payment isn't possible
> (due to location and/or economic status plus reasons for not using AMO).
> I think the required payment should be low in order to minimize the
> amount of exceptions we need to give. We might need to do a study of
> non-AMO add-on developers to determine where to draw this line.

Sounds reasonable.

> 3) Don't allow non-AMO web installs and only allow side-loading.
>
> This one I just disagree with. The evidence we have points to silent
> side-loading as the main culprit for add-on problems. Web installs
> provide some hurdles for installation, and if we need to discuss how to
> refine that install experience to make it safer, it should be a separate
> discussion.

I think I also disagree, for the same reason - a huge aspect of the
problem we tried to tackle with squeaky was side-loading from crapware
like Java. It's hurting us where it counts - search. The desktop PM team
has soem stats on how much I would ask them ( unsure if that data is
public ).

Jeff

Robert Kaiser

unread,
Aug 21, 2014, 12:17:42 PM8/21/14
to mozilla-addons-...@lists.mozilla.org
Jorge Villalobos schrieb:
> 1) It's more difficult for developers to get started, since it requires
> a special Firefox build to even work on a trivial add-on.
>
> This is something I think we can mitigate leveraging the developer
> tools. Just like app developers can easily install the Firefox OS
> Simulator to test their apps, we can make it easy for add-on developers
> to install and launch the special add-on tester Firefox build.

Can it be something that just puts an existing build into a special mode
that accepts this, triggered by devtools, and not a whole separate
build? It's a bad idea to test your add-on in a build that actually is
not the same as what the users will be running, after all.

KaiRo

Irving Reid

unread,
Aug 21, 2014, 12:34:34 PM8/21/14
to addons-user...@lists.mozilla.org
I would also strongly prefer to *not* use a special Firefox build, both
for user experience and to not create extra load on our build and
distribution people and infrastructure.

We're trading off how difficult it is for attackers to disable our
signature checking vs. how much work we (and our add-on developers) need
to do.

For Chrome, all you need to do is go to chrome://extensions and check
the "Developer mode" check box; presumably they make it a bit difficult
for attackers to flip that setting, but I haven't looked into what
they're doing.

I've suggested before, and will suggest again, that Mozilla publish an
"Add-on Developer" add-on that enables unsigned add-ons loaded from a
separate directory, possibly accompanied by some UI hints to show that
'developer mode' is on and/or unsigned add-ons are loaded.

This would also give us a convenient place to ship add-on development
tools without increasing the size of the default browser distribution.

- irving -

On 2014-08-21 12:17 PM, Robert Kaiser wrote:
> Jorge Villalobos schrieb:
>> 1) It's more difficult for developers to get started, since it requires
>> a special Firefox build to even work on a trivial add-on.
>>
>> This is something I think we can mitigate leveraging the developer
>> tools. Just like app developers can easily install the Firefox OS
>> Simulator to test their apps, we can make it easy for add-on developers
>> to install and launch the special add-on tester Firefox build.
>
> Can it be something that just puts an existing build into a special mode
> that accepts this, triggered by devtools, and not a whole separate
> build? It's a bad idea to test your add-on in a build that actually is
> not the same as what the users will be running, after all.
>
> KaiRo
> _______________________________________________
> addons-user-experience mailing list
> addons-user...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/addons-user-experience

Jorge Villalobos

unread,
Aug 21, 2014, 1:01:25 PM8/21/14
to addons-user...@lists.mozilla.org
On 8/21/14, 10:17 AM, Robert Kaiser wrote:
> Jorge Villalobos schrieb:
>> 1) It's more difficult for developers to get started, since it requires
>> a special Firefox build to even work on a trivial add-on.
>>
>> This is something I think we can mitigate leveraging the developer
>> tools. Just like app developers can easily install the Firefox OS
>> Simulator to test their apps, we can make it easy for add-on developers
>> to install and launch the special add-on tester Firefox build.
>
> Can it be something that just puts an existing build into a special
> mode that accepts this, triggered by devtools, and not a whole
> separate build? It's a bad idea to test your add-on in a build that
> actually is not the same as what the users will be running, after all.
>
> KaiRo
A suggestion I gave in a previous iteration of this proposal was to have
command-line switch that would run Firefox in "developer mode", and the
only visible difference would be a dialog at startup that users would
need to click through in order to activate that mode (the default in the
dialog would be to start in normal mode). That would be trading the
inconvenience of downloading and using a special build with the
inconvenience of having a dialog pop up on every restart when you're
working on your add-on.

In response to Irving's suggestions, we definitely need something better
than a pref of an extension, since those are trivially easy to modify or
inject by an installer.

Jorge

Jeff Griffiths

unread,
Aug 21, 2014, 1:14:22 PM8/21/14
to Jorge Villalobos, addons-user...@lists.mozilla.org


Jorge Villalobos wrote:
> On 8/21/14, 10:17 AM, Robert Kaiser wrote:
>> Jorge Villalobos schrieb:
>>> 1) It's more difficult for developers to get started, since it requires
>>> a special Firefox build to even work on a trivial add-on.
>>>
>>> This is something I think we can mitigate leveraging the developer
>>> tools. Just like app developers can easily install the Firefox OS
>>> Simulator to test their apps, we can make it easy for add-on developers
>>> to install and launch the special add-on tester Firefox build.
>> Can it be something that just puts an existing build into a special
>> mode that accepts this, triggered by devtools, and not a whole
>> separate build? It's a bad idea to test your add-on in a build that
>> actually is not the same as what the users will be running, after all.
>>
>> KaiRo
> A suggestion I gave in a previous iteration of this proposal was to have
> command-line switch that would run Firefox in "developer mode", and the
> only visible difference would be a dialog at startup that users would
> need to click through in order to activate that mode (the default in the
> dialog would be to start in normal mode). That would be trading the
> inconvenience of downloading and using a special build with the
> inconvenience of having a dialog pop up on every restart when you're
> working on your add-on.
>
> In response to Irving's suggestions, we definitely need something better
> than a pref of an extension, since those are trivially easy to modify or
> inject by an installer.

Command-line arguments are easy to modify as well ( in the Desktop
shortcut, for example ) so the question really is, what is less annoying
- that initial dialog on start or having a whole separate build?

Personally I prefer the former.

FWIW, the SDK team is changing the add-on manager to allow for a new
format of SDK-based extensions we call 'Native Jetpacks':

* just a directory or a zip file containing a package.json - no RDF etc.
* the extension can be loaded from a directory on-disk dynamically, and
the idea is to expose something like a 'reload' button in the add-on
manager, modelled after chrome.

I mention this because in this scenario the dialog prompt on start would
be far less annoying as there would typically be no need to restart the
browser during development. I use a similar workflow already using
Wladimir's 'extension auto-installer' extension and a shell script. It's
way better than the SDK's 'cfx run'.

( who this really sucks for are people developing using overlays,
they'll see the prompt a lot more )

Jeff

Irving Reid

unread,
Aug 21, 2014, 1:39:41 PM8/21/14
to addons-user...@lists.mozilla.org
On 2014-08-21 1:01 PM, Jorge Villalobos wrote:
> In response to Irving's suggestions, we definitely need something better
> than a pref of an extension, since those are trivially easy to modify or
> inject by an installer.

Well, the "Extension Developer" extension would have to be signed by a
valid extension-signing certificate, and we could do further pinning in
the browser to allow only a particular ID or signing key. Basically,
what we end up with is "There is a Mozilla-signed thing in your browser
profile that turns on add-on development". If an attacker drops our
Extension Developer add-on along with their attack, we're then relying
on UI to let the user know something is going on. As a first step, we
can refuse to install the ExtDev add-on if it is side-loaded.

We're getting well into diminishing returns here, because most of the
add-on management code is written in JS and can be monkeypatched by any
other add-on (signed, of course, or we wouldn't have loaded it).

- irving -

Gervase Markham

unread,
Aug 27, 2014, 9:04:20 AM8/27/14
to Jorge Villalobos
On 21/08/14 18:01, Jorge Villalobos wrote:
> In response to Irving's suggestions, we definitely need something better
> than a pref of an extension, since those are trivially easy to modify or
> inject by an installer.

They are, but surely any extension or installer which flips Firefox into
a "developer mode" so it can do stuff is clearly malware, and could be
treated as such by us and AV companies?

Gerv

Jeff Griffiths

unread,
Aug 27, 2014, 12:23:59 PM8/27/14
to Gervase Markham, mozilla-addons-...@lists.mozilla.org, Jorge Villalobos


Gervase Markham wrote:
> On 21/08/14 18:01, Jorge Villalobos wrote:
>> In response to Irving's suggestions, we definitely need something better
>> than a pref of an extension, since those are trivially easy to modify or
>> inject by an installer.
>
> They are, but surely any extension or installer which flips Firefox into
> a "developer mode" so it can do stuff is clearly malware, and could be
> treated as such by us and AV companies?

There are lots of extensions out there that are clearly malware, and
they're still out there causing problems despite what I can only assume
are the best efforts of the AV industry.

I think what I want is:

* no safeguards at all in nightly & aurora
* safeguards in beta and release
* some way to test anyway in beta and release, either the commend-line
flag or the special build. I prefer the former as long as:

1) it pops up a scary modal dialog on start
2) it requires what I think of as second-order hacking skills to get
around, eg the hackers would need to patch our binary.

$0.02, Jeff

Jorge Villalobos

unread,
Aug 27, 2014, 12:54:46 PM8/27/14
to Jeff Griffiths, Gervase Markham, mozilla-addons-...@lists.mozilla.org
On 8/27/14, 10:23 AM, Jeff Griffiths wrote:
>
>
> Gervase Markham wrote:
>> On 21/08/14 18:01, Jorge Villalobos wrote:
>>> In response to Irving's suggestions, we definitely need something
>>> better
>>> than a pref of an extension, since those are trivially easy to
>>> modify or
>>> inject by an installer.
>>
>> They are, but surely any extension or installer which flips Firefox into
>> a "developer mode" so it can do stuff is clearly malware, and could be
>> treated as such by us and AV companies?
>
> There are lots of extensions out there that are clearly malware, and
> they're still out there causing problems despite what I can only
> assume are the best efforts of the AV industry.
>
> I think what I want is:
>
> * no safeguards at all in nightly & aurora
> * safeguards in beta and release
> * some way to test anyway in beta and release, either the commend-line
> flag or the special build. I prefer the former as long as:
>
> 1) it pops up a scary modal dialog on start
> 2) it requires what I think of as second-order hacking skills to get
> around, eg the hackers would need to patch our binary.
>
> $0.02, Jeff

Yes, these installers are so prevalent that we should at least try to
address them in our design. We won't be able to create a bullet-proof
system, but these aren't edge cases we're talking about.

Jorge

Jeff Griffiths

unread,
Aug 27, 2014, 1:02:11 PM8/27/14
to Jorge Villalobos, mozilla-addons-...@lists.mozilla.org, Gervase Markham


Jorge Villalobos wrote:
> On 8/27/14, 10:23 AM, Jeff Griffiths wrote:
>>
>> Gervase Markham wrote:
>>> On 21/08/14 18:01, Jorge Villalobos wrote:
>>>> In response to Irving's suggestions, we definitely need something
>>>> better
>>>> than a pref of an extension, since those are trivially easy to
>>>> modify or
>>>> inject by an installer.
>>> They are, but surely any extension or installer which flips Firefox into
>>> a "developer mode" so it can do stuff is clearly malware, and could be
>>> treated as such by us and AV companies?
>> There are lots of extensions out there that are clearly malware, and
>> they're still out there causing problems despite what I can only
>> assume are the best efforts of the AV industry.
>>
>> I think what I want is:
>>
>> * no safeguards at all in nightly& aurora
>> * safeguards in beta and release
>> * some way to test anyway in beta and release, either the commend-line
>> flag or the special build. I prefer the former as long as:
>>
>> 1) it pops up a scary modal dialog on start
>> 2) it requires what I think of as second-order hacking skills to get
>> around, eg the hackers would need to patch our binary.
>>
>> $0.02, Jeff
>
> Yes, these installers are so prevalent that we should at least try to
> address them in our design. We won't be able to create a bullet-proof
> system, but these aren't edge cases we're talking about.

Bullet-proof doesn't exist, but I want the techniques required to be
beyond patching ini files.

Kris Maglione

unread,
Aug 27, 2014, 5:08:57 PM8/27/14
to Jeff Griffiths, mozilla-addons-...@lists.mozilla.org, Gervase Markham, Jorge Villalobos
On Wed, Aug 27, 2014 at 09:23:59AM -0700, Jeff Griffiths wrote:
>
>
>Gervase Markham wrote:
>>On 21/08/14 18:01, Jorge Villalobos wrote:
>>>In response to Irving's suggestions, we definitely need something better
>>>than a pref of an extension, since those are trivially easy to modify or
>>>inject by an installer.
>>
>>They are, but surely any extension or installer which flips Firefox into
>>a "developer mode" so it can do stuff is clearly malware, and could be
>>treated as such by us and AV companies?
>
>There are lots of extensions out there that are clearly malware, and
>they're still out there causing problems despite what I can only
>assume are the best efforts of the AV industry.
>
>I think what I want is:
>
>* no safeguards at all in nightly & aurora
>* safeguards in beta and release
>* some way to test anyway in beta and release, either the commend-line
>flag or the special build. I prefer the former as long as:
>
> 1) it pops up a scary modal dialog on start

I don't think that a modal dialog at startup is acceptable. It
will infuriate a lot of developers (including myself,
obviously), and seriously complicate automated testing.

I can think of a few alternate solutions:

1) Only allow developer mode for non-system profiles.

Advantages:

• Developers should be testing in development-specific
profiles in any case, so it shouldn't hurt their work flow.

Disadvantages:

• Can be circumvented by configuring by starting Firefox
with the -profile flag.

2) Use a modified UI rather than a modal dialog.

Advantages:

• Less cognitive and time burden at startup.

Disadvantages:

• Difficult to do in a way which can't be bypassed.
• May interfere with the functionality of some add-ons, thus
hurt testing efforts.
• May be too subtle to alert most users to a problem.

3) A separate developer build.

Advantages:

• Allows us to deploy a more hardened release build.
• Gives developers, ideally, a better testing experience
with a closer approximation of the behavior end users will
see.
• Could come bundled with the recommended set of developer
preferences and extensions.

Disadvantages:

• Downloading a separate build may be considered a hassle by
some developers.
• It may be tempting for some third-parties to replace the
stock Firefox with these builds. At the very least, we'd
need to distribute them with modified branding (Mozilla
Hackable has a nice dual meaning, depending on the
reader?)

As a side note, if we do this, I don't think these builds
should be available as an installer. They should be
tarballs/zip files/DMGs like we release for development
builds.

There may be other options, but in any case, I vastly prefer the
third.

--
Kris Maglione
Add-ons Technical Editor
Mozilla Corporation

Get and set methods are evil.
--Allen Holub

Robert Kaiser

unread,
Aug 28, 2014, 11:20:54 AM8/28/14
to mozilla-addons-...@lists.mozilla.org
Jeff Griffiths schrieb:
> There are lots of extensions out there that are clearly malware, and
> they're still out there causing problems despite what I can only assume
> are the best efforts of the AV industry.

And actually, there's a lot of malware out there that is not even
add-ons but binary software installed on the system and hooking DLLs
into our process - we need to keep in mind that all the work we do here
does nothing at all about those and actually might push more adware and
malware to go that route instead and circumvent whatever we do here in
any case.

KaiRo

Robert Kaiser

unread,
Aug 28, 2014, 11:23:52 AM8/28/14
to mozilla-addons-...@lists.mozilla.org
Kris Maglione schrieb:
> 3) A separate developer build.
> [...]
> Disadvantages:

* Not testing on the actual thing that users will see, which violates QA
standards.

Because of that, it's pretty much out by default for me.

KaiRo

quick...@gmail.com

unread,
Aug 28, 2014, 8:00:47 AM8/28/14
to mozilla-addons-...@lists.mozilla.org
Hi all,

I just binge-read most of the threads in the group, so it's possible I may be confusing a few details on what was just a suggestion at the time, and what's being currently considered to be implemented.

Most of my opinions and concerns have already been voiced by others, so I'll just skip those, because it seems those have all been taken into account already of what seems to be the "more accepted" proposal. As a developer, there are however a few things that I want to give voice to that I haven't seen mentioned yet.

1) I haven't seen any reference anywhere about test builds: alphas, betas, rc's and pretty much anything that, when uploaded, will appear in the development channel. I assume they would be signed as well, following the same process as normal releases, but that really should be made more obvious.

2) One common scenario that happens for me: user reports a bug, I can't reproduce the exact same bug but only something similar, or even not at all; I make some fixes; I reply to user "Try this test build and let me know if that works.".

Usually I upload that package as a test build to AMO (like in the above point) and link the user to it. But that is a commodity, AMO shouldn't be made so it's a necessity that we must rely on. For example, if this signing enforcement was already in place, development (bugfixing) of one of my add-ons would have essentially stopped, as AMO has been on the fritz for the last month and I haven't been able to reliably upload anything for weeks.

On the other hand, I (you/we) can't expect regular users to install any firefox developmental build in this situation just to test a dev package of an add-on. Not only is it an incredible hassle for them that they're not used to, it can be scary to see messages like "Be careful, as this build can be unstable and does not provide protection against unwanted apps." and the such. I don't see most normal users with the (conscious) confidence to do something like this.

In short, all of the "developer work and hassle" being discussed seems to be centered on the developer. But sometimes the end-user is a part of this work too. That also needs to be taken into account!

3) Another issue that's still not clear to me is the case of personal add-ons. I'm not sure of how enterprise policies work or would work, as this is not my case. My case is I do have a couple of personal add-ons that, because of their specificity, would be of no use to anyone else, so uploading them to AMO would be useless.

Would I still need to upload them to AMO in order to have them signed? I'm against this of course, personally I don't care if their code is public or not, but unless AMO has some kind of "make add-on hidden" feature that we can turn on, I don't think many people would want to make their code public. And even with that kind of hidden feature, others have already noted the "need for secrecy" that some enterprises would require, which even uploading their code anywhere would be going against.

Which brings me to, would this kind of add-on be considered non-AMO hosted, and would I have to pay the $5 (or whatever that ends up being)? That's also unacceptable, at least in my case, I'm not going to pay to use something that I have made myself. That's just a human basic principle, especially when it's not supposed to "meet mozilla's standards", but mine only (also a valid point for enterprises btw). We would be forced to give up the securities these policies are supposed to bring (by using a firefox developmental build) just to use our own little special add-ons, this is a very inconsiderate tradeoff you would be imposing. (Again, personally I don't care and could use the developmental build for personal use, as I know what to avoid on the web so I have close to zero problems with these malware issues, but I'm against the principle.)

4) As a more general concern, I honestly don't see this making a lot of progress against unwanted add-on installations, whether they're malware, greyware or however you want to classify them.

Nothing stops a blocked/banned user from using a proxy/going to a friends house/using a high techy-techy IP scrambler/whatever to create a new account, repack and reupload their add-on with new valid automatic certificates and start the "be bad/user report of badness/investigate/terminate" cycle all over again. This is also valid for non-AMO hosted add-ons, as someone (sorry, I can't find that post at the moment) said, there's money in this and a lot of it. Someone who's made a lucrative effort in coding a malicious add-on is probably not above pretending to be someone else and acquiring new certificates for five bucks (and produce a few more lucrative weeks before anyone notices again), regardless of the install process they choose.

Sure it would be more difficult to do it than it is now, but if it still allows money to be made with these activities, they aren't going to diminish by any significant amount. This would only bring an increased degree in maintenance, of the certificates and of AMO and its tools in general.

I don't mean to sound discouraging, it's just an honest opinion. And note that I'm not against the principle of signing either the add-on or the user himself. But in the end, I only see it as a sort of glorified whitelist, that would be as effective as the current blocklist system in place, with all these added "side-effects" and compromises on all sides that I don't think will bring enough benefit so that they would be justified.

But it's just my opinion, and of course if/when this is implemented, I look forward to being proven wrong. :)

Luís Miguel

Dave Townsend

unread,
Sep 3, 2014, 10:12:33 AM9/3/14
to Jorge Villalobos, Daniel Veditz, mozilla-addons-...@lists.mozilla.org, Wil Clouser
On Tue, Aug 19, 2014 at 1:49 PM, Jorge Villalobos <jo...@mozilla.com> wrote:

>
> If I'm missing anything, please bring it up.
>

One unanswered question is how Fennec fits into this. Do we intend for
these restrictions to take effect there? Sideloading is not something that
happens on mobile devices so the plan as-is would mean tying Fennec users
to a single add-ons marketplace, something that goes against our goals of
user choice.

Fennec also doesn't support object signing certificates at the moment, as I
understand it the bits have been re-used for open webapp signing so there
might be a large amount of work to solve that.

Andrew Williamson

unread,
Sep 3, 2014, 10:26:32 AM9/3/14
to Dave Townsend, Jorge Villalobos, Daniel Veditz, mozilla-addons-...@lists.mozilla.org, Wil Clouser
Since gecko 29 webapp signing is handled by specific code, it doesn't
re-use the add-on object signing anymore. (I can't say if the object
signing in Fennec has been fixed afterwards though.)

Andrew Williamson
App Review Technical Lead @ Marketplace.Firefox.com

Jorge Villalobos

unread,
Sep 3, 2014, 12:15:11 PM9/3/14
to Dave Townsend, Daniel Veditz, mozilla-addons-...@lists.mozilla.org, Wil Clouser
On 9/3/14, 8:12 AM, Dave Townsend wrote:
> On Tue, Aug 19, 2014 at 1:49 PM, Jorge Villalobos <jo...@mozilla.com
> <mailto:jo...@mozilla.com>> wrote:
>
>
> If I'm missing anything, please bring it up.
>
>
> One unanswered question is how Fennec fits into this. Do we intend for
> these restrictions to take effect there? Sideloading is not something
> that happens on mobile devices so the plan as-is would mean tying
> Fennec users to a single add-ons marketplace, something that goes
> against our goals of user choice.
>
> Fennec also doesn't support object signing certificates at the moment,
> as I understand it the bits have been re-used for open webapp signing
> so there might be a large amount of work to solve that.

Desktop Firefox is definitely our main target here (it has even been
suggested we could limit it to Windows), so I think that if Fennec isn't
ready to handle signatures then it should just ignore them until it can.
The impact will be null or minimal.

I'm very much opposed to closing the non-AMO web install method, and
limiting Fennec wouldn't be my biggest concern if we went that way.

Jorge

Jorge Villalobos

unread,
Sep 12, 2014, 7:32:46 PM9/12/14
to mozilla-addons-...@lists.mozilla.org
On 8/28/14, 6:00 AM, quick...@gmail.com wrote:
> Hi all,
>
> I just binge-read most of the threads in the group, so it's possible I may be confusing a few details on what was just a suggestion at the time, and what's being currently considered to be implemented.
>
> Most of my opinions and concerns have already been voiced by others, so I'll just skip those, because it seems those have all been taken into account already of what seems to be the "more accepted" proposal. As a developer, there are however a few things that I want to give voice to that I haven't seen mentioned yet.
>
> 1) I haven't seen any reference anywhere about test builds: alphas, betas, rc's and pretty much anything that, when uploaded, will appear in the development channel. I assume they would be signed as well, following the same process as normal releases, but that really should be made more obvious.

That's a good question, since it's an edge case that wasn't covered. If
we follow the same policy we apply on AMO now, you can only upload to
the developer channel if your add-on is already Fully Reviewed. Those
versions don't go through review, and they would also be automatically
signed. However, we need to further discuss this case since it can be
considered a vulnerability in the system.

> 2) One common scenario that happens for me: user reports a bug, I can't reproduce the exact same bug but only something similar, or even not at all; I make some fixes; I reply to user "Try this test build and let me know if that works.".
>
> Usually I upload that package as a test build to AMO (like in the above point) and link the user to it. But that is a commodity, AMO shouldn't be made so it's a necessity that we must rely on. For example, if this signing enforcement was already in place, development (bugfixing) of one of my add-ons would have essentially stopped, as AMO has been on the fritz for the last month and I haven't been able to reliably upload anything for weeks.
>
> On the other hand, I (you/we) can't expect regular users to install any firefox developmental build in this situation just to test a dev package of an add-on. Not only is it an incredible hassle for them that they're not used to, it can be scary to see messages like "Be careful, as this build can be unstable and does not provide protection against unwanted apps." and the such. I don't see most normal users with the (conscious) confidence to do something like this.
>
> In short, all of the "developer work and hassle" being discussed seems to be centered on the developer. But sometimes the end-user is a part of this work too. That also needs to be taken into account!

Just like in the non-AMO case, AMO developers will have the option to
request certificates to sign their add-ons. The idea is to charge for
this service, but we can probably do something like offer them for free
to developers of fully reviewed add-ons on AMO. The only other option
would be to ask users to use the testing version of Firefox, which can
be a hassle like you mention, but hopefully won't be terribly
inconvenient to do.


> 3) Another issue that's still not clear to me is the case of personal add-ons. I'm not sure of how enterprise policies work or would work, as this is not my case. My case is I do have a couple of personal add-ons that, because of their specificity, would be of no use to anyone else, so uploading them to AMO would be useless.
>
> Would I still need to upload them to AMO in order to have them signed? I'm against this of course, personally I don't care if their code is public or not, but unless AMO has some kind of "make add-on hidden" feature that we can turn on, I don't think many people would want to make their code public. And even with that kind of hidden feature, others have already noted the "need for secrecy" that some enterprises would require, which even uploading their code anywhere would be going against.
>
> Which brings me to, would this kind of add-on be considered non-AMO hosted, and would I have to pay the $5 (or whatever that ends up being)? That's also unacceptable, at least in my case, I'm not going to pay to use something that I have made myself. That's just a human basic principle, especially when it's not supposed to "meet mozilla's standards", but mine only (also a valid point for enterprises btw). We would be forced to give up the securities these policies are supposed to bring (by using a firefox developmental build) just to use our own little special add-ons, this is a very inconsiderate tradeoff you would be imposing. (Again, personally I don't care and could use the developmental build for personal use, as I know what to avoid on the web so I have close to zero problems with these malware issues, but I'm against the principle.)

Yeah, your options in that case would be to either get a (non-free in
most cases) self-signing cert, or use the developer build of Firefox.
For enterprises I don't expect it to be a problem to make a one-time
payment to sign private add-ons. For users with the technical skills to
make add-ons just for themselves, I think using the development build
should also be agreeable.

Also, as I've argued before, we need to make reasonable exceptions for
the self-signing certs since we don't want to kill a potential long tail
of non-AMO development.

> 4) As a more general concern, I honestly don't see this making a lot of progress against unwanted add-on installations, whether they're malware, greyware or however you want to classify them.
>
> Nothing stops a blocked/banned user from using a proxy/going to a friends house/using a high techy-techy IP scrambler/whatever to create a new account, repack and reupload their add-on with new valid automatic certificates and start the "be bad/user report of badness/investigate/terminate" cycle all over again. This is also valid for non-AMO hosted add-ons, as someone (sorry, I can't find that post at the moment) said, there's money in this and a lot of it. Someone who's made a lucrative effort in coding a malicious add-on is probably not above pretending to be someone else and acquiring new certificates for five bucks (and produce a few more lucrative weeks before anyone notices again), regardless of the install process they choose.

It's true that we can't create a completely effective solution for this,
but we don't need to. One of the important changes this brings in is a
level of accountability that we don't have now. There are many add-on
IDs in the wild that we have no idea what they are. There's plenty of
evidence of randomized add-on IDs (different ID per install), and
malware using add-on IDs of known add-ons. With this system we will at
least be able to track the origin of a malicious ID and deal with it and
all IDs created with that cert. This will also significantly increase
the difficulty of creating and distributing new add-on IDs, and allow
developers to really own their IDs to prevent abuse.

Also, in the cases of non-malicious non-AMO add-ons, we will be able to
find the developers more easily in case there are problems with their
add-ons, which is a problem we have to deal with regularly.

> Sure it would be more difficult to do it than it is now, but if it still allows money to be made with these activities, they aren't going to diminish by any significant amount. This would only bring an increased degree in maintenance, of the certificates and of AMO and its tools in general.

Yes, there's certainly an additional cost in maintenance, but I think
it's worth it because of the benefits I mention above.

> I don't mean to sound discouraging, it's just an honest opinion. And note that I'm not against the principle of signing either the add-on or the user himself. But in the end, I only see it as a sort of glorified whitelist, that would be as effective as the current blocklist system in place, with all these added "side-effects" and compromises on all sides that I don't think will bring enough benefit so that they would be justified.

The blocklist has served us well, but it's showing its age and needs
major improvements. To deal with the way add-on malware is created now,
we need something more sophisticated, which is why we're going with signing.


> But it's just my opinion, and of course if/when this is implemented, I look forward to being proven wrong. :)
>
> Lu�s Miguel
>

Thanks for the feedback!

Jorge

Luís Miguel

unread,
Nov 3, 2014, 11:14:50 AM11/3/14
to mozilla-addons-...@lists.mozilla.org
Here's another question I just thought of. Will non-signed add-ons ("illegal"?), that still (somehow?) ping AMO for updates be accounted in the statistics?

For instance, right now blocklisted versions of my add-on still show up in my statistics: https://addons.mozilla.org/firefox/addon/the-fox-only-better/statistics/usage/versions/?last=30. BTW, I'm linking to the "versions" statistics, but this is valid to every part of the statistics, including the "### users" that appears publicly with the add-on listing pretty much everywhere, these versions still seem to inflate those numbers.

There are a lot of those versions, which makes the (relevant) data very hard to read. I hope this is something you will take into consideration, when introducing the new signing system. As the developer in this specific situation, I would probably like to see this:
- (primary) not show blocklisted/non-signed versions of the add-on in the statistics by default;
- (secondary) create an "include blocklisted/non-signed versions" checkbox, or in alternative, create separate stats/graphs for these; it is still important to have this data at hand, but only for me - developer - or you - AMO -, not for the general public if I choose to make the statistics public.

Also, perhaps it's OOT, but do you think it would be worth it investing on this filtering/division for the current blocklist system, while the signing system isn't introduced? I can create (a) bug(s) for this if you think it's worth pursuing.

Jorge Villalobos

unread,
Nov 4, 2014, 6:28:36 PM11/4/14
to mozilla-addons-...@lists.mozilla.org
Unsigned versions that are installed (and should be disabled
automatically) will probably continue to send update pings. One thing we
could do to provide better stats is to send the signature status on the
update ping, so AMO can filter out all pings that come from unsigned
files. Adding a filter in the dashboard seems like overkill since most
developers wouldn't be interested in versions they didn't create.

Integrating it to the current blocklist would be messy, and we have to
focus our limited developer resources on the most critical stuff, so I
think that filing those bugs wouldn't be useful. We should definitely
pick this up again once we're start seeing this in Nightly builds.

Jorge

Luís Miguel

unread,
Nov 5, 2014, 6:21:21 AM11/5/14
to mozilla-addons-...@lists.mozilla.org
On Tuesday, November 4, 2014 11:28:36 PM UTC, Jorge Villalobos wrote:
> Unsigned versions that are installed (and should be disabled
> automatically) will probably continue to send update pings. One thing we
> could do to provide better stats is to send the signature status on the
> update ping, so AMO can filter out all pings that come from unsigned
> files. Adding a filter in the dashboard seems like overkill since most
> developers wouldn't be interested in versions they didn't create.

Perhaps it shouldn't be as direct as "filter all pings from unsigned files". For instance, I would still be interested in pings from my add-ons that are run in the firefox development build, as they could be either custom builds of mine (for debugging) or made by the users themselves that changed something (apply a personal taste maybe?) and continue to do so in every update.

Another situation would be the beta/alpha/dev builds case, which isn't very well defined yet. If for some reason it's decided that they won't be signed, then they will also only be usable in the firefox dev build.

Maybe "filter all pings from unsigned files that come from firefox builds blocking unsigned add-ons"? These are all just edge cases I'm sure, but I don't think it'll hurt to give them a thought or two. :)

tr...@adblockplus.org

unread,
Jan 15, 2015, 6:53:27 PM1/15/15
to mozilla-addons-...@lists.mozilla.org
Hello everyone,

On Tuesday, August 19, 2014 at 7:49:36 PM UTC+2, Jorge Villalobos wrote:
> 1) It's more difficult for developers to get started, since it requires
> a special Firefox build to even work on a trivial add-on.

>From https://docs.google.com/a/adblockplus.org/document/d/1KhpDteoHFmVRkzlrT8v0N3F-KrPxLoZFM3mWmEmOses/edit it seems that requiring a special build (nightly, aurora or debug) is the approach that was chosen in the end. Unfortunately, this is going to become a massive barrier to entry for the Firefox ecosystem. Also, like KaiRo above I am concerned about not testing the add-on in the build that the users will be running. Is that decision final? While a dialog on startup (one that cannot be dismissed for a few seconds, otherwise the malware will do it) might not be quite as secure, it's certainly a much better compromise between security and usability.

> 2) Require non-AMO developers to pay and sign an agreement in order to
> obtain self-signing certs.

Is that still the plan? The current documentation talks about requiring uploading add-ons to AMO for signing, even if they aren't published. Self-signing is only mentioned as an exception and I wonder how hard it will be to get this exception applied.

Point in question: we generate Adblock Plus development builds automatically, and ask our users to test these. For Chrome we solved the issue by uploading the development builds to Chrome Web Store automatically - CWS provides an upload API, is stable and new versions are published immediately. For AMO, sadly, none of this is true. We cannot go upload the builds manually every time, and the review overhead would kill this anyway with several builds created per day occasionally. So we would certainly prefer to keep self-signing our extensions (currently five of them, with one not being published on AMO).

regards
Wladimir

Jorge Villalobos

unread,
Jan 16, 2015, 12:47:47 PM1/16/15
to mozilla-addons-...@lists.mozilla.org
On 1/15/15 3:54 PM, tr...@adblockplus.org wrote:
> Hello everyone,
>
> On Tuesday, August 19, 2014 at 7:49:36 PM UTC+2, Jorge Villalobos wrote:
>> 1) It's more difficult for developers to get started, since it requires
>> a special Firefox build to even work on a trivial add-on.
>
>>From https://docs.google.com/a/adblockplus.org/document/d/1KhpDteoHFmVRkzlrT8v0N3F-KrPxLoZFM3mWmEmOses/edit it seems that requiring a special build (nightly, aurora or debug) is the approach that was chosen in the end. Unfortunately, this is going to become a massive barrier to entry for the Firefox ecosystem. Also, like KaiRo above I am concerned about not testing the add-on in the build that the users will be running. Is that decision final? While a dialog on startup (one that cannot be dismissed for a few seconds, otherwise the malware will do it) might not be quite as secure, it's certainly a much better compromise between security and usability.

Yes, the decision is final. You'll be able to install unsigned
extensions on Nightly, Developer Editor, and debug builds of Beta and
Release.

>> 2) Require non-AMO developers to pay and sign an agreement in order to
>> obtain self-signing certs.
>
> Is that still the plan? The current documentation talks about requiring uploading add-ons to AMO for signing, even if they aren't published. Self-signing is only mentioned as an exception and I wonder how hard it will be to get this exception applied.
>
> Point in question: we generate Adblock Plus development builds automatically, and ask our users to test these. For Chrome we solved the issue by uploading the development builds to Chrome Web Store automatically - CWS provides an upload API, is stable and new versions are published immediately. For AMO, sadly, none of this is true. We cannot go upload the builds manually every time, and the review overhead would kill this anyway with several builds created per day occasionally. So we would certainly prefer to keep self-signing our extensions (currently five of them, with one not being published on AMO).

We're still figuring out how we're going to handle the submissions to
AMO, since we don't want to create a bottleneck to developers but we
also want to make sure all add-ons are safe to us. I think we can find a
way to make your test builds practical to sign and distribute quickly,
but otherwise your tester will have to use one of the builds mentioned
above.

Jorge

Robert Kaiser

unread,
Jan 18, 2015, 9:13:55 AM1/18/15
to mozilla-addons-...@lists.mozilla.org
Jorge Villalobos schrieb:
> Yes, the decision is final. You'll be able to install unsigned
> extensions on Nightly, Developer Editor, and debug builds of Beta and
> Release.

Sounds like it's best to either not QA add-ons in a useful way any more or abandon developing them.

KaiRo

Philip Chee

unread,
Jan 19, 2015, 11:52:53 PM1/19/15
to mozilla-addons-...@lists.mozilla.org
On 17/01/2015 01:46, Jorge Villalobos wrote:

> Yes, the decision is final. You'll be able to install unsigned
> extensions on Nightly, Developer Editor, and debug builds of Beta
> and Release.

Is there a build time switch to turn this off? e.g. in mozconfig?

>>> 2) Require non-AMO developers to pay and sign an agreement in
>>> order to obtain self-signing certs.
>>
>> Is that still the plan? The current documentation talks about
>> requiring uploading add-ons to AMO for signing, even if they aren't
>> published. Self-signing is only mentioned as an exception and I
>> wonder how hard it will be to get this exception applied.
>>
>> Point in question: we generate Adblock Plus development builds
>> automatically, and ask our users to test these. For Chrome we
>> solved the issue by uploading the development builds to Chrome Web
>> Store automatically - CWS provides an upload API, is stable and new
>> versions are published immediately. For AMO, sadly, none of this is
>> true. We cannot go upload the builds manually every time, and the
>> review overhead would kill this anyway with several builds created
>> per day occasionally. So we would certainly prefer to keep
>> self-signing our extensions (currently five of them, with one not
>> being published on AMO).
>
> We're still figuring out how we're going to handle the submissions
> to AMO, since we don't want to create a bottleneck to developers but
> we also want to make sure all add-ons are safe to us. I think we can
> find a way to make your test builds practical to sign and distribute
> quickly, but otherwise your tester will have to use one of the builds
> mentioned above.

How about extension authors who have ideological reasons (or delusions
of conspiracies) for not having anything to do with AMO?

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

unread,
Jan 20, 2015, 12:23:46 PM1/20/15
to mozilla-addons-...@lists.mozilla.org
On 1/19/15 10:51 PM, Philip Chee wrote:
> On 17/01/2015 01:46, Jorge Villalobos wrote:
>
>> Yes, the decision is final. You'll be able to install unsigned
>> extensions on Nightly, Developer Editor, and debug builds of Beta
>> and Release.
>
> Is there a build time switch to turn this off? e.g. in mozconfig?

Yes, I believe that's the way this behavior will be toggled.


>>>> 2) Require non-AMO developers to pay and sign an agreement in
>>>> order to obtain self-signing certs.
>>>
>>> Is that still the plan? The current documentation talks about
>>> requiring uploading add-ons to AMO for signing, even if they aren't
>>> published. Self-signing is only mentioned as an exception and I
>>> wonder how hard it will be to get this exception applied.
>>>
>>> Point in question: we generate Adblock Plus development builds
>>> automatically, and ask our users to test these. For Chrome we
>>> solved the issue by uploading the development builds to Chrome Web
>>> Store automatically - CWS provides an upload API, is stable and new
>>> versions are published immediately. For AMO, sadly, none of this is
>>> true. We cannot go upload the builds manually every time, and the
>>> review overhead would kill this anyway with several builds created
>>> per day occasionally. So we would certainly prefer to keep
>>> self-signing our extensions (currently five of them, with one not
>>> being published on AMO).
>>
>> We're still figuring out how we're going to handle the submissions
>> to AMO, since we don't want to create a bottleneck to developers but
>> we also want to make sure all add-ons are safe to us. I think we can
>> find a way to make your test builds practical to sign and distribute
>> quickly, but otherwise your tester will have to use one of the builds
>> mentioned above.
>
> How about extension authors who have ideological reasons (or delusions
> of conspiracies) for not having anything to do with AMO?

They'll still be able to use their add-ons using any of the builds that
have signature enforcement off by default. There's no other way around
it, by design. We're trying to make the non-AMO dev experience as smooth
and hassle-free as possible, but I can understand if people in that
group are skeptical about it.

Jorge

tr...@adblockplus.org

unread,
Jan 20, 2015, 1:14:53 PM1/20/15
to mozilla-addons-...@lists.mozilla.org
On Friday, January 16, 2015 at 6:47:47 PM UTC+1, Jorge Villalobos wrote:
> I think we can find a
> way to make your test builds practical to sign and distribute quickly,
> but otherwise your tester will have to use one of the builds mentioned
> above.


I hope you can find a way, otherwise we won't have any testers. Our Chrome development builds used to have a much lower barrier to entry than installing a new build (you had to download & run a Windows registry file) and yet we lost almost all of our development build users.

Gervase Markham

unread,
Jan 21, 2015, 9:54:55 AM1/21/15
to Jorge Villalobos
On 20/01/15 17:22, Jorge Villalobos wrote:
> They'll still be able to use their add-ons using any of the builds that
> have signature enforcement off by default. There's no other way around
> it, by design. We're trying to make the non-AMO dev experience as smooth
> and hassle-free as possible, but I can understand if people in that
> group are skeptical about it.

Just to be clear about this: once this system is fully in place, if you
want your addon to work with standard release builds of Firefox, it has
to be hosted on AMO?

Gerv


Gijs Kruitbosch

unread,
Jan 21, 2015, 10:38:39 AM1/21/15
to mozilla-addons-...@lists.mozilla.org
AIUI, no, but it has to be signed by Mozilla, for which you can either
host it on AMO, or submit it to get a signed copy back if Mozilla are
happy with it (exact process for the latter TBD).

~ Gijs

Jorge Villalobos

unread,
Jan 21, 2015, 10:43:36 AM1/21/15
to mozilla-addons-...@lists.mozilla.org
As Gijs pointed out, the file will be submitted to AMO just for signing,
and it won't be hosted or distributed on AMO.

Jorge

Philip Chee

unread,
Jan 22, 2015, 4:21:46 AM1/22/15
to mozilla-addons-...@lists.mozilla.org
1. There are some hyperactive extension developers out there. For
example the author of the (new) download statusbar. In the beginning he
was pushing 2-5 updates per *day* to AMO. I think he's calmed down
recently but how would AMO handle this sort of situation?

2. Mozdev. Can we get/buy a self signing cert for all projects hosted on
mozdev or do each individual project have to jump through the hoops?

Gervase Markham

unread,
Jan 22, 2015, 5:11:44 AM1/22/15
to Jorge Villalobos
On 21/01/15 15:42, Jorge Villalobos wrote:
> As Gijs pointed out, the file will be submitted to AMO just for signing,
> and it won't be hosted or distributed on AMO.

And this signing will involve a code review as normal?

So there is no longer a possibility of having a private addon
distributed within, say, a company? Or can a company add a new signing
key to the keystore and sign their own addons?

Gerv

Jorge Villalobos

unread,
Jan 22, 2015, 12:42:29 PM1/22/15
to mozilla-addons-...@lists.mozilla.org
On 1/22/15 3:20 AM, Philip Chee wrote:
> On 21/01/2015 23:42, Jorge Villalobos wrote:
>> On 1/21/15 8:53 AM, Gervase Markham wrote:
>>> On 20/01/15 17:22, Jorge Villalobos wrote:
>>>> They'll still be able to use their add-ons using any of the builds that
>>>> have signature enforcement off by default. There's no other way around
>>>> it, by design. We're trying to make the non-AMO dev experience as smooth
>>>> and hassle-free as possible, but I can understand if people in that
>>>> group are skeptical about it.
>>>
>>> Just to be clear about this: once this system is fully in place, if you
>>> want your addon to work with standard release builds of Firefox, it has
>>> to be hosted on AMO?
>>>
>>> Gerv
>>
>> As Gijs pointed out, the file will be submitted to AMO just for signing,
>> and it won't be hosted or distributed on AMO.
>
> 1. There are some hyperactive extension developers out there. For
> example the author of the (new) download statusbar. In the beginning he
> was pushing 2-5 updates per *day* to AMO. I think he's calmed down
> recently but how would AMO handle this sort of situation?

Our only interest for non-AMO add-ons is that they don't have
exploitable security vulnerabilities, so they will be held to a slightly
lower standard than preliminary reviewed add-ons on AMO. This should
make their reviews easier and quicker, in theory.

I also think we'll need to be able to waive the review step to
developers who have proven to be consistently security-conscious and
need a quick response to signing.

The review side of this proposal is still a bit in flux.

> 2. Mozdev. Can we get/buy a self signing cert for all projects hosted on
> mozdev or do each individual project have to jump through the hoops?

Each individual developer has to go through this independently.

Jorge


Jorge Villalobos

unread,
Jan 22, 2015, 12:47:46 PM1/22/15
to mozilla-addons-...@lists.mozilla.org
On 1/22/15 4:10 AM, Gervase Markham wrote:
> On 21/01/15 15:42, Jorge Villalobos wrote:
>> As Gijs pointed out, the file will be submitted to AMO just for signing,
>> and it won't be hosted or distributed on AMO.
>
> And this signing will involve a code review as normal?

There will be a minimal security review, since that's all we should care
about for non-AMO add-ons (add-ons seeking to use side-loading will be
held to a higher standard, though). How that will look is still being
defined, but we definitely don't want to create a bottleneck for non-AMO
development.

> So there is no longer a possibility of having a private addon
> distributed within, say, a company? Or can a company add a new signing
> key to the keystore and sign their own addons?

There will be an alternative for these cases, but we want to keep them
to the absolute minimum. It should be restricted to cases where the
add-ons won't be available on the web, and there will probably be some
contract to sign. We will provide a way for developers to self-sign if
they meet the criteria.

Jorge

Philip Chee

unread,
Jan 22, 2015, 11:37:39 PM1/22/15
to mozilla-addons-...@lists.mozilla.org
On 23/01/2015 01:41, Jorge Villalobos wrote:

> Our only interest for non-AMO add-ons is that they don't have
> exploitable security vulnerabilities, so they will be held to a slightly
> lower standard than preliminary reviewed add-ons on AMO. This should
> make their reviews easier and quicker, in theory.
>
> I also think we'll need to be able to waive the review step to
> developers who have proven to be consistently security-conscious and
> need a quick response to signing.
>
> The review side of this proposal is still a bit in flux.

AFAIK there are only two paid staff doing reviews. I believe that there
is a lot of dark matter out there so I hope you have plans to increase
the number of people doing reviews at least in the first few months as
people rush to get their addons reviewed/signed/etc.

Kev Needham

unread,
Jan 23, 2015, 11:52:53 AM1/23/15
to addons-user...@lists.mozilla.org
This will, most likely, be a total non-starter with the Enterprise
community. Getting an organization to commit to a legal document just so
they can distribute our product in their org (especially given our
approach to orgs and institutions in the past) is really not going to fly.

Opinion only, but has this idea been floated on the Enterprise list?

kev

On 2015-01-22, 9:46 AM, Jorge Villalobos wrote:
> There will be an alternative for these cases, but we want to keep them
> to the absolute minimum. It should be restricted to cases where the
> add-ons won't be available on the web, and there will probably be some
> contract to sign. We will provide a way for developers to self-sign if
> they meet the criteria.
>
> Jorge

Jorge Villalobos

unread,
Jan 23, 2015, 11:59:28 AM1/23/15
to mozilla-addons-...@lists.mozilla.org
On 1/22/15 10:36 PM, Philip Chee wrote:
> On 23/01/2015 01:41, Jorge Villalobos wrote:
>
>> Our only interest for non-AMO add-ons is that they don't have
>> exploitable security vulnerabilities, so they will be held to a slightly
>> lower standard than preliminary reviewed add-ons on AMO. This should
>> make their reviews easier and quicker, in theory.
>>
>> I also think we'll need to be able to waive the review step to
>> developers who have proven to be consistently security-conscious and
>> need a quick response to signing.
>>
>> The review side of this proposal is still a bit in flux.
>
> AFAIK there are only two paid staff doing reviews. I believe that there
> is a lot of dark matter out there so I hope you have plans to increase
> the number of people doing reviews at least in the first few months as
> people rush to get their addons reviewed/signed/etc.
>
> Phil
>

Yes, the plan is to get more resources to cover for the increased load.

Jorge

Jorge Villalobos

unread,
Jan 23, 2015, 12:00:20 PM1/23/15
to mozilla-addons-...@lists.mozilla.org
We'll be making a larger announcement later this month, and I'll make
sure the Enterprise list is informed of this.

Jorge

JS

unread,
Jan 25, 2015, 3:21:37 PM1/25/15
to mozilla-addons-...@lists.mozilla.org
On 1/22/2015 12:46 PM, Jorge Villalobos wrote:> On 1/22/15 4:10 AM,
Private extensions are, by definition, extensions which should not
be shared with others or submitted to external parties for review.
Especially where they contain or reveal personal information and
activity, proprietary data and practices, internal security details,
and/or other sensitive information. Even the use of a private
extension is something that should not be disclosed to outside
parties. Especially when the disclosure is linked to personal
information. To some people, these may seem like overly strict
Need To Know requirements. However, they are legitimate and lawful hard
requirements for some applications. They are also the default,
safest, best practice for all cases. This usage pattern is one
of the most important patterns to support.

The only alternatives that would meet such requirements are those
that can be fully accomplished on the user side and would involve
no approval from, submissions to, etc an outside party (which
simply happens to be Mozilla in this case).

As a private extension developer I think I would want:

1) Extension signing enforcement as normal except for those
extensions I've developed and privately commanded the application
to accept. Config data stored external to the app and passed in
or pulled in would seem to be the best approach.

2) An official, proper release build of Release code that is
configured to provide this flexibility. There could be visual feedback,
but there should not be any startup prompts. I've
explicitly chosen to install this build on the systems I own and
control.

It sounds as though Nightly, Developer Edition, and debug builds
of Beta and Release would not meet such objectives.

Jorge Villalobos

unread,
Jan 26, 2015, 5:27:36 PM1/26/15
to mozilla-addons-...@lists.mozilla.org
On 1/25/15 2:20 PM, JS wrote:
> As a private extension developer I think I would want:
>
> 1) Extension signing enforcement as normal except for those
> extensions I've developed and privately commanded the application
> to accept. Config data stored external to the app and passed in
> or pulled in would seem to be the best approach.
>
> 2) An official, proper release build of Release code that is
> configured to provide this flexibility. There could be visual feedback,
> but there should not be any startup prompts. I've
> explicitly chosen to install this build on the systems I own and
> control.
>
> It sounds as though Nightly, Developer Edition, and debug builds
> of Beta and Release would not meet such objectives.

The prompt idea was abandoned in favor of the debug builds for Beta and
Release. So I think the current solution should meet your requirements,
unless there's something in the "official, proper" part that I'm missing.

Jorge

Gijs Kruitbosch

unread,
Jan 26, 2015, 8:14:49 PM1/26/15
to Jorge Villalobos
Jorge, have you ever run debug builds? They are really, really slow, and
produce lots of warning spew that is not particularly helpful for the
average add-on dev, I would argue.

I'm not convinced debug builds of release/beta would be an acceptable
way of running these add-ons, certainly not in a permanent kind of setup
as implied by the author (rather than just temporarily, to test whether
something works or whatever).

~ Gijs

JS

unread,
Jan 27, 2015, 6:24:58 AM1/27/15
to mozilla-addons-...@lists.mozilla.org
On 1/26/2015 5:26 PM, Jorge Villalobos wrote:
> The prompt idea was abandoned in favor of the debug builds for
> Beta and Release. So I think the current solution should meet your
> requirements, unless there's something in the "official, proper"
> part that I'm missing.

Of the alternate builds mentioned, the debug version of Release
sounds the closest. To confirm and clear up any confusion on my
part: it will have a) signature enforcement enabled by default,
b) no way to turn of signature enforcement for extensions in
general, and c) only the ability to whitelist specific extension
IDs via autoconfig?

Gijs mentioned two aspects of debug builds (reduced performance,
excessive debug messages) that can make them less suitable for
production use. Which is indeed what I am talking about. There are
other potential issues, but I'm not sure to what degree they would
apply in this context.

1) Packaging differences? Are the same types available? Are they
all signed properly?
2) Distribution differences? Is the "debug build" as available, easy
to find, and download as the release build?
3) Installation differences? Does the debug build install in the
same way as the release build? Are there any restrictions, or
defaults based on the assumption that it will only be used for
testing purposes?
4) Updating differences? Does the debug build check for and
download newer versions of itself (debug builds) or newer versions
of the release build?
5) Footprint differences, on disk and in memory?
6) Are remote debugging features enabled in the debug build?
7) Are there any other feature or configuration differences between
the debug build and release build (apart from the one we're talking
about)?


J. Ryan Stinnett

unread,
Jan 27, 2015, 11:07:23 AM1/27/15
to Gijs Kruitbosch, mozilla-addons-...@lists.mozilla.org, Jorge Villalobos
On Mon, Jan 26, 2015 at 7:14 PM, Gijs Kruitbosch
<gijskru...@gmail.com> wrote:
> On 26/01/2015 22:26, Jorge Villalobos wrote:
>>
> Jorge, have you ever run debug builds? They are really, really slow, and
> produce lots of warning spew that is not particularly helpful for the
> average add-on dev, I would argue.
>
> I'm not convinced debug builds of release/beta would be an acceptable way of
> running these add-ons, certainly not in a permanent kind of setup as implied
> by the author (rather than just temporarily, to test whether something works
> or whatever).

I agree with Gijs, debug builds are extremely painful to use,
especially if you attempt to use our DevTools to debug anything. You
might wait on the order of minutes (!!) for actions to complete.

Could we offer a modified build of Release and Beta that is identical
to a regular, optimized build, but simply has the signing check
disabled?

- Ryan

mco...@gmail.com

unread,
Jan 27, 2015, 11:35:26 AM1/27/15
to mozilla-addons-...@lists.mozilla.org
On Tuesday, 27 January 2015 11:07:23 UTC-5, J. Ryan Stinnett wrote:

> Could we offer a modified build of Release and Beta that is identical
> to a regular, optimized build, but simply has the signing check
> disabled?
>
> - Ryan

That was my understanding of the plan. In that model it'd be unbranded builds of Release/Beta with the build-time flag set to allow unsigned installations. All other functionality, including updates, would be identical. A true debug build would be painful.

-- Mike

JS

unread,
Jan 27, 2015, 1:51:14 PM1/27/15