Extension signing blog post

1630 views
Skip to first unread message

Jorge Villalobos

unread,
Feb 10, 2015, 12:42:41 PM2/10/15
to mozilla-addons-...@lists.mozilla.org
Hello,

I just published this blog post, explaining what we're doing with
extension signing:
http://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experience/.
Please read it carefully and let me know if you have any questions.

Expect increased activity on this list due to this announcement. I'll
try to keep up and respond to anything that comes up.

Regards,

Jorge

Mike Kaply

unread,
Feb 10, 2015, 1:00:08 PM2/10/15
to mozilla-addons-...@lists.mozilla.org
I see one pretty significant problem with this and that is that we will be completely unable to test our extensions on released versions of Firefox.

How can I deliver a version of my extension to my QA team that they can test on a released version of Firefox?

Signing it with every update doesn't make sense, since I am sending them multiple builds throughout my development process.

Mike

Mike Kaply

unread,
Feb 10, 2015, 1:09:10 PM2/10/15
to mozilla-addons-...@lists.mozilla.org
On Tuesday, February 10, 2015 at 11:42:41 AM UTC-6, Jorge Villalobos wrote:
Also, you never addressed the enterprise issue.

Expecting some company to give Mozilla the source code to an internal extension that they use for their company seems like a nonstarter.

Google does not require this. They have mechanisms to allow companies to install extensions that bypass the chrome store.

Mike Connor

unread,
Feb 10, 2015, 1:33:39 PM2/10/15
to Mike Kaply, mozilla-addons-...@lists.mozilla.org
>From the post:

> For extensions that will never be publicly distributed and will never
leave an internal network, there will be a third option. We’ll have more
details available on this in the near future.

On 10 February 2015 at 13:09, Mike Kaply <mi...@kaply.com> wrote:

> On Tuesday, February 10, 2015 at 11:42:41 AM UTC-6, Jorge Villalobos wrote:
> Also, you never addressed the enterprise issue.
>
> Expecting some company to give Mozilla the source code to an internal
> extension that they use for their company seems like a nonstarter.
>
> Google does not require this. They have mechanisms to allow companies to
> install extensions that bypass the chrome store.
>
> _______________________________________________
> addons-user-experience mailing list
> addons-user...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/addons-user-experience
>

Mike Kaply

unread,
Feb 10, 2015, 1:39:43 PM2/10/15
to mozilla-addons-...@lists.mozilla.org
On Tuesday, February 10, 2015 at 12:33:39 PM UTC-6, Mike Connor wrote:
> >From the post:
>
> > For extensions that will never be publicly distributed and will never
> leave an internal network, there will be a third option. We'll have more
> details available on this in the near future.

Sorry, I missed that, but still that's not good enough for me.

Why did you not just wait to announce this until you had that problem solved?

Are there even ideas on the table that can be discussed?

Mike

Mike Connor

unread,
Feb 10, 2015, 2:27:39 PM2/10/15
to Mike Kaply, mozilla-addons-...@lists.mozilla.org
It's pretty close, but still ironing out some details.

Keep in mind that it's only going to be available for a very limited set of
circumstances, and we didn't want to conflate discussion of that concept
with the overall changes to how add-ons will work for the vast majority of
add-ons and users.

-- Mike

On 10 February 2015 at 13:39, Mike Kaply <mi...@kaply.com> wrote:

> On Tuesday, February 10, 2015 at 12:33:39 PM UTC-6, Mike Connor wrote:
> > >From the post:
> >
> > > For extensions that will never be publicly distributed and will never
> > leave an internal network, there will be a third option. We'll have more
> > details available on this in the near future.
>
> Sorry, I missed that, but still that's not good enough for me.
>
> Why did you not just wait to announce this until you had that problem
> solved?
>
> Are there even ideas on the table that can be discussed?
>
> Mike

Mike Connor

unread,
Feb 10, 2015, 2:30:24 PM2/10/15
to Mike Kaply, mozilla-addons-...@lists.mozilla.org
Producing unbranded versions of the same source tag should be sufficient
for testing, no? If for every beta/release version there is a
corresponding unbranded version with this restriction eased, I would
consider that acceptable for QA purposes.

To be clear, the intent is that there will not be a way to configure a
release build to bypass this restriction, as that bypass would also be
usable by malicious installers.

On 10 February 2015 at 12:59, Mike Kaply <mi...@kaply.com> wrote:

