Re: Add-on File Registration PRD

classic Classic list List threaded Threaded
165 messages Options
1234 ... 9
Reply | Threaded
Open this post in threaded view
|

Re: Add-on File Registration PRD

Jorge Villalobos-2
Cross posting to dev.planning, where I originally intended this to be.
Please follow up to dev.planning.

Jorge

On 10/30/13 3:42 PM, Jorge Villalobos wrote:

> Hello!
>
> As many of you know, the Add-ons Team, User Advocacy Team, Firefox Team
> and others have been collaborating for over a year in a project called
> Squeaky [1]. Our aim is to improve user experience for add-ons,
> particularly add-ons that we consider bad for various levels of "bad".
>
> Part of our work consists on pushing forward improvements in Firefox
> that we think will significantly achieve our goals, which is why I'm
> submitting this spec for discussion:
>
> https://docs.google.com/document/d/1SZx7NlaMeFxA55-u8blvgCsPIl041xaJO5YLdu6HyOk/edit?usp=sharing
>
> The Add-on File Registration System is intended to create an add-on file
> repository that all add-on developers need to submit their files to.
> This repository won't publish any of the files, and inclusion won't
> require more than passing a series of automatic malware checks. We will
> store the files and generated hashes for them.
>
> On the client side, Firefox will compute the hashes of add-on files
> being installed and query the API for it. If the file is registered, it
> can be installed, otherwise it can't (there is planned transition period
> to ease adoption). There will also be periodic checks of installed
> add-ons to make sure they are registered. All AMO files would be
> registered automatically.
>
> This system will allow us to better keep track of add-on IDs, be able to
> easily find the files they correspond to, and have effective
> communication channels to their developers. It's not a silver bullet to
> solve add-on malware problems, but it raises the bar for malware developers.
>
> We believe this strikes the right balance between a completely closed
> system (where only AMO add-ons are allowed) and the completely open but
> risky system we currently have in place. Developers are still free to
> distribute add-ons as they please, while we get a much-needed set of
> tools to fight malware and keep it at bay.
>
> There are more details in the doc, so please give it a read and post
> your comments and questions on this thread.
>
> Jorge Villalobos
> Add-ons Developer Relations Lead
>
> [1] https://wiki.mozilla.org/AMO/Squeaky
>

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Add-on File Registration PRD

David E. Ross-3
On 10/30/2013 2:55 PM, Jorge Villalobos wrote:

> Cross posting to dev.planning, where I originally intended this to be.
> Please follow up to dev.planning.
>
> Jorge
>
> On 10/30/13 3:42 PM, Jorge Villalobos wrote:
>> Hello!
>>
>> As many of you know, the Add-ons Team, User Advocacy Team, Firefox Team
>> and others have been collaborating for over a year in a project called
>> Squeaky [1]. Our aim is to improve user experience for add-ons,
>> particularly add-ons that we consider bad for various levels of "bad".
>>
>> Part of our work consists on pushing forward improvements in Firefox
>> that we think will significantly achieve our goals, which is why I'm
>> submitting this spec for discussion:
>>
>> https://docs.google.com/document/d/1SZx7NlaMeFxA55-u8blvgCsPIl041xaJO5YLdu6HyOk/edit?usp=sharing
>>
>> The Add-on File Registration System is intended to create an add-on file
>> repository that all add-on developers need to submit their files to.
>> This repository won't publish any of the files, and inclusion won't
>> require more than passing a series of automatic malware checks. We will
>> store the files and generated hashes for them.
>>
>> On the client side, Firefox will compute the hashes of add-on files
>> being installed and query the API for it. If the file is registered, it
>> can be installed, otherwise it can't (there is planned transition period
>> to ease adoption). There will also be periodic checks of installed
>> add-ons to make sure they are registered. All AMO files would be
>> registered automatically.
>>
>> This system will allow us to better keep track of add-on IDs, be able to
>> easily find the files they correspond to, and have effective
>> communication channels to their developers. It's not a silver bullet to
>> solve add-on malware problems, but it raises the bar for malware developers.
>>
>> We believe this strikes the right balance between a completely closed
>> system (where only AMO add-ons are allowed) and the completely open but
>> risky system we currently have in place. Developers are still free to
>> distribute add-ons as they please, while we get a much-needed set of
>> tools to fight malware and keep it at bay.
>>
>> There are more details in the doc, so please give it a read and post
>> your comments and questions on this thread.
>>
>> Jorge Villalobos
>> Add-ons Developer Relations Lead
>>
>> [1] https://wiki.mozilla.org/AMO/Squeaky
>>
>

