Extension signing blog post

[Jorge Villalobos]

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]

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]

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]

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

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]

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]

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]

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]

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

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Yes, unpacked extensions will still be supported.

[a...@iinet.net.au]

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]

"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]

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]

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]

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]

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]

[andrew....@gmail.com]

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]

So... add a trivially abused flag for third party installers to use to
bypass a security restriction?

[Mike Connor]

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]

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]

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]

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

[Gijs Kruitbosch]

On 12/02/2015 15:03, 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.

The search settings are no longer just in about:config. A time will
likely soon come when that is true for the homepage setting as well.

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

Greasemonkey scripts are not chrome-privileged, and Greasemonkey doesn't
mess with your ability to uninstall. I expect we'll work with the
greasemonkey authors to further minimize vectors such as these.

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

If you're writing your own add-ons, you should probably already be using
Firefox Developer Edition, which won't have these restrictions (as
stated explicitly in the blogpost) and won't require your add-on to be
signed.

~ Gijs

[Mike Kaply]

But the reality is that all we're doing is engaging in a contest to see who can be more creative.

Malware/Adware developers have already figured out ways to mess with Chrome that just simply bypass add-ons completely, and they can use these same mechanisms for Firefox (and are).

So we're simply trading one problem for another.

[Mike Kaply]

On Thursday, February 12, 2015 at 2:37:44 PM UTC-6, Gijs Kruitbosch wrote:

> If you're writing your own add-ons, you should probably already be using
> Firefox Developer Edition, which won't have these restrictions (as
> stated explicitly in the blogpost) and won't require your add-on to be
> signed.
>

That might sound like a good idea, but in practice you could create add-ons that don't work in current versions of firefox (or the ESR). I've done that accidentally. You're developing for a browser in the future.

[Gijs Kruitbosch]

Whereas if you write it against the current version of Firefox, it might
break after the 1-6 weeks until the next update.

API compatibility is a separate problem, it's not really specifically
related to this plan. If you prefer, you could test the add-on against
the unbranded version of release to get back the same problem you're
having now.

For purely selfish reasons, I'd much rather technical users like add-on
devs use Firefox Developer Edition - it helps us weed out issues
earlier, and stops us having to do point releases because people don't
realize stuff breaks until it hits release.

~ Gijs

[p...@scm.tees.ac.uk]

On Tuesday, February 10, 2015 at 5:42:41 PM UTC, Jorge Villalobos wrote:
> 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.

This does concern me, for similar reasons to other posters (i.e., custom extensions that are not intended for wide distribution).

I do understand the UI/UX issues around end-users and people clicking through dialogs, so the general direction of the proposal is sane.

Would it really be so unsafe to have a command-line option that re-enables the installation of unsigned extensions?
Alternatively, would it be possible to install additional keys so that we can still keep the verification step, but sign with a local private key? This doesn't introduce a wider risk unless bad actors are able to persuade end-users to install such keys.

[Mike Kaply]

On Thursday, February 12, 2015 at 2:58:45 PM UTC-6, Gijs Kruitbosch wrote:
pdate.
>
> API compatibility is a separate problem, it's not really specifically
> related to this plan. If you prefer, you could test the add-on against
> the unbranded version of release to get back the same problem you're
> having now.
>
> For purely selfish reasons, I'd much rather technical users like add-on
> devs use Firefox Developer Edition - it helps us weed out issues
> earlier, and stops us having to do point releases because people don't
> realize stuff breaks until it hits release.

And this really shows what a pain this is.

At this point, I'm expected to have give six versions of "Firefox" installed.

Nightly for testing bugs
Developer Edition for development of add-on
Beta (unbranded) for testing
Beta (maybe)
Release (unbranded) for testing
Release (for my day to day use)

It's getting kind of silly.

[Jorge Villalobos]

If an add-on fails the automated review, the developer can request a
manual review. This involves a delay, of course, so we're aiming to
minimize these cases and also minimize how long the review takes.

Jorge

[Jorge Villalobos]

Disabling or tampering with the blocklist would generally be considered
malicious behavior, so it's likely that it will be part of the tests
that we will include for non-AMO add-ons. We don't have the list of
tests clearly defined now, but they are aimed to ensure that add-ons
aren't malicious or very unsafe to use.

There are cases like enterprise deployments were such tampering might
make sense, and for those cases we have a different method in the works
that we will announce in a followup.

Jorge

[Gijs Kruitbosch]

On 12/02/2015 18:44, p...@scm.tees.ac.uk wrote:
> This doesn't introduce a wider risk unless bad actors are able to persuade end-users to install such keys.

.... or modify the trust store directly... much easier than modifying the
binary executable blob.

~ Gijs

[Gijs Kruitbosch]

On 12/02/2015 21:04, Mike Kaply wrote:
> Nightly for testing bugs
> Developer Edition for development of add-on