> I see one pretty significant problem with this and that is that we will be
> completely unable to test our extensions on released versions of Firefox.
>
> How can I deliver a version of my extension to my QA team that they can
> test on a released version of Firefox?
>
> Signing it with every update doesn't make sense, since I am sending them
> multiple builds throughout my development process.
>
> Mike
>
>
>
> On Tuesday, February 10, 2015 at 11:42:41 AM UTC-6, Jorge Villalobos wrote:

Mike Kaply

unread,
Feb 10, 2015, 2:33:55 PM2/10/15
to mozilla-addons-...@lists.mozilla.org
On Tuesday, February 10, 2015 at 1:30:24 PM UTC-6, Mike Connor wrote:
> Producing unbranded versions of the same source tag should be sufficient
> for testing, no? If for every beta/release version there is a
> corresponding unbranded version with this restriction eased, I would
> consider that acceptable for QA purposes.

No, it's not. You're not testing with the exact same version of code that is released. It doesn't make sense that we should require our QA to use different than what our customers will be using. It should be exactly the same, down to every bit.

> To be clear, the intent is that there will not be a way to configure a
> release build to bypass this restriction, as that bypass would also be
> usable by malicious installers.

Then use a popup like Chrome does (that can't be bypassed). It would be much less annoying than this.

Mike

Mike Connor

unread,
Feb 10, 2015, 2:49:09 PM2/10/15
to Mike Kaply, mozilla-addons-...@lists.mozilla.org
On 10 February 2015 at 14:33, Mike Kaply <mi...@kaply.com> wrote:

> On Tuesday, February 10, 2015 at 1:30:24 PM UTC-6, Mike Connor wrote:
> > Producing unbranded versions of the same source tag should be sufficient
> > for testing, no? If for every beta/release version there is a
> > corresponding unbranded version with this restriction eased, I would
> > consider that acceptable for QA purposes.
>
> No, it's not. You're not testing with the exact same version of code that
> is released. It doesn't make sense that we should require our QA to use
> different than what our customers will be using. It should be exactly the
> same, down to every bit.


That's a choice you can make, of course, but I'd be deeply surprised if you
identify a single bug that occurs in one build but not the other. With the
number of versions and build configurations supported in the wild (not to
mention variability from OS/patch/driver differences, themes, other
add-ons, etc) this seems like a relatively extreme constraint. We had a
lot of discussions about this and we're confident that in practice it will
be a non-issue. We know not everyone will agree, that's okay.


> > To be clear, the intent is that there will not be a way to configure a
> > release build to bypass this restriction, as that bypass would also be
> > usable by malicious installers.
>
> Then use a popup like Chrome does (that can't be bypassed). It would be
> much less annoying than this.
>

These approaches have been tried, and have been found wanting. There's
also the reality that users don't read dialogs, so I'm not at all keen on
that as a "solution" for malware.

-- Mike

Mindaugas J.

unread,
Feb 10, 2015, 3:11:03 PM2/10/15
to mozilla-addons-...@lists.mozilla.org
1) API to submit builds automatically via build scripts?
2) Extension proxy file support? Which builds? FF stable/beta/aurora?

My main concerns are:
1) Live extension development from VCS working directories.
2) We have a few thousand beta testers most of whom will probably not be OK with using unstable FF builds every day. Furthermore, uploading incremental builds manually via browser to Chrome Web Store every time is inconvenient, to put it mildly.

Jorge Villalobos

unread,
Feb 10, 2015, 3:20:10 PM2/10/15
to mozilla-addons-...@lists.mozilla.org
On 2/10/15 1:20 PM, Mindaugas J. wrote:
> 1) API to submit builds automatically via build scripts?

We considered this. However, the process wouldn't be reliable since
add-ons can fail to pass the automated review and a manual step is then
necessary for that build to be signed. With that caveat, it might still
make sense, but it's not a priority.

> 2) Extension proxy file support? Which builds? FF stable/beta/aurora?

That would probably be the same as unsigned files, so nightly, aurora,
and special builds.

> My main concerns are:
> 1) Live extension development from VCS working directories.
> 2) We have a few thousand beta testers most of whom will probably not be OK with using unstable FF builds every day. Furthermore, uploading incremental builds manually via browser to Chrome Web Store every time is inconvenient, to put it mildly.

As explained in the blog post, there's the option of using unbranded
builds that are otherwise identical to release and beta builds. Would
that be sufficient for your testers?