So the plan is to stop me from installing extensions that I know to be
good but have not gone through addons.mozilla.org?  You do not indicate
any option for the user to override this prohibition.  I have several
such extensions, and I do not want to lose the ability to get updates to
them.

This appears to be a total reversal of past Mozilla philosophy, which
not only encouraged the development of extensions but also strongly
advocated the use of extension where users wanted features that the
developers were not interested in providing.

Also cross-posted to mozilla.dev.extensions.  However, I have set
Followup-To for mozilla.dev.planning.

--
David E. Ross
<http://www.rossde.com/>

Where does your elected official stand?  Which
politicians refuse to tell us where they stand?
See the non-partisan Project Vote Smart at
<http://votesmart.org/>.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Add-on File Registration PRD

a.very.loud.noise
In reply to this post by Jorge Villalobos-2
On Wednesday, October 30, 2013 9:55:21 PM UTC, jorgev wrote:
> Cross posting to dev.planning, where I originally intended this to be.
>

There are two large problems with this.
1) Since Firefox will not allow any unregistered add-on to be installed then creating new an extension or theme will become impossible unless you allow blank add-ons to be registered.  If I create a new extension it cannot be installed and tested until it is registered.  

2) The company I work for has a number of extensions that are only used on our own servers.  They are have no functionality outside of our servers.  By requiring permission from Mozilla to run these extensions we will need to make certain items that could possibly give insight on our production practices to our competitors are removed and thus functionality would be lost.

 
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Add-on File Registration PRD

Nicholas Nethercote
On Wed, Oct 30, 2013 at 6:57 PM,  <[hidden email]> wrote:
>
> There are two large problems with this.
> 1) Since Firefox will not allow any unregistered add-on to be installed then creating new an extension or theme will become impossible unless you allow blank add-ons to be registered.  If I create a new extension it cannot be installed and tested until it is registered.

And would the edit/run cycle become edit/register/run?

> 2) The company I work for has a number of extensions that are only used on our own servers.  They are have no functionality outside of our servers.  By requiring permission from Mozilla to run these extensions we will need to make certain items that could possibly give insight on our production practices to our competitors are removed and thus functionality would be lost.

Yeah.

I'm pretty sympathetic to the suggestions that crack down on add-ons,
but this seems unworkably strict.

Nick
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Add-on File Registration PRD

Onno Ekker-2
In reply to this post by Jorge Villalobos-2
On 10/30/2013 10:55 PM, Jorge Villalobos wrote:

> Cross posting to dev.planning, where I originally intended this to be.
> Please follow up to dev.planning.
>
> Jorge
>
> On 10/30/13 3:42 PM, Jorge Villalobos wrote:
>> Hello!
>>
>> As many of you know, the Add-ons Team, User Advocacy Team, Firefox Team
>> and others have been collaborating for over a year in a project called
>> Squeaky [1]. Our aim is to improve user experience for add-ons,
>> particularly add-ons that we consider bad for various levels of "bad".
>>
>> Part of our work consists on pushing forward improvements in Firefox
>> that we think will significantly achieve our goals, which is why I'm
>> submitting this spec for discussion:
>>
>> https://docs.google.com/document/d/1SZx7NlaMeFxA55-u8blvgCsPIl041xaJO5YLdu6HyOk/edit?usp=sharing
>>
>> The Add-on File Registration System is intended to create an add-on file
>> repository that all add-on developers need to submit their files to.
>> This repository won't publish any of the files, and inclusion won't
>> require more than passing a series of automatic malware checks. We will
>> store the files and generated hashes for them.
>>
>> On the client side, Firefox will compute the hashes of add-on files
>> being installed and query the API for it. If the file is registered, it
>> can be installed, otherwise it can't (there is planned transition period
>> to ease adoption). There will also be periodic checks of installed
>> add-ons to make sure they are registered. All AMO files would be
>> registered automatically.
>>
>> This system will allow us to better keep track of add-on IDs, be able to
>> easily find the files they correspond to, and have effective
>> communication channels to their developers. It's not a silver bullet to
>> solve add-on malware problems, but it raises the bar for malware developers.
>>
>> We believe this strikes the right balance between a completely closed
>> system (where only AMO add-ons are allowed) and the completely open but
>> risky system we currently have in place. Developers are still free to
>> distribute add-ons as they please, while we get a much-needed set of
>> tools to fight malware and keep it at bay.
>>
>> There are more details in the doc, so please give it a read and post
>> your comments and questions on this thread.
>>
>> Jorge Villalobos
>> Add-ons Developer Relations Lead
>>
>> [1] https://wiki.mozilla.org/AMO/Squeaky
>>
>