If you're happy to run Nightly to test bugs, might as well develop there.

I suggested devedition because it's more stable than nightly - I meant
for devedition to be really the only thing people run; for developing as
well as day-to-day browsing.

If it's too unstable for that for your purposes, run beta as your daily
browser (and write add-ons against nightly). You don't need release, and
you only need one of nightly/devedition.

~ Gijs

[Jorge Villalobos]

On 2/12/15 7:46 AM, Philip Chee wrote:
> On 12/02/2015 06:35, Jorge Villalobos wrote:
>> On 2/11/15 4:28 PM, Mike Kaply wrote:
>>> 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
>>>
>>
>> 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
>
> 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.

But changing the GUID isn't a significant effort, so it makes sense to
do that just to keep the add-on working. Or use any of the browser
versions that will support unsigned extensions...

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

That's a tricky situation and that will need to be handled case by case.
I would expect that in most cases it will be clear who is the actual
owner of an ID, so they will be the ones who get it (this has happened
on AMO a couple of times). In other cases, we'll have to work out some
reasonable resolution.

Jorge

[Jorge Villalobos]

On 2/12/15 12:44 PM, p...@scm.tees.ac.uk wrote:
> On Tuesday, February 10, 2015 at 5:42:41 PM UTC, Jorge Villalobos wrote:
>> 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.
>
> This does concern me, for similar reasons to other posters (i.e., custom extensions that are not intended for wide distribution).
>
> I do understand the UI/UX issues around end-users and people clicking through dialogs, so the general direction of the proposal is sane.
>
> Would it really be so unsafe to have a command-line option that re-enables the installation of unsigned extensions?

Yes. Unfortunately it doesn't require much to override the Firefox
shortcut in order to add certain command-line options.

> Alternatively, would it be possible to install additional keys so that we can still keep the verification step, but sign with a local private key? This doesn't introduce a wider risk unless bad actors are able to persuade end-users to install such keys.

Since the additional keys (or their registry, at least) would be in the
Firefox profile, that would still be fairly easy to subvert.

Jorge

[Daniel Veditz]

On 2/11/15 6:12 PM, JS wrote:
> 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?

No.

> The last time I looked into the subject, I think I concluded that it
> is possible to disable all background communications with 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.

You will be able to install and run signed add-ons without any
connection to Mozilla. The revocation mechanism piggybacks on the
blocklist so you may not want to kill that. As you note downloading the
blocklist does not reveal to Mozilla which add-ons you have installed.
That aspect of user privacy was an important design consideration.

-Dan Veditz

[Daniel Veditz]

On 2/11/15 6:15 PM, a...@iinet.net.au wrote:
> 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.

What did the cause of the problem turn out to be? Did you diff the AMO
version against the one that worked? There are no differences in the
browser engine between installing a file from the web or installing it
from a local file.

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

If we can't deliver on that promise then this scheme will fail.

-Dan Veditz

[Anthony Shipman]

On Fri, 13 Feb 2015 08:34:17 am Daniel Veditz wrote:
> On 2/11/15 6:15 PM, a...@iinet.net.au wrote:

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

> What did the cause of the problem turn out to be? Did you diff the AMO
> version against the one that worked? There are no differences in the
> browser engine between installing a file from the web or installing it
> from a local file.
>

There was a syntax error in the add-on from two let declarations with the same
name. (I don't know if the V35 compatibility checks were supposed to find
this). When installed via AMO the add-on was dead in the water. When installed
from a .xpi file there was just an error message and the add-on continued to
run as the problematic function was not being used. So there was some
difference in the handling of exceptions depending on the installation path.

--
Anthony Shipman Mamas don't let your babies
a...@iinet.net.au grow up to be outsourced.

[Kris Maglione]

On Wed, Feb 11, 2015 at 06:15:16PM -0800, a...@iinet.net.au wrote:
>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.

There aren't any differences between how add-ons are loaded
whether downloaded from AMO or not. It is possible to change
compatibility metadata on AMO, which only takes effect when AMO
is used for update pings. But this happens regardless of whether
the add-on is installed from AMO or not. It only changes when
non-AMO XPIs use a different `updateURL`, in which case that
server becomes responsible for overriding metadata.

I've also occasionally seen add-on code behave differently when
it detects certain cookies, in an attempt to determine whether
it was installed from AMO. But any differences in behavior there
are purely the result of add-on code.

There are cases where AMO will not present the option of
installing an add-on, but Firefox will allow it when the add-on
is installed from a file, but that's a different matter.

In any case, nothing about the signing service will require that
add-ons only be installed from AMO. You'll still be able to
distribute them as you see fit.

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

You will be able to sign your add-on for you own use prior to
releasing it, and there will be builds which allow signing to be
disabled which differ from release builds in no way other than a
changed name.

--
Kris Maglione
Add-ons Technical Editor
Mozilla Corporation

