Update on Signed Add-ons proposal

[Jorge Villalobos]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

We'll be making a larger announcement later this month, and I'll make
sure the Enterprise list is informed of this.

Jorge

[JS]

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]

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]

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]

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]

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]

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]

On 1/27/2015 11:33 AM, mco...@gmail.com wrote:

> 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.

What are the implications of "unbranded"?

[Mike Connor]

Unbranded == not using the Firefox name or logo.

On 27 January 2015 at 13:50, JS <js_losxc...@comcast.net> wrote:

> On 1/27/2015 11:33 AM, mco...@gmail.com wrote:
>

> 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.
>

> What are the implications of "unbranded"?
>
>
>

[Jorge Villalobos]

On 1/27/15 5:24 AM, JS wrote:
> 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?

Sorry about the confusing info, but there have been many versions of
this proposal, and the latest one hasn't been appropriately published. I
hope to have a blog post up in the Add-ons Blog soon that will explain
all of this.

Under the current plan, normal Beta and Release versions of Firefox will
not allow unsigned add-ons to be installed at all. There will be no
preferences or command line options to change this. Keep in mind that we
will have a transition period where we will only warn about unsigned
add-ons.

To install unsigned add-ons you'll have to either use Nightly, Developer
Edition, or special Beta and Release builds.

> 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.

We discussed using debug builds or using non-debug, unbranded builds
with only the signature checking change. The latter option is
preferable, for the reasons others have brought up in this thread. I
wasn't positive if it was practical from a Release Engineering
perspective, but from Mike's responses it looks like we still want to go
this way.

> 1) Packaging differences? Are the same types available? Are they
> all signed properly?

Packaging extensions will continue to be the same. You will submit the
XPI to us and we will return the signed version. If your extension used
the old signing method (so the install dialog wouldn't show the unknown
developer message), you'll need to stop doing that.

The type in install.rdf will remain the same, and only extensions
(type=2) are affected by this change.

> 2) Distribution differences? Is the "debug build" as available, easy
> to find, and download as the release build?

No, we don't want to make it *that* easy for people to install unsigned
add-ons. We will certainly point to them from places where developers
would look for such documentation, but we're not going to advertise
these builds.

> 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?

Since it would be unbranded (it wouldn't call itself Mozilla Firefox),
the install location would be different. Other than that and the
signature check being removed, it should be the same.

> 4) Updating differences? Does the debug build check for and
> download newer versions of itself (debug builds) or newer versions
> of the release build?

It should update to the correct version, yes. We'll need to verify this,
though.

> 5) Footprint differences, on disk and in memory?

Unless we go with the debug build solution, I don't think so.

> 6) Are remote debugging features enabled in the debug build?

I suppose so, but I'm not familiar enough with them. If we go with the
unbranded build, it should work like regular Firefox.

> 7) Are there any other feature or configuration differences between
> the debug build and release build (apart from the one we're talking
> about)?

Just the ones I mentioned already.

Jorge

[mco...@gmail.com]

On Sunday, 25 January 2015 15:21:37 UTC-5, JS wrote:
> This usage pattern is one
> of the most important patterns to support.

That's a rather strong assertion, do you have any information to support it? Based on all data we have, concretely addressing sideloading and unsafe add-ons will positively impact an order of magnitude more users than all of our ESR users combined.

> 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).

The solution would be to obtain a signing cert for each add-on. All other options would be easily subverted by malicious actors. That may not be ideal, but it's the solution we have for now.

> 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.

The main problem here is that any installer running as admin could write to this same config file, and thus bypass this security restriction for all builds. That's a non-starter if we're looking to reduce malicious side-loading.

> 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.

Our intent would be to not ship any officially branded builds with a security feature disabled or easily evaded.

-- Mike

[Michael Vario]

My concern, the same that I see others have, is the lack of any override. I use some old addons, and I occasionally use some pre-release addons from the developers. I don't want to not be able to do this.

I suppose I will be forced to use a developer version, but since I am on Linux (an Ubuntu derivative) and currently get Firefox via the repository I'll have to hope for a PPA of the developer build.

I do wish/request that some sort of override (even if a bit too difficult for casuals) would remain available for more advance users.

I am not a developer, just a user

I have never had an issue with malware in a addon.

I would be fine with a developer/testing addon that lets me continue to use Firefox as I have been doing.

Thank you.

[peter...@gmail.com]

Will we still be able to use Firefox extension proxy files for add-ons development?

https://developer.mozilla.org/en-US/Add-ons/Setting_up_extension_development_environment#Firefox_extension_proxy_file

[Dan Stillman]

On 6/5/16 10:20 PM, peter...@gmail.com wrote:
> Will we still be able to use Firefox extension proxy files for add-ons development?
>
> https://developer.mozilla.org/en-US/Add-ons/Setting_up_extension_development_environment#Firefox_extension_proxy_file