Can everyone submit an add-on to Squeaky? Or only the add-on developer?
I ask this because to me it's not clear what happens to the metadata,
like in install.rdf. It's still necessary sometimes to edit this file,
especially for the targetApplication's maxVersion. There are also other
local edits (forks or branches) possible to existing add-ons, that are
not (yet) in the official version.

Onno
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Add-on File Registration PRD

J. Ryan Stinnett
In reply to this post by Jorge Villalobos-2
As others have mentioned, I don't think this degree of centralization is wanted or needed at all.

Why should it be necessary for me to register on AMO if I don't want to use it to distribute an add-on?  That seems very bad to me.

> This repository won't publish any of the files, and inclusion won't
> require more than passing a series of automatic malware checks. We will
> store the files and generated hashes for them.

This seems like it will just escalate an "arms race" with malware developers.  It will simply take them a bit of time to find clever ways around whatever scanning is being done.

> This system will allow us to better keep track of add-on IDs, be able to
> easily find the files they correspond to, and have effective
> communication channels to their developers.

These seem like anti-goals to me.  I don't want you to track anything about a non-AMO add-on.  Also, if you expect to detect malware with the scheme, I don't think the guilty developers would really be open to communication.

> We believe this strikes the right balance between a completely closed
> system (where only AMO add-ons are allowed) and the completely open but
> risky system we currently have in place. Developers are still free to
> distribute add-ons as they please, while we get a much-needed set of
> tools to fight malware and keep it at bay.

I completely disagree with your summary here.  This spec would add roadblocks to both the add-on development and distribution process, only to get what seem to like questionable value from surveying all that data.

Non-AMO developers are already avoiding AMO because they find it too limiting for one reason or another.  I would much rather allow the good bunch of non-AMO developers to continue innovating as they have today, instead of throwing a bunch of roadblocks at them, which could cause them to give up altogether.

- Ryan
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Add-on File Registration PRD

Gregory Szorc-3
In reply to this post by Nicholas Nethercote
On 10/30/2013 7:22 PM, Nicholas Nethercote wrote:
> On Wed, Oct 30, 2013 at 6:57 PM,  <[hidden email]> wrote:
>>
>> There are two large problems with this.
>> 1) Since Firefox will not allow any unregistered add-on to be installed then creating new an extension or theme will become impossible unless you allow blank add-ons to be registered.  If I create a new extension it cannot be installed and tested until it is registered.
>
> And would the edit/run cycle become edit/register/run?

This doesn't seem to be a valid concern as the proposal address this:

> Add-on developers testing their add-ons locally shouldn’t need to register every build, so they need a way to override registration.
> One possible solution is to add a command line switch (-noaddonreg) which opens Firefox in a mode that ignores registration checks. To avoid malicious applications from launching Firefox in this mode, Firefox could prompt users at startup if this switch is on, pointing out that it is an insecure mode and giving them the default option of starting in normal mode. Developers would quickly learn to mechanically choose the non-default and this would just become a minor annoyance in their development process.
> Additionally (or alternatively), a locked pref could be used to whitelist add-on IDs.

This seems like a very minor inconvenience to developers and one that
could be made invisible through tooling (such as the Add-on SDK's cfx tool).


_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Add-on File Registration PRD

Jorge Villalobos-2
In reply to this post by Onno Ekker-2
On 10/30/13 11:20 PM, Onno Ekker wrote:

> On 10/30/2013 10:55 PM, Jorge Villalobos wrote:
>> Cross posting to dev.planning, where I originally intended this to be.
>> Please follow up to dev.planning.
>>
>> Jorge
>>
>> On 10/30/13 3:42 PM, Jorge Villalobos wrote:
>>> Hello!
>>>
>>> As many of you know, the Add-ons Team, User Advocacy Team, Firefox Team
>>> and others have been collaborating for over a year in a project called
>>> Squeaky [1]. Our aim is to improve user experience for add-ons,
>>> particularly add-ons that we consider bad for various levels of "bad".
>>>
>>> Part of our work consists on pushing forward improvements in Firefox
>>> that we think will significantly achieve our goals, which is why I'm
>>> submitting this spec for discussion:
>>>
>>> https://docs.google.com/document/d/1SZx7NlaMeFxA55-u8blvgCsPIl041xaJO5YLdu6HyOk/edit?usp=sharing
>>>
>>> The Add-on File Registration System is intended to create an add-on file
>>> repository that all add-on developers need to submit their files to.
>>> This repository won't publish any of the files, and inclusion won't
>>> require more than passing a series of automatic malware checks. We will
>>> store the files and generated hashes for them.
>>>
>>> On the client side, Firefox will compute the hashes of add-on files
>>> being installed and query the API for it. If the file is registered, it
>>> can be installed, otherwise it can't (there is planned transition period
>>> to ease adoption). There will also be periodic checks of installed
>>> add-ons to make sure they are registered. All AMO files would be
>>> registered automatically.
>>>
>>> This system will allow us to better keep track of add-on IDs, be able to
>>> easily find the files they correspond to, and have effective
>>> communication channels to their developers. It's not a silver bullet to
>>> solve add-on malware problems, but it raises the bar for malware developers.
>>>
>>> We believe this strikes the right balance between a completely closed
>>> system (where only AMO add-ons are allowed) and the completely open but
>>> risky system we currently have in place. Developers are still free to
>>> distribute add-ons as they please, while we get a much-needed set of
>>> tools to fight malware and keep it at bay.
>>>
>>> There are more details in the doc, so please give it a read and post
>>> your comments and questions on this thread.
>>>
>>> Jorge Villalobos
>>> Add-ons Developer Relations Lead
>>>
>>> [1] https://wiki.mozilla.org/AMO/Squeaky
>>>
>>
>
> Can everyone submit an add-on to Squeaky? Or only the add-on developer?
> I ask this because to me it's not clear what happens to the metadata,
> like in install.rdf. It's still necessary sometimes to edit this file,
> especially for the targetApplication's maxVersion. There are also other
> local edits (forks or branches) possible to existing add-ons, that are
> not (yet) in the official version.
>
> Onno
>