Jorge

Mike Kaply

unread,
Feb 10, 2015, 3:30:04 PM2/10/15
to mozilla-addons-...@lists.mozilla.org
Will the signing method being implemented be ignored by earlier versions of Firefox?

That is to say, will an extension signed by AMO be installable in versions of Firefox like 38 (the ESR) that are before the new mechanism?

Mike

Jorge Villalobos

unread,
Feb 10, 2015, 3:34:14 PM2/10/15
to mozilla-addons-...@lists.mozilla.org
Yes, we're basically taking over the old signing mechanism and using it
for this, giving special meanings to our signatures.

Jorge

luck...@musites.com

unread,
Feb 10, 2015, 5:18:06 PM2/10/15
to mozilla-addons-...@lists.mozilla.org
On Tuesday, 10 February 2015 20:20:10 UTC, Jorge Villalobos wrote:
> On 2/10/15 1:20 PM, Mindaugas J. wrote:
> > 1) API to submit builds automatically via build scripts?
>
> We considered this. However, the process wouldn't be reliable since
> add-ons can fail to pass the automated review and a manual step is then
> necessary for that build to be signed. With that caveat, it might still
> make sense, but it's not a priority.

I would expect any API to be asynchronous anyway (code signing is not exactly a predictable or quick operation even if fully automated). I imagine sending an API signing request and getting back a "task identifier" which I can then submit to a 2nd API endpoint to query the status of the task. Bonus points if the AMO servers can ping a user-supplied URL when the status changes.

I periodically try to find ways to improve the localisation experience for people that donate their time to translating my addon and the next item on my (and no-doubt their) wish list is a way to automatically see the result of their translation work in a new XPI based on the appropriate code version (beta, stable, specific git commit, etc.) I parked the idea once I saw that add-on signing was going to become mandatory but I am certainly hoping for an API to be available for this kind of use-case soon.

Thanks,
Chris

Jonathan Kamens

unread,
Feb 10, 2015, 6:05:02 PM2/10/15
to mozilla-addons-...@lists.mozilla.org
Jorge Villalobos <jo...@mozilla.com> writes:
>As explained in the blog post, there's the option of using unbranded
>builds that are otherwise identical to release and beta builds. Would
>that be sufficient for your testers?

It's not fair to ask thousands of end users who have agreed
to be beta-testers for your add-on to use an unbranded,
non-standard browser just so that they can beta-test your
add-on.

Not to mention the fact that what it appears you're then
asking them to do is _compromise their browser's security_ as
part of being one of your beta-testers.

And then when you get five or six of the big add-on
developers doing this, you'll end up with tens of thousands
of users, if not more, running unbranded browsers that aren't
protected from unsigned add-ons.

I'm not sure what the answer here is, but I don't think "ask
beta-testers to use the unbranded browser" is it.

Dan Stillman

unread,
Feb 10, 2015, 6:05:30 PM2/10/15
to mozilla-addons-...@lists.mozilla.org
On 2/10/15 5:18 PM, luck...@musites.com wrote:
> On Tuesday, 10 February 2015 20:20:10 UTC, Jorge Villalobos wrote:
>> On 2/10/15 1:20 PM, Mindaugas J. wrote:
>>> 1) API to submit builds automatically via build scripts?
>> We considered this. However, the process wouldn't be reliable since
>> add-ons can fail to pass the automated review and a manual step is then
>> necessary for that build to be signed. With that caveat, it might still
>> make sense, but it's not a priority.
> I would expect any API to be asynchronous anyway (code signing is not exactly a predictable or quick operation even if fully automated). I imagine sending an API signing request and getting back a "task identifier" which I can then submit to a 2nd API endpoint to query the status of the task. Bonus points if the AMO servers can ping a user-supplied URL when the status changes.
>
> I periodically try to find ways to improve the localisation experience for people that donate their time to translating my addon and the next item on my (and no-doubt their) wish list is a way to automatically see the result of their translation work in a new XPI based on the appropriate code version (beta, stable, specific git commit, etc.) I parked the idea once I saw that add-on signing was going to become mandatory but I am certainly hoping for an API to be available for this kind of use-case soon.

Yeah, I want to echo the importance of an API for this. For Zotero we
produce dev builds for end users to try after we fix issues they report,
and those are built and pushed using a single command-line script.
(Release builds are the same, just without the automatic push.)
Introducing a manual in-browser step every time we build an XPI really
isn't acceptable.