Signing doesn't really affect the local development process, except to
the extent that signature enforcement needs to be disabled. So you just
need a version of Firefox that allows unsigned builds, and then proxy
files work fine.

Unfortunately we don't yet have unbranded builds (with
xpinstall.signatures.required support) of Firefox 47, despite its being
released tomorrow, so at the moment you can only run unsigned code on
Firefox 46 or Dev Edition/Nightly. But that's a separate issue [1].


[1] https://mail.mozilla.org/pipermail/dev-addons/2016-May/000634.html
(There were follow-ups from me, Jorge and Kev, but for some reason those
aren't archived. I've asked for an update in that thread.)

[Russ]

Is signing going to be enforced in Firefox 48 or will it be postponed again? Pages like https://wiki.mozilla.org/Addons/Extension_Signing have scary language about mandatory signing, but this has kept getting delayed ever since I started tracking it last year.

[Jorge Villalobos]

On 6/30/16 1:33 PM, Russ wrote:
> Is signing going to be enforced in Firefox 48 or will it be postponed again? Pages like https://wiki.mozilla.org/Addons/Extension_Signing have scary language about mandatory signing, but this has kept getting delayed ever since I started tracking it last year.
>

All signs point to shipping on Firefox 48. There should be a blog post
about the unbranded builds coming up very soon.

Jorge

[a2jc...@gmail.com]

On Tuesday, August 19, 2014 at 1:49:36 PM UTC-4, 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.
>
> 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

For the record, I really, utterly, massively, completely, hugely -- did I say REALLY? -- hate this new "feature." As a user, I do not want or need my browser to be "Big Brother" to me. If I install an add-on, it's because I WANTED it, and I WANT to be able to run whatever the heck add-ons I choose to, on my own browser, on my own computer. I find it infuriating that the development team has decided I'm too stupid for my own good and removed even the OPTION of running an unsigned third-party extension. This just might be the beginning of the end of Firefox, since more and more, the software seems apparently designed to impose the designers' desires on the users rather than allowing users to determine our needs. I've been unhappy with a lot of the recent changes, but this far outstrips them all for ticking me off.

[Brian Nakamoto]

On Monday, July 4, 2016 at 3:25:34 AM UTC-7, a2jc...@gmail.com wrote:

> I find it infuriating that the development team has decided I'm too stupid for my own good and removed even the OPTION of running an unsigned third-party extension. This just might be the beginning of the end of Firefox, since more and more, the software seems apparently designed to impose the designers' desires on the users rather than allowing users to determine our needs.

Hi a2jc…

Providing a user option to run unsigned extensions exposes Firefox to exploits that can change the user option without user knowledge. One of the goals of signing extensions is to discourage extensions that would otherwise be accompanied by such exploits. The needs of the many outweigh the needs of the few. Savvy people who want to run unsigned extensions can use the unbranded version of Firefox. The broad majority and the Firefox platform itself should benefit from the direct and implicit regulatory powers that extension signing gives to AMO.

-Brian

[mous...@gmail.com]

On Tuesday, July 5, 2016 at 7:53:44 PM UTC-4, Brian Nakamoto wrote:
> On Monday, July 4, 2016 at 3:25:34 AM UTC-7, a2jc...@gmail.com wrote:
>

> > I find it infuriating that the development team has decided I'm too stupid for my own good and removed even the OPTION of running an unsigned third-party extension. This just might be the beginning of the end of Firefox...

>
> Hi a2jc…
>
> Providing a user option to run unsigned extensions exposes Firefox to exploits that can change the user option without user knowledge. One of the goals of signing extensions is to discourage extensions that would otherwise be accompanied by such exploits. The needs of the many outweigh the needs of the few.

I completely agree with a2jc. (As for "many" vs "few" - I've heard that kind of BS before. Don't tell me you counted all the FF users, asked them all what their needs are, then made your decision tabulating all the responses.)

You're making Firefox unusable in my environment, because some of the extensions we need to use internally are not signed (at least by FF-acceptable keys/certs) and are not going to be signed in an FF-approved way in the foreseeable future.

The correct and reasonable decision is to set the default strict, but allow the user to override it if/when the user needs it. Exactly the way it is now.

> Savvy people who want to run unsigned extensions can use the unbranded version of Firefox.

It is unclear what's the status and stability of the "unbranded version". It is also unclear where/how one can download it, or how it is updated. FOR SURE I don't want to run Nightly Build in my production environment (but yes I do want to run [some] unsigned extensions whose origins I validate myself by other means [not via Firefox signature check] - but my threat model is not your burden or your business).

> The broad majority and the Firefox platform itself should benefit from the direct and implicit regulatory powers that extension signing gives to AMO.