If the code and the comments disagree, then both are probably wrong.
--attributed to Norm Schryer

[Anthony Shipman]

On Fri, 13 Feb 2015 06:56:16 am Mike Connor wrote:
> So... add a trivially abused flag for third party installers to use to
> bypass a security restriction?
>

The user would have to run the program manually to set the command line flag.
Most would not be able to do this. Can a third party installer on Windows
change the command line flags for firefox?

[Anthony Shipman]

On Fri, 13 Feb 2015 08:46:58 am Kris Maglione wrote:
> You will be able to sign your add-on for you own use prior to
> releasing it, and there will be builds which allow signing to be
> disabled which differ from release builds in no way other than a
> changed name.
>

If the signing check flag can depend on the name or path of the executable
how does that differ from depending on a command line flag or environment
variable?

[Gijs Kruitbosch]

This is off-topic, but can you email me personally with more details
about this? I'm curious about what you mean.

> So we're simply trading one problem for another.

Nobody is denying there are trade-offs. Security always has them.

If I leave 1000 euro in a vault with a 10,000 euro cost to break open,
it's not worth breaking open the vault (and hopefully, it was
cost-effective to build said vault).

Right now, the break-in cost of the Firefox add-on security model is
effectively very close to 0 if you're a local actor.

This plan will drive up that cost. If that deters enough people without
too much cost to legitimate devs and users, that's a win. It doesn't
need to be perfect (security never is, unless you sacrifice *everything*).

I get that people are upset that there is a non-zero cost for legitimate
devs. But that's a necessary part of the trade-off. Having read the
entire thread, I've not heard any reasonable alternatives that, as
mconnor said, adequately balance the need of the many with those few who
are inconvenienced by these changes. Most people want a "simple opt-out"
which would defeat the point of the break-in-cost-increase we're trying
to achieve.

~ Gijs

[Anthony Shipman]

On Fri, 13 Feb 2015 08:46:58 am Kris Maglione wrote:

> In any case, nothing about the signing service will require that
> add-ons only be installed from AMO. You'll still be able to
> distribute them as you see fit.
>

I hope I won't find myself saying to a customer:
"I've found the bug and fixed it. But mozilla policy prevents
me from providing you with the fix. It has to go via the AMO site for a
security review. This may take 5, 10, 15 or even 20 days. If it should
happen that this change doesn't fix your problem then we will have to
start again."

That could take some months.

[Dan Stillman]

Emiliano isn't asking what happens. He's saying that occasional failures
from the automated test � the reason you gave above for there not being
an API for this � is no reason not to optimize for the standard case of
developers wanting to continue using automated build/release tools.
Given Mozilla's own reliance on automated dev builds, it's hypocritical
to take away this ability from add-on developers for some indeterminate
period of time while an API is maybe considered. This should be a
fundamental design requirement of the system � and if the website is
simply designed around the same API, it hardly even needs to delay the
release. Saying "it's not a priority" seems pretty disrespectful of
developers' time.

(That said, I don't really understand how automated testing is supposed
to protect against the things this is supposed to protect against in a
dynamic language like JavaScript. Can't a malware author that wants to,
say, modify the search pref simply obfuscate that code to avoid
automated detection? While I had serious concerns with it, the proposal
made more sense to me as an actual deterrent to malware when add-ons
were going to be initially manually reviewed with possible whitelisting.
The current proposal seems more effective at enforcing the sort of
security checks that AMO does (which, as has been mentioned, are often
false positives that are waived after explanations) than preventing
determined bad actors.)

[Kris Maglione]

On Fri, Feb 13, 2015 at 08:51:20AM +1100, Anthony Shipman wrote:
>On Fri, 13 Feb 2015 08:46:58 am Kris Maglione wrote:

>> You will be able to sign your add-on for you own use prior to
>> releasing it, and there will be builds which allow signing to be
>> disabled which differ from release builds in no way other than a
>> changed name.
>
>If the signing check flag can depend on the name or path of the
>executable how does that differ from depending on a command
>line flag or environment variable?

Sorry, to be clear: They will differ in no way aside from the
branding (name, images), and the ability to disable mandatory
add-on signing. The latter will only affect the add-on
installation process, though, and should in no way change the
runtime experience such that it will affect your ability to test
an add-on.

--
Kris Maglione
Add-ons Technical Editor
Mozilla Corporation

Religion began when the first scoundrel met the first fool.
--Voltaire

[Kris Maglione]

On Fri, Feb 13, 2015 at 08:49:22AM +1100, Anthony Shipman wrote:
>On Fri, 13 Feb 2015 06:56:16 am Mike Connor wrote:
>> So... add a trivially abused flag for third party installers to use to
>> bypass a security restriction?
>>
>
>The user would have to run the program manually to set the command line flag.
>Most would not be able to do this. Can a third party installer on Windows
>change the command line flags for firefox?