As luckyrat says, there should be a simple API that gives back a token
that can be used in subsequent status requests (and the webpage could
even use the API itself). If the signing fails, so be it — we can log in
and investigate. But we should be able to get back signed XPIs from an
automated system without resorting to screen scraping. Otherwise this is
just going to penalize developers who are trying to produce stable,
well-tested extensions.

JS

unread,
Feb 11, 2015, 12:00:00 AM2/11/15
to mozilla-addons-...@lists.mozilla.org
On 2/10/2015 1:09 PM, Mike Kaply wrote:
> Also, you never addressed the enterprise issue.
> > Expecting some company to give Mozilla the source code
> to an internal extension that they use for their company seems
> like a nonstarter.

I'd suggest we try not to think of this as an "enterprise issue",
because it is a general one. It would affect large enterprises,
small companies, and individual users who wish to protect the
source code and information communicated by the extensions they
develop and use.

Mike Connor

unread,
Feb 11, 2015, 12:07:42 AM2/11/15
to Jonathan Kamens, mozilla-addons-...@lists.mozilla.org
The other alternative is, of course, to submit beta add-ons through AMO for
signing before sharing to your . That introduces some overhead, but it's
probably better to deal with that yourself. It'd be nice to have an API
model in place, but I don't consider a blocker.

There's no easy answer here that doesn't weaken the user security model or
introduce overhead for developers, which is unfortunate. We're trying to
minimize that pain for developers, but ultimately we have to do what's best
for users, even if it adds some overhead for developers.

On 10 February 2015 at 17:29, Jonathan Kamens <j...@kamens.us> wrote:

> Jorge Villalobos <jo...@mozilla.com> writes:
> >As explained in the blog post, there's the option of using unbranded
> >builds that are otherwise identical to release and beta builds. Would
> >that be sufficient for your testers?
>
> It's not fair to ask thousands of end users who have agreed
> to be beta-testers for your add-on to use an unbranded,
> non-standard browser just so that they can beta-test your
> add-on.
>
> Not to mention the fact that what it appears you're then
> asking them to do is _compromise their browser's security_ as
> part of being one of your beta-testers.
>
> And then when you get five or six of the big add-on
> developers doing this, you'll end up with tens of thousands
> of users, if not more, running unbranded browsers that aren't
> protected from unsigned add-ons.
>
> I'm not sure what the answer here is, but I don't think "ask
> beta-testers to use the unbranded browser" is it.

JS

unread,
Feb 11, 2015, 7:32:44 AM2/11/15
to mozilla-addons-...@lists.mozilla.org
On 2/10/2015 12:41 PM, Jorge Villalobos wrote:

> In the case of developers who want their extensions to be side
> loaded (installed via an application installer rather than using
> the usual Web install method) the review bar will be higher,
> equal to fully reviewed add-ons on AMO (with the exception of
> AMO content restrictions). This is a convenient installation
> avenue for software that comes bundled with an extension, for
> example an antivirus application that includes a Firefox
> extension that interacts with it.

In the case where an application installs a fully reviewed and
signed extension, will there be a prompt to inform the user
of the attempt and give them a way to allow or block the
installation?

> Extensions that meet the full review standard will have a
> smoother and friendlier install experience, regardless of
> where they’re hosted.

Will it be possible to completely block all web installs,
regardless of origin?



Mike Kaply

unread,
Feb 11, 2015, 10:59:57 AM2/11/15
to mozilla-addons-...@lists.mozilla.org
Was any thought given to focusing on the developer versus focusing on the add-ons?

Requiring developers to register with Mozilla to be able to develop add-ons and giving them a key that they could then use to sign add-ons.

Then if there is a bad actor, their key is revoked and none of their add-ons would work.

Then you could focus on weeding out the bad developers, not just bad add-ons.

Jorge Villalobos

unread,
Feb 11, 2015, 11:46:48 AM2/11/15
to mozilla-addons-...@lists.mozilla.org
On 2/11/15 6:33 AM, JS wrote:
> On 2/10/2015 12:41 PM, Jorge Villalobos wrote:
>
>> In the case of developers who want their extensions to be side
>> loaded (installed via an application installer rather than using
>> the usual Web install method) the review bar will be higher,
>> equal to fully reviewed add-ons on AMO (with the exception of
>> AMO content restrictions). This is a convenient installation
>> avenue for software that comes bundled with an extension, for
>> example an antivirus application that includes a Firefox
>> extension that interacts with it.
>
> In the case where an application installs a fully reviewed and
> signed extension, will there be a prompt to inform the user
> of the attempt and give them a way to allow or block the
> installation?