File registration would be tied to an account, so the developer should
be the one submitting it. maxVersion changes are generally not necessary
anymore, so hopefully that won't be a major problem. If you needed to
modify the XPI for whatever reason, you should also change the add-on ID
and then submit it for registration.

For abandoned add-ons that are still widely used, we might do some
registration ourselves.

Jorge
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Add-on File Registration PRD

Jorge Villalobos-2
In reply to this post by a.very.loud.noise
On 10/30/13 7:57 PM, [hidden email] wrote:
> On Wednesday, October 30, 2013 9:55:21 PM UTC, jorgev wrote:
>> Cross posting to dev.planning, where I originally intended this to be.
>>
>
> There are two large problems with this.
> 1) Since Firefox will not allow any unregistered add-on to be installed then creating new an extension or theme will become impossible unless you allow blank add-ons to be registered.  If I create a new extension it cannot be installed and tested until it is registered.  

As posted by someone else, the proposal addresses the developer flow.
Not only new add-ons but also existing add-ons under development need a
way to bypass registration to avoid having to register every single build.

> 2) The company I work for has a number of extensions that are only used on our own servers.  They are have no functionality outside of our servers.  By requiring permission from Mozilla to run these extensions we will need to make certain items that could possibly give insight on our production practices to our competitors are removed and thus functionality would be lost.

Registered files are not exposed in any way to the public. The only way
to learn about them would be to send an API call using the add-on ID and
a file hash, which will tell you if the hash is registered or not. I
don't see how that would give your competitors any insights (unless
you're saying Mozilla is your competitor).

We understand that because of various reasons, like business policies of
not sharing certain information under any circumstances, registering
add-ons for internal use will not be possible. In those cases you will
have the option of just blocking the API in your internal network. API
failures will allow the add-on to be installed. We're also looking into
locked preferences to whitelist a set of IDs.

Jorge
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Add-on File Registration PRD

Jorge Villalobos-2
In reply to this post by David E. Ross-3
On 10/30/13 6:09 PM, David E. Ross wrote:

> On 10/30/2013 2:55 PM, Jorge Villalobos wrote:
>> Cross posting to dev.planning, where I originally intended this to be.
>> Please follow up to dev.planning.
>>
>> Jorge
>>
>> On 10/30/13 3:42 PM, Jorge Villalobos wrote:
>>> Hello!
>>>
>>> As many of you know, the Add-ons Team, User Advocacy Team, Firefox Team
>>> and others have been collaborating for over a year in a project called
>>> Squeaky [1]. Our aim is to improve user experience for add-ons,
>>> particularly add-ons that we consider bad for various levels of "bad".
>>>
>>> Part of our work consists on pushing forward improvements in Firefox
>>> that we think will significantly achieve our goals, which is why I'm
>>> submitting this spec for discussion:
>>>
>>> https://docs.google.com/document/d/1SZx7NlaMeFxA55-u8blvgCsPIl041xaJO5YLdu6HyOk/edit?usp=sharing
>>>
>>> The Add-on File Registration System is intended to create an add-on file
>>> repository that all add-on developers need to submit their files to.
>>> This repository won't publish any of the files, and inclusion won't
>>> require more than passing a series of automatic malware checks. We will
>>> store the files and generated hashes for them.
>>>
>>> On the client side, Firefox will compute the hashes of add-on files
>>> being installed and query the API for it. If the file is registered, it
>>> can be installed, otherwise it can't (there is planned transition period
>>> to ease adoption). There will also be periodic checks of installed
>>> add-ons to make sure they are registered. All AMO files would be
>>> registered automatically.
>>>
>>> This system will allow us to better keep track of add-on IDs, be able to
>>> easily find the files they correspond to, and have effective
>>> communication channels to their developers. It's not a silver bullet to
>>> solve add-on malware problems, but it raises the bar for malware developers.
>>>
>>> We believe this strikes the right balance between a completely closed
>>> system (where only AMO add-ons are allowed) and the completely open but
>>> risky system we currently have in place. Developers are still free to
>>> distribute add-ons as they please, while we get a much-needed set of
>>> tools to fight malware and keep it at bay.
>>>
>>> There are more details in the doc, so please give it a read and post
>>> your comments and questions on this thread.
>>>
>>> Jorge Villalobos
>>> Add-ons Developer Relations Lead
>>>
>>> [1] https://wiki.mozilla.org/AMO/Squeaky
>>>
>>
>
> So the plan is to stop me from installing extensions that I know to be
> good but have not gone through addons.mozilla.org?  You do not indicate
> any option for the user to override this prohibition.  I have several
> such extensions, and I do not want to lose the ability to get updates to
> them.

The proposal mentions a way to bypass check for add-ons that are under
development, and possibly an add-on ID whitelist. It's also possible to
just block the API calls, since network errors won't prevent add-ons
from being installed.

> This appears to be a total reversal of past Mozilla philosophy, which
> not only encouraged the development of extensions but also strongly
> advocated the use of extension where users wanted features that the
> developers were not interested in providing.

We're adding a malware detection step in the development process. I
don't think that's a complete reversal. What would be a complete
reversal in our philosophy would be to only allow AMO add-ons, and
that's something I've been fighting for years so it doesn't happen.
However, there are real problems and risks in way we currently deal with
add-ons, which is why we're putting this proposal forward. This is a
middle ground where we can have some control over malware distribution
while still allowing developers to create whatever they want (that isn't
malicious) outside of AMO.

Jorge
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Add-on File Registration PRD

avih-2
In reply to this post by Jorge Villalobos-2
On Thursday, October 31, 2013 6:57:48 PM UTC+2, jorgev wrote:

> On 10/30/13 7:57 PM, [hidden email] wrote:
>
> > On Wednesday, October 30, 2013 9:55:21 PM UTC, jorgev wrote:
>
> >> Cross posting to dev.planning, where I originally intended this to be.
>
> >>
>
> >
>
> > There are two large problems with this.
>
> > 1) Since Firefox will not allow any unregistered add-on to be installed then creating new an extension or theme will become impossible unless you allow blank add-ons to be registered.  If I create a new extension it cannot be installed and tested until it is registered.  
>
>
>
> As posted by someone else, the proposal addresses the developer flow.
>
> Not only new add-ons but also existing add-ons under development need a
>
> way to bypass registration to avoid having to register every single build.
>
>
>
> > 2) The company I work for has a number of extensions that are only used on our own servers.  They are have no functionality outside of our servers.  By requiring permission from Mozilla to run these extensions we will need to make certain items that could possibly give insight on our production practices to our competitors are removed and thus functionality would be lost.
>
>
>
> Registered files are not exposed in any way to the public. The only way
>
> to learn about them would be to send an API call using the add-on ID and
>
> a file hash, which will tell you if the hash is registered or not. I
>
> don't see how that would give your competitors any insights (unless
>
> you're saying Mozilla is your competitor).
>
>
>
> We understand that because of various reasons, like business policies of
>
> not sharing certain information under any circumstances, registering
>
> add-ons for internal use will not be possible. In those cases you will
>
> have the option of just blocking the API in your internal network. API
>
> failures will allow the add-on to be installed. We're also looking into
>
> locked preferences to whitelist a set of IDs.
>
>
>
> Jorge

I'm copying my post from dev.platform:

On Thursday, October 31, 2013 2:09:06 AM UTC+2, David E. Ross wrote:
> This appears to be a total reversal of past Mozilla philosophy, ...

Agreed. Central repo and mandatory approval is not what Mozilla is IMO. While there are some gains from such move, I think it hurts freedom and openness more.

Essentially the browser has become an operating system, where apps/addons could be installed to it, including malwares. However, consider what happens if Microsoft or Apple would not let any app run unless it's approved on their main desktop OS? Look at the open community response to IOS closed garden.