Yes, not only can they, but we've come across several installers
that do.

--
Kris Maglione
Add-ons Technical Editor
Mozilla Corporation

Once plants and animals were raised together on the same farm -- which
therefore neither produced unmanageable surpluses of manure, to be
wasted and to pollute the water supply, nor depended on such
quantities of commercial fertilizer. The genius of American farm
experts is very well demonstrated here: they can take a solution and
divide it neatly into two problems.
--Wendell Berry

[Mike Connor]

Aside from "yes" to your question (see Kris' reply), I'm not sure why you
believe a user would have to manually invoke this flag. It's absolutely
possible to call any executable with a command line flag or flags using
normal OS calls.

On 12 February 2015 at 16:49, Anthony Shipman <a...@iinet.net.au> wrote:

> On Fri, 13 Feb 2015 06:56:16 am Mike Connor wrote:
> > So... add a trivially abused flag for third party installers to use to
> > bypass a security restriction?
> >
>
> The user would have to run the program manually to set the command line
> flag.
> Most would not be able to do this. Can a third party installer on Windows
> change the command line flags for firefox?
>

[Gunther]

12 Şubat 2015 Perşembe 23:12:03 UTC+2 tarihinde Gijs Kruitbosch yazdı:

The config option to turn signing off can be in a privileged file that can only be changed with admin privileges. This would deter most simple malware Mozilla is concerned about and let users to turn it off.

-G

[Mike Connor]

Key revocation has two major flaws:

* We'd have to know the key was lost or compromised. There's been cases
where major vendors with full time security teams have unknowingly had
their code signing keys compromised for extended periods of time. There
are probably undiscovered examples as well.

* We have to assume that anyone using a compromised key to bypass installs
is going to actively subvert any revocation mechanism within the browser.

And, ultimately, independent discovery of bad actors is hard and scales
relatively poorly, and worse if we don't even know what's out there. We
have that problem now, and self-signing preserves the status quo in terms
of user protection. I think the evidence is clear in terms of that not
working.

-- Mike

On 11 February 2015 at 19:27, <emilian...@iris-advies.com> wrote:

> 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.
> _______________________________________________
> addons-user-experience mailing list
> addons-user...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/addons-user-experience
>

[Mike Connor]

As stated a number of times, most malware/greyware is deployed via an
installer running with admin access.

On 12 February 2015 at 17:10, Gunther <termina...@gmail.com> wrote:

> 12 Şubat 2015 Perşembe 23:12:03 UTC+2 tarihinde Gijs Kruitbosch yazdı:

> The config option to turn signing off can be in a privileged file that can
> only be changed with admin privileges. This would deter most simple malware
> Mozilla is concerned about and let users to turn it off.
>
> -G

[Gijs Kruitbosch]

On 12/02/2015 22:10, Gunther wrote:
> The config option to turn signing off can be in a privileged file that can only be changed with admin privileges. This would deter most simple malware Mozilla is concerned about and let users to turn it off.
>
> -G

You're assuming most users (and/or the malware we're concerned with) run
without admin privileges. This is not true, especially not on Windows
home installs.

~ Gijs

[Gunther]

If the user is unknowingly installing malware and giving admin privileges to an untrusted executable, it is "game over" for him like Jorge said as a reply in blog post.

You can't secure Firefox on a compromised system, malware have unlimited options to tamper with user experience once it got admin including changing system wide proxy and injecting ads or tampering Firefox binary.

IMHO it would be best to have a grace period testing forced signing and user having the ability to turn it off. "Serious" type of malware possibly changing privileged files is a speculation at this point.

Forced signing and privileged config will deter web based tricks and most of the light malware executables so I think this is a reasonable compromise between security and open nature.

-G

[Lemon Juice]

As I read the responses here I think the biggest problem with the
current add-on sighing plans is that developers will be inconvenienced
too much. There were already developers writing here how important it is
for them to send test builds of their extensions to their users for
testing, one of them even said they lost almost all of their Chrome
testers after Google enforced a similar mechanism. I think these are
very serious problems because this will hinder add-on development
process and as a result the whole Mozilla ecosystem will suffer.

There needs to be a way to run unsigned add-ons in a regular release.
There are a couple of options:

1. Use a secure vault provided by an OS to store permissions for running
each unsigned add-on. These systems are already used by some
applications for storing passwords in an encrypted form, for example:

- Netbeans FTP passwords: http://wiki.netbeans.org/FaqMasterPasswordDialog
- SVN passwords:
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.netmodel.html#svn.serverconfig.netmodel.credcache

Firefox could use the OS secure store to save the permission to run a
particular extension. In other words, unsigned extensions are always
disabled by default. The only way to run then would be to open Fx
Add-ons Manager and choose to run an unsigned extension - Fx would then
save the permission flag (probably in a form of a hash of the add-on ID
and/or XPI digest) into the OS vault. On Windows this would be by means
of logon authentication and the permissions would be non-transferable
across systems or OS accounts and would be lost on OS password change -
that would be fine.