Users will always be prompted when installing add-ons and will have the
option not to install them.

>> Extensions that meet the full review standard will have a
>> smoother and friendlier install experience, regardless of
>> where they’re hosted.
>
> Will it be possible to completely block all web installs,
> regardless of origin?

I don't think so. There are ways to limit extension installation in
enterprise deployments. I'm not sure what those methods are, however. Is
there a specific use case you're thinking about?

Jorge

Jorge Villalobos

unread,
Feb 11, 2015, 11:48:38 AM2/11/15
to mozilla-addons-...@lists.mozilla.org
It was considered yes. But it also introduces various problems, like
lost or stolen keys, bad actors who pose as good ones for the sake of
getting a key, and developing a set of tools that is easy and robust
enough for all add-on developers to use.

Jorge

Mike Kaply

unread,
Feb 11, 2015, 4:19:18 PM2/11/15
to mozilla-addons-...@lists.mozilla.org
What if someone has two versions of an add-on with the same ID, one that's distributed off of AMO and one that is distributed via AMO.

Will the signing system be able to handle that?

Mike Connor

unread,
Feb 11, 2015, 5:12:25 PM2/11/15
to Mike Kaply, mozilla-addons-...@lists.mozilla.org
We talked about this separately, but ultimately I think the idea of AMO vs.
non-AMO forks is something we'd like to see go away, with all add-ons
having the same requirements and install experience instead of considering
AMO to be "special" in any way. Obviously there will continue to be some
content restrictions, mostly based around legal compliance, but aside from
that I expect us to level the playing field as much as possible.

Jorge Villalobos

unread,
Feb 11, 2015, 5:23:10 PM2/11/15
to mozilla-addons-...@lists.mozilla.org
On 2/11/15 3:19 PM, Mike Kaply wrote:
> What if someone has two versions of an add-on with the same ID, one that's distributed off of AMO and one that is distributed via AMO.
>
> Will the signing system be able to handle that?
>

If you're referring to the same developer having those two distribution
channels, then it is sort of possible. You can create Beta versions on
AMO that will be signed and won't be released to main branch users, but
will still be visible on the site. We haven't contemplated supporting
non-AMO versions on AMO listings, and it sounds like it would make
things fairly complicated.

What is the benefit of using the same ID vs just using a different one
for the different branches?

Jorge

Mike Kaply

unread,
Feb 11, 2015, 5:28:54 PM2/11/15
to mozilla-addons-...@lists.mozilla.org
On Wednesday, February 11, 2015 at 4:23:10 PM UTC-6, Jorge Villalobos wrote:
> What is the benefit of using the same ID vs just using a different one
> for the different branches?

Extensions are already out in the wild with different versions with the same ID.

For instance, the WEB.DE mailcheck has the AMO version, the version that is in the partner builds and the version that is shipped from the website.

Same ID, three different update paths, three subtly different user experiences.

Mike

Jorge Villalobos

unread,
Feb 11, 2015, 5:36:52 PM2/11/15
to mozilla-addons-...@lists.mozilla.org
It's not difficult to change the add-on ID during an update, though, for
the non-AMO cases. It should be simpler than trying to hack around this
some other way.

I'll bring up this case to see if we can support it, but it sound to me
like it would add too much complexity.

Jorge

ave...@loyaltycommerce.com

unread,
Feb 11, 2015, 5:40:11 PM2/11/15
to mozilla-addons-...@lists.mozilla.org
After the changes in the blog post happen, will users see an extension as signed by Mozilla, or will the extension show as signed by the entity who made it?

Jorge Villalobos

unread,
Feb 11, 2015, 5:43:33 PM2/11/15
to mozilla-addons-...@lists.mozilla.org
On 2/11/15 3:54 PM, ave...@loyaltycommerce.com wrote:
> After the changes in the blog post happen, will users see an extension as signed by Mozilla, or will the extension show as signed by the entity who made it?
>

Neither. The signature will come from Mozilla, but exposing that to the
user would be misleading, since we're not asserting ownership of the
add-on. The signature will just determine if the add-on can be installed
(and how it is installed).

Jorge

Daniel Veditz