That simply means that as Firefox becomes more hard-nosed with certificate verification (it fails to verify our internal certs despite their issuing Root CA being installed in Authorities and given full Trust) and with extensions it cannot validate (and will [soon?] fail to accept no matter what the user says) - we will simply abandon this platform and move elsewhere.

[Brian Nakamoto]

> I completely agree with a2jc. (As for "many" vs "few" - I've heard that kind of BS before. Don't tell me you counted all the FF users, asked them all what their needs are, then made your decision tabulating all the responses.)

I do not work for Mozilla, but I assume they have some informative stats given all of the user telemetry collected by Firefox.

https://telemetry.mozilla.org

> The correct and reasonable decision is to set the default strict, but allow the user to override it if/when the user needs it. Exactly the way it is now.

I could agree—if there were a way to prevent abuse of the override by the bad actors AMO seeks to discourage.

> It is unclear what's the status and stability of the "unbranded version". It is also unclear where/how one can download it, or how it is updated.

AFAIK, the unbranded builds are not available yet.

https://blog.mozilla.org/addons/2016/06/01/add-ons-update-82/

> > The broad majority and the Firefox platform itself should benefit from the direct and implicit regulatory powers that extension signing gives to AMO.
>
> That simply means that as Firefox becomes more hard-nosed with certificate verification (it fails to verify our internal certs despite their issuing Root CA being installed in Authorities and given full Trust) and with extensions it cannot validate (and will [soon?] fail to accept no matter what the user says) - we will simply abandon this platform and move elsewhere.

I hope the forthcoming unbranded version of Firefox will meet your needs. :)

P.S. Here is AMO's blog post about the case for extension signing – https://blog.mozilla.org/addons/2015/04/15/the-case-for-extension-signing/

-Brian (who isn't associated with Mozilla)

[mous...@gmail.com]

On Monday, July 11, 2016 at 5:19:50 PM UTC-4, Brian Nakamoto wrote:
> > I completely agree with a2jc. (As for "many" vs "few" - I've heard that kind of BS before. Don't tell me you counted all the FF users, asked them all what their needs are, then made your decision tabulating all the responses.)
>
> I do not work for Mozilla, but I assume they have some informative stats given all of the user telemetry collected by Firefox.
>
> https://telemetry.mozilla.org

1. Did you bother to check that site yourself, and read what that telemetry is about?
2. Some installations (mine included) by policy do *not* send back any "telemetry". So naturally they would not be counted even if this bunch of developers really cared to learn users' opinion.

> > The correct and reasonable decision is to set the default strict, but allow the user to override it if/when the user needs it. Exactly the way it is now.
>
> I could agree—if there were a way to prevent abuse of the override by the bad actors AMO seeks to discourage.

It's a basic fundamental disagreement between giving grown people tools and letting them decide what and how to do with them (including things that could be risky/dangerous - after all that's life), and keeping them all in a nice asylum neatly wrapped in clean straightjackets to make sure they don't cause any harm to themselves or to others. Those elitist developers can take their product and use it themselves.

> > It is unclear what's the status and stability of the "unbranded version". It is also unclear where/how one can download it, or how it is updated.
>
> AFAIK, the unbranded builds are not available yet.

I know. I hope they aren't crazy enough to completely block extensions until unbranded are available, but frankly I don't care any more - see below.

> > > The broad majority and the Firefox platform itself should benefit from the direct and implicit regulatory powers that extension signing gives to AMO.
> >
> > That simply means that as Firefox becomes more hard-nosed with certificate verification (it fails to verify our internal certs despite their issuing Root CA being installed in Authorities and given full Trust) and with extensions it cannot validate (and will [soon?] fail to accept no matter what the user says) - we will simply abandon this platform and move elsewhere.
>
> I hope the forthcoming unbranded version of Firefox will meet your needs. :)

I do not know that, and I have my doubts, based on the current stable "branded" release. But I gave up on Mozilla - it crashed and burned, as far as I'm concerned.

Experience of today: attempting to get a DCS connection (DCS = Defense Collaboration Services). The latest Firefox: it messed around and ended up hanging rather than establishing a connection (not even an error message!). Google Chrome: took my certificates, took the server certificates, established connection, let me participate in an online meeting. Take a guess what browser I'm going to use.

Firefox used to be the best - now it's a screwed up tool maintained by misguided fanatics.

> P.S. Here is AMO's blog post about the case for extension signing – https://blog.mozilla.org/addons/2015/04/15/the-case-for-extension-signing/

Thanks. I've already found that blog via Google search. Extensions I'm using might be sign-able (or maybe not), but they certainly cannot be reviewed by Mozilla, and won't be in a whitelist. Not that Mozilla site would be accessible from where I need to run the stuff anyway.

To summarize: Firefox screwed up certificate processing, and is about to royally screw up extensions installation. I don't have time to waste on such a browser, especially when alternatives are better than competitive.

[opera...@gmail.com]

To prevent addon developer to install proxy addon on release version is really a bad idea.