It's possible this could be circumvented by a malicious application but
would be much more difficult than without any protections now. This
would not be 100% undefeatable but I don't think it has to be - if
malicious installers find it too hard to circumvent Mozilla signing
requirement then if they are determined they will simply move to other
points of attack. An installer runs with administrative rights and it
can manipulate applications in all kinds of ways and change Firefox
behaviour without having to side-load add-ons. This can't be remedied
and no air-tight signing mechanism will prevent it.

Other solutions:

2. Require a master password and use it to allow running unsigned
add-ons. A user would have to enter the master password when choosing to
run an unsigned extension in the add-ons manager and then the permission
to run would be saved in an encrypted form (the master password being
the encryption key, of course). On every new Firefox starup the user
would have to provide the master password to run the unsigned
extensions. The extensions could even be encrypted with the master
password! No installer would be able to bypass the mechanism without a
clear user consent and requiring to enter the master password. This
would make it relatively pain free for regular users to test extensions
sent to them outside any official channels. The master password could be
combined with the current master password in Fx so as not to require two
separate passwords for different things.

3. Extension of the previous idea: apart from master password allow
using a secure key that could be loaded by Fx from a USB drive, network
drive, etc. allowing to skip the need for entering the password.
However, this could be too easy to set up the system drive for the key -
that would need to be further discussed.

4. Provide an option (on installation) to get the unbranded build to
install with a name similar to the official Firefox, preferably having
the word "Firefox" as part of the name and a similar icon. Then
people/companies really needing full freedom could switch to these
builds without introducing uncertainty among the users as to what
browser this really is. The about: page could describe how the build
differs from the regular Firefox.

I think the current proposal is too restrictive and will make Firefox a
walled garden. The price for that is very high and it's both problematic
for users and for developers. Remember that malicious software will
always find a way to mess up with installed browsers and you can't
prevent that with a strictest add-on signing mechanism. Therefore, it
doesn't make sense to make it too strict because you will never achieve
the ultimate goal of preventing malicious manipulations and when it's
too strict many developers will cease to contribute or will contribute
less - because the whole process will become too cumbersome.

[a...@iinet.net.au]

On Friday, February 13, 2015 at 7:32:59 AM UTC+11, Gijs Kruitbosch wrote:

> 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

What's to stop malware from installing a modified version of FF with any loop-hole at all?

[Lemon Juice]

I couldn't agree more. If light malware executables are deterred then
that's all it matters. If some malware is not light then it can hack the
system and Firefox in unimaginable ways and the add-on signing
requirement will be powerless to prevent it. You can only aim at light
malware, anything beyond that is not part of Firefox's responsibility or
capability.

However, if add-on signing is too restrictive it can deter more
developers that malware executables.

[Philipp Kewisch]

On 2/12/15 9:31 PM, Gijs Kruitbosch wrote:
> On 12/02/2015 02:32, a...@iinet.net.au wrote:
>> 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.

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

So whats stopping malware from binary-patching Firefox to remove the
checks? I guess the answer to that could be virus scanners.

So what if malware downloads the unbranded Firefox, replaces all the
artwork with the official branding and then replaces the shortcuts? If
malware has control of the whole system, I don't see much gain in
attempting to protect Firefox. If it just has control of Firefox, I'm
sure there is some sandboxing that can be done?

I have the feeling we are making a lot of developers unhappy without
much gain. At the end, malware developers will think of a new way to
circumvent the check or trick the user and we are back to the drawing
board. The malware situation should be improved, but for a Browser that
has a certain focus on community, I don't think it should be at the cost
of addon develoeprs.

Anyway, to make the branded build problem a bit easier, would it be
possible to create a file like channel-prefs.js that holds a preference
that overrides anything set in about:config and at the same time use
some sandboxing mechanism to prevent addons to writing to that file?
Then developers could ask users to change the file preference
temporarily in the branded build and you'd only have the problem of
malware that has full system access. For that, see my argument above.

Philipp

[Robert Kaiser]

Mike Kaply schrieb:

> Malware/Adware developers have already figured out ways to mess with Chrome that just simply bypass add-ons completely, and they can use these same mechanisms for Firefox (and are).

There's also a lot of malware/adware fro Firefox that "just" injects DLLs into our processes and therefore doesn't need to go through add-ons at all. I fear that add-on signing will just push them more to do that, and unfortunately, those injected DLLs cause more crashes and are harder to get rid of than add-ons. I'm not looking forward to that.

KaiRo

[Robert Kaiser]

Mike Connor schrieb:
> 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.

