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