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.