unread,
Feb 11, 2015, 7:34:21 PM2/11/15
to mozilla-addons-...@lists.mozilla.org
On 2/10/15 10:09 AM, Mike Kaply wrote:
> Also, you never addressed the enterprise issue.
>
> Expecting some company to give Mozilla the source code to an internal
> extension that they use for their company seems like a nonstarter.

>From the blog:

"For extensions that will never be publicly distributed and will never
leave an internal network, there will be a third option. We’ll have more
details available on this in the near future."

-Dan Veditz

Daniel Veditz

unread,
Feb 11, 2015, 7:45:42 PM2/11/15
to mozilla-addons-...@lists.mozilla.org
On 2/10/15 11:33 AM, Mike Kaply wrote:
> Then use a popup like Chrome does (that can't be bypassed). It would
> be much less annoying than this.

For an add-on that requires a Firefox restart to install there's nothing
we can do that can't be bypassed. Chrome benefits from never having
allowed extensions to be as invasive/integrated as Mozilla's

-Dan Veditz

JS

unread,
Feb 11, 2015, 9:11:54 PM2/11/15
to mozilla-addons-...@lists.mozilla.org
Both questions were an attempt to determine if any useful
protection mechanisms would be eliminated on the basis that
Mozilla has reviewed an extension and signed it. A Mozilla
signed extension isn't by definition one that is safe for
all users and applications. Alerting the user, allowing
them to reject Mozilla signed extensions based on whatever
criteria they wish, etc are important features.

I forgot a question earlier, which I'd like to ask now.
Will the signature verification system, including whatever
revocation mechanism you intend to adopt, involve new or
additional pieces of information being sent to Mozilla or
other parties? Involve limitations on what background
communications can be blocked?

The last time I looked into the subject, I think I concluded
that it is possible to disable all background communications
with Mozilla servers (through numerous configuration changes
and/or firewalling of Mozilla servers). Doing so didn't
interfere with the installation of extensions from local XPI
files, or the use of those extensions. I think you could
even selectively enable the blocklist download and make use
of it without informing Mozilla of the extensions you are
using. Those options, while not appropriate for all users
to make use of, do give other users the ability to adjust
the behavior of Firefox to suit their various security
requirements. I'm wondering if the new design will create
any impediments or issues related to this.

Philip Chee

unread,
Feb 12, 2015, 8:48:08 AM2/12/15
to mozilla-addons-...@lists.mozilla.org
Real life example:

1. There is (or was) an abandoned/orphaned extension Gmail Manager. The
user community has been keeping this alive through trial and error and
googling devmo (many eyes, shallow bugs, etc) but none of them are
professional addon developers or anything developers.

Over the course of time several variants have been made. e.g. A user may
be using GM with patches A, C, and D. Another with patches A, D, and E, etc.

They all have the same GUID. Why? This is no problem because they will
never update from AMO, and in any case if the original author does come
back, everyone automatically updates to the latest official version.

Also what if you get different modified versions submitted from
different people?

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.

Mike Kaply

unread,
Feb 12, 2015, 10:19:04 AM2/12/15
to mozilla-addons-...@lists.mozilla.org
Will we still be able to have unpacked extensions in this model?

That is, will an extension marked <unpack> be unzipped?

If not, that's a problem, since the searchplugins directory is not supported in packed extensions.

Dave Townsend

unread,
Feb 12, 2015, 11:09:44 AM2/12/15
to Mike Kaply, mozilla-addons-...@lists.mozilla.org
Yes, unpacked extensions will still be supported.

a...@iinet.net.au

unread,
Feb 12, 2015, 11:55:50 AM2/12/15
to mozilla-addons-...@lists.mozilla.org
Here's a thought. How about a command line option such
as
firefox -unsigned '{yada-yada-yada}'
which tells firefox to allow just that particular add-on
to be installed without signing, from a .xpi file, as usual. Then I can run my own add-on for testing on the real browser locally until I am ready to release it to AMO.

SamuelJ...@mail.com

unread,
Feb 12, 2015, 11:55:50 AM2/12/15
to mozilla-addons-...@lists.mozilla.org
"Extensions that change the homepage and search settings without user consent have become very common, just like extensions that inject advertisements into Web pages or even inject malicious scripts into social media sites."

Extension signing would do NOTHING to prevent this. Your stated reason for not allowing an about:config setting to disable the "feature" is that "malicious add-ons and applications can easily manipulate those settings" ... that means malicious applications can easily manipulate the homepage and search settings, too! In other words, the first two use cases you listed are moot.

Also, unless you plan to also require signing of all userscripts for extensions like Greasemonkey, a malicious application could simply install the (signed) Greasemonkey extension and then enable their own malicious userscript, allowing them to inject advertisements into Web pages and malicious scripts into social media sites, your second two use cases.

None of your use cases have been addressed. This is BS.

I have non-public personal extensions that I want to continue using. I don't want to have to provide my code to Mozilla just so that I can continue using it.

a...@iinet.net.au

unread,
Feb 12, 2015, 11:55:50 AM2/12/15
to mozilla-addons-...@lists.mozilla.org
Recently I had a customer with a problem with my add-on. It would not run when installed from AMO. I was able to supply a .xpi file he could install and it worked. This showed up some differences in how add-ons are loaded for AMO vs non-AMO. Without being able to install from a .xpi I may never have found the cause of the problem.

I also always use an add-on in my own browser for some time before releasing a version for others to use. This new signing system seems to prevent this. It seems that I would have to be running a non-standard browser e.g. the "Developer Edition" for normal use in order to test my add-on. I don't have confidence that things will just work when it is installed in a standard browser.

emilian...@iris-advies.com

unread,
Feb 12, 2015, 11:55:51 AM2/12/15
to mozilla-addons-...@lists.mozilla.org
On Tuesday, February 10, 2015 at 9:20:10 PM UTC+1, Jorge Villalobos wrote:
> On 2/10/15 1:20 PM, Mindaugas J. wrote:
> > 1) API to submit builds automatically via build scripts?
>
> We considered this. However, the process wouldn't be reliable since
> add-ons can fail to pass the automated review and a manual step is then
> necessary for that build to be signed. With that caveat, it might still
> make sense, but it's not a priority.

