Hacker News Reader

Comment by jape | Hacker News Reader

While this is extremely dubious behavior from Mozilla, and reminds me why I stopped donating to them (the moment Firefox started requiring _their_ signature in order to load addons), Mozilla still has the "automated signing API" in place. Supposedly, this API allows to get an XPI signed as long as it passes a series of automated checks. So it's worth a try.

This was the excuse they used anyway when trying to justify their signature requirements were "not a walled garden". I didn't believe it of course.

You can also just mark the addon as "not listed in AMO" when submitting it to addons.mozilla.org and it will not be listed on the store, but it will be signed. More details in https://developer.mozilla.org/docs/Mozilla/Add-ons/Distribut...

View on HN

I've recently been experimenting with creating an extension, and the automated signing was literally one of the first things I did when I followed the Hello World tutorial. It's very easy to obtain an .xpi that you can distribute to your users yourself.

How do you do this without leaking your code to mozilla?

I don't think you can have Mozilla sign it without letting them see the code.

Out of curiosity, under what circumstances would you consider distributing an extension bundle to be leaking its code? Unless I'm misunderstanding, isn't this the same file you'll be distributing to your users? At first bluff it seems similar to worrying about leaking your website's frontend (I've got news for you...).

It could be a private extension developed by a company internally, and only distributed to internal users.

If it's for an entire company, then it's easy enough to compile your own copy of firefox that accepts extensions signed with the company signature rather than mozilla.

It's really not. Small businesses exist.

If you have the resources to develop an internal company addon, you have the resources to build a firefox that accepts a different signature.

Respectfully disagree - having to rebuild each time patches come out, on multiple OSes and versions, which have a patch to allow unsigned extensions is a massively more time expensive than developing a browser extension, and requires extra knowledge on the behalf of the persons responsible

Luckily it's not necessary: you can still enable a flag in ESR releases that allow installation of unsigned add-ons, so that solves it for company-internal tools.

off-topic: the phrase is, "at first blush"

Aren't extension written in Javascript? Then the source is always visible to users.

They are referring to an internal company tool

"Leaking your code to mozilla"? What do you think they are going to do with it?

Doesn't matter. When developing an internal company tool, it can become a blocker due to policy or legal reasons.

Luckily,when it's internal you can use the ESR release and set a policy that allows it to be installed anyway.

> dubious behavior

When you criticize someone this strongly, it pays to at least acknowledge the reasons they've given for making the decisions they made, even if you don't like those reasons. Here they are: https://blog.mozilla.org/addons/2015/04/15/the-case-for-exte...

Reply on news.ycombinator.com