Yes, we are re.inventing prefs outside of prefs, and in the race, malware will just adapt and use those outside storages for their manipulations instead, and then we will create another storage mechanism and they'll adapt, and another, and another...

And they probably will inject DLLs that intercept the signature checking as well or just do their stuff without needing add-ons at all. After all, DLLs are even more powerful than add-ons.

KaiRo

[JS]

On 2/12/2015 6:01 PM, Lemon Juice wrote:

> 1. Use a secure vault provided by an OS to store permissions for running
> each unsigned add-on.

I've been meaning to ask if such options have been explored. Thanks
for bringing it up. If there are application-sealed storage options
on one or more platforms, they could be worth taking advantage of.
Not only for this problem, but others. I'm interested to see the
responses to this, and am off to check out your links.

[Philip Chee]

On 12/02/2015 10:36, andrew....@gmail.com wrote:

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

You can't write addons for IE, or at least without a lot of pain, pain,
and pain. However Spartan will support Chrome or Chrome-like extensions.

YMMV.

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.

[Emiliano Heyns]

On Thu, Feb 12, 2015 at 11:18 PM, Mike Connor <mco...@mozilla.com> wrote:

> Key revocation has two major flaws:
>
> * We'd have to know the key was lost or compromised. There's been cases
> where major vendors with full time security teams have unknowingly had
> their code signing keys compromised for extended periods of time. There
> are probably undiscovered examples as well.
>

If that is the case, what justifies the idea that putting all this
responsibility in a single place (Mozilla) makes this structurally better?
You've just made the case that even *if* Mozilla were a major vendor with a
full time security team, the current proposal allows for *everyone's*
security compromised rather than just some. Unless I'm overlooking
something, this suggests to me it would in fact be *vastly* better to have
decentralized signing.

>
> * We have to assume that anyone using a compromised key to bypass installs
> is going to actively subvert any revocation mechanism within the browser.
>

Which holds unreservedly for the case when the Mozilla key is compromised,
except worse: no active subversion will be necessary.

> And, ultimately, independent discovery of bad actors is hard and scales
> relatively poorly, and worse if we don't even know what's out there. We
> have that problem now, and self-signing preserves the status quo in terms
> of user protection. I think the evidence is clear in terms of that not
> working.
>
>

That at least is a decent argument. I do wonder what makes Mozilla plugins
so different from any random Windows app, which doesn't require centralized
control over who can release when.

Mind that I'm not in principle against Mozilla taking up the role of
guardian, even if a centralized authority *does* make me uneasy. It's
mainly that I've taken my plugins off AMO because the review process took
*ages*, and I like to "release early, release often". Having to wait even
days hinders my ability to troubleshoot with my users; I sometimes bake
instrumented versions just for diagnosis. The proposed solution makes me
powerless to help my users, and the communication about this radical change
suggests that the burden on the plugin developers is at most an
afterthought.

Emile

[Gijs Kruitbosch]

The answer to this and the suggestion of modifying the binaries
(although for the latter: OS signature checks + virus scanners, indeed)
is indeed "not very much - but it's a lot more work!".

As I've said elsewhere in this thread, the point is to increase the cost
of "breaking into Firefox". We're assuming the malware is executing with
admin privileges, so a watertight solution is literally impossible.

The effective argument is, considering the prevalence of
malware-injected add-ons, we *need*, for the sake of our users, to
increase the cost of doing this type of thing. Doing nothing is not an
option. Add-on signing and signature check enforcement provides what we
think is the most effective and least-add-on-developer/user-hostile way
to do this. The argument is *not* "this will fix all the problems and
doesn't increase the work for add-on devs". We're aware it won't fix
every conceivable way of getting into Firefox. We're aware it does put
up extra hurdles for developers. But so far, nobody has offered
alternatives that do also significantly increase the cost of "breaking
into Firefox", or decreases the work for add-on developers without also
punching a much-lower-cost hole in the barriers we're trying to put up
for malware.

Let's turn this around, back to the original argument: assuming
manipulating text (so also shortcut), DB, Windows registry, and files in
the user's Firefox profile counts as "easy" for the malware: how would
you protect against those attack vectors, if not by doing crypto-based
verification of extra code from the executable? And how would you offer
an opt-out that doesn't involve an "easy" switch (pref, commandline
option, registry option, ...)?

~ Gijs

[Mike Kaply]

A few other thoughts here.

1. You guys keep talking about the scope of the problem, but you're not giving anyone any data. Maybe if you gave some data on how big the problem was, it might help people understand.

2. What about simply requiring signed extensions with Mozilla being one of the signers for AMO. Then anyone that was willing to go through the pain of getting a signing cert was able to sign anything they wanted, and anyone that wasn't would use Mozilla.

[Philipp Kewisch]

On 2/13/15 2:59 PM, Mike Kaply wrote:

> 2. What about simply requiring signed extensions with Mozilla being one of the signers for AMO. Then anyone that was willing to go through the pain of getting a signing cert was able to sign anything they wanted, and anyone that wasn't would use Mozilla.
>

You mean just require them to be signed with any certificate? Getting a
signing cert is surprisingly simple and can be done without much cost at
startssl.com for example. This won't stop anyone.

Philipp

[Ben Bucksch]

I have a number of significant issues with this. To make a clear
discussion thread, I'll make one post per issue.

One non-starter for me is that you clearly (per your own statements)
discussed this internally at length, and only publish it when you made
your decision. Your decision seems to be final, given your responses to
objections in this thread. That's a non-starter for an open-source
project. In fact, at this point, it isn't an open-source *project*
anymore, it's just another a *company* that publishes its product as
open-source.

This is affecting a great many of developers and a whole community, and
you just can't make these discussions internally and simply publish the
decision. That's highly offensive.

[Mike Connor]

Let's not get the pitchforks out here. Especially not on some meta
argument about the nature of Mozilla as a project.

The bulk of what we're announcing here was discussed on this list at
length, stretching back to at least June 2014. The proposal has been
tweaked and modified multiple times based on all of that feedback. This
announcement was the culmination of a lot of public discussions and bugs
stretching across _years_, rather than something magically sprung,
fully-formed, upon an unsuspecting public.

-- Mike

On 13 February 2015 at 10:44, Ben Bucksch <ben.buck...@beonex.com>
wrote:

[Ben Bucksch]

This is threatening basic open-source values of freedom and sharing.

Apple has great products, but I still have to recommend my friends
against using them, because the only way to get apps on the device is
when Apple approves it. And we all know from the press and sometimes
personal experience that their rules are sometimes somewhat arbitrary.
AMO is no exception here, as I know from personal experience.

A single world-wide gatekeeper who makes the final (!) decision on what
can be published or not is a massive problem for freedom. In fact, we
have a word for that; it's called "censorship". Censorship is defined as
a mandatory pre-approval by a certain authority before anybody else can
publish anything to the public. This is true here. The effects of
censorship are well-know and I luckily don't have to lay this out here.

On a very practical level, I wrote a little app that is highly useful
and that I would like to share with my friends. For certain reasons, I
cannot publish it, though. I have an Android version, which I didn't
publish, I just post an APK via my website and give it only to my
friends. I did not submit it to the Google store, even as hidden app. I
do not have an iOS version, because there's the Apple gatekeeper.

I also have a FirefoxOS "packaged app" version of this app, which was
rejected by Firefox Marketplace validator because of a totally silly
issue. I'm using a totally legit feature that's allowed per spec, but
the validator author thinks it's not a good idea and the validator
rejects it. Thus, I cannot publish the app (without redesigning it), and
I haven't. This is bad validators and censorship in action.

Having a gatekeeper between me and my friends is total no-go for me.
It's going not only against freedom, but against the very principle of
sharing. You cannot get between me and my next, you have NO RIGHT to do
that.

The whole reason why I got involved in Mozilla in the first place was
because I wanted to foster freedom. I have contributed many years of
work to Mozilla. It's completely unacceptable that the Mozilla project
now turns around and starts with censorship. If we accept that, then I
don't know why we're here. Freedom is out spot in the market.

I understand the problem of malware, and I agree it must be solved. I'm
with you on that. But there are always many solutions to a given
problem. "We have to do this in order to solve ABC" is a faulty
reasoning. (I will not discuss alternatives here, but suffice to say
that they are several.)

"I am sick, so I have to kill myself". Find the right medicine, without
killing the patient. Don't kill freedom.

[Ben Bucksch]

In the previous posts I've shown that the collateral damage is going to
be enormous, even on a value level, even more so practical.

I am not sure this change is actually going to achieve what is intended:
To keep bad actors out of Firefox. The whole premise here is that there
is tons of malware that sideloads (installs via native third-party
installers) Firefox extensions that in turn change the search engine,
homepage, newtab page, add toolbars, inject ads into webpages and
similar nastiness which makes them money and is bad for users and the
Firefox reputation and the Mozilla Corporation revenue. E.g. by running
an unrelated installer for a "fix your Samsung phone" app or whatever
half-legal grey-area scam.

So, to fix this problem, we have to assume that a bad actor is running
native executables on the computer's machine. Also, given that we're
talking about millions of dollars, we have to assume that these bad
actors are highly motivated.

There are several easy ways to circumvent the protections here:
* Whatever store you use to save the search engine, implement that and
change it. This is already being done for Google Chrome
* Replace Firefox binaries selectively. After all, it's not hard to
compile Firefox.
* Use the Windows accessability APIs, which Firefox supports and which
allow low level access to window widgets and allow to read/add/modify
them, to inject ads and toolbars into Firefox using native widgets. This
has the additional benefit (for the bad actors) of also working
cross-browser.
* Change DNS locally to redirect www.google.com or similar to a proxy.