This really bums me out. I have a fully automatic release setup. Having to manually upload the extension to AMO is a big throwback to me.

So what if it fails the automated review? As a registered dev, you have my email address, mail me. Why design the process for that which should be the exception, and burden the rule with that?

Michael Vario

unread,
Feb 12, 2015, 11:55:51 AM2/12/15
to mozilla-addons-...@lists.mozilla.org
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.

emilian...@iris-advies.com

unread,
Feb 12, 2015, 11:55:51 AM2/12/15
to mozilla-addons-...@lists.mozilla.org
On Wednesday, February 11, 2015 at 5:48:38 PM UTC+1, Jorge Villalobos wrote:
> On 2/11/15 9:59 AM, Mike Kaply wrote:
> > Was any thought given to focusing on the developer versus focusing on the add-ons?
> >
> > Requiring developers to register with Mozilla to be able to develop add-ons and giving them a key that they could then use to sign add-ons.
> >
> > Then if there is a bad actor, their key is revoked and none of their add-ons would work.
> >
> > Then you could focus on weeding out the bad developers, not just bad add-ons.
> >
>
> It was considered yes. But it also introduces various problems, like
> lost

request a new one

> or stolen keys,

Request a new one, invalidate the old one.

> bad actors who pose as good ones for the sake of
> getting a key,

revoke the current one.

> and developing a set of tools that is easy and robust
> enough for all add-on developers to use.

So offer two routes. Why should I suffer because some devs are not hip with the command line?

A downloadable and revokable key that would allow for offline signing sounds like a *much* better system to me.

SamuelJ...@mail.com

unread,
Feb 12, 2015, 11:55:51 AM2/12/15
to mozilla-addons-...@lists.mozilla.org

andrew....@gmail.com

unread,
Feb 12, 2015, 11:55:52 AM2/12/15
to mozilla-addons-...@lists.mozilla.org
This is going to really f#$! me up.

How about this for a fix:

Have a note on firefox.com saying something to the effect of:
"Add-ons are great. Be careful when you install from a non-Mozilla site. And if you install an add-on that does something you don't like, or if your Firefox/Thunderbird, etc. starts behaving in a bad way after installing an add-on, then uninstall that add-on."

I maintain a bunch of add-ons that are used by me. Alone. Just me. At work and at home. I maintain a few add-ons that are used by about 3 people at work, including me. And I can't just go an install different versions of Firefox willy-nilly at work. That's against the rules.

Now you're punish-the-masses-for-the-few-bad-apples approach is going to mess things up for the rest of us.

Frankly, it may be time to start writing IE add-ons. That is our _official_ browser at work.