What about companies who have private addons for their own employees which they don't want to share with Mozilla? What about addons which are against some US regulations? can we stop the government from preventing Mozilla approving those? What about addons which are against Mozilla's philosophy? Do we wanna stop those? Would we?

This really is a line Mozilla should not cross IMO.

Mozilla may provide signing for those who request it, or even maintain a repository of malware hashes (sort of antivirus), but making mandatory approval of addons is not something I'd like to see.

Also, is there a discussion going on? or is this a probe to see how much resistance there is for it? What would stop this suggested change from taking place? How many people were involved in creating this suggestion?

- avih
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Add-on File Registration PRD

Mike Connor-4
In reply to this post by Jorge Villalobos-2

On Oct 31, 2013, at 12:57 PM, Jorge Villalobos <[hidden email]> wrote:

> We understand that because of various reasons, like business policies of
> not sharing certain information under any circumstances, registering
> add-ons for internal use will not be possible. In those cases you will
> have the option of just blocking the API in your internal network. API
> failures will allow the add-on to be installed. We're also looking into
> locked preferences to whitelist a set of IDs.

I’m not convinced this will create a significant barrier, since a side loaded add-on is already coming in with admin privs, and thus can trivially subvert things like host resolution.

Is there a reason we haven’t just gone with signing of XPIs (submit unsigned XPIs, get back signed XPIs) rather than a network-driven API?  It’d be good to understand which options were considered over the last year.

— Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Add-on File Registration PRD

Boris Zbarsky
In reply to this post by avih-2
On 10/31/13 1:06 PM, Avi Hal wrote:
> However, consider what happens if Microsoft or Apple would not let any app run unless it's approved on their main desktop OS?

Just for what it's worth, Apple already does this by default, starting
with OS X 10.8.  It's possible to change the default behavior by going
into the OS security settings, for now; we'll see if that lasts.

There was a bit of stink about it at the time on tech sites, but mostly
it's been business as usual for Apple.

Not that I think we should use Apple as a role model for this stuff, of
course.  ;)

-Boris
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Add-on File Registration PRD

4mr.minj
In reply to this post by Jorge Villalobos-2
Well, this is annoying...

I don't want to see a stupid popup every time I restart FF/open a different profile.

>AMO will also expose a file upload API, to facilitate automated file registration.

We make daily builds in two branches: beta and nightly. They are used by up to 10% of our users. Needless to say, this gets a strong down-vote unless it will be easy to integrate in build scripts.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Add-on File Registration PRD

Jorge Villalobos-2
In reply to this post by avih-2
On 10/31/13 11:06 AM, Avi Hal wrote:

> On Thursday, October 31, 2013 6:57:48 PM UTC+2, jorgev wrote:
>> On 10/30/13 7:57 PM, [hidden email] wrote:
>>
>>> On Wednesday, October 30, 2013 9:55:21 PM UTC, jorgev wrote:
>>
>>>> Cross posting to dev.planning, where I originally intended this to be.
>>
>>>>
>>
>>>
>>
>>> There are two large problems with this.
>>
>>> 1) Since Firefox will not allow any unregistered add-on to be installed then creating new an extension or theme will become impossible unless you allow blank add-ons to be registered.  If I create a new extension it cannot be installed and tested until it is registered.  
>>
>>
>>
>> As posted by someone else, the proposal addresses the developer flow.
>>
>> Not only new add-ons but also existing add-ons under development need a
>>
>> way to bypass registration to avoid having to register every single build.
>>
>>
>>
>>> 2) The company I work for has a number of extensions that are only used on our own servers.  They are have no functionality outside of our servers.  By requiring permission from Mozilla to run these extensions we will need to make certain items that could possibly give insight on our production practices to our competitors are removed and thus functionality would be lost.
>>
>>
>>
>> Registered files are not exposed in any way to the public. The only way
>>
>> to learn about them would be to send an API call using the add-on ID and
>>
>> a file hash, which will tell you if the hash is registered or not. I
>>
>> don't see how that would give your competitors any insights (unless
>>
>> you're saying Mozilla is your competitor).
>>
>>
>>
>> We understand that because of various reasons, like business policies of
>>
>> not sharing certain information under any circumstances, registering
>>
>> add-ons for internal use will not be possible. In those cases you will
>>
>> have the option of just blocking the API in your internal network. API
>>
>> failures will allow the add-on to be installed. We're also looking into
>>
>> locked preferences to whitelist a set of IDs.
>>
>>
>>
>> Jorge
>
> I'm copying my post from dev.platform:
>
> On Thursday, October 31, 2013 2:09:06 AM UTC+2, David E. Ross wrote:
>> This appears to be a total reversal of past Mozilla philosophy, ...
>
> Agreed. Central repo and mandatory approval is not what Mozilla is IMO. While there are some gains from such move, I think it hurts freedom and openness more.
>
> Essentially the browser has become an operating system, where apps/addons could be installed to it, including malwares. However, consider what happens if Microsoft or Apple would not let any app run unless it's approved on their main desktop OS? Look at the open community response to IOS closed garden.
>
> What about companies who have private addons for their own employees which they don't want to share with Mozilla? What about addons which are against some US regulations? can we stop the government from preventing Mozilla approving those? What about addons which are against Mozilla's philosophy? Do we wanna stop those? Would we?
>
> This really is a line Mozilla should not cross IMO.
>
> Mozilla may provide signing for those who request it, or even maintain a repository of malware hashes (sort of antivirus), but making mandatory approval of addons is not something I'd like to see.
>
> Also, is there a discussion going on? or is this a probe to see how much resistance there is for it? What would stop this suggested change from taking place? How many people were involved in creating this suggestion?
>
> - avih
>