There's nothing you can do against these attacks. You must assume that
they WILL be done. The only reason why they haven't been done yet is
that there were easier, cleaner mechanisms. Once you cut them, worse
solutions will immerse.

My point here is that even if you make this change that causes a lot of
pain for developers and removes freedom, you will still not achieve your
end goal. The stakes for the bad guys are too high to just give up.

Ben

[Ben Bucksch]

I work on an extension for a company. That company has several brands,
each of them well-known and used by millions each. I have one codebase,
but one build per brand.
Furthermore, we have several products, e.g. a branded browser in
cooperation with Mozilla, and a stand-alone extension. Furthermore, we
have different forms of the extension.

Given that these factors multiply, we currently have 20 XPIs for each
version.

Of course, I have a build system that changes the version number,
commits the version to git, builds all the XPIs, and uploads them all to
the server, with a single command.

How shall I handle this now? Are you expecting me to manually upload and
download 20 XPIs to/from AMO, by hand, for *every single version* I
create? That's a non-starter.

Do you think I have a right to have an automated build and publish
system? Then please give me a way to script the upload and download, at
the very least. (After automated login via password, of course.)

Ben

[Ben Bucksch]

I see many people here objecting, and giving good reasons, I don't see
you changing your stance. I don't call that a "discussion".

[Ben Bucksch]

Mike Connor wrote, On 13.02.2015 17:03:

> culmination of a lot of public discussions and bugs
> stretching across _years_, rather than something magically sprung,
> fully-formed, upon an unsuspecting public.

I've been involved in these bugs and discussions, and I remember a lot
of disagreement from the community, wherever I went.

What you implemented now is a lot *more* aggressive than what I remember
being discussed and being rejected.

[Ben Bucksch]

Daniel Veditz wrote, On 12.02.2015 01:44:
> For an add-on that requires a Firefox restart to install there's nothing
> we can do that can't be bypassed

That's my point. I don't think bad actors doing sideloading fear a
Firefox restart at all.

See my post "Not effective".

Ben

[Ben Bucksch]

Mike Kaply wrote, On 11.02.2015 16:59:
> 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.

+1

This is the model used by e.g. Microsoft Windows for device drivers. It
was considered very restrictive, thus Microsoft took Vista until 8 until
making it mandatory.

In the traditional model, the software developer gets a normal SSL
certificate (like for servers), just with the "code signing" bit set,
from any accepted CA.

I would propose that Mozilla acts as a CA for the purpose of extension
installation only. (Don't be scared of the "CA" word, that's no more
dangerous or risky than signing extension XPIs.) Mozilla would need a
way to validate identities.

Most addon developers already have an AMO account. Most of them could be
considered as validated already. New signups could be validated via
various methods. Apple uses a credit card charge of $1, IIRC, but that's
not very secure, because credit cards get stolen and sold by the
thousands. Luckily, there are other identity validation systems already
in place.

Either way, this model would be a lot more practical, because once I
have the certificate, I should be able to sign XPIs myself and Mozilla
doesn't get in the way between me and my customers. But bad actors and
still be taken out.

Ben

[Mike Connor]

Yep, pretty much this. Obtaining a code signing cert is simply not an
effective control. Better than nothing, but signed malware is a reality
these days.

On 13 February 2015 at 10:08, Philipp Kewisch <moz...@kewis.ch> wrote:

> On 2/13/15 2:59 PM, Mike Kaply wrote:
>

> > 2. What about simply requiring signed extensions with Mozilla being one
> of the signers for AMO. Then anyone that was willing to go through the pain
> of getting a signing cert was able to sign anything they wanted, and anyone
> that wasn't would use Mozilla.
> >
>

> You mean just require them to be signed with any certificate? Getting a
> signing cert is surprisingly simple and can be done without much cost at
> startssl.com for example. This won't stop anyone.
>
> Philipp

[Ben Bucksch]

Gijs Kruitbosch wrote, On 12.02.2015 21:36:
> If you're writing your own add-ons, you should probably already be
> using Firefox Developer Edition, which won't have these restrictions
> (as stated explicitly in the blogpost) and won't require your add-on
> to be signed.

You want us to eat Mozilla's dogfood. That's a fair interest.

One problem is what Mike mentioned, that my addon then might break on
old versions.

More important is that I want *others* to eat my dogfood. I create an
extension for a company, and we caught several nasty bugs by the fact
that many employees - non-technical team members - are installing the
extension we develop on their main browser. They ran into issues, e.g.
compatibility with other common third-party extensions, or scenarios
like unclear shutdown, that QA didn't catch. These employees would not
install any special edition of Firefox, they are normal people and I'm
glad they use our extension at all. This is the whole idea of "dogfood"
(as used by Netscape originally), and this change kills it.

Ben