Mike Connor

unread,
Feb 12, 2015, 2:56:23 PM2/12/15
to a...@iinet.net.au, mozilla-addons-...@lists.mozilla.org
So... add a trivially abused flag for third party installers to use to
bypass a security restriction?

Mike Connor

unread,
Feb 12, 2015, 3:01:50 PM2/12/15
to andrew....@gmail.com, mozilla-addons-...@lists.mozilla.org
On 11 February 2015 at 21:36, <andrew....@gmail.com> wrote:

> This is going to really f#$! me up.
>
> How about this for a fix:
>
> Have a note on firefox.com saying something to the effect of:
> "Add-ons are great. Be careful when you install from a non-Mozilla site.
> And if you install an add-on that does something you don't like, or if your
> Firefox/Thunderbird, etc. starts behaving in a bad way after installing an
> add-on, then uninstall that add-on."
>

The reality is that users don't read warnings like this, for the most
part. It also presumes that users will connect those dots after the fact,
which isn't really reflected in


> I maintain a bunch of add-ons that are used by me. Alone. Just me. At
> work and at home. I maintain a few add-ons that are used by about 3 people
> at work, including me. And I can't just go an install different versions
> of Firefox willy-nilly at work. That's against the rules.
>

But it's okay to run your own software in add-on form? That's an odd
restriction (a bad add-on can do just as much as a bad app).


> Now you're punish-the-masses-for-the-few-bad-apples approach is going to
> mess things up for the rest of us.
>

Based on the data we have, the number of users negatively impacted by
abusive add-ons vastly outweighs the number of people in your situation.
The needs of the many, etc.

-- Mike

Mike Connor

unread,
Feb 12, 2015, 3:07:28 PM2/12/15
to SamuelJ...@mail.com, mozilla-addons-...@lists.mozilla.org
On 12 February 2015 at 10:06, <SamuelJ...@mail.com> wrote:

> "Extensions that change the homepage and search settings without user
> consent have become very common, just like extensions that inject
> advertisements into Web pages or even inject malicious scripts into social
> media sites."
>
> Extension signing would do NOTHING to prevent this. Your stated reason for
> not allowing an about:config setting to disable the "feature" is that
> "malicious add-ons and applications can easily manipulate those settings"
> ... that means malicious applications can easily manipulate the homepage
> and search settings, too! In other words, the first two use cases you
> listed are moot.
>

Search settings moved out of preferences last year to combat this, but
add-ons can do anything the UI can do. Home page and new tab will move to
that model this year.


> Also, unless you plan to also require signing of all userscripts for
> extensions like Greasemonkey, a malicious application could simply install
> the (signed) Greasemonkey extension and then enable their own malicious
> userscript, allowing them to inject advertisements into Web pages and
> malicious scripts into social media sites, your second two use cases.
>
> None of your use cases have been addressed. This is BS.
>

If GM becomes a major avenue for abuse, we'll need to find a solution
there. No solution is airtight without crippling the capabilities of
add-ons, and that's hardly a better solution.


> I have non-public personal extensions that I want to continue using. I
> don't want to have to provide my code to Mozilla just so that I can
> continue using it.


Then you'll have the option of running different builds. There's no
one-size-fits-all.

Gijs Kruitbosch

unread,
Feb 12, 2015, 3:32:59 PM2/12/15
to mozilla-addons-...@lists.mozilla.org
Malware will start replacing all the user's desktop/start menu / windows
app shortcuts with such a commandline, including their own unsigned and
malicious add-on. They already do this with things like opening their
(hijacked) homepages and so on instead of the user's chosen homepage, so
there is no reason for them to stop there.

~ Gijs

Gijs Kruitbosch

unread,
Feb 12, 2015, 3:34:26 PM2/12/15
to mozilla-addons-...@lists.mozilla.org
On 12/02/2015 02:36, andrew....@gmail.com wrote:
> This is going to really f#$! me up.
>
> How about this for a fix:
>
> Have a note on firefox.com saying something to the effect of:
> "Add-ons are great. Be careful when you install from a non-Mozilla site. And if you install an add-on that does something you don't like, or if your Firefox/Thunderbird, etc. starts behaving in a bad way after installing an add-on, then uninstall that add-on."

The problem is usually not people purposefully installing an add-on that
turns out to be malicious. The problem is people running (other)
software on their machine that then "infects" Firefox with a malicious
add-on.

~ Gijs