This is the discussion. We need to determine if there are drawbacks we
aren't aware of, and what people think about the drawbacks we know
about, specifically the openness issue.

It's difficult to say how many people have been involved with this idea,
since it has existed for a couple of years. At least a couple dozen
people from various teams within Mozilla have known about this and
shared their thoughts. Now it's time for the whole Mozilla community to
have their say.

However, I think it's unlikely that we just decide not to do anything.
It will either be this or something similar. The security risks of the
current system are pretty large.

Jorge
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Add-on File Registration PRD

Jorge Villalobos-2
In reply to this post by Jorge Villalobos-2
On 10/31/13 11:16 AM, Mike Connor wrote:

>
> On Oct 31, 2013, at 12:57 PM, Jorge Villalobos <[hidden email]> wrote:
>
>> We understand that because of various reasons, like business policies of
>> not sharing certain information under any circumstances, registering
>> add-ons for internal use will not be possible. In those cases you will
>> have the option of just blocking the API in your internal network. API
>> failures will allow the add-on to be installed. We're also looking into
>> locked preferences to whitelist a set of IDs.
>
> I’m not convinced this will create a significant barrier, since a side loaded add-on is already coming in with admin privs, and thus can trivially subvert things like host resolution.
>
> Is there a reason we haven’t just gone with signing of XPIs (submit unsigned XPIs, get back signed XPIs) rather than a network-driven API?  It’d be good to understand which options were considered over the last year.
>
> — Mike
>

There are a couple of reasons why signing isn't in this proposal. The
first one is that we would need to set a cut-off point after which we
only allow signed files. That would exclude all installations of
previously unsigned files, which would be massive. In this proposal,
developers have the possibility of registering their old files, so
current users can continue using them. Even for old, abandoned add-ons,
either us or one of their users can register old files so that they
continue working. On the AMO side we can automatically register all
files old, and new, fairly easily.

Signing XPIs would require us to repackage the files to add the
signature, and that's something we've had problems with in the past
(like with SDK repacks). I don't have confidence that it would work for
the the huge back-catalog of add-on files we have. And, even if we did
sign them all, that still excludes all installs of old files.

Jorge
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Add-on File Registration PRD

Jorge Villalobos-2
In reply to this post by 4mr.minj
On 10/31/13 1:10 PM, [hidden email] wrote:
> Well, this is annoying...
>
> I don't want to see a stupid popup every time I restart FF/open a different profile.
>
>> AMO will also expose a file upload API, to facilitate automated file registration.
>
> We make daily builds in two branches: beta and nightly. They are used by up to 10% of our users. Needless to say, this gets a strong down-vote unless it will be easy to integrate in build scripts.
>

The upload API is meant to handle this use case specifically, and we'll
make sure it works well.

Jorge
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Add-on File Registration PRD

a.very.loud.noise
In reply to this post by Jorge Villalobos-2
On Thursday, October 31, 2013 9:57:48 AM UTC-7, jorgev wrote:

> On 10/30/13 7:57 PM, [hidden email] wrote:
>
> > On Wednesday, October 30, 2013 9:55:21 PM UTC, jorgev wrote:
>
> >> Cross posting to dev.planning, where I originally intended this to be.
>
> >>
>
> >
>
> > There are two large problems with this.
>
> > 1) Since Firefox will not allow any unregistered add-on to be installed then creating new an extension or theme will become impossible unless you allow blank add-ons to be registered.  If I create a new extension it cannot be installed and tested until it is registered.  
>
>
>
> As posted by someone else, the proposal addresses the developer flow.
>
> Not only new add-ons but also existing add-ons under development need a
>
> way to bypass registration to avoid having to register every single build.
>
>
>
> > 2) The company I work for has a number of extensions that are only used on our own servers.  They are have no functionality outside of our servers.  By requiring permission from Mozilla to run these extensions we will need to make certain items that could possibly give insight on our production practices to our competitors are removed and thus functionality would be lost.
>
>
>
> Registered files are not exposed in any way to the public. The only way
>
> to learn about them would be to send an API call using the add-on ID and
>
> a file hash, which will tell you if the hash is registered or not. I
>
> don't see how that would give your competitors any insights (unless
>
> you're saying Mozilla is your competitor).
>
>
>
> We understand that because of various reasons, like business policies of
>
> not sharing certain information under any circumstances, registering
>
> add-ons for internal use will not be possible. In those cases you will
>
> have the option of just blocking the API in your internal network. API
>
> failures will allow the add-on to be installed. We're also looking into
>
> locked preferences to whitelist a set of IDs.
>
>
>
> Jorge

The command line switch (-noaddonreg)(which I didn't notice, sorry about that) is a much better idea.  A whitelist in unworkable in a corporate situation simply because the amount of effort it would take to roll it out to 200+ isn't worth the money it would cost.  -noaddonreg would solve the problem nicely since it would be a very easy way to take Mozilla out of seconding guessing our IT department's choices.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Add-on File Registration PRD

Gijs Kruitbosch ("Hannibal")
In reply to this post by Jorge Villalobos-2
On 31/10/13, 21:56 , Jorge Villalobos wrote:

> On 10/31/13 11:16 AM, Mike Connor wrote:
>>
>> On Oct 31, 2013, at 12:57 PM, Jorge Villalobos <[hidden email]> wrote:
>>
>>> We understand that because of various reasons, like business policies of
>>> not sharing certain information under any circumstances, registering
>>> add-ons for internal use will not be possible. In those cases you will
>>> have the option of just blocking the API in your internal network. API
>>> failures will allow the add-on to be installed. We're also looking into
>>> locked preferences to whitelist a set of IDs.
>>
>> I’m not convinced this will create a significant barrier, since a side loaded add-on is already coming in with admin privs, and thus can trivially subvert things like host resolution.
>>
>> Is there a reason we haven’t just gone with signing of XPIs (submit unsigned XPIs, get back signed XPIs) rather than a network-driven API?  It’d be good to understand which options were considered over the last year.
>>
>> — Mike
>>
>
> There are a couple of reasons why signing isn't in this proposal. The
> first one is that we would need to set a cut-off point after which we
> only allow signed files. That would exclude all installations of
> previously unsigned files, which would be massive. In this proposal,
> developers have the possibility of registering their old files, so
> current users can continue using them. Even for old, abandoned add-ons,
> either us or one of their users can register old files so that they
> continue working. On the AMO side we can automatically register all
> files old, and new, fairly easily.
>
> Signing XPIs would require us to repackage the files to add the
> signature, and that's something we've had problems with in the past
> (like with SDK repacks). I don't have confidence that it would work for
> the the huge back-catalog of add-on files we have. And, even if we did
> sign them all, that still excludes all installs of old files.
>
> Jorge
>

The thing is, you're implicitly signing things now, in a certain way.
All a signature really is is a guarantee of an identity that it knows
about some thing (usually based on a hash of the thing).

If we allowed signed add-ons without the hash being registered
centrally, that'd likely alleviate the burden somewhat for people
wanting to locally deploy stuff (and not wanting the
signature-checking-style-things going in AMO's direction) and do good
things in terms of the openness discussion as well: all we're enforcing
is some kind of voucher for the correctness of the package, which would
be either the certificate chain for a signature of a signed xpi, or AMO
in the case of an unsigned one.

~ Gijs
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Add-on File Registration PRD

Gavin Sharp-3
In reply to this post by J. Ryan Stinnett
On Thu, Oct 31, 2013 at 7:49 AM, J. Ryan Stinnett <[hidden email]> wrote:
> This seems like it will just escalate an "arms race" with malware developers.
> It will simply take them a bit of time to find clever ways around whatever
> scanning is being done.

That the solution isn't perfect and results in an "arms race" doesn't
mean that it has no value. Sometimes it makes sense to "get into the
arms race" if it means that we protect more of our users in practice.

(Of course, the specifics of how we approach this is complicated and
worthy of debate. Sometimes the costs of being in the arms race
outweigh the benefits, but that's not always the case.)

Gavin
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
1234 ... 9