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

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.

 

On Wed, Oct 30, 2013 at 6:57 PM,  <a.very....@gmail.com> 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

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

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

On 10/30/2013 7:22 PM, Nicholas Nethercote wrote:
> On Wed, Oct 30, 2013 at 6:57 PM,  <a.very....@gmail.com> 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).

On 10/30/13 7:57 PM, a.very....@gmail.com 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 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

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

On Oct 31, 2013, at 12:57 PM, Jorge Villalobos <jo...@mozilla.com> 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

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

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.

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

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 upload API is meant to handle this use case specifically, and we'll
make sure it works well.

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.

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

On 31/10/13, 22:30 , a.very....@gmail.com wrote:
> On Thursday, October 31, 2013 9:57:48 AM UTC-7, jorgev wrote:
>> On 10/30/13 7:57 PM, a.very....@gmail.com 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..

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

How do we envision this working? For it to work for people in enterprise
situations, it having a click-through UI is a no-no. As an add-on dev,
I'd get pretty tired of having to click through it all the time. If
there's no warning at all, I'd imagine malware will have started using
it as a startup parameter for Firefox before it's been through the 12
weeks from nightly to release...

~ Gijs

On Thu, Oct 31, 2013 at 7:49 AM, J. Ryan Stinnett <jry...@gmail.com> 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

Well, I guess an apology is in order. I had not envisioned such a way as this for you to mitigate security risks without disabling third party add-ons, so I see now that your rejection of my add-on, AsYouWish[1] from AMO was not a result of arbitrariness.

However, I am concerned that my platform, which allows websites to gain access to Addon SDK privileges upon user approval, may be treated as malware (since sites may be able to use it as such).

At an earlier time, Mozilla felt that enablePrivilege was a fair enough mechanism (e.g., to allow more rapid deployment by developers and avoidance of installation for users such as add-ons cannot provide), and even now, with other third party add-ons, there can be a spectrum of privilege escalation.

For example, I have completed initial work on WebAppFind[2] to allow executables to be associated with file extensions on the desktop (currently Windows only), so that when a user right-clicks "Open With..." or assigns the executable as the default handler for a file on their desktop and double-clicks the file, Firefox will be invoked with command line instructions sent by the executable that my add-on receives, and it will then grant a suitable website the necessary message listening and posting capabilities that will allow it to read and potentially overwrite the contents of the opened file. I think this is a far more circumscribed escalation of privileges than AsYouWish, but I'm not sure whether you would block this from AMO or worse, treat it as malware due to it enabling a malicious (albeit user-approved) website to overwrite the contents of a clicked file.

I would hope you could clarify in plain language what the attempts at "malware" exclusion mean as far as those add-ons which deliberately facilitate an escalation of privileges. I would think that any postMessage communication between websites and add-ons (as is already a part of your SDK API) is likely to be used to provide some form of escalation of privileges, so if you are going to be policing this, I hope you can define a consistent (and hopefully not unduly constraining) policy in this regard.

The web is moving forward with even more dangerous capabilities like user-approved Geo-location, so I hope that efforts for minimization of risk will not unduly hold back an increase of opportunities.

[1] https://github.com/brettz9/asyouwish/
[2] https://github.com/brettz9/webappfind

I develop an extension for use on an intranet that has no access to the Internet. Will this affect my extension?

On Wednesday, October 30, 2013 5:55:21 PM UTC-4, jorgev wrote:
> Cross posting to dev.planning, where I originally intended this to be.

The proposal describes it as something that would be implemented in Firefox. My concern is what impact this might have on Thunderbird.

1) Would this only be implemented in Firefox or might it actually be implemented in Gecko or some other shared library that forces the Thunderbird developers to support this proposal unless they want to fork and maintain their own version of that component?

2) The "series of automatic malware checks" might block some Thunderbird add-ons because whoever designed the malware checks is focused strictly on Firefox.

3) Mozilla has stopped development of Thunderbird so the development process no longer mimics Firefox's. Thunderbird has only one release a year with new features (implemented by the community) so users are very dependent upon add-ons for new features/functionality. Many popular add-ons haven't been updated for several years.

This means that any additional obstacles have a disproportionate effect on Thunderbird users. Please don't evaluate the impact just in terms of what it means to Firefox users.

On 10/31/2013 1:50 PM, Jorge Villalobos wrote:
> 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, a.very....@gmail.com 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
>

What is needed is an end-user option that says "I accept the risk.  Let
me install and enable the addons I want."  There already is a similar
existing option for about:config

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

On 10/31/2013 07:49 AM, J. Ryan Stinnett wrote:
>> 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.

Escalate, yes. But we're already in that arms race, and there's no way
to avoid it. We provide the capability to modify the operation of users'
browsers. It is inevitably exploited for both good and harmful purposes.
We do what we can to keep the balance on the good side without choking
it off entirely. Barriers to side-loaded extensions and AMO review are
just two example attempts we've made to swing things towards the good
side. This proposal pushes harder on the good side, at the risk of
choking off the supply (it improves quality at the cost of quantity, and
it's hard to say what the end result is.)

This system involves permanently storing IP addresses and the full text
of all addon files. That's a dangerous pile of data to be sitting on. Do
we want to handle subpoenas for IP addresses known to belong to
organizations and individuals under investigation? Do we want to risk a
security breach exposing a whole lot of data that doesn't belong to us?

Some organizations will have policies that forbid exposing these data
(in particular, the addon files) to external third parties, no matter
how convincingly they promise to take care of them. We would lose those
users unless we came up with a better mechanism for local registration.
But such a mechanism might defeat part of the desired benefits of this
proposal (eg having better contact info for addon authors.)

I don't know what the automatic malware analysis is, but every similar
analysis that I've ever worked on has required constant change,
especially when it's exposed as a tool in the arms race against people
motivated to subvert it (eg malware authors.) I'm skeptical that we
could rerun the analysis on the entire registry, every time the analysis
changes. The registry will at least have to track what version of the
analysis was run for a given entry, and the browser UI would need to
accept a registered addon becoming unregistered at any time.

The proposal would slow down startup, since all enabled addons will need
to be hashed before loading them "for real". (And those hashes would
need to be looked up in a local cache of the registry, assuming you
don't want to wait on a network hit during startup.)

An alternative to consider would be to run the analysis on the client
side. The code for the analysis could be updated with every Firefox
release or more frequently. The perf hit could be mitigated by running
the analysis for popular addons on the AMO side, and using the registry
sketched out in the proposal for those. Sure, malware could subvert the
local analysis, but it could just as easily lie about the content hash
used to query the registry. (The client side would still probably want
to cache the analysis results across browser restarts, so it'd still
need to checksum the file and look up the checksum in a local registry
to avoid redoing the analysis during startup.)

On 01/11/13, 24:54 , Jorge Villalobos wrote:
> On 10/31/13 3:33 PM, Gijs Kruitbosch wrote:
>> 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 <jo...@mozilla.com>

>>>> 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
>
> So, you're suggesting to have signing in addition to the hashes, as a
> way to opt-out?
>
> Jorge

Yes, but to shoot my own plan down a little bit, I'm not sure how much
that gets you in the malware department. Getting a cert that lets you
sign packages is just a question of money, not of the reputability of
your business. On the other hand, it *would* make it harder to have
random IDs for signed add-ons, as you'd need to sign each one when you
change the ID (as that'd change the file hash and thus the signature).

We could also consider adding blocklist features that block based on the
signature/cert chain used, so that even if malware providers obtain a
cert, we could decide to block add-ons signed with that cert.

~ Gijs

On 01/11/2013 01:06, Jorge Villalobos wrote:

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

Here is my usecase:

I run http://xsidebar.mozdev.org/modifiedmisc.html

This is a collection of Firefox and Thunderbird extensions that I have
modified to work with SeaMonkey.

These extensions fall into various categories:

1. Orphaned extensions that I have been keeping alive by updating the
code. The original authors aren't around any more, and even if they are
they probably aren't interested in any more involvement with Mozilla.
These extensions may or may not be registered with AMO. How would I get
AMO to accept my mods?

2. Active extensions from authors who aren't interested in supporting
SeaMonkey - as it their right. Assuming that these authors are still
using AMO, how do I get my forks registered? Without changing the
extension ID.

An additional usecase:

3. Extensions that aren't on AMO (due to some disagreements with AMO
policies or some other dispute) but are hosted on mozdev, or
extensions-mirror, or code.google.com or github, or bitbucket, or
sourceforge, or the authors blog. If these authors aren't interested in
involvement with AMO, forcing them to register their addons are just
going to make them even more annoyed with AMO.

You have a problem but your proposed cure is worse than the disease.
Stop listening to the echo chamber and pay more attention to extension
developers please.

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.

On Wed, Oct 30, 2013 at 11:42 PM, Jorge Villalobos <jo...@mozilla.com> wrote:
> 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].

(Actually, many of us probably didn't know.)

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

I disagree on the point of right balance. I think this is at the same
time to Draconian and too lenient.

I think this is to Draconian, because it prevents organizations
("enterprises") from deploying add-ons within the organization without
having to coordinate from an outside entity. Based on what Mike Kaply
said on the add-on experience mailing list, I believe this would be a
problem for real organizations that deploy Firefox today. I think it
would be a big mistake to add another round of fuel to the meme that
Mozilla is hostile to the enterprise sector.

Undermining enterprise deployment undermines the Mozillians who've
fought hard to be able to use and let others use Firefox in their
workplaces. In general, the home use sector and the enterprise sector
spill over in both directions: People who are happy with Firefox at
home want to use it at work and will be less happy if they can't. On
the other hand, if people are forced to use something other than
Firefox at work, they might get accustomed to it or even like it and
move to the same non-Firefox browser at home.

So I think it would be a very bad idea to proceed with this plan
without solving the enterprise deployment concerns before proceeding.
(That is, proceeding and maybe solving the enterprise concerns later
would mean the damage would be done by the times of the solution
arrives.)

On the other hand, I think this proposal is too lenient, because it
wouldn't solve the problem of search hijacks an unwanted toolbars. The
mockups for this project suggest that search hijacks and unwanted
toolbars could still be registered.
(https://wiki.mozilla.org/Add-ons/FileRegistration/Mockups)

That is, it seems to me that this proposal would have significant
downsides but not be a major win in terms of the most common add-on
annoyances.

On Thu, Oct 31, 2013 at 7:19 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> Just for what it's worth, Apple already does this by default, starting with
> OS X 10.8.

What Apple is doing by default on OS X is substantially different from
this proposal. By default, Apple requires OS X *developers* to be
registered and requires the developers to sign the apps they
distribute. This means that the apps don't need to be disclosed to
Apple prior to distribution, but ex-post revocation in case of
misbehavior is possible. This proposal involves disclosing the add-ons
to Mozilla prior to distribution.

As far as I can tell, the requirement to disclose add-ons to Mozilla
ex-ante provides Mozilla with the opportunity to run a malware scan
and to put the code on file in case there's a need to study the code
more carefully for the purpose of ex-post policy enforcement.

Are a malware scan and having the code on file really worth the
downsides of the proposed system when the definition of "malware"
doesn't even include the most typical sorts of unwanted add-ons?

--
Henri Sivonen
hsiv...@hsivonen.fi
http://hsivonen.fi/

Jorge Villalobos wrote:
> 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.

Perhaps it is because I am newer here, but part of what made it so hard for me to read your initial post was that I personally do not perceive any malware risk, so it came across as many developer restrictions for a threat that did not even seem to be real.

I would suggest adding more information about what Mozilla considers to be "malware" and how prevalent it seems to be today.

Jorge Villalobos wrote:
> If a user installs a file that is not registered, a message will be shown
> explaining that the file can’t be installed for their protection.

It looks as if there is no way to get around the decision received from the registration service once a check has been made.  Why is that?  Alerting the user that Mozilla considers an add-on to be unsafe seems okay, but it just does not seem possible to truly know whether *each user* would agree the extension is unsafe if they knew what it was doing.  

Could there be a button to continue anyway?  Or at least a link to some documentation explaining how to white list IDs?

Jorge Villalobos wrote:
> ...you will have the option of just blocking the API in your internal

> network. API failures will allow the add-on to be installed.

Do you plan to publish the host names of the servers used in this process so that they can easily be blocked for people / organizations who choose this option?  Perhaps they could be part of the same documentation that I was suggesting above that would explain how to white list.

Jorge Villalobos wrote:
> So, you're suggesting to have signing in addition to the hashes, as a
> way to opt-out?

I do think this is valuable to explore as a lighter-weight solution for any developers that do not feel comfortable handing over their code.  As you mentioned earlier, supporting signing *only* seems bad, since it would lead to many broken extensions.  But a "dual path" approach that also made signing available as an option seems more developer friendly.  I hope that this approach can be evaluated.

- Ryan

On Thu, Oct 31, 2013 at 9:33 PM, Eric Moore <erm...@gmail.com> wrote:

> On Wednesday, October 30, 2013 5:55:21 PM UTC-4, jorgev wrote:
> > Cross posting to dev.planning, where I originally intended this to be.
>
> The proposal describes it as something that would be implemented in
> Firefox. My concern is what impact this might have on Thunderbird.
>
> 1) Would this only be implemented in Firefox or might it actually be
> implemented in Gecko or some other shared library that forces the
> Thunderbird developers to support this proposal unless they want to fork
> and maintain their own version of that component?
>

Due to the nature of the code this will certainly be implemented
predominantly in toolkit but it will be done so in a way that allows
applications to opt-in to it similar to other things that we have added in
the past like the sideloading opt-in screen and hotfix support.

> 2) The "series of automatic malware checks" might block some Thunderbird
> add-ons because whoever designed the malware checks is focused strictly on
> Firefox.
>

I don't know the specifics of the checks but I believe it is more about
checking for the existance of actual binary malware that the add-on might
try to execute. This would apply equally to Thunderbird add-ons as well as
Firefox add-ons. Regardless I'm sure the AMO team will be open to make
changes if this became a problem.

On Thu, Oct 31, 2013 at 11:55 PM, Steve Fink <sf...@mozilla.com> wrote:

> The proposal would slow down startup, since all enabled addons will need
> to be hashed before loading them "for real". (And those hashes would
> need to be looked up in a local cache of the registry, assuming you
> don't want to wait on a network hit during startup.)
>

The intention is not to hash the add-ons during startup. We've talked about
the option of hashing some time later to verify that all the installed
add-ons are still valid. This does create a way for an application on the
user's system to get an unknown add-on into Firefox but that seems like an
ok trade-off against saving startup time.

> An alternative to consider would be to run the analysis on the client
> side. The code for the analysis could be updated with every Firefox
> release or more frequently. The perf hit could be mitigated by running
> the analysis for popular addons on the AMO side, and using the registry
> sketched out in the proposal for those. Sure, malware could subvert the
> local analysis, but it could just as easily lie about the content hash
> used to query the registry. (The client side would still probably want
> to cache the analysis results across browser restarts, so it'd still
> need to checksum the file and look up the checksum in a local registry
> to avoid redoing the analysis during startup.)
>

The malware check itself is not the most important part of this proposal.
Being able to get information about and contact the developers of
potentially harmful extensions and blocking the ability of malware to
create per-install versions of their extensions that would be difficult for
us to block is what we're trying to solve here. Local file checks just
don't help.

Earlier comments pointed out that enterprises can just block access to the
API which would effectively turn off this feature. Do you think that isn't
good enough to solve the problem?

> On the other hand, I think this proposal is too lenient, because it
> wouldn't solve the problem of search hijacks an unwanted toolbars. The
> mockups for this project suggest that search hijacks and unwanted
> toolbars could still be registered.
> (https://wiki.mozilla.org/Add-ons/FileRegistration/Mockups)
>
> That is, it seems to me that this proposal would have significant
> downsides but not be a major win in terms of the most common add-on
> annoyances.
>

This is a general tool to help combat the prevalence of malware add-ons by
blocking the install of add-ons that we don't know about and giving us the
ability to look at add-ons after the fact to evaluate them for potential
blocklisting or developer outreach. That doesn't mean we can't also work on
specific types of malware. We have already added some tools to mitigate
against search engine hijacking in Firefox.

On Friday, 1 November 2013 16:04:31 UTC, Dave Townsend  wrote:
> Earlier comments pointed out that enterprises can just block access to the
> API which would effectively turn off this feature. Do you think that isn't
> good enough to solve the problem?

I'd say so.  You're asking people to add rules to their firewall in order to solve an application usability issue.  This means that (a) there's going to be a pain point in tracking down the firewall team and getting them to make a change in the first place (always frustrating) and then (b) when someone is cleaning up the firewall and can't work out why a rule is there, and removes it, suddenly your internal-only Firefox addons stop working, and nobody can work out why!

This should be something that users can override.  If my Android phone can let me install applications from anywhere on earth, once I tell it I understand the risks, then my browser should be able to do likewise.  Locking me into a central, single, blesed repository, that I cannot override as a user, is what put me off ever getting an iPhone.  This is _not_ openness.

Andy

On 11/1/13 6:19 AM, Philip Chee wrote:> On 01/11/2013 01:06, Jorge
If they're abandoned you can just register them without changing their
ID. If the original developer wanted to register them and complained to
us, we would need to give him/her the rights to the ID, and then we
would be in case (2).

> 2. Active extensions from authors who aren't interested in supporting
> SeaMonkey - as it their right. Assuming that these authors are still
> using AMO, how do I get my forks registered? Without changing the
> extension ID.

You can ask the developers of the original add-on to add you as a
(possibly hidden) owner or developer of the extension, so you can
register your versions under their ID. They wouldn't need to be hosted
on AMO in order to be registered.

If the developer refuses, then you would have no choice other than using
a different ID.

> An additional usecase:
>
> 3. Extensions that aren't on AMO (due to some disagreements with AMO
> policies or some other dispute) but are hosted on mozdev, or
> extensions-mirror, or code.google.com or github, or bitbucket, or
> sourceforge, or the authors blog. If these authors aren't interested in
> involvement with AMO, forcing them to register their addons are just
> going to make them even more annoyed with AMO.

Yes, that's a problem we can't really avoid if we want to make any
useful changes. This system is designed to minimize the amount of
contact developers have with AMO and the AMO-specific policies that are
usually the reason they host their add-ons elsewhere.

> You have a problem but your proposed cure is worse than the disease.
> Stop listening to the echo chamber and pay more attention to extension
> developers please.

We're in a position where something needs to change. If you have any
alternative to offer other than "let's keep things like they are", this
is the time and place to do it. We're well aware of the impact this will
have on developers, and we're doing our best to make keep it to a minimum.

Jorge

On 11/01/2013 08:55 AM, Dave Townsend wrote:
> On Thu, Oct 31, 2013 at 11:55 PM, Steve Fink <sf...@mozilla.com
> <mailto:sf...@mozilla.com>> wrote:
>
>     The proposal would slow down startup, since all enabled addons
>     will need
>     to be hashed before loading them "for real". (And those hashes would
>     need to be looked up in a local cache of the registry, assuming you
>     don't want to wait on a network hit during startup.)
>
>
> The intention is not to hash the add-ons during startup. We've talked
> about the option of hashing some time later to verify that all the
> installed add-ons are still valid. This does create a way for an
> application on the user's system to get an unknown add-on into Firefox
> but that seems like an ok trade-off against saving startup time.

So as a malware author, I would need to be sure that on first run my
addon disables the check either by adding a whitelist pref, preventing
the API from being called, or blocking that network address; or that it
does its damage then uninstalls itself (or replaces itself with a
registered addon). That's still *some* additional protection, I suppose,
since we can at least detect most of those (at least until the next turn
in the arms race game.)

>  
>
>     An alternative to consider would be to run the analysis on the client
>     side. The code for the analysis could be updated with every Firefox
>     release or more frequently. The perf hit could be mitigated by running
>     the analysis for popular addons on the AMO side, and using the
>     registry
>     sketched out in the proposal for those. Sure, malware could
>     subvert the
>     local analysis, but it could just as easily lie about the content hash
>     used to query the registry. (The client side would still probably want
>     to cache the analysis results across browser restarts, so it'd still
>     need to checksum the file and look up the checksum in a local registry
>     to avoid redoing the analysis during startup.)
>
>
> The malware check itself is not the most important part of this
> proposal. Being able to get information about and contact the
> developers of potentially harmful extensions and blocking the ability
> of malware to create per-install versions of their extensions that
> would be difficult for us to block is what we're trying to solve here.
> Local file checks just don't help.

The benefits of client-side analysis are (1) solving the scaling problem
and (2) providing a fallback for (good) addons that are intentionally
absent from the registry. It sounds like you don't really care about #1,
presumably because you'd be fine with the registry containing lots of
"outdated" entries (as in, entries only validated against old malware
lists.) This makes sense if the primary purposes are contact info and
blacklist-by-default. I still think that #2 is a major deal, because I
imagine that there are many many situations where uploading the full
code forever and having your IP stored forever are unwanted.

#2 is pretty antagonistic to the contact info goal. It still feels to me
like there ought to be some way to gain more contact info without doing
the full current proposal. For example, we could have a registry in
addition to or instead of the proposed registry, where nothing is stored
permanently but the author must respond to the given contact email
address before their hash is added to the registry.

To be clear, I still feel like my objections to the current proposal are
each individually enough to kill it in its current form, and I'd like to
see a response to them. I imagine the people who have put this proposal
together disagree with me. I am personally very sympathetic to attempts
to tighten up the addon ecosystem somewhat, because I get the general
anecdotal impression that unwanted addons are a serious problem -- and
so too is the problem of bad behavior inadvertently triggered by
*wanted* addons, which the contact info aspect of this proposal would
help to address. (And I'd love to have the source code of a large
percentage of the addons used in the field, so that we could check
whether we can remove problematic features without endless deprecation
cycles. But I don't think that's worth the cost of requiring all the
source to be registered.)

I'm also feeling like addon acceptance should be modular, so that the
Mozilla whitelist is one source of known-acceptable addons but
individuals and enterprises could add additional sources of truth
easily. For example, if it were straightforward to set up additional
local whitelist servers. Perhaps the community could stand up additional
ones for specific purposes. Obviously, you'd need to make it hard for
unwanted whitelists to get installed.

To fork the discussion on this towards the technical feasibility (let's assume we decided to go down this path):

1. Storing the files would be a daunting task.

Each file would need to be stored in some sort of key-value database which we don't presently have infrastructure for. If we use sha256 (as the PRD recommends), there's a very likely chance that eventually we'll hit a collision. That means we'd need to be able to do lookups by add-on ID + file path, hash + add-on ID + file path, etc. Every means of lookup would require an additional index (if we use an RDBMS like MySQL, which is what AMO uses now). We could conceivably start using HBase, but I know of only one team that uses it now (perhaps not anymore?) and they don't like it at all.

The infrastructure aside, this would require a non-trivial amount of space. If we're storing hashes for every file for all of time, that's going to get REALLY big very quickly. I don't think it's improbable that this would need a dedicated cluster to be able to store that much data.

2. The bandwidth required would be non-trivial.

Many add-ons contain large numbers of files. We'd need to register every file (you could just rename "malicious_file.js" to "completely_innocent.jpg" and `eval()` it). On the client side, that means pinging the API with hundreds, if not thousands (tens of thousands? more?) of hashes on a regular basis. Hashes are mostly random, so they won't compress well. This means that someone with a few dozen completely legitimate add-ons might get swamped with these multi-megabyte requests to our servers.

What happens if that request fails? We know it will, that's why we've started distributing Firefox with a CDN. The more you're pumping down the wire, the more likely the system is to fail. This issue could be solved by chunking the request, but that does not address the bandwidth issues.

3. Hackability

Sha256 is obviously strong, but in this day and age (especially going forward) it's not inconceivable that an attacker could buy a crapload of Butterfly Labs boxes (or botnet time) and crunch out a malicious file that has the same hash as jQuery or another very common file in add-ons. Countering this would require changes to Firefox to detect, but by the time we respond to the issue, the malicious add-on could have done any number of nefarious things to block whatever fix we deploy.

We could solve this by using a hashing algorithm with less probability of collisions and greater computational requirements, but that won't be a completely future-proof solution. Furthermore, the greater the size of the hash, the harder the above to issues are to solve.

4. Sheer brute force feasibility.

What's to stop an attacker from doing the following:

- Buy time on a botnet
- Create hundreds of thousands of permutations of an obfuscated malicious file and submit it to the automated API with different IDs (from different IPs)
- Distribute a unique piece of add-on malware to each victim

I can't see how we'd be able to seek out and/or blacklist a massive amount of malicious scripts, especially if they're mixed in with a massive amount of legitimate scripts. Munching a piece of JavaScript AST to be undetectably unique is not a hard problem to solve.
_______________________________________________
dev-planning mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-planning

Having a profile-level preference would make this trivially easy to
bypass, and we already have an installation warning that clearly is not
sufficient to deter users from installing malware.

There will be ways to disable this feature, as explained in the spec,
but they won't be as easy to get to.

Jorge

On Fri, Nov 1, 2013 at 10:30 AM, Steve Fink <sf...@mozilla.com> wrote:

>  On 11/01/2013 08:55 AM, Dave Townsend wrote:
>

> On Thu, Oct 31, 2013 at 11:55 PM, Steve Fink <sf...@mozilla.com> wrote:
>
>> The proposal would slow down startup, since all enabled addons will need
>> to be hashed before loading them "for real". (And those hashes would
>> need to be looked up in a local cache of the registry, assuming you
>> don't want to wait on a network hit during startup.)
>>
>
>  The intention is not to hash the add-ons during startup. We've talked
> about the option of hashing some time later to verify that all the
> installed add-ons are still valid. This does create a way for an
> application on the user's system to get an unknown add-on into Firefox but
> that seems like an ok trade-off against saving startup time.
>
>
> So as a malware author, I would need to be sure that on first run my addon
> disables the check either by adding a whitelist pref, preventing the API
> from being called, or blocking that network address; or that it does its
> damage then uninstalls itself (or replaces itself with a registered addon).
> That's still *some* additional protection, I suppose, since we can at least
> detect most of those (at least until the next turn in the arms race game.)
>

You have to get your add-on installed in the first place of course but its
true that once you have code running on the system circumventing this
wouldn't be all that difficult.
It isn't just blacklist by default, it's also gives us a far more flexible
blacklisting capability than we have now allowing us to quickly target
entire classes of add-ons if needed.

#2 is pretty antagonistic to the contact info goal. It still feels to me
> like there ought to be some way to gain more contact info without doing the
> full current proposal. For example, we could have a registry in addition to
> or instead of the proposed registry, where nothing is stored permanently
> but the author must respond to the given contact email address before their
> hash is added to the registry.
>

I know we've gone back and forth over whether to retain copies of the files
or not. The benefits are clear, we get the ability re-check existing
add-ons for new forms of malware as they are found. It could also give
Mozilla a lot more information that we currently have about how prevalent
API use is in extensions in the wild to help us understand the impact of
code changes. Right now we have to rely only on the add-ons on AMO but this
isn't the full picture.

>
> To be clear, I still feel like my objections to the current proposal are
> each individually enough to kill it in its current form, and I'd like to
> see a response to them. I imagine the people who have put this proposal
> together disagree with me. I am personally very sympathetic to attempts to
> tighten up the addon ecosystem somewhat, because I get the general
> anecdotal impression that unwanted addons are a serious problem -- and so
> too is the problem of bad behavior inadvertently triggered by *wanted*
> addons, which the contact info aspect of this proposal would help to
> address. (And I'd love to have the source code of a large percentage of the
> addons used in the field, so that we could check whether we can remove
> problematic features without endless deprecation cycles. But I don't think
> that's worth the cost of requiring all the source to be registered.)
>

The enterprise issue is certainly a problem that might warrant a change to
this proposal but for others I just don't see that the cost of having to
create an AMO account and upload a copy of your add-on (which should be
doable with a simple command line) is in any way onerous and the potential
benefits for users far outweigh it.

>
> I'm also feeling like addon acceptance should be modular, so that the
> Mozilla whitelist is one source of known-acceptable addons but individuals
> and enterprises could add additional sources of truth easily. For example,
> if it were straightforward to set up additional local whitelist servers.
> Perhaps the community could stand up additional ones for specific purposes.
> Obviously, you'd need to make it hard for unwanted whitelists to get
> installed.
>
>

I don't think that that is something enterprises would want to spend time
doing, do you?

On Fri, Nov 1, 2013 at 10:48 AM, Matt Basta <mba...@mozilla.com> wrote:

> To fork the discussion on this towards the technical feasibility (let's
> assume we decided to go down this path):
>
> 1. Storing the files would be a daunting task.
>
> Each file would need to be stored in some sort of key-value database which
> we don't presently have infrastructure for. If we use sha256 (as the PRD
> recommends), there's a very likely chance that eventually we'll hit a
> collision. That means we'd need to be able to do lookups by add-on ID +
> file path, hash + add-on ID + file path, etc. Every means of lookup would
> require an additional index (if we use an RDBMS like MySQL, which is what
> AMO uses now). We could conceivably start using HBase, but I know of only
> one team that uses it now (perhaps not anymore?) and they don't like it at
> all.
>
> The infrastructure aside, this would require a non-trivial amount of
> space. If we're storing hashes for every file for all of time, that's going
> to get REALLY big very quickly. I don't think it's improbable that this
> would need a dedicated cluster to be able to store that much data.
>

I'm not sure why we wouldn't just store the files in a filesystem rather
than a database.

> 2. The bandwidth required would be non-trivial.
>
> Many add-ons contain large numbers of files. We'd need to register every
> file (you could just rename "malicious_file.js" to
> "completely_innocent.jpg" and `eval()` it). On the client side, that means
> pinging the API with hundreds, if not thousands (tens of thousands? more?)
> of hashes on a regular basis. Hashes are mostly random, so they won't
> compress well. This means that someone with a few dozen completely
> legitimate add-ons might get swamped with these multi-megabyte requests to
> our servers.
>

To be clear this proposal doesn't talk about hashing every file, it's a
hash for the whole add-on so if you have 10 add-ons installed it would ping
for 10 hashes.

> What happens if that request fails? We know it will, that's why we've
> started distributing Firefox with a CDN. The more you're pumping down the
> wire, the more likely the system is to fail. This issue could be solved by
> chunking the request, but that does not address the bandwidth issues.
>

In failure or offline the client assumes acceptance.

> 3. Hackability
>
> Sha256 is obviously strong, but in this day and age (especially going
> forward) it's not inconceivable that an attacker could buy a crapload of
> Butterfly Labs boxes (or botnet time) and crunch out a malicious file that
> has the same hash as jQuery or another very common file in add-ons.
> Countering this would require changes to Firefox to detect, but by the time
> we respond to the issue, the malicious add-on could have done any number of
> nefarious things to block whatever fix we deploy.
>
> We could solve this by using a hashing algorithm with less probability of
> collisions and greater computational requirements, but that won't be a
> completely future-proof solution. Furthermore, the greater the size of the
> hash, the harder the above to issues are to solve.
>

Do we think people are really going to go to those lengths just to get an
add-on installed into Firefox? There are probably easier ways to attack a
user's machine.

4. Sheer brute force feasibility.
>
> What's to stop an attacker from doing the following:
>
> - Buy time on a botnet
> - Create hundreds of thousands of permutations of an obfuscated malicious
> file and submit it to the automated API with different IDs (from different
> IPs)
>

I believe there will be a limit on how many add-ons a user can register
over a time period.

On 11/01/2013 10:48 AM, Matt Basta wrote:
> 4. Sheer brute force feasibility.
>
> What's to stop an attacker from doing the following:
>
> - Buy time on a botnet
> - Create hundreds of thousands of permutations of an obfuscated malicious file and submit it to the automated API with different IDs (from different IPs)

> - Distribute a unique piece of add-on malware to each victim
>
> I can't see how we'd be able to seek out and/or blacklist a massive amount of malicious scripts, especially if they're mixed in with a massive amount of legitimate scripts. Munching a piece of JavaScript AST to be undetectably unique is not a hard problem to solve.
>

I don't understand. The proposal is a whitelist, not a blacklist. So if
we can detect the malware, none of these hashes would get registered. If
we can't detect the malware, there's no need to generate permutations of
it. (Well, unless you're worried that we will later detect the malware
and remove that hash.)

Are you just saying that the registry won't solve the malware problem
because the analysis won't work? That's believable.

On 10/31/13 6:38 PM, bre...@gmail.com wrote:
> Well, I guess an apology is in order. I had not envisioned such a way as this for you to mitigate security risks without disabling third party add-ons, so I see now that your rejection of my add-on, AsYouWish[1] from AMO was not a result of arbitrariness.
>
> However, I am concerned that my platform, which allows websites to gain access to Addon SDK privileges upon user approval, may be treated as malware (since sites may be able to use it as such).
>
> At an earlier time, Mozilla felt that enablePrivilege was a fair enough mechanism (e.g., to allow more rapid deployment by developers and avoidance of installation for users such as add-ons cannot provide), and even now, with other third party add-ons, there can be a spectrum of privilege escalation.
>
> For example, I have completed initial work on WebAppFind[2] to allow executables to be associated with file extensions on the desktop (currently Windows only), so that when a user right-clicks "Open With..." or assigns the executable as the default handler for a file on their desktop and double-clicks the file, Firefox will be invoked with command line instructions sent by the executable that my add-on receives, and it will then grant a suitable website the necessary message listening and posting capabilities that will allow it to read and potentially overwrite the contents of the opened file. I think this is a far more circumscribed escalation of privileges than AsYouWish, but I'm not sure whether you would block this from AMO or worse, treat it as malware due to it enabling a malicious (albeit user-approved) website to overwrite the contents of a clicked file.
>
> I would hope you could clarify in plain language what the attempts at "malware" exclusion mean as far as those add-ons which deliberately facilitate an escalation of privileges. I would think that any postMessage communication between websites and add-ons (as is already a part of your SDK API) is likely to be used to provide some form of escalation of privileges, so if you are going to be policing this, I hope you can define a consistent (and hopefully not unduly constraining) policy in this regard.
>
> The web is moving forward with even more dangerous capabilities like user-approved Geo-location, so I hope that efforts for minimization of risk will not unduly hold back an increase of opportunities.
>
> [1] https://github.com/brettz9/asyouwish/
> [2] https://github.com/brettz9/webappfind
>

Your add-on won't be flagged as malware.

I can't be very specific about the rules that we will use to qualify
malware, as they aren't fully written yet, but they would initially
target the forms of malware we know about:
* Impersonation of known developers. There are many malware add-ons that
claim to be built by Adobe or Mozilla, so they don't look suspicious in
the Add-ons Manager.
* Add-ons that through remote scripts hijack Facebook and other social
media accounts. These are generally built as Greasemonkey scripts and
follow certain patterns we should be able to detect.

We're not planning on using this to restrict security-sensitive APIs or
enforce other quality requirements on existing add-ons. Non-AMO
developers should be able to experiment and create potential footguns,
as long as they are properly presented to potential users.

In a nutshell, the malware checks will be aimed at add-ons with obvious
malicious intent.

Jorge

On 10/31/13 7:07 PM, ert...@gmail.com wrote:
> I develop an extension for use on an intranet that has no access to the Internet. Will this affect my extension?
>

No. Failure to contact the API will allow the installation to happen.

Jorge

On 11/1/13 9:45 AM, Dave Townsend wrote:
> On Thu, Oct 31, 2013 at 9:33 PM, Eric Moore <erm...@gmail.com> wrote:
>
>> On Wednesday, October 30, 2013 5:55:21 PM UTC-4, jorgev wrote:
>>> Cross posting to dev.planning, where I originally intended this to be.
>>
>> The proposal describes it as something that would be implemented in
>> Firefox. My concern is what impact this might have on Thunderbird.
>>
>> 1) Would this only be implemented in Firefox or might it actually be
>> implemented in Gecko or some other shared library that forces the
>> Thunderbird developers to support this proposal unless they want to fork
>> and maintain their own version of that component?
>>
>
> Due to the nature of the code this will certainly be implemented
> predominantly in toolkit but it will be done so in a way that allows
> applications to opt-in to it similar to other things that we have added in
> the past like the sideloading opt-in screen and hotfix support.

To add to this, I'm not aware of large malware problems in Thunderbird,
so I suspect that it wouldn't make sense to enable file registration for
this particular application. I can see it applying for SeaMonkey, though.

On AMO the plan is to register all add-ons, regardless of application
compatibility, just in case these applications decide to activate the
client-side portion. So that would cover Thunderbird add-ons on AMO, at
least.

>> 2) The "series of automatic malware checks" might block some Thunderbird
>> add-ons because whoever designed the malware checks is focused strictly on
>> Firefox.
>>
>
> I don't know the specifics of the checks but I believe it is more about
> checking for the existance of actual binary malware that the add-on might
> try to execute. This would apply equally to Thunderbird add-ons as well as
> Firefox add-ons. Regardless I'm sure the AMO team will be open to make
> changes if this became a problem.

The kinds of code checks we do on AMO are generally
application-agnostic. When they are biased towards Firefox it just means
that the check won't apply to Thunderbird. Since we've been doing this
sort of checks for a few years without any incidents for Thunderbird
add-ons (that I can recall), I don't expect any big problems to come out
of this new set of checks we'll create. If they do we'll deal with them,
of course.

Jorge

> Do we think people are really going to go to those lengths just to get an add-on installed into Firefox? There are probably easier ways to attack a user's machine.

If crunching numbers a single time to produce an undetectable add-on that we can't block because it matches, say, Firebug or Adblock's hash and can be installed on large numbers of users machines is possible, attackers are definitely going to do it. Couple that with a DNS attack or a Google bomb to target users looking to install legitimate add-ons and you've just found a sneaky way into users' machines.

We live in an age where leaked passwords hashed and salted using HMAC trigger mayhem; we shouldn't underestimate the connivery of an attacker just because a potential attack sounds implausible.

4. Sheer brute force feasibility.
>
> What's to stop an attacker from doing the following:
>
> - Buy time on a botnet
> - Create hundreds of thousands of permutations of an obfuscated malicious
> file and submit it to the automated API with different IDs (from different
> IPs)
>

I believe there will be a limit on how many add-ons a user can register
over a time period.

> - Distribute a unique piece of add-on malware to each victim
>
> I can't see how we'd be able to seek out and/or blacklist a massive amount
> of malicious scripts, especially if they're mixed in with a massive amount
> of legitimate scripts. Munching a piece of JavaScript AST to be
> undetectably unique is not a hard problem to solve.
>
>

Right, but whether the analysis is server-side or client-side doesn't
affect that benefit very much.

>
>     #2 is pretty antagonistic to the contact info goal. It still feels
>     to me like there ought to be some way to gain more contact info
>     without doing the full current proposal. For example, we could
>     have a registry in addition to or instead of the proposed
>     registry, where nothing is stored permanently but the author must
>     respond to the given contact email address before their hash is
>     added to the registry.
>
>
> I know we've gone back and forth over whether to retain copies of the
> files or not. The benefits are clear, we get the ability re-check
> existing add-ons for new forms of malware as they are found. It could
> also give Mozilla a lot more information that we currently have about
> how prevalent API use is in extensions in the wild to help us
> understand the impact of code changes. Right now we have to rely only
> on the add-ons on AMO but this isn't the full picture.

Do we know a rough distribution of reasons for why addon authors host
them on non-AMO sites? (With the goal of estimating how many of these
addons would be willing to go through the registry.)

>  
>
>
>     To be clear, I still feel like my objections to the current
>     proposal are each individually enough to kill it in its current
>     form, and I'd like to see a response to them. I imagine the people
>     who have put this proposal together disagree with me. I am
>     personally very sympathetic to attempts to tighten up the addon
>     ecosystem somewhat, because I get the general anecdotal impression
>     that unwanted addons are a serious problem -- and so too is the
>     problem of bad behavior inadvertently triggered by *wanted*
>     addons, which the contact info aspect of this proposal would help
>     to address. (And I'd love to have the source code of a large
>     percentage of the addons used in the field, so that we could check
>     whether we can remove problematic features without endless
>     deprecation cycles. But I don't think that's worth the cost of
>     requiring all the source to be registered.)
>
>
> The enterprise issue is certainly a problem that might warrant a
> change to this proposal but for others I just don't see that the cost
> of having to create an AMO account and upload a copy of your add-on
> (which should be doable with a simple command line) is in any way
> onerous and the potential benefits for users far outweigh it.

My objections were: (1) subpoenas and privacy, (2) organizational
policies against exposing internal code, (3) scaling, and (4) perf. We
were discussing perf (startup costs vs subverting the restrictions by
allowing a first run.) The developer friction point is important, but I
suspect it can be managed adequately.

>  
>
>
>     I'm also feeling like addon acceptance should be modular, so that
>     the Mozilla whitelist is one source of known-acceptable addons but
>     individuals and enterprises could add additional sources of truth
>     easily. For example, if it were straightforward to set up
>     additional local whitelist servers. Perhaps the community could
>     stand up additional ones for specific purposes. Obviously, you'd
>     need to make it hard for unwanted whitelists to get installed.
>
>
> I don't think that that is something enterprises would want to spend
> time doing, do you?

Depends on how juicy the carrot is. Enterprise IT departments really
don't like fixing problems caused by their users installing malware, and
having the Mozilla registry available to help with the problem is a big
plus from that perspective. If this just involved hosting a JSON file or
something, I could imagine enterprises very much liking this. (Though
perhaps it'd need to be integrated with whatever Enterprise IT
Architecture Synergy Management Command and Control Server bullshit they
already use.)

One of the most important goals for the admin tools in this system is to
be able to monitor and deter this sort of spamming. We should be able to
detect mass registrations coming from a specific account or IP address /
IP range in order to look into it and see if it's legitimate or not.
Having the malicious files will also allow us to add checks for them so
similar patterns aren't allowed in the future, hopefully making Firefox
a much less attractive attack vector for malware authors.

On Nov 1, 2013, at 1:57 PM, Jorge Villalobos <jo...@mozilla.com> wrote:

> I think that's a good idea, and I'll give it some more thought. One
> problem is that we need to set some bar of legitimacy for the developers
> we're handing out the certs to, since it needs to be much higher than
> the one we have for registration. Otherwise we would be back at where we
> are now. It should be possible to design it in a way we can drop
> specific certs if we learn they are being used for malicious purposes.

That’s how most of our crypto infrastructure works.  We don’t need to reinvent the wheel here, we can just block specific certs, and (as a more nuclear option) distrust any roots that repeatedly provide certs to bad actors.  There’s no need for us to wade into the world of providing code signing certs.

> There's also a problem of perception, where this would look like big
> businesses would be able to "buy" an exception to the rules that apply
> to the majority. We would need to make the scope of this very clear to
> avoid confusion.

I don’t think we should look at the file registration service as a rule, but as a mechanism to comply with a rule that all add-ons must be trackable and blockable through some Mozilla-controllable mechanism.  If a file is registered with AMO, we can block/revoke that hash.  If it’s a signed XPI, we can block the cert for all installs (if the blocklist isn’t sufficient here).  If the point is to protect users and defend against bad actors, I don’t think it’s necessary for us to get all files.

As for an exception to the rules, I’d actually argue that blocking a cert is a much more effective mechanism than blocking a file hash, since I can create infinite free AMO accounts, but every cert that gets picked off costs me a couple of hundred dollars.  My prediction is that bad actors will look to trick the automated tests through code obfuscation rather than spend cash on a large set of certs.  If that leaves otherwise good actors with the option of buying a cert (or, more likely, using a cert they already have) and having a minimal amount of overhead, so much the better.

— Mike

On 11/1/13 12:55 AM, Steve Fink wrote:
> This system involves permanently storing IP addresses and the full text
> of all addon files. That's a dangerous pile of data to be sitting on. Do
> we want to handle subpoenas for IP addresses known to belong to
> organizations and individuals under investigation? Do we want to risk a
> security breach exposing a whole lot of data that doesn't belong to us?

The collection of IP addresses is meant to fight spamming of the system,
which is a scenario that Matt Basta just brought up on a different
response. We want to able to detect multiple account registration and
multiple file registration from the same location, in order to deter
system abuse.

This doesn't require us to maintain IP address information permanently,
so we can work out a retention policy that allows us to continue to
benefit from its advantages while storing IP addresses for as little
time as possible. The document doesn't contemplate this, so thank you
for bringing it up.

> Some organizations will have policies that forbid exposing these data
> (in particular, the addon files) to external third parties, no matter
> how convincingly they promise to take care of them. We would lose those
> users unless we came up with a better mechanism for local registration.
> But such a mechanism might defeat part of the desired benefits of this
> proposal (eg having better contact info for addon authors.)

The spec already mentions a few ways for enterprises to bypass the
system if needed, and Gijs proposed an interesting idea where we would
be able to give them signing certs for their internal add-ons. There
will definitely be ways to deal with this for enterprises, we haven't
ignored their requirements.

> I don't know what the automatic malware analysis is, but every similar
> analysis that I've ever worked on has required constant change,
> especially when it's exposed as a tool in the arms race against people
> motivated to subvert it (eg malware authors.) I'm skeptical that we
> could rerun the analysis on the entire registry, every time the analysis
> changes. The registry will at least have to track what version of the
> analysis was run for a given entry, and the browser UI would need to
> accept a registered addon becoming unregistered at any time.

We've contemplated those situations and we believe we can support them.
We already have ways to search the source code of all AMO add-ons for
specific code patterns. The magnitude of non-AMO add-ons is unknown,
though, but I believe the scalability of these tools is mostly a matter
of hardware.

> The proposal would slow down startup, since all enabled addons will need
> to be hashed before loading them "for real". (And those hashes would
> need to be looked up in a local cache of the registry, assuming you
> don't want to wait on a network hit during startup.)

As Dave mentioned, we won't do a check that blocks startup.

> An alternative to consider would be to run the analysis on the client
> side. The code for the analysis could be updated with every Firefox
> release or more frequently. The perf hit could be mitigated by running
> the analysis for popular addons on the AMO side, and using the registry
> sketched out in the proposal for those. Sure, malware could subvert the
> local analysis, but it could just as easily lie about the content hash
> used to query the registry. (The client side would still probably want
> to cache the analysis results across browser restarts, so it'd still
> need to checksum the file and look up the checksum in a local registry
> to avoid redoing the analysis during startup.)

This would only address part of the problem, as Dave also pointed out.
Knowing what is out there and how to address is also a very big part of it.

Jorge

On Nov 1, 2013, at 2:17 PM, Matt Basta <mba...@mozilla.com> wrote:

>> Do we think people are really going to go to those lengths just to get an add-on installed into Firefox? There are probably easier ways to attack a user's machine.
>

> If crunching numbers a single time to produce an undetectable add-on that we can't block because it matches, say, Firebug or Adblock's hash and can be installed on large numbers of users machines is possible, attackers are definitely going to do it. Couple that with a DNS attack or a Google bomb to target users looking to install legitimate add-ons and you've just found a sneaky way into users' machines.

The amount of time it would take to generate a collision would be very much not free, even on a botnet, and it’d be trivial to publish an update with a different hash.  I’d assume that the “block” response could be “block this version but grab the update” in this model.

Assuming we make the hashes reasonably non-trivial to calculate, I think the deck will be firmly stacked against this being an economically viable attack vector.

— Mike

On Oct 31, 2013, at 4:56 PM, Jorge Villalobos <jo...@mozilla.com> wrote:

> On 10/31/13 11:16 AM, Mike Connor wrote:
>>
>> On Oct 31, 2013, at 12:57 PM, Jorge Villalobos <jo...@mozilla.com> 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.

I’m curious why you think the use-case of installing old versions of add-ons would be “massive” since it seems like a pretty small corner case.  I doubt either of us have data, but the idea that a significant number of users are archiving old versions seems somewhat far-fetched.  Some do, for sure, but that doesn’t necessarily mean it’s a use-case we need to protect.  I’m actually of the opinion that we would lose very little for the vast majority of users if we stop supporting unmaintained add-ons.

For this new model to be effective I believe we need to raise the bar on what we allow to be installed.  Grandfathering everything doesn’t really solve that.

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

I don’t know the nature of the issues you’ve experienced previously, but what you’re talking about here is just an automated repack system.  We do those reliably for localized and custom partner builds already, we should be able to do the same thing for add-ons.

— Mike

On 11/1/13 9:34 AM, J. Ryan Stinnett wrote:
> Jorge Villalobos wrote:
>> 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.
>
> Perhaps it is because I am newer here, but part of what made it so hard for me to read your initial post was that I personally do not perceive any malware risk, so it came across as many developer restrictions for a threat that did not even seem to be real.
>
> I would suggest adding more information about what Mozilla considers to be "malware" and how prevalent it seems to be today.

You're right, and that's partly intentional. There are certain risks
that I'd rather not mention publicly because I don't want to encourage
them to happen.

One thing I can point out (and will probably add to the doc) is the
amount of malware add-ons we block:
https://addons.mozilla.org/firefox/blocked/. They're all labeled
"(malware)". As you can see, we block at least a few instances per
month, and those are only the ones we hear about. They are constantly
mutating and reappearing, and there's very little we can do now to
prevent that.

We know this is a problem for Facebook and Google, and we have had
conversations with them about dealing with some of these problems.

> Jorge Villalobos wrote:
>> If a user installs a file that is not registered, a message will be shown
>> explaining that the file can’t be installed for their protection.
>
> It looks as if there is no way to get around the decision received from the registration service once a check has been made.  Why is that?  Alerting the user that Mozilla considers an add-on to be unsafe seems okay, but it just does not seem possible to truly know whether *each user* would agree the extension is unsafe if they knew what it was doing.  
>
> Could there be a button to continue anyway?  Or at least a link to some documentation explaining how to white list IDs?

The UX design for this hasn't even started, so I can't really say how it
will look. However, we don't want it to be easy to disable. We want
knowledgeable people to be able to override it because they're either
developers or have other environmental restrictions (like in
enterprises), but this will only be effective if the majority of users
keep it turned on.

>
> Jorge Villalobos wrote:
>> ...you will have the option of just blocking the API in your internal
>> network. API failures will allow the add-on to be installed.
>
> Do you plan to publish the host names of the servers used in this process so that they can easily be blocked for people / organizations who choose this option?  Perhaps they could be part of the same documentation that I was suggesting above that would explain how to white list.

Like with the blocklist, this will just be one URL you'll need to block,
so it should be really easy to do.

> Jorge Villalobos wrote:
>> So, you're suggesting to have signing in addition to the hashes, as a
>> way to opt-out?
>
> I do think this is valuable to explore as a lighter-weight solution for any developers that do not feel comfortable handing over their code.  As you mentioned earlier, supporting signing *only* seems bad, since it would lead to many broken extensions.  But a "dual path" approach that also made signing available as an option seems more developer friendly.  I hope that this approach can be evaluated.
>
> - Ryan

Yes, I agree this is a nice idea. We'll definitely give it more thought.

Jorge

On 11/01/2013 02:49 PM, Jorge Villalobos wrote:
> On 11/1/13 9:34 AM, J. Ryan Stinnett wrote:
>> Do you plan to publish the host names of the servers used in this process so that they can easily be blocked for people / organizations who choose this option?  Perhaps they could be part of the same documentation that I was suggesting above that would explain how to white list.
> Like with the blocklist, this will just be one URL you'll need to block,
> so it should be really easy to do.

Wouldn't it be an HTTPS URL and therefore harder to block?

http://mxr.mozilla.org/mozilla-central/source/browser/app/profile/firefox.js#53
is:

  pref  <http://mxr.mozilla.org/mozilla-central/ident?i=pref>("extensions.blocklist.url","https://addons.mozilla.org/blocklist/3/...");

That seems like the network would need to have addons.mozilla.org
black-holed with a fake DNS entry, or all of the IP addresses it could
resolve to would need to be blacklisted, or the Enterprise would need to
be actively MITM-ing all SSL connections on the network.  The last one
is not something we would want to encourage people to do.

I'm assuming a non-addons.mozilla.org domain would be used with distinct
IP addresses so the organization wouldn't have to block AMO entirely?

Andrew

I'm not sure if the PRD mentions this, but while it should allow the installation to happen, there should be a warning that the add-on can't be verified.

Excellent, thanks for the reply and very good to see what appears to me to be a lot of effort toward balancing security with the needs of companies, experimenters, etc.

In other words, this "feature" will not be user-friendly.  Instead, it
will be user-hostile.


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

I normally disconnect from the Internet for all software installations,
except where only stub installers requiring further downloads are
involved.  If I can install a non-registered extension while
disconnected from the Internet, will I be able to use it -- will my
Mozilla application have the extension's functionality -- after I
reconnect to the Internet?

On 11/1/2013 11:49 AM, Jorge Villalobos wrote [in part]:

>
> One thing I can point out (and will probably add to the doc) is the
> amount of malware add-ons we block:
> https://addons.mozilla.org/firefox/blocked/. They're all labeled
> "(malware)". As you can see, we block at least a few instances per
> month, and those are only the ones we hear about. They are constantly
> mutating and reappearing, and there's very little we can do now to
> prevent that.

The Blocklist page only lists plugins.  Are you planning to include
plugins in this registration scheme?

If the scheme applies only to extenstions, where is the list of
extensions blocked in the past?

Why not merely make AMO the repository of analyzed, approved, safe
extensions?  Then, you could "advertise" AMO as the place of safety.
Those of us who collect extensions from other sources would not lose
that ability.

How far are you planning to go to protect users?  After all, Mozilla
cannot stop us from installing non-Mozilla applications that do not
directly interface with Mozilla applications.  Just give us a source of
"good" applications without interfering with our ability to choose other
sources.

On 11/1/2013 5:35 PM, David E. Ross wrote:
> On 11/1/2013 11:49 AM, Jorge Villalobos wrote [in part]:
>
>> One thing I can point out (and will probably add to the doc) is the
>> amount of malware add-ons we block:
>> https://addons.mozilla.org/firefox/blocked/. They're all labeled
>> "(malware)". As you can see, we block at least a few instances per
>> month, and those are only the ones we hear about. They are constantly
>> mutating and reappearing, and there's very little we can do now to
>> prevent that.
> The Blocklist page only lists plugins.

No, it also includes extensions. TornTV (the first one listed currently)
is one example.

On 31/10/2013 23:56, Jorge Villalobos wrote:
> On 10/31/13 3:35 PM, Gijs Kruitbosch wrote:
>> On 31/10/13, 22:30 , a.very....@gmail.com wrote:
>>> 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.
>>>
>> How do we envision this working? For it to work for people in enterprise
>> situations, it having a click-through UI is a no-no. As an add-on dev,
>> I'd get pretty tired of having to click through it all the time. If
>> there's no warning at all, I'd imagine malware will have started using
>> it as a startup parameter for Firefox before it's been through the 12
>> weeks from nightly to release...
>>
>> ~ Gijs
>
> There would be a keyboard shortcut, of course. At the very least
> something like "Left arrow + Return", which is something that a
> developer should be able to do without even thinking about it.
>
> Jorge

Speaking with my extension developer hat on: this would get very old
very quickly. Having to click/keyboard through a warning every time I
restart (which happens a lot when developing, and at least daily even
when not) would be extremely irritating, no matter how easy it is to do.

I suggest dropping the persistent nag screen and putting the switch on
the other side of the airtight hatchway: anybody with write access to
the Firefox application folder can already do whatever the heck they
want (including replacing Firefox with a version that silently doesn't
check add-ons), so we may just as well use a file in that folder to turn
development mode on or off, and we won't lose anything by not prompting
on every startup.

Or similarly, the proposal already specifies that anybody with write
access to /etc can disable the checking without getting a nag screen
(via /etc/hosts, or the networking config, or editing the firewall,
or...), so we could use a file in there too.

(We'd also need a per-profile preference to ignore the global setting
and turn checking back on, to give the user some way to override it
without needing write permission to the folder.)

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

Hi,

I have another use case which isn't clearly described by the current doc.

I have an English version of Firefox/Thunderbird installed with
additional language packs from
<http://ftp.mozilla.org/pub/mozilla.org/%APP%/%CHANNEL%/%VERSION%/%OS%/xpi/>.

After each update I have to manually add the language packs again.
Those files are created by Mozilla but aren't published to amo.

It would be a real shame if it wouldn't be possible anymore to add
different languages to your installation.

Onno

Dave Townsend <dtow...@mozilla.com> wrote:
> I don't know the specifics of the checks but I believe it is more about
> checking for the existance of actual binary malware that the add-on might
> try to execute.

This implies that Mozilla's malware scanner would be better than
Windows anti-virus software run on the users' computers.

Why would Mozilla's scanner be better for Windows than anti-virus
solutions that users are already supposed to be using?
Is there a big need to run Mac & Linux malware scans and end users
just don't have anti-virus software installed?

> The intention is not to hash the add-ons during startup. We've talked about
> the option of hashing some time later to verify that all the installed
> add-ons are still valid. This does create a way for an application on the
> user's system to get an unknown add-on into Firefox but that seems like an
> ok trade-off against saving startup time.

Wouldn't that mean that by the time the check runs, the malware has
already had the chance to do its misdeeds and to cover its tracks?

Also, the notion that startup might be the first time Firefox sees an
add-on suggests that the add-on hasn't been installed as an .xpi
through Firefox itself but has been dropped on the system by an .exe.
This means that arbitrary malicious code (the dropper/installer .exe)
has already had a chance to run.

Since as a technical matter the solution doesn't address malicious
code in the dropper/installer .exe and as a policy matter the solution
doesn't address unwanted toolbars or search hijacks created by known
companies (as opposed to criminals in the shadows), I think it would
be helpful to have a clearer statement of the threat model to
understand what threat the proposed solution would address.

> The malware check itself is not the most important part of this proposal.
> Being able to get information about and contact the developers of
> potentially harmful extensions and blocking the ability of malware to
> create per-install versions of their extensions that would be difficult for
> us to block is what we're trying to solve here.

If the malware check isn't the most important part and tracing
software to developers is the important part, is there a reason why a
solution like the OS X default mode wouldn't work? That is, instead of
requiring developers to disclose software to Mozilla ahead of time,
would it not be sufficient to require developers to sign the software
with a key that's registered with Mozilla together with contact info
and that Mozilla can revoke?

>> So I think it would be a very bad idea to proceed with this plan
>> without solving the enterprise deployment concerns before proceeding.
>> (That is, proceeding and maybe solving the enterprise concerns later
>> would mean the damage would be done by the times of the solution
>> arrives.)
>
>
> Earlier comments pointed out that enterprises can just block access to the
> API which would effectively turn off this feature. Do you think that isn't
> good enough to solve the problem?

I think it's not good enough, because it means that the part of the
organization that handles Firefox deployment has to coordinate with
the part of the organization that manages all firewalls. Anecdotes
suggest that it's notoriously difficult to get firewall changes done
organization-wide. Moreover, there might not even be
organization-managed firewalls for remote employees or laptops that
travel outside the organization's internal network.

One option would be making ESR not have this feature, but that would
mean telling organizations that otherwise would be OK with running
up-to-date software to go run out-of-date (+ sec-critical backports)
software.

> This is a general tool to help combat the prevalence of malware add-ons by
> blocking the install of add-ons that we don't know about and giving us the
> ability to look at add-ons after the fact to evaluate them for potential
> blocklisting or developer outreach. That doesn't mean we can't also work on
> specific types of malware. We have already added some tools to mitigate
> against search engine hijacking in Firefox.

As noted, the mockups clearly suggest that unwanted toolbars and
search hijacks would not the categorized as "malware". What's the
reason for not trying to eradicate unwanted toolbars and search
hijacks as part of *this* initiative? If the answer is that it
wouldn't work because of reason X, why wouldn't reason X also make
this solution not work for the extensions that are categorized as
"malware"?

--
Henri Sivonen
hsiv...@hsivonen.fi
http://hsivonen.fi/

Hi,

read the thread now. I ignored it based on the subject, btw, didn't seem
to affect anything in real life from just glancing at that.

I'd like to get langpacks excluded. Maybe we need to make their
abilities to do stuff more robustly checked, but for a localizer wanting
to test their work, this is really cumbersome. Note, the default config
of those might even fail the malware checks, as the default identifies
the author as "mozilla.org".

For non-l10n questions:

We'd need developers to grant us a license to their code, right? Do we
know for how many add-ons we'd actually need a license agreement that's
not covered by the EULA of the add-on?

I think that the current proposals for developers and internal org
add-ons are too course. The proposal seems to expose them to malware
just for the sake of their own development or deployment.

I think that blocking the install is too hard for non-registered
add-ons. A consistent UI that encourages users to uninstall
non-registered add-ons might be all we need to get developers to
register voluntarily.

Also, the "just break the network" path seems to be easy to get to for
malware installed by .exe installers on windows, at least. Or at least
be open to social engineering as much as dismissing a non-registered
add-on UI.

Axel

"Official" opt-out by blocking the network/DNS/etc during install is both uncomfortable (yet can be induced also by malware) and also logically inconsistent since it could be considered a temporary and valid network state, and users don't know what to expect when the network is back on (i.e. would the addon get disabled or not).

Also, as noted earlier, a central repo with so much data is ripe for abuse from various vectors (official of otherwise). We could have as many mechanisms in place to reduce the risk, but the risk is still there.

A voluntary one is reasonable, as is AMO in its current state, but a mandatory one is certain to raise quite a bit of hostility for the idea, both from enterprises but also from those with privacy concerns, of which Mozilla surely is one of. Collecting data on every developer as a mandatory step for not rejecting her addon falls also into this category.

I think that the current status-quo where plugins/apps/addons could either be opted-in voluntarily by the developer (signing/whitelist/etc, without getting into the technical details), or spawn a clear yet manageable message about the dangers of such action is the maximum we should consider.

-avih

On Mon, Nov 4, 2013 at 1:20 AM, Henri Sivonen <hsiv...@hsivonen.fi> wrote:

> Dave Townsend <dtow...@mozilla.com> wrote:
> > I don't know the specifics of the checks but I believe it is more about
> > checking for the existance of actual binary malware that the add-on might
> > try to execute.
>
> This implies that Mozilla's malware scanner would be better than
> Windows anti-virus software run on the users' computers.
>

I was mistaken on this, there are other checks going on as Jorge mentioned
earlier.

> > The intention is not to hash the add-ons during startup. We've talked
> about
> > the option of hashing some time later to verify that all the installed
> > add-ons are still valid. This does create a way for an application on the
> > user's system to get an unknown add-on into Firefox but that seems like
> an
> > ok trade-off against saving startup time.
>
> Wouldn't that mean that by the time the check runs, the malware has
> already had the chance to do its misdeeds and to cover its tracks?
>

We hash and check the add-on at install time so checks at startup are only
useful to detect the case where something already running on the user's
computer has changed an add-on's files.

> Also, the notion that startup might be the first time Firefox sees an
> add-on suggests that the add-on hasn't been installed as an .xpi
> through Firefox itself but has been dropped on the system by an .exe.
> This means that arbitrary malicious code (the dropper/installer .exe)
> has already had a chance to run.
>

> Since as a technical matter the solution doesn't address malicious
> code in the dropper/installer .exe and as a policy matter the solution
> doesn't address unwanted toolbars or search hijacks created by known
> companies (as opposed to criminals in the shadows), I think it would
> be helpful to have a clearer statement of the threat model to
> understand what threat the proposed solution would address.
>

I think the point is that this can address unwanted toolbars and search
hijacks, it is an extension to the existing blocklisting capabilities that
we have in place that make it easier for us to control the spread of bad
add-ons.

> > The malware check itself is not the most important part of this proposal.
> > Being able to get information about and contact the developers of
> > potentially harmful extensions and blocking the ability of malware to
> > create per-install versions of their extensions that would be difficult
> for
> > us to block is what we're trying to solve here.
>
> If the malware check isn't the most important part and tracing
> software to developers is the important part, is there a reason why a
> solution like the OS X default mode wouldn't work? That is, instead of
> requiring developers to disclose software to Mozilla ahead of time,
> would it not be sufficient to require developers to sign the software
> with a key that's registered with Mozilla together with contact info
> and that Mozilla can revoke?
>

It's the difference between being able to stop an attach before it starts
versus having to clean up after many users have been attacked.

> > This is a general tool to help combat the prevalence of malware add-ons
> by
> > blocking the install of add-ons that we don't know about and giving us
> the
> > ability to look at add-ons after the fact to evaluate them for potential
> > blocklisting or developer outreach. That doesn't mean we can't also work
> on
> > specific types of malware. We have already added some tools to mitigate
> > against search engine hijacking in Firefox.
>
> As noted, the mockups clearly suggest that unwanted toolbars and
> search hijacks would not the categorized as "malware". What's the
> reason for not trying to eradicate unwanted toolbars and search
> hijacks as part of *this* initiative? If the answer is that it
> wouldn't work because of reason X, why wouldn't reason X also make
> this solution not work for the extensions that are categorized as
> "malware"?
>

Which mockups are you referring to here?

Is there a bugzilla.mozilla.org bug report for this change?  If so, what
is the bug number?

On 11/1/13 6:30 PM, David E. Ross wrote:
> On 11/1/2013 11:04 AM, Jorge Villalobos wrote:
>> On 10/31/13 7:07 PM, ert...@gmail.com wrote:
>>> I develop an extension for use on an intranet that has no access to the Internet. Will this affect my extension?
>>>
>>
>> No. Failure to contact the API will allow the installation to happen.
>>
>> Jorge
>>
>
> I normally disconnect from the Internet for all software installations,
> except where only stub installers requiring further downloads are
> involved.  If I can install a non-registered extension while
> disconnected from the Internet, will I be able to use it -- will my
> Mozilla application have the extension's functionality -- after I
> reconnect to the Internet?

There will be a regular check for add-on registration, so it would be
disabled (or removed) eventually. If you don't want registration to
apply to you at all, the easiest way would be to block the URL used for
the registration API.

Jorge

On 11/1/13 12:43 PM, Mike Connor wrote:
>
> On Oct 31, 2013, at 4:56 PM, Jorge Villalobos <jo...@mozilla.com> wrote:
>
>> On 10/31/13 11:16 AM, Mike Connor wrote:
>>>
>>> On Oct 31, 2013, at 12:57 PM, Jorge Villalobos <jo...@mozilla.com> 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.
>
> I’m curious why you think the use-case of installing old versions of add-ons would be “massive” since it seems like a pretty small corner case.  I doubt either of us have data, but the idea that a significant number of users are archiving old versions seems somewhat far-fetched.  Some do, for sure, but that doesn’t necessarily mean it’s a use-case we need to protect.  I’m actually of the opinion that we would lose very little for the vast majority of users if we stop supporting unmaintained add-ons.
>
> For this new model to be effective I believe we need to raise the bar on what we allow to be installed.  Grandfathering everything doesn’t really solve that.

Add-ons can have a fairly long shelf life. They can be abandoned for
years without their users noticing a problem. Having compatibility on by
default means that users won't notice until the add-on breaks.

And we're not only talking about old add-ons. We would be forcing all
add-on developers to produce new versions of their add-ons to support a
system where signatures are required, and then expect all users to
update to those versions. I think this would introduce a lot of friction
in the transition to the new system.

>> 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.
>
> I don’t know the nature of the issues you’ve experienced previously, but what you’re talking about here is just an automated repack system.  We do those reliably for localized and custom partner builds already, we should be able to do the same thing for add-ons.
>
> — Mike

I can assure you it hasn't worked well when we've had to repack hundreds
of add-ons in the past. I'd rather avoid doing something like this when
the results have been far from ideal.

Jorge

That's one of the possible overrides we're looking into, which is having
a locked pref with an ID whitelist. These prefs can only be changed in
the installation directory.

Jorge

On 11/4/13 3:20 AM, Henri Sivonen wrote:
> Dave Townsend <dtow...@mozilla.com> wrote:
>> I don't know the specifics of the checks but I believe it is more about
>> checking for the existance of actual binary malware that the add-on might
>> try to execute.
>
> This implies that Mozilla's malware scanner would be better than
> Windows anti-virus software run on the users' computers.
>
> Why would Mozilla's scanner be better for Windows than anti-virus
> solutions that users are already supposed to be using?
> Is there a big need to run Mac & Linux malware scans and end users
> just don't have anti-virus software installed?

While we'll probably do a virus check in extensions with binaries, the
majority of checks will be focused on malicious JavaScript patterns. Our
knowledge of malicious add-ons in the wild gives us a much better chance
of detecting a malicious add-on than any general antivirus tool.

>> The intention is not to hash the add-ons during startup. We've talked about
>> the option of hashing some time later to verify that all the installed
>> add-ons are still valid. This does create a way for an application on the
>> user's system to get an unknown add-on into Firefox but that seems like an
>> ok trade-off against saving startup time.
>
> Wouldn't that mean that by the time the check runs, the malware has
> already had the chance to do its misdeeds and to cover its tracks?
>
> Also, the notion that startup might be the first time Firefox sees an
> add-on suggests that the add-on hasn't been installed as an .xpi
> through Firefox itself but has been dropped on the system by an .exe.
> This means that arbitrary malicious code (the dropper/installer .exe)
> has already had a chance to run.
>
> Since as a technical matter the solution doesn't address malicious
> code in the dropper/installer .exe and as a policy matter the solution
> doesn't address unwanted toolbars or search hijacks created by known
> companies (as opposed to criminals in the shadows), I think it would
> be helpful to have a clearer statement of the threat model to
> understand what threat the proposed solution would address.

We can't effectively stop an EXE running locally with admin privileges.
We can try to make it harder for these installers to inject malware into
Firefox, but a sufficiently determined attacker will find a way. We're
trying to block the less sophisticated attacks (which we believe are
most of them) and prevent other types of attack that we know are
possible but aren't happening widely (as far as we know).

Unwanted toolbar installs is something we already deal with at a policy
level and using blocklisting as the hammer, and it has yielded positive
results so far.

>> The malware check itself is not the most important part of this proposal.
>> Being able to get information about and contact the developers of
>> potentially harmful extensions and blocking the ability of malware to
>> create per-install versions of their extensions that would be difficult for
>> us to block is what we're trying to solve here.
>
> If the malware check isn't the most important part and tracing
> software to developers is the important part, is there a reason why a
> solution like the OS X default mode wouldn't work? That is, instead of
> requiring developers to disclose software to Mozilla ahead of time,
> would it not be sufficient to require developers to sign the software
> with a key that's registered with Mozilla together with contact info
> and that Mozilla can revoke?

The malware check is also important and necessary. I responded to the
certificate proposals in other replies on this thread.
I don't believe these toolbars are malware if they disclose their
purpose clearly and can be easily removed by users. We have a set of
guidelines they need to follow
(https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Add-on_guidelines)
in order to not be blocklisted. We have blocked many of them in the past
and will continue to do so.

One of the main problems we've had when dealing with these toolbars is
the lack of information we have about their developers, or even their
add-on ID. Some have resorted to randomizing their add-on ID, for
various reasons, one of them probably to avoid detection by us. This
system will help us with these problems, provided the developers don't
resort to subverting the entire system (and in that case we can possibly
resort to other means of escalation, since these are for the most part
real companies).

So, this proposal will help us in dealing with these add-ons, but the
malware checks won't. Determining whether a greyware toolbar add-on is
within our policies or not requires a more cautious look at what it does
and we won't block all of them by default.

Jorge

There aren't any bugs for this at the moment.

Jorge

On 2013-11-04 3:48 PM, Jorge Villalobos wrote:
> On 11/1/13 12:43 PM, Mike Connor wrote:
>>
>> I’m curious why you think the use-case of installing old versions of add-ons would be “massive” since it seems like a pretty small corner case.  I doubt either of us have data, but the idea that a significant number of users are archiving old versions seems somewhat far-fetched.  Some do, for sure, but that doesn’t necessarily mean it’s a use-case we need to protect.  I’m actually of the opinion that we would lose very little for the vast majority of users if we stop supporting unmaintained add-ons.
>>
>> For this new model to be effective I believe we need to raise the bar on what we allow to be installed.  Grandfathering everything doesn’t really solve that.
> Add-ons can have a fairly long shelf life. They can be abandoned for
> years without their users noticing a problem. Having compatibility on by
> default means that users won't notice until the add-on breaks.

None of this really answers my concern, which is that this use-case
matters to relatively few users, and thus doesn't merit weakening the
strength of the system.  From what I've seen, the most-used add-ons
still get updated on a somewhat regular basis.  I'd like to see an
evaluation of the tradeoffs (stronger system for all users vs.
disruption for a minority).

Have we used FHR data to identify the real-world stats on these tradeoffs?

> And we're not only talking about old add-ons. We would be forcing all
> add-on developers to produce new versions of their add-ons to support a
> system where signatures are required, and then expect all users to
> update to those versions. I think this would introduce a lot of friction
> in the transition to the new system.

I think anything we do to enforce centralization will create friction
with developers not already using AMO.  If the solution doesn't require
submission of code to Mozilla and matches how other software is
typically deployed (signing of binaries), I'd expect less resistance to
that solution.  (If you're on a closed intranet, you don't even need to
pay for a cert, you can deploy your own root and and sign with a
certificate signed by that root.)

>>> 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.
>> I don’t know the nature of the issues you’ve experienced previously, but what you’re talking about here is just an automated repack system.  We do those reliably for localized and custom partner builds already, we should be able to do the same thing for add-ons.
>>
>> — Mike
> I can assure you it hasn't worked well when we've had to repack hundreds
> of add-ons in the past. I'd rather avoid doing something like this when
> the results have been far from ideal.

This sounds like we're making decisions on how to protect users based on
implementation problems we've had on AMO in the past.  I'm not sure
that's the right approach.  If sign+repack was trivial and reliable,
would we implement that instead?  I think it's worth checking the
assumption that this would be hard against building a high-volume
service to validate hashes and store lots of add-ons.

-- Mike

On Friday, November 1, 2013 10:55:43 AM UTC-5, Dave Townsend wrote:

>
>
> The malware check itself is not the most important part of this proposal.
>
> Being able to get information about and contact the developers of
>
> potentially harmful extensions and blocking the ability of malware to
>
> create per-install versions of their extensions that would be difficult for
>

> us to block is what we're trying to solve here. Local file checks just
>
> don't help.

What's to prevent someone from just creating a fake AMO account? You guys don't do any validation.

On Mon, Nov 4, 2013 at 11:12 PM, Jorge Villalobos <jo...@mozilla.com> wrote:
> We can't effectively stop an EXE running locally with admin privileges.

Right.

> We can try to make it harder for these installers to inject malware into
> Firefox, but a sufficiently determined attacker will find a way. We're
> trying to block the less sophisticated attacks (which we believe are
> most of them) and prevent other types of attack that we know are
> possible but aren't happening widely (as far as we know).

How likely it is that the outcome of this effort is that the attackers
raise their level of sophistication and Firefox suffers marketshare
and goodwill damage from private extensions becoming too hard to
maintain and deploy (leaving us with both attacks and
marketshare/goodwill damage)?

Is there an articulation of what threats exactly this proposal is
designed to address and why those threats are worth addressing in an
environment where attackers can escalate by putting the malicious code
inside their installer .exes?

> Unwanted toolbar installs is something we already deal with at a policy
> level and using blocklisting as the hammer, and it has yielded positive
> results so far.

In the blocklisting bugs I've followed, the blocklisting process has
been terribly slow. It's been a while though since I've paid
attention. How long does it take these days to get a deceptively
installed toolbar blocked?

> I responded to the
> certificate proposals in other replies on this thread.

Do you mean "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."?

Dave Townsend wrote:
> Which mockups are you referring to here?

https://wiki.mozilla.org/Add-ons/FileRegistration/Mockups

On Nov 5, 2013, at 6:21 AM, Henri Sivonen wrote:

>> We can try to make it harder for these installers to inject malware into
>> Firefox, but a sufficiently determined attacker will find a way. We're
>> trying to block the less sophisticated attacks (which we believe are
>> most of them) and prevent other types of attack that we know are
>> possible but aren't happening widely (as far as we know).
>
> How likely it is that the outcome of this effort is that the attackers
> raise their level of sophistication and Firefox suffers marketshare
> and goodwill damage from private extensions becoming too hard to
> maintain and deploy (leaving us with both attacks and
> marketshare/goodwill damage)?
>
> Is there an articulation of what threats exactly this proposal is
> designed to address and why those threats are worth addressing in an
> environment where attackers can escalate by putting the malicious code
> inside their installer .exes?

Many add-on practices today are in a grey area: packaged with unrelated installers, opt-out, unclear effects. They hurt our experience, and are unwanted. Straight blocklisting as currently implemented is possible, and we use it, but it's not a durable solution since it's tied to addon ID, which can be permuted by the author or, worse, randomly by each installer.

A registration system prevents this obvious approach to avoiding the blocklist (as would some of the other approaches under discussion here). Truly nefarious addons could still try to subvert Firefox by altering our binaries or our prefs, but that is an overt attack and pushes those applications clearly into the realm of malware, at which point they'd run afoul of OS-level malware detection tools as well (which can interdict executables before they run on the system, something a userland app can't do.)

The goal of this proposal is not to solve user-executed malware. The goal is to disambiguate the grey area so that bad actors have no plausible way to claim that this is something we support/permit. This is our product; it's extensible but it's not a free for all. We should and will exercise controls when we feel it's being misused.

J

---
Johnathan Nightingale
VP Firefox
@johnath

On 2/11/2013 7:19 a.m., Steve Fink wrote:
>> >I don't think that that is something enterprises would want to spend
>> >time doing, do you?
> Depends on how juicy the carrot is. Enterprise IT departments really
> don't like fixing problems caused by their users installing malware, and
> having the Mozilla registry available to help with the problem is a big
> plus from that perspective. If this just involved hosting a JSON file or
> something, I could imagine enterprises very much liking this. (Though
> perhaps it'd need to be integrated with whatever Enterprise IT
> Architecture Synergy Management Command and Control Server bullshit they
> already use.)

Hmm, I rather like the base idea there - although I think it would be
best targeted at just enterprise-style deployments. They could set an
alternate URL for the registration server (as part of the deployed
default preferences), and have it point to an in-house proxy
registration server. That would have it's own DB - if an add-on wasn't
in their DB, the proxy would just request the info from AMO and relay it
to the client. That would give organisations a central way to easily
manage a list of safe add-ons that are only available inside that
organisation, and they wouldn't need to submit potentially sensitive
add-ons to AMO.

All that is entirely doable in the current proposed spec. However, it
would be nice to have an example/reference (open source) implementation
of a proxy server provided by Mozilla.

- Blair

On 5/11/2013 1:15 p.m., mka...@gmail.com wrote:
> What's to prevent someone from just creating a fake AMO account? You guys don't do any validation.

What would be the effects of a fake account? Being able to contact the
author is primarily a means of helping resolve issues with an add-on. An
author could simply ignore emails from AMO too.

- Blair

On 2/11/2013 5:18 a.m., and...@ducker.org.uk wrote:

> On Friday, 1 November 2013 16:04:31 UTC, Dave Townsend  wrote:
>>> Earlier comments pointed out that enterprises can just block
>>> access to the API which would effectively turn off this feature.
>>> Do you think that isn't good enough to solve the problem?

> I'd say so.  You're asking people to add rules to their firewall in
> order to solve an application usability issue.  This means that (a)
> there's going to be a pain point in tracking down the firewall team
> and getting them to make a change in the first place (always
> frustrating) and then (b) when someone is cleaning up the firewall
> and can't work out why a rule is there, and removes it, suddenly your
> internal-only Firefox addons stop working, and nobody can work out
> why!

There will also be a preference organisations can deploy to the
application directory to override default behaviour.

- Blair

Because that approach isn't good enough, as evidenced by the problems
with the current system. I'd like to flag add-ons as AMO-approved as
well - but that's in addition to/complementary the file registration
system. They're solving two different issues.

- Blair

On 2/11/2013 6:57 a.m., Jorge Villalobos wrote:
> On 11/1/13 2:29 AM, Gijs Kruitbosch wrote:
>>> So, you're suggesting to have signing in addition to the hashes, as a
>>> way to opt-out?

[...]

> I think that's a good idea

+1, I've thought about this myself as an additional way to prove an
add-on is ok to install. I think it's additional to the current method
though, so not something we need to do right away (especially
considering the extreme void of signed add-ons at the moment).

- Blair

That would do the trick if the whitelist supported wildcards.

On Tue, Nov 5, 2013 at 6:52 PM, Johnathan Nightingale
<joh...@mozilla.com> wrote:
> The goal of this proposal is not to solve user-executed malware. The goal is
> to disambiguate the grey area so that bad actors have no plausible way to
> claim that this is something we support/permit.

Considering the potential for collateral damage, this is a pretty
heavy way of disambiguating the gray area to accomplish "bad actors
have no plausible way to claim". Making claims isn't a technical thing
but goes back to policy. Why do we need to make a claiming contest
about what our policy is a technical escalation instead of merely
making it an escalation of words by just claiming authority over what
Mozilla "support[s]/permit[s]" and proceeding to blocklisting
accordingly? That is, if we are shy to act on the gray area now, why
do we need to shrink the gray area technically to get rid of our
shyness instead of shrinking the gray area on the policy statement
level by saying that previously "gray" extensions are now blocklisted?

As for id morphing that evades the current policy enforcement
mechanism, isn't id morphing already unambiguously in the "bad actor"
category so there's really nothing to disambiguate there? Is there a
reason why OS-level malware detection maintaners are unwilling to
pursue id morphing add-ons as malware but would be willing to pursue
those add-ons if we forced the add-ons installer .exes to become more
nefarious if the add-ons no longer could morph their ids?

OTOH, since this really is about *actors*, it seems weird to me to
require the registration of individual software artifacts instead of
requiring the registration of *actors* (OS X default-style), so that
non-bad actors would't need to disclose their artifacts to Mozilla and
all artifacts from a given bad actor could be blocked as one
operation. As Jorge noted, there's a grandfathering problem, but is it
really that much harder for extension authors to issue signed updates
than to upload all their old releases to the registration Web app?

I have archived the .xpi files of all extensions that I have installed.
 Some of them are "abandoned" but still have the functionality that I
want.  If I get a new computer and install Mozilla applications with
which those extensions still work, I will want to install them.  I do
not want to lose their functionality.  This proposal would block such
installations.

The more I consider this proposal, the more I'm convinced that it's not
quite right yet.  That said, there's a path forward I'd like us to consider:

* Signing add-ons should be an acceptable alternative to registration of
add-ons.  This is a broadly understood requirement for most developers,
as Windows and OS X already rely on code signing.  This would be the
best way to opt out for most of the "internal"/"sensitive" add-on use cases.

* The requirement to pre-register add-ons creates a lot of overhead for
humans.  If we're relying on automated scanning anyway, why pre-register
at all?  The goal here is to block "bad" things, not to block "unknown"
things on the presumption of guilt.  Instead, I'd like us to consider a
model where clients can submit "unknown" add-ons to Mozilla for
verification if they don't match a recognized hash.  This would avoid
the grandfathering problem (assuming those older add-ons don't get
rejected for Bad Things) while still building a database of "grey"
add-ons for later analysis and remediation.

-- Mike
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning

> > What is needed is an end-user option that says "I accept the risk.  Let
>
> > me install and enable the addons I want."  There already is a similar
>
> > existing option for about:config
>
>
>
> Having a profile-level preference would make this trivially easy to
>
> bypass, and we already have an installation warning that clearly is not
>
> sufficient to deter users from installing malware.
>
>
>
> There will be ways to disable this feature, as explained in the spec,
>
> but they won't be as easy to get to.
>
>
>
> Jorge

Is a profile-level preference that has to be entered into about:config manually really not sufficient?  People install malware add-ons despite the warning now, but that is a window that appears when the user tries to install something and allows installation with a single click of the "Allow" button.  If, when an unregistered add-on tried to install, a popup stated that the add-on could not be installed because it was not registered with Mozilla and made no mention of how to override this behavior, would that not be a sufficient barrier to installation for most users who end up installing malware now?

On 11/6/13 12:23 PM, David E. Ross wrote:
> On 11/5/2013 8:26 PM, Blair McBride wrote:
>> Because that approach isn't good enough, as evidenced by the problems
>> with the current system. I'd like to flag add-ons as AMO-approved as
>> well - but that's in addition to/complementary the file registration
>> system. They're solving two different issues.
>>
>> - Blair
>>
>>
>>
>>
>> On 2/11/2013 1:44 p.m., David E. Ross wrote:
>>> Why not merely make AMO the repository of analyzed, approved, safe
>>> extensions?  Then, you could "advertise" AMO as the place of safety.
>>> Those of us who collect extensions from other sources would not lose
>>> that ability.
>>>
>>> How far are you planning to go to protect users?  After all, Mozilla
>>> cannot stop us from installing non-Mozilla applications that do not
>>> directly interface with Mozilla applications.  Just give us a source of
>>> "good" applications without interfering with our ability to choose other
>>> sources.
>>>
>
> I have archived the .xpi files of all extensions that I have installed.
>  Some of them are "abandoned" but still have the functionality that I
> want.  If I get a new computer and install Mozilla applications with
> which those extensions still work, I will want to install them.  I do
> not want to lose their functionality.  This proposal would block such
> installations.

If they are indeed abandoned and you know are safe, you could register
them yourself. We might need to do that ourselves for other popular
abandoned add-ons.

Jorge

On 11/6/13 6:32 PM, wsha...@gmail.com wrote:
>>> What is needed is an end-user option that says "I accept the risk.  Let
>>
>>> me install and enable the addons I want."  There already is a similar
>>
>>> existing option for about:config
>>
>>
>>
>> Having a profile-level preference would make this trivially easy to
>>
>> bypass, and we already have an installation warning that clearly is not
>>
>> sufficient to deter users from installing malware.
>>
>>
>>
>> There will be ways to disable this feature, as explained in the spec,
>>
>> but they won't be as easy to get to.
>>
>>
>>
>> Jorge
>
> Is a profile-level preference that has to be entered into about:config manually really not sufficient?  

No. That can be easily subverted by pretty much any software running in
the system. We're planning on having an application-level preference to
override it, so only admin users and software running with admin
privileges will be able to touch it.

> People install malware add-ons despite the warning now, but that is a window that appears when the user tries to install something and allows installation with a single click of the "Allow" button.  If, when an unregistered add-on tried to install, a popup stated that the add-on could not be installed because it was not registered with Mozilla and made no mention of how to override this behavior, would that not be a sufficient barrier to installation for most users who end up installing malware now?

That is what is being proposed. Unregistered add-ons would not be
installed and the user would be notified about it. There would be no
visible override.

Putting the override behind a profile-level pref would make things
difficult for users but not difficult at all for malware creators, so it
wouldn't be sufficient.

Jorge

On 11/5/13 5:21 AM, Henri Sivonen wrote:
> On Mon, Nov 4, 2013 at 11:12 PM, Jorge Villalobos <jo...@mozilla.com> wrote:
>> We can't effectively stop an EXE running locally with admin privileges.
>
> Right.
>
>> We can try to make it harder for these installers to inject malware into
>> Firefox, but a sufficiently determined attacker will find a way. We're
>> trying to block the less sophisticated attacks (which we believe are
>> most of them) and prevent other types of attack that we know are
>> possible but aren't happening widely (as far as we know).
>
> How likely it is that the outcome of this effort is that the attackers
> raise their level of sophistication

Some probably will, but others won't. It really depends on the incentive
behind their attacks. In some cases it will be worth doing the extra
effort, but I suspect in most cases it won't. If you have a malicious
binary running with admin privileges in the user's system I think there
are more attractive targets than spamming users' Facebook walls or
changing their search settings or default pages. And even if they all
did, we would not be worse off than we are today.

> and Firefox suffers marketshare
> and goodwill damage from private extensions becoming too hard to
> maintain and deploy (leaving us with both attacks and
> marketshare/goodwill damage)?

There are different categories of private extensions that I think need
to be handled separately.

There are internal enterprise add-ons, which we're trying to address in
this proposal by offering different ways to override the system. There's
the whitelist pref, blocking the API URL, creating a proxy for it (see a
recent response by Blair about it), or possibly offering a signing
certificate. Deploying any of these has some cost, but we're trying to
make it as low as possible.

The majority of non-AMO add-on installs we track could be classified as
greyware. It's mostly the toolbar add-ons that range from the absolutely
unwelcome to the seemingly necessary (like what is bundled with AV
software). Since these are mostly about monetization and most developers
are willing to modify their software to comply with our policies (when
they are threatened with blocklisting), I expect them to just register
their add-ons. If they decide to subvert our system we will have to
chase them around and find ways to make them comply, like we do now. My
only concern for this category is that we get the more user desired
add-ons (the AV ones) on board so users don't have them blocked.

There are add-ons that are distributed outside of AMO out of convenience
or because the developers chose not to deal with our admittedly slow
review process, or their add-on was rejected by us for some reason.
These are add-ons we don't know much about but for the most part have
relatively little usage. It's possible that some of them decide to let
their add-ons break because they don't want to deal with AMO, but I
wouldn't expect that to have a huge impact in terms of usage.

Then are also non-AMO abandoned add-ons, where one possible solution is
to just register them ourselves to reduce friction during the transition.

> Is there an articulation of what threats exactly this proposal is
> designed to address and why those threats are worth addressing in an
> environment where attackers can escalate by putting the malicious code
> inside their installer .exes?

The document lists the main motivations behind this proposal:

* There are numerous add-on IDs being distributed and installed in the
wild that the Add-ons Team have no knowledge about. Many are believed to
be generated per-install.
* Finding contact information for add-on developers can be a daunting
task, when sometimes all the Add-ons Team have is an add-on ID and a name.
* Finding file samples of these add-ons can be just as difficult.

I think Johnath put it very well in his message. There will be a group
of developers who will realize they're doing things wrong and fall in
line, while there will be others who will continue avoiding our system,
or avoid it more overtly. If we can use this system to reduce this
problem, and have better control over add-on IDs and malware out there,
I think that's a big gain for our users. We're balancing this with the
inconvenience for non-AMO developers and some non-AMO add-on users, but
we believe the net effect will be positive.

>> Unwanted toolbar installs is something we already deal with at a policy
>> level and using blocklisting as the hammer, and it has yielded positive
>> results so far.
>
> In the blocklisting bugs I've followed, the blocklisting process has
> been terribly slow. It's been a while though since I've paid
> attention. How long does it take these days to get a deceptively
> installed toolbar blocked?

It's variable since it's a manual process where the I'm right in the
middle of the critical path. Our resources are extremely limited, so I
haven't been able to reach a point where I can guarantee specific
response times.

In some cases we blocklist on the day the bug is filed, which is
generally when the add-on is clearly malicious or there's no way to
contact the developer. In the murkier cases we contact the developer,
usually as soon as the bug is filed, and then give them 2-3 weeks to
respond. If there's no response, we block. If they respond then this
becomes much less predictable because of development timelines and back
and forth between us and the developers.

The sources of truth here would be the list of blocked add-ons, linking
to the bugs, and the list of open blocklist bugs:

https://addons.mozilla.org/en-US/firefox/blocked/
https://bugzilla.mozilla.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=Blocklist%20pending&sharer_id=189742&list_id=8483185

>> I responded to the
>> certificate proposals in other replies on this thread.
>
> Do you mean "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."?

Yes. Mike replied with more comments, which I need to follow up on.

On 11/4/13 4:01 PM, Mike Connor wrote:
> On 2013-11-04 3:48 PM, Jorge Villalobos wrote:
>> On 11/1/13 12:43 PM, Mike Connor wrote:
>>>
>>> I’m curious why you think the use-case of installing old versions of
>>> add-ons would be “massive” since it seems like a pretty small corner
>>> case.  I doubt either of us have data, but the idea that a
>>> significant number of users are archiving old versions seems somewhat
>>> far-fetched.  Some do, for sure, but that doesn’t necessarily mean
>>> it’s a use-case we need to protect.  I’m actually of the opinion that
>>> we would lose very little for the vast majority of users if we stop
>>> supporting unmaintained add-ons.
>>>
>>> For this new model to be effective I believe we need to raise the bar
>>> on what we allow to be installed.  Grandfathering everything doesn’t
>>> really solve that.
>> Add-ons can have a fairly long shelf life. They can be abandoned for
>> years without their users noticing a problem. Having compatibility on by
>> default means that users won't notice until the add-on breaks.
>
> None of this really answers my concern, which is that this use-case
> matters to relatively few users, and thus doesn't merit weakening the
> strength of the system.  From what I've seen, the most-used add-ons
> still get updated on a somewhat regular basis.  I'd like to see an
> evaluation of the tradeoffs (stronger system for all users vs.
> disruption for a minority).

Since this will affect all add-ons, we can't just think about the most
used ones. There's a very long tail of add-on usage, and even on AMO we
have very popular add-ons that haven't been updated in years.

> Have we used FHR data to identify the real-world stats on these tradeoffs?

No. We're only beginning to use FHR to look into add-on trends, and it
would be fairly difficult to come up with a report that tells us how
many people have add-ons installed that were created within some time
range, especially if what we want is to evaluate the non-AMO add-ons world.

>> And we're not only talking about old add-ons. We would be forcing all
>> add-on developers to produce new versions of their add-ons to support a
>> system where signatures are required, and then expect all users to
>> update to those versions. I think this would introduce a lot of friction
>> in the transition to the new system.
>
> I think anything we do to enforce centralization will create friction
> with developers not already using AMO.  If the solution doesn't require
> submission of code to Mozilla and matches how other software is
> typically deployed (signing of binaries), I'd expect less resistance to
> that solution.  (If you're on a closed intranet, you don't even need to
> pay for a cert, you can deploy your own root and and sign with a
> certificate signed by that root.)

I think the suggestion of allowing a certificate system limited to
internal deployments is very good. I don't think it's the right way to
go for the entire system because of the reasons I've explained in this
thread, on top of the loss of insight we would have into the add-on
files and potential malware patterns.

>>>> 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.
>>> I don’t know the nature of the issues you’ve experienced previously,
>>> but what you’re talking about here is just an automated repack
>>> system.  We do those reliably for localized and custom partner builds
>>> already, we should be able to do the same thing for add-ons.
>>>
>>> — Mike
>> I can assure you it hasn't worked well when we've had to repack hundreds
>> of add-ons in the past. I'd rather avoid doing something like this when
>> the results have been far from ideal.
>
> This sounds like we're making decisions on how to protect users based on
> implementation problems we've had on AMO in the past.  I'm not sure
> that's the right approach.  If sign+repack was trivial and reliable,
> would we implement that instead?  I think it's worth checking the
> assumption that this would be hard against building a high-volume
> service to validate hashes and store lots of add-ons.
>
> -- Mike

This isn't the only reason I don't think we should go with this, but it
is one of them. We've had initiatives fail in the past because of
implementation problems and lack of resources to fix them, so I won't
dismiss this concern this easily. If the system we're proposing is
easier to implement, I don't see how that's not a point in its favor.

Jorge

On 11/7/2013 12:10 PM, Jorge Villalobos wrote:
> There are different categories of private extensions that I think need
> to be handled separately.

You neglected one category: add-ons undergoing development (as in "I
made a typo, let me touch the JS file and restart Firefox" phase of
development). Of all the categories of private extensions, this is by
far the most important one, since it is from this that the entire
ecosystem of add-ons springs into existence.

--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

On Thursday, November 7, 2013 12:02:56 PM UTC-5, jorgev wrote:

> No. That can be easily subverted by pretty much any software running in
>
> the system. We're planning on having an application-level preference to
>
> override it, so only admin users and software running with admin
>
> privileges will be able to touch it.
>

I guess for the purpose of enabling the preference intentionally it is not too important whether it is profile-level or application-level.  I'm still curious about a few things though.

1. If software in the system is changing Firefox preferences in unwanted ways, isn't the system already compromised?

2. Or is the problem that the add-on registration malware analysis would not be able to check if an add-on changed the noaddonreg profile-level preference?  So such an add-on could still be installed and could then allow malware add-ons in after it.

3. If the software changing Firefox preferences was installed by the user (because it was thought to be safe), couldn't it just prompt for admin privileges like many installers do?

4. Is the -noaddonreg flag still being considered?  Could software in the system change Firefox shortcuts to add this switch without admin privileges?

5. Regardless of how the local override works, it is going to be accompanied by a UI prompt that can not be disabled, correct?  And that is why these more elaborate overrides (IP blocking, signing add-ons) are being considered as well?

A malware author could create a fake account, create malware, get it registered and then distribute. When we find it, we could block it, but they could just do it again.

As long as there is a low barrier to entry to getting an account on AMO, the system can be bypassed.

On 11/8/13 6:25 AM, wsha...@gmail.com wrote:
> On Thursday, November 7, 2013 12:02:56 PM UTC-5, jorgev wrote:
>
>> No. That can be easily subverted by pretty much any software running in
>>
>> the system. We're planning on having an application-level preference to
>>
>> override it, so only admin users and software running with admin
>>
>> privileges will be able to touch it.
>>
>
> I guess for the purpose of enabling the preference intentionally it is not too important whether it is profile-level or application-level.  I'm still curious about a few things though.
>
> 1. If software in the system is changing Firefox preferences in unwanted ways, isn't the system already compromised?

Not necessarily. Any extension and software running on the system can
change any profile-level preference without necessarily compromising
anything else.

A malicious application running with admin privileges is what would
compromise the system and what we can't battle effectively. The way
we're planning the overrides is so that only these applications are
capable of subverting the system.

>
> 2. Or is the problem that the add-on registration malware analysis would not be able to check if an add-on changed the noaddonreg profile-level preference?  So such an add-on could still be installed and could then allow malware add-ons in after it.
>

A malicious installer could change the shortcut to add the flag, which
is why we're also planning on having a startup prompt when the flag is
enabled so it takes additional user action to enable this mode.

> 3. If the software changing Firefox preferences was installed by the user (because it was thought to be safe), couldn't it just prompt for admin privileges like many installers do?
>

Yes, we can't really prevent that and it goes into AV software territory.

> 4. Is the -noaddonreg flag still being considered?  Could software in the system change Firefox shortcuts to add this switch without admin privileges?
>

See response for #2.

> 5. Regardless of how the local override works, it is going to be accompanied by a UI prompt that can not be disabled, correct?  And that is why these more elaborate overrides (IP blocking, signing add-ons) are being considered as well?
>

The application-level preference is probably going to be the most
practical of all approaches. But having the command line flag might be
necessary for non-admin users. The other overrides we're thinking about
(certs, blocking the API) are aimed at enterprise deployments and
internal add-ons, which we don't need to monitor as closely.

Jorge

On 11/7/13 11:36 PM, Joshua Cranmer 🐧 wrote:
> On 11/7/2013 12:10 PM, Jorge Villalobos wrote:
>> There are different categories of private extensions that I think need
>> to be handled separately.
>
> You neglected one category: add-ons undergoing development (as in "I
> made a typo, let me touch the JS file and restart Firefox" phase of
> development). Of all the categories of private extensions, this is by
> far the most important one, since it is from this that the entire
> ecosystem of add-ons springs into existence.
>

True. There are also add-ons that people manually modify to override
compatibility or do minor fixes. For those cases we have various
overrides you can use to bypass the system. The most attractive of them,
I think, is to change an application level preference that will act as
an ID whitelist.

Jorge

We're planning the system in a way where we'll be able to track unusual
activity like multiple accounts or multiple submissions happening at the
same time or from the same IP address/range. While it won't be
bulletproof, I think we can raise the bar high enough to deter most abuse.

Jorge

On 11/6/13 12:45 PM, Mike Connor wrote:
> The more I consider this proposal, the more I'm convinced that it's not
> quite right yet.  That said, there's a path forward I'd like us to
> consider:
>
> * Signing add-ons should be an acceptable alternative to registration of
> add-ons.  This is a broadly understood requirement for most developers,
> as Windows and OS X already rely on code signing.  This would be the
> best way to opt out for most of the "internal"/"sensitive" add-on use
> cases.

I like the idea of using signatures as an override for internal add-ons.
We don't really need to monitor them since they aren't publicly
distributed and their users are subject to their company policies and
not ours. This should also be a whitelist, though, since we can't allow
any signed add-on to bypass this.

> * The requirement to pre-register add-ons creates a lot of overhead for
> humans.  If we're relying on automated scanning anyway, why pre-register
> at all?  The goal here is to block "bad" things, not to block "unknown"
> things on the presumption of guilt.  Instead, I'd like us to consider a
> model where clients can submit "unknown" add-ons to Mozilla for
> verification if they don't match a recognized hash.  This would avoid
> the grandfathering problem (assuming those older add-ons don't get
> rejected for Bad Things) while still building a database of "grey"
> add-ons for later analysis and remediation.

If we give all users to option to bypass the block by just sending the
file to us, they will do it. If our malware checks are not good enough,
then the installation will succeed and we would have failed.

The way the system is currently planned, it is up to the malware
developer to submit the files for registration, which gives us an
advantage in that we can link file uploads with metadata like time of
upload, IP address and registered account. We can use that to identify
malware submission patterns, malicious files and create new checks to
strengthen the system.

If we allow users to upload the files themselves, then we're giving
malware developers the possibility of using their targets as proxies for
registration, which makes it much more difficult for us to fight
malicious submissions.

I'm sure some users will do this even if we don't give them the option
in the UI, which works in our favor in the case of abandonware. But
giving that option in the default UI would make it too commonplace and
would be damaging to the overall reliability of the system.

Jorge

On 2013-11-08 11:43 AM, Jorge Villalobos wrote:
> This should also be a whitelist, though, since we can't allow
> any signed add-on to bypass this.

Why not?

>> * The requirement to pre-register add-ons creates a lot of overhead for
>> humans.  If we're relying on automated scanning anyway, why pre-register
>> at all?  The goal here is to block "bad" things, not to block "unknown"
>> things on the presumption of guilt.  Instead, I'd like us to consider a
>> model where clients can submit "unknown" add-ons to Mozilla for
>> verification if they don't match a recognized hash.  This would avoid
>> the grandfathering problem (assuming those older add-ons don't get
>> rejected for Bad Things) while still building a database of "grey"
>> add-ons for later analysis and remediation.
> If we give all users to option to bypass the block by just sending the
> file to us, they will do it. If our malware checks are not good enough,
> then the installation will succeed and we would have failed.
>
> The way the system is currently planned, it is up to the malware
> developer to submit the files for registration, which gives us an
> advantage in that we can link file uploads with metadata like time of
> upload, IP address and registered account. We can use that to identify
> malware submission patterns, malicious files and create new checks to
> strengthen the system.

I'm not convinced at all that we'll be able to identify suspicious
patterns of developer behavior more effectively than we'll be able to
identify code patterns that should be detected and blocked.  Even if we
get tipped off by this sort of forensics, we'll still have to build the
scanning code to look for similar (and obfuscated) examples and
block/revoke them all, so I'm not sure it gives us much.

I agree with mkaply that there's very little value to accounts in terms
of preventing abuse if signups don't require validation.  I don't think
we need to go full silo like Chrome, but if we're relying on user
registration as an element of our security model, we need to
significantly raise the bar for getting one of those accounts. The
further we go on that front, up to and including charging for access,
the stronger this factor becomes.

This all leads up to something I think we've missed: I believe we should
consider economic (in addition to technical) factors as a key weapon in
this fight.  As long as it's profitable to target our users, they will
be targets.  If we make it unprofitable enough, attackers will find
other targets, even if they can beat the technical safeguards.

> If we allow users to upload the files themselves, then we're giving
> malware developers the possibility of using their targets as proxies for
> registration, which makes it much more difficult for us to fight
> malicious submissions.

This proxy problem already exists without validation of accounts as
being from real people.  Even five years ago there were demos at Black
Hat of distributed gaming of captchas.

> I'm sure some users will do this even if we don't give them the option
> in the UI, which works in our favor in the case of abandonware. But
> giving that option in the default UI would make it too commonplace and
> would be damaging to the overall reliability of the system.

To repeat, unless we are doing strong identify verification as well
preventing duplicate accounts, the user registration aspect can be gamed
and abused.  I do not think the system you're proposing is stronger in
practice than relying directly on scanning/hashes.

-- Mike

I just received a reply to an E-mail message that I had sent to an
extension developer.  My original message was about a problem with his
extension.  His reply contained a link to download a trial version of a
fix to my problem.

I am NOT an extension developer.  With your scheme implemented, would I
be able to test the trial version if the developer is not yet ready to
register it?

Addon development does not mean application development; I am unlikely
to be able to change the application-level preference in my
distro-installed Firefox.  I can, if I really wanted to, via sudo, but
that's a tad ridiculous.

At this point, I'm still not seeing the advantage of app-level pref vs.
profile-level pref; to me, they're the same side of the air-tight hatch.
  Perhaps specific examples of the difference would help?

--
Mook

... Who keeps thinking that preventing people from installing whatever
extension they want is going against "the ability to shape their own
experiences on the Internet."

Jorge Villalobos schrieb:

> On 11/8/13 6:25 AM, wsha...@gmail.com wrote:
>> 1. If software in the system is changing Firefox preferences in unwanted ways, isn't the system already compromised?
>
> Not necessarily. Any extension and software running on the system can
> change any profile-level preference without necessarily compromising
> anything else.

In the typical Windows XP install it probably can change admin stuff as
well (given the usual case is people from from an admin user).

>> 3. If the software changing Firefox preferences was installed by the user (because it was thought to be safe), couldn't it just prompt for admin privileges like many installers do?
>
> Yes, we can't really prevent that and it goes into AV software territory.

Did we actually gather data from the kind of software we want to fight
here? I suspect that a number of those things are installed by
admin-priviledged installers anyhow and may be able to run with those
privileges themselves. And if they ain't yet, we just might force them
to go to that strategy and do bitguard-like stuff, i.e. install
non-add-on binaries that just hook into our process and change stuff
that way.

Robert Kaiser

I've read every post on this topic, and I've got some observations to offer.

I develop and distribute two add ons which are not, and never have been,
published through AMO;  Dephormation & Secret Agent. Dephormation
disrupts Phorm's communications surveillance. Secret Agent randomises
the browser user agent to suppress device fingerprinting. We can argue
about how effective either might be, its not relevant to the topic in hand.

How and who defines 'malware?

Taking the Dephormation add on for example; I suspect if you were to ask
Kent Ertugrul whether Phorm's spyware was malware, he would say no.
Conversely, Phorm would claim my code was malicious, given the damage it
might cause to their involuntary surveillance business.

Needless to say, I take entirely the opposite view. As do the people who
choose to install my software.

So. The key question is which side do *you* take? If you appoint
yourself as the arbitor between good and evil in a binary world, you
cannot sit on the fence.

Kent Erutugrul probably pays better than I ever will. He employs better
lawyers. I guess that would ensure he wins?

On submitting code, vs code signing... the latter is obviously more
sensible. But if the cost is prohibitive, you will cause people like me
to reassess the commitment we make to developing add ons. However
signing code does not guarantee the quality or intent of the code.

On the question of freewill, I don't think it should be up to you to
protect me from the consequences of my own poor judgement. If I elect to
install an item of software on my own computer, who are you to decide
whether the consequences are in my best interest or not? Its my computer.

Finally... to summarise... I think you need to articulate a much better,
stronger case for what you are doing. On that focusses only on the harm
to other people resulting from software installation. Rather than
protecting the individual from the consequences of choosing freely to
ignore your advice. For example; if this is about selectively targeting
add ons that spread spam, relay malware, support DDOS attacks then there
is a more compelling case to make for protecting other people.

If you are protecting me from the consequences of exercising my own
freewill, or stupidity, I disagree with your goal completely.

To borrow a bit of John Stuart Mills philosophy on liberty;

"The sole end for which mankind are warranted, individually or
collectively, in interfering with the liberty of action of any of their
number, is self-protection. That the only purpose for which power can be
rightfully exercised over any member of a civilized community, against
his will, is to prevent harm to others. His own good, either physical or
moral, is not sufficient warrant. He cannot rightfully be compelled to
do or forbear because it will be better for him to do so, because it
will make him happier, because, in the opinion of others, to do so would
be wise, or even right...The only part of the conduct of anyone, for
which he is amenable to society, is that which concerns others. In the
part which merely concerns him, his independence is, of right, absolute.
Over himself, over his own body and mind, the individual is sovereign."

... to which I'd add 'over his own computer the individual is sysadmin too'.

https://en.wikipedia.org/wiki/John_Stuart_Mill

regards
Pete

PS; blocking access to a target domain from within an add on is also a
risk you might want to consider. In that case it would be possible for a
single add on to suppress any network access.

On 08/11/13 16:43, Jorge Villalobos wrote:
> I like the idea of using signatures as an override for internal add-ons.
> We don't really need to monitor them since they aren't publicly
> distributed and their users are subject to their company policies and
> not ours. This should also be a whitelist, though, since we can't allow
> any signed add-on to bypass this.

If we are considering this (and I think it's worth considering), please
consult Brian Smith and the rest of the CA team to make sure we do it
right. I know he has some opinions about the current addon signing model.

Gerv

What we have is what we've learned from the add-ons in the wild we
investigate for blocklisting. There are a few different categories that
might react differently to the restrictions we're putting in place. If
an add-on is being installed by an admin-privileged installer, though,
it's easier to disable or bypass the whole system rather than going
binary-only, since that requires more technical know-how than what we've
encountered so far. Also, the incentive to do this already exists, since
blocking injected binaries is more difficult than blocking extensions.
Whether we would be moving more developers in that particular direction
or not is a difficult question to answer.

Jorge

Using any of the available overrides, yes.

Jorge

On 11/8/13 1:11 PM, Mike Connor wrote:
> On 2013-11-08 11:43 AM, Jorge Villalobos wrote:
>> This should also be a whitelist, though, since we can't allow
>> any signed add-on to bypass this.
>
> Why not?
>

Because allowing any signed add-on to bypass registration opens another
big whole in the system. Signing an add-on isn't particularly difficult,
and if we want to have a cert option and still keep the level of control
we're aiming for, we need to be in control of which certs are accepted.

>>> * The requirement to pre-register add-ons creates a lot of overhead for
>>> humans.  If we're relying on automated scanning anyway, why pre-register
>>> at all?  The goal here is to block "bad" things, not to block "unknown"
>>> things on the presumption of guilt.  Instead, I'd like us to consider a
>>> model where clients can submit "unknown" add-ons to Mozilla for
>>> verification if they don't match a recognized hash.  This would avoid
>>> the grandfathering problem (assuming those older add-ons don't get
>>> rejected for Bad Things) while still building a database of "grey"
>>> add-ons for later analysis and remediation.
>> If we give all users to option to bypass the block by just sending the
>> file to us, they will do it. If our malware checks are not good enough,
>> then the installation will succeed and we would have failed.
>>
>> The way the system is currently planned, it is up to the malware
>> developer to submit the files for registration, which gives us an
>> advantage in that we can link file uploads with metadata like time of
>> upload, IP address and registered account. We can use that to identify
>> malware submission patterns, malicious files and create new checks to
>> strengthen the system.
>
> I'm not convinced at all that we'll be able to identify suspicious
> patterns of developer behavior more effectively than we'll be able to
> identify code patterns that should be detected and blocked.  Even if we
> get tipped off by this sort of forensics, we'll still have to build the
> scanning code to look for similar (and obfuscated) examples and
> block/revoke them all, so I'm not sure it gives us much.

Since there are many malicious add-ons out there using identical /
nearly identical code but randomized IDs, this gives us back the ability
to block them, at least to the extent we can block non-randomized
malicious add-ons now. We already have to do similar analysis when
looking for the compatibility impact of various changes in platform
code. The scale in this case is larger, but I don't think it's unmanageable.

> I agree with mkaply that there's very little value to accounts in terms
> of preventing abuse if signups don't require validation.  I don't think
> we need to go full silo like Chrome, but if we're relying on user
> registration as an element of our security model, we need to
> significantly raise the bar for getting one of those accounts. The
> further we go on that front, up to and including charging for access,
> the stronger this factor becomes.
>
> This all leads up to something I think we've missed: I believe we should
> consider economic (in addition to technical) factors as a key weapon in
> this fight.  As long as it's profitable to target our users, they will
> be targets.  If we make it unprofitable enough, attackers will find
> other targets, even if they can beat the technical safeguards.

I don't think charging developers is a valid option. That will
discourage many aspiring developers from even getting started, due to
economic limitations and sometimes even geographic limitations (I can't
pay because I'm from X). It's also at odds with our goals of open and
free participation.

It's true that free accounts are no barrier of entry. The main benefit
we get from accounts is for greyware add-ons that we have a problem
getting contacts for. We have other ways to control what is being
registered that doesn't require identification, specifically IP
addresses and the code being uploaded. These can also be randomized in
various ways, but not without cost. If we have good enough tools, we
should set the bar high enough that only a few will try to jump it and
succeed. We could be proven wrong about this, but I don't think it's a
good idea to establish a registration fee without even trying a
different way.

>> If we allow users to upload the files themselves, then we're giving
>> malware developers the possibility of using their targets as proxies for
>> registration, which makes it much more difficult for us to fight
>> malicious submissions.
>
> This proxy problem already exists without validation of accounts as
> being from real people.  Even five years ago there were demos at Black
> Hat of distributed gaming of captchas.

In the wild, however, it's about cost / benefit. There's no question
that it's possible to game parts of the system.

I think my message fell through the cracks (no replies) and I haven't
seen the issue of blocking an HTTPS URL be addressed, so I'm replying to
my own message here to re-raise this issue.

On 11/01/2013 05:15 PM, Andrew Sutherland wrote:
> On 11/01/2013 02:49 PM, Jorge Villalobos wrote:
>> On 11/1/13 9:34 AM, J. Ryan Stinnett wrote:
>>> Do you plan to publish the host names of the servers used in this
>>> process so that they can easily be blocked for people /
>>> organizations who choose this option? Perhaps they could be part of
>>> the same documentation that I was suggesting above that would
>>> explain how to white list.
>> Like with the blocklist, this will just be one URL you'll need to block,
>> so it should be really easy to do.
>
> Wouldn't it be an HTTPS URL and therefore harder to block?
>
> http://mxr.mozilla.org/mozilla-central/source/browser/app/profile/firefox.js#53
> is:
>
>  pref
> <http://mxr.mozilla.org/mozilla-central/ident?i=pref>("extensions.blocklist.url","https://addons.mozilla.org/blocklist/3/...");
>
> That seems like the network would need to have addons.mozilla.org
> black-holed with a fake DNS entry, or all of the IP addresses it could
> resolve to would need to be blacklisted, or the Enterprise would need
> to be actively MITM-ing all SSL connections on the network.  The last
> one is not something we would want to encourage people to do.
>
> I'm assuming a non-addons.mozilla.org domain would be used with
> distinct IP addresses so the organization wouldn't have to block AMO
> entirely?

On 11/11/2013 12:25 PM, Andrew Sutherland wrote:
>>> Like with the blocklist, this will just be one URL you'll need to block,
>>> so it should be really easy to do.
>>
>> Wouldn't it be an HTTPS URL and therefore harder to block?

>>  [...]

>> I'm assuming a non-addons.mozilla.org domain would be used with
>> distinct IP addresses so the organization wouldn't have to block AMO
>> entirely?

It shouldn't live on addons.mozilla.org itself. If you can't set up a
separate registry.AMO then at least sticking it on services.AMO or
versioncheck.AMO would be better (both have collateral damage if admins
do decide to block it though).

-Dan Veditz

On Mon, Nov 11, 2013 at 10:28 PM, Jorge Villalobos <jo...@mozilla.com> wrote:
> Signing an add-on isn't particularly difficult,
> and if we want to have a cert option and still keep the level of control
> we're aiming for, we need to be in control of which certs are accepted.

Requiring add-ons to be signed with a private key whose public key is
certified by Mozilla in response to registration to a Mozilla service
would make the level of author identification identical to the level
of author identification in the model you propose.

--
Henri Sivonen
hsiv...@hsivonen.fi
http://hsivonen.fi/

It's a good point and we'll take it into account. If we need to set up a
different subdomain to address this issue, that's what we'll do.

Jorge

On 11/12/13 2:59 AM, Henri Sivonen wrote:
> On Mon, Nov 11, 2013 at 10:28 PM, Jorge Villalobos <jo...@mozilla.com> wrote:
>> Signing an add-on isn't particularly difficult,
>> and if we want to have a cert option and still keep the level of control
>> we're aiming for, we need to be in control of which certs are accepted.
>
> Requiring add-ons to be signed with a private key whose public key is
> certified by Mozilla in response to registration to a Mozilla service
> would make the level of author identification identical to the level
> of author identification in the model you propose.
>

Yes, that's what I was trying to say before, that if we go with
certificates, we need a process where we whitelist them in some form.

Jorge

On 2013-11-11 3:28 PM, Jorge Villalobos wrote:
> On 11/8/13 1:11 PM, Mike Connor wrote:
>> On 2013-11-08 11:43 AM, Jorge Villalobos wrote:
>>> This should also be a whitelist, though, since we can't allow
>>> any signed add-on to bypass this.
>> Why not?
>>
> Because allowing any signed add-on to bypass registration opens another
> big whole in the system. Signing an add-on isn't particularly difficult,
> and if we want to have a cert option and still keep the level of control
> we're aiming for, we need to be in control of which certs are accepted.

The main thing about legitimate code signing certs is that they're
expensive (~$200) and take time to obtain for attackers, and free for us
to block.  That's an expensive game of whack-a-mole for attackers,
especially compared to gaming AMO registration for free. If a root CA
grants too many bad certs, we'll simply flip the code signing trust bit
for that CA.  I don't believe this would be a significant issue in
practice (and we'd have big allies in any fight to stomp out rogue certs).

>> I'm not convinced at all that we'll be able to identify suspicious
>> patterns of developer behavior more effectively than we'll be able to
>> identify code patterns that should be detected and blocked.  Even if we
>> get tipped off by this sort of forensics, we'll still have to build the
>> scanning code to look for similar (and obfuscated) examples and
>> block/revoke them all, so I'm not sure it gives us much.
> Since there are many malicious add-ons out there using identical /
> nearly identical code but randomized IDs, this gives us back the ability
> to block them, at least to the extent we can block non-randomized
> malicious add-ons now. We already have to do similar analysis when
> looking for the compatibility impact of various changes in platform
> code. The scale in this case is larger, but I don't think it's unmanageable.

This doesn't really address my point, which is that we're not going to
gain much from registration as long as it's something lots and lots of
people can do.  The focus will be on code scanning, at which point we're
not going to gain much, if anything, from forcing a signup.  Abuse
detection in real time is not really a solved problem here, we'll have
post-facto forensics, but that's about it.

>> I agree with mkaply that there's very little value to accounts in terms
>> of preventing abuse if signups don't require validation.  I don't think
>> we need to go full silo like Chrome, but if we're relying on user
>> registration as an element of our security model, we need to
>> significantly raise the bar for getting one of those accounts. The
>> further we go on that front, up to and including charging for access,
>> the stronger this factor becomes.
>>
>> This all leads up to something I think we've missed: I believe we should
>> consider economic (in addition to technical) factors as a key weapon in
>> this fight.  As long as it's profitable to target our users, they will
>> be targets.  If we make it unprofitable enough, attackers will find
>> other targets, even if they can beat the technical safeguards.
> I don't think charging developers is a valid option. That will
> discourage many aspiring developers from even getting started, due to
> economic limitations and sometimes even geographic limitations (I can't
> pay because I'm from X). It's also at odds with our goals of open and
> free participation.

Charging developers is a nuclear option, but if we're in a cost/benefit
fight we might need to go there eventually.  There are other ways of
raising the bar that don't impose financial cost, but would impede any
attempt to attack at scale, such as requiring some sort of verification
that a developer is a real person.

> It's true that free accounts are no barrier of entry. The main benefit
> we get from accounts is for greyware add-ons that we have a problem
> getting contacts for. We have other ways to control what is being
> registered that doesn't require identification, specifically IP
> addresses and the code being uploaded. These can also be randomized in
> various ways, but not without cost. If we have good enough tools, we
> should set the bar high enough that only a few will try to jump it and
> succeed. We could be proven wrong about this, but I don't think it's a
> good idea to establish a registration fee without even trying a
> different way.

Again, it's a nuclear option.  We could impose something more hardcore
than a captcha, such as requiring some sort of human interaction for
developer account requests (review that the profile looks real and the
person is a real person, with lots of options on how we do
verification).  The goal would be to make developer accounts difficult
to obtain in quantity.

>>> If we allow users to upload the files themselves, then we're giving
>>> malware developers the possibility of using their targets as proxies for
>>> registration, which makes it much more difficult for us to fight
>>> malicious submissions.
>> This proxy problem already exists without validation of accounts as
>> being from real people.  Even five years ago there were demos at Black
>> Hat of distributed gaming of captchas.
> In the wild, however, it's about cost / benefit. There's no question
> that it's possible to game parts of the system.

It's always possible, thus my desire to make it prohibitive to do it at
scale.  What is a relatively small ask for developers to do once can be
prohibitive to do dozens or hundreds of times.

-- Mike

On 11/11/2013 20:04, Jorge Villalobos wrote:
> <snip>
> Jorge
>

I disagree profoundly with what you're doing Jorge.

At worst, it empowers people with rather sinister motives, and big
pockets, at the expense of smaller developers.

At best, it is going to be circumvented by crooks anyway, and would
barely make any difference.

And thats not a good thing. Provided there is no impact on other
internet users, you should leave the control over a computer to the
discretion of the user, and no one else.

Don't impose your view of 'malware' on other people, because your
judgement and your integrity will be tested in ways you can't possibly
imagine.

Pete

On 11/11/2013 20:04, Jorge Villalobos wrote:

> On 11/10/13 10:30 AM, Dephormation wrote:

[...]

>> So. The key question is which side do *you* take? If you appoint
>> yourself as the arbitor between good and evil in a binary world, you
>> cannot sit on the fence.
>>
>> Kent Erutugrul probably pays better than I ever will. He employs better
>> lawyers. I guess that would ensure he wins?
>
> Judging by your add-ons' descriptions, I think they would be accepted on
> AMO. Maybe not with full review in the case of Secret Agent, but they're
> definitely far from what we consider malware. Whether Phorm would ask
> the add-on to be taken down and whether they would be successful is a
> different matter that I can't really comment on.
>
> However, the registration system is not a public listing or a
> distribution channel, so we will limit our control to dealing with real
> malware, not add-ons that may annoy some people.

But how will you limit your control?  It seems you will have that
control in all cases, whether you want it or not, and therefore you will
have to make those decisions.

If someone takes legal action, or if there's a petition from a million
Firefox users, or if there's a load of bad publicity on major news
sites, then "I can't really comment" isn't a strong position.  If you
have the power to block, then you have to be able to defend a decision
not to use it, as well as justify decisions to use it.

As you said, it's a question of balance, and I think this issue already
exists with the blocklist, but it doesn't seem like it should be
dismissed...

Michael

Just pointing out that your "takes legal action" example existed prior
to the blocklist due to the lack of ability to disable misbehaving
add-ons and was one of the reasons the blocklist was implemented.

Robert

>
> Michael

On Fri, Nov 8, 2013 at 8:43 AM, Jorge Villalobos <jo...@mozilla.com> wrote:
> On 11/6/13 12:45 PM, Mike Connor wrote:
>> The more I consider this proposal, the more I'm convinced that it's not
>> quite right yet.  That said, there's a path forward I'd like us to
>> consider:
>>
>> * Signing add-ons should be an acceptable alternative to registration of
>> add-ons.  This is a broadly understood requirement for most developers,
>> as Windows and OS X already rely on code signing.  This would be the
>> best way to opt out for most of the "internal"/"sensitive" add-on use
>> cases.
>
> I like the idea of using signatures as an override for internal add-ons.
> We don't really need to monitor them since they aren't publicly
> distributed and their users are subject to their company policies and
> not ours. This should also be a whitelist, though, since we can't allow
> any signed add-on to bypass this.

What certificates would go on the whitelist? If we'd have a whitelist
of certificates, then how do we deal with abuse of certificates that
are on the whitelist? I believe this is unnecessary complication that
adds unnecessary risk of the system being bypassed. What percentage of
users would actually be severely affected if we just refused to
install internal addons that aren't registered with us? I would guess
that the percentage would be WELL under 1%. The benefits that the
99.x% of users gain by the registration mechanism more than offsets
that. Plus, even the negatively-impacted users would gain by being
more protected from bad addons, so even the users that lose the
ability to use internal addons might have a net win.

I think we should have a whitelist of certificates, with only have one
entry on it: the certificate that signs the hotfix addon. That way,
downtime of the registration check mechanism doesn't lead to the
inability to use the hotfix addon.

Cheers,
Brian

On Wed, Nov 13, 2013 at 9:06 AM, Mike Connor <mco...@mozilla.com> wrote:
> On 2013-11-11 3:28 PM, Jorge Villalobos wrote:
>>

>> On 11/8/13 1:11 PM, Mike Connor wrote:
> The main thing about legitimate code signing certs is that they're expensive
> (~$200) and take time to obtain for attackers, and free for us to block.

I don't think we should build a system on the assumption that getting
code signing certs from a commercial CA is expensive, unless we're
going to set a minimum price in our CA program, which would be counter
to some goals we have in our CA program. Similarly, we'll be working
with CAs to make it much easier to get certs.

Further, even if certs were always expensive and hard to legally
obtain, so that only good guys could obtain them legitimately, we'd
still have to deal with compromises of the CA and the certificate
owner. In particular, what happens when somebody obtains the private
key of the certificate holder, and the certificate holder doesn't even
realize it (so the cert is never revoked). IMO, this risk is very high
and the benefits of taking that risk don't warrant that high level of
risk.

> That's an expensive game of whack-a-mole for attackers, especially compared
> to gaming AMO registration for free. If a root CA grants too many bad certs,
> we'll simply flip the code signing trust bit for that CA.  I don't believe
> this would be a significant issue in practice (and we'd have big allies in
> any fight to stomp out rogue certs).

You are making assumptions about how readily we distrust CAs that are not valid.

Anyway, I would like to end the code-signing part of Mozilla's CA
program. We are not benefiting from it and it looks likely to take up
resources that could be better spent on the SSL part of Mozilla's CA
program. So, I'm hoping we end up trusting zero CAs for code signing,
except for the Firefox Marketplace CA.

> This doesn't really address my point, which is that we're not going to gain
> much from registration as long as it's something lots and lots of people can
> do.  The focus will be on code scanning, at which point we're not going to
> gain much, if anything, from forcing a signup.  Abuse detection in real time
> is not really a solved problem here, we'll have post-facto forensics, but
> that's about it.

Signups allow us to take reputation into account. Reputation is a very
valuable metric in determining trustworthiness. See the Google
SafeBrowsing API for downloads and Microsoft Application Reputation
feature for how other browsers (and soon Firefox) make good use of
reputation tracking as a security tool. If nothing else, tracking
reputation allows us to prioritize resources for malware scanning
and/or manual review.

Also, there are design considerations for improving privacy protection
that such reputation management tools provide, that we could learn
from. For example, we could keep Firefox up to date with the hashes of
the most popular X,000 addons so that we can avoid sending the hashes
of these addons to AMO; this would improve privacy if we could remove
all the other ways we end up sending the set of installed addons to
Mozilla.

>> I don't think charging developers is a valid option. That will
>> discourage many aspiring developers from even getting started, due to
>> economic limitations and sometimes even geographic limitations (I can't
>> pay because I'm from X). It's also at odds with our goals of open and
>> free participation.
>
> Charging developers is a nuclear option, but if we're in a cost/benefit
> fight we might need to go there eventually.  There are other ways of raising
> the bar that don't impose financial cost, but would impede any attempt to
> attack at scale, such as requiring some sort of verification that a
> developer is a real person.

Charging is usually done to use the credit card company as a proxy for
identity verification, which is a component of reputation tracking. I
think we should implement Jorge's proposal without worrying so much
about identity verification, and see how much it improves things.

> It's always possible, thus my desire to make it prohibitive to do it at
> scale.  What is a relatively small ask for developers to do once can be
> prohibitive to do dozens or hundreds of times.

One option would be a built-in 1-business-day delay for the approval
of the first addon, with the ability for somebody to manually approve
addons during that delay.

Cheers,
Brian

Why is everyone thinking about allowing any certificate? Couldn't Mozilla act as a CA and issue it's own certificates to the developers in exchange for the contact info?

When I said "I can't comment" I meant specifically in the hypothetical
situation where the add-on is listed on AMO. In the case of just
registration, we wouldn't be listing or distributing the add-on in any
way, so I don't think we would be in a position where we can be forced
to take it down. It wouldn't be different from blocklisting, like you
and others have pointed out, and we've never blocked add-ons for these
reasons.

Jorge

Given that this thread is cooling off a bit, I took some time to update
the doc with the feedback that all of you gave us:

* Added a subsection about Account Spamming, which mentions using IP
addresses to identify and block spammers, as well as a retention policy
we should have so we don't keep this information indefinitely. It also
mentions the concerns there are about automatic account creation and
registration and a possible way to attack this problem (with a short
waiting period for first submissions).

* Added an Overrides subsection, dedicated to the possible overrides for
this system. It mentions the locked pref, command line switch, API
blocking and code signing, though the latter doesn't seem to be
realistic at least for a v1.

Next steps include posting the proposal in the Add-ons Blog, to bring
more people in the discussion, and come up with a timeline and resources
to work on this.

This doesn't mean this discussion is over. Please continue adding any
feedback you have.

Thanks!

Jorge

I read much of the proposed doc and many of the user posts, and to my best understanding, I feel the proposal has some issues (sorry if it's duplicate/answered, I couldn't read everything posted so far):

1. "Only files that pass these checks will be registered and will be installable in Firefox."
I think this is the one that most people take issue with.  Can it be changed to just a warning for unregistered addons during installation/update (right now proposal is for an error message that explains unregistered just can't be installed)?  I develop both addons hosted on AMO and ones for our company intranet. I see the registration system a serious deterrent to using addons for internal usage. To even upload anything to you guys, whether we think it'd leak IP or not, we have to go through company publication system to get admin/lawyer approval. The whole process is just not gonna be worth it to spend effort using addons.  If new versions are created often, bypassing/whitelist etc. workarounds have to be very smooth to make the proposal not extremely annoying. In case you say that our IT should take care of implementing the proposed overrides, no, they don't. They only deal with IE support, and I'm sure our company is not the only big company doing that, however much I don't like the idea of using IE myself. And we don't have remote admin rights to efficiently do what we need to do for overrides.

2. It seems to me that this system might be taken advantage of by malware authors due to the potentially false sense of security. The email/proposal said it would run some simple malware check then register it (which is a kind of endorsement for its safety).  If any malware author defeats those malware checks, they can dope people into thinking their addons are safe 'cause Mozilla kinda endorsed it.

3. "It will be possible to register any old versions of existing add-ons."
Will that at least be done automatically for AMO addons? I know my addons sometimes have users using much older Firefox, and some of my addons using Addon SDK, and it means that those users have to use older versions of my addons. I really don't want to have to manually register every old version to not anger my users (who might update from one old version to another old).

4. "AMO developers should have access to the File Registration features, in case they distribute different versions of their add-ons, like prerelease versions, outside of AMO".
What exactly does the "access to File Registration Features" mean? The ability to show addons are registered on AMO already? Is that also kinda defeating registration purpose? Would that be potentially exploited 'cause it sounds like the system endorses AMO developers and thus they can do whatever they want outside AMO (like different versions which might very well contain malware)?

5. The hash is for the XPI file only? What about the addons that expand into directory upon install? Would that cause registration system fail to recognize those addons (particularly if during install, the internet is off)?

6. If addon can install fine when net is off, then when Firefox eventually finds that addon shouldn't be installed, what happens? Just a warning or disabling the addon?

7. The API URL block overrides doesn't work well when user uses work laptop from home, airport ... Switch override and some other need IT authority/support to roll out efficiently, not an option in some company as I mentioned.

Overall I strongly favor either NOT have such a fallible system that might be providing false sense of security, or have one that simply warns user but does not block installation.

User should have the ultimate say if they want some addon installed or not.  Yes, you might know better than what the user knows in most cases, but even the US constitution is not assuming that the governing body ALWAYS knows better. Users should be allowed to have their choices.

Mingyi

On Sun, Nov 17, 2013 at 7:24 PM,  <khag...@gmail.com> wrote:
> Why is everyone thinking about allowing any certificate? Couldn't Mozilla act as a CA and issue it's own certificates to the developers in exchange for the contact info?

FWIW, when I advocated for signatures instead of code upload earlier
in this thread, I meant signatures with keys certified by AMO--OS X
Gatekeeper-style.

On 11/22/13 8:08 AM, ming...@gmail.com wrote:
> I read much of the proposed doc and many of the user posts, and to my best understanding, I feel the proposal has some issues (sorry if it's duplicate/answered, I couldn't read everything posted so far):
>
> 1. "Only files that pass these checks will be registered and will be installable in Firefox."
> I think this is the one that most people take issue with.  Can it be changed to just a warning for unregistered addons during installation/update (right now proposal is for an error message that explains unregistered just can't be installed)?

Showing a dialog users can override isn't effective because most users
will just ignore it and do whatever it takes to get rid of it or install
whatever they were installing. This is how malware is currently being
distributed and installed, by tricking users into believing they need it.

>  I develop both addons hosted on AMO and ones for our company intranet. I see the registration system a serious deterrent to using addons for internal usage. To even upload anything to you guys, whether we think it'd leak IP or not, we have to go through company publication system to get admin/lawyer approval. The whole process is just not gonna be worth it to spend effort using addons.  If new versions are created often, bypassing/whitelist etc. workarounds have to be very smooth to make the proposal not extremely annoying. In case you say that our IT should take care of implementing the proposed overrides, no, they don't. They only deal with IE support, and I'm sure our company is not the only big company doing that, however much I don't like the idea of using IE myself. And we don't have remote admin rights to efficiently do what we need to do for overrides.

The document specifies various overrides which cater to different
situations. If none of them work for you, please explain why.

> 2. It seems to me that this system might be taken advantage of by malware authors due to the potentially false sense of security. The email/proposal said it would run some simple malware check then register it (which is a kind of endorsement for its safety).  If any malware author defeats those malware checks, they can dope people into thinking their addons are safe 'cause Mozilla kinda endorsed it.

Registered add-ons will be installed in the same way they have always
been installed. There's nothing in the UI saying they are safe or
anything like that. Unregistered add-ons will probably show a similar UI
as blocklisted add-ons do now. I don't see how we're introducing a false
sense of security. Most users won't even be aware of this new system, if
we do this right.

> 3. "It will be possible to register any old versions of existing add-ons."
> Will that at least be done automatically for AMO addons? I know my addons sometimes have users using much older Firefox, and some of my addons using Addon SDK, and it means that those users have to use older versions of my addons. I really don't want to have to manually register every old version to not anger my users (who might update from one old version to another old).

All AMO add-ons will be registered, as the doc indicates.

> 4. "AMO developers should have access to the File Registration features, in case they distribute different versions of their add-ons, like prerelease versions, outside of AMO".
> What exactly does the "access to File Registration Features" mean? The ability to show addons are registered on AMO already? Is that also kinda defeating registration purpose? Would that be potentially exploited 'cause it sounds like the system endorses AMO developers and thus they can do whatever they want outside AMO (like different versions which might very well contain malware)?

It just means that you can register non-AMO versions of your add-ons,
like alphas.

> 5. The hash is for the XPI file only? What about the addons that expand into directory upon install? Would that cause registration system fail to recognize those addons (particularly if during install, the internet is off)?

Both are covered in the doc. There will be hashes for XPIs and unpacked
XPIs. Network failure when calling the API means the XPI will be
installed. There are regular checks that would eventually recognize if
an unregistered add-on was incorrectly installed.

> 6. If addon can install fine when net is off, then when Firefox eventually finds that addon shouldn't be installed, what happens? Just a warning or disabling the addon?

Disabling or uninstalling. That hasn't been determined yet.

> 7. The API URL block overrides doesn't work well when user uses work laptop from home, airport ... Switch override and some other need IT authority/support to roll out efficiently, not an option in some company as I mentioned.

That's a good point. A non-admin user with an internal add-on installed
and not inside an office network. That's something we hadn't considered,
thanks.

> Overall I strongly favor either NOT have such a fallible system that might be providing false sense of security, or have one that simply warns user but does not block installation.
>
> User should have the ultimate say if they want some addon installed or not.  Yes, you might know better than what the user knows in most cases, but even the US constitution is not assuming that the governing body ALWAYS knows better. Users should be allowed to have their choices.
>
> Mingyi

I've said this a couple of times in this thread, so I'll keep it short:
we're trying to protect users against real threats happening now through
add-on installation. We have decided that we can't let users install
whatever they want, since they are often fooled into installing
malicious or otherwise unwanted things. We're taking action, and we're
trying to make it as least troublesome as possible for both users and
add-on devs. Not doing anything is not an option, though.

Jorge

It appears that government is not the only organization trying to impose
a "nanny-state" on the population.  Yes, I know this is a hostile
comment; but I feel the proposal is hostile against more experienced
users.

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

On Nov 22, 2013 7:05 PM, "Jorge Villalobos" <jo...@mozilla.com> wrote:
> We have decided that we can't let users install
> whatever they want

This is the source of almost all of the complaints. Who are this "we" and
when did they decide that users couldn't install the add-ons they wanted.
At least give us an option in about:config to disable this, you can't
believe that changing something could be done without knowing what you are
doing. I can't believe that the only thing you propose to override this
behaviour is to block an IP and you don't see any problem with it.

There's a whole section in the document about overrides. There will be a
preference that can be modified, but not through about:config since it
could be trivially changed by other add-ons and installers.

Jorge

Hi, Jorge,

For the proposed overrides:

    A locked pref that can only be edited in the application directory would hold a whitelist of add-on IDs to ignore. Only users who are admins in their systems can use this.

As I said, only our IT has the admin for rolling out apps, but they only support IE.

    A command line switch (-noaddonreg) that 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.

This isn't going to work for end users who install Firefox on their own. Also our IT won't roll Firefox out, with the switch or not.

    The API URLs can be blocked in enterprise settings, which effectively enables all add-on installation (this might require us to have a dedicated subdomain for the API). Alternatively it could be proxied to use a internal API instead.

As I said, and you agreed, that this option won't work well for users with internal addon working outside office.

    Code signing has been suggested as an addition or alternative to the proposal. As an addition, it could work as an override for enterprise environments. It has been pointed out that the complexity of such a system is not worth the effort given its limited scope, so we might only consider it for v2.

This might be the way to go for our situation, but it's only an unaccepted proposal at least for first version.

Some of the overrides proposed above, without IT help, would work ONLY IF we instructed each of the internal addon users on the method AND that they actually do that, which we know it's impossible; Or they allow us do it for them, which depends on the premise that we know all users who want to install internal addons, and even then it's a hassle to do this for each user.

It's just a big annoyance, although I do agree that security should be a bigger concern.

BTW when you said all AMO addons will be registered as per doc, which I do know. But I wonder if all old versions of all AMO addons would be auto-registered?

Mingyi

Jorge Villalobos schrieb:

> We have decided that we can't let users install
> whatever they want

Now that's putting it in very dangerous words, as it makes you sound as
if we did want to take control away from users, when on the contrary,
Mozilla's stance is to make people be more in control of their online
lives, and AFAIK even the idea behind what you're trying to get here is
to give back control to the user by not having third parties mess with
their Firefox.

KaiRo

tl;dr
I *oppose* this whole concept of a walled garden strongly, on legal, technical and "moral" (openess, Manifesto) reasons.

Am Mittwoch, 30. Oktober 2013 22:55:21 UTC+1 schrieb jorgev:
> > 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".

I don't recall you bootstrapping a discussion about file registration in amo-editors-internal...
I have to admit that I was recently mostly inactive as an AMO editor, but even a search through my archives yields nothing. I missed it in the 31. Oct add-on update blog post, though.

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

Mozilla creating some kind of walled garden, even if the walls are thinner than with other walled gardens?
Opposed! Simple as that.

There are a couple of add-ons that I cannot legally give the source code or even binary code to mozilla, and a couple of others I simply do not want to share.

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

So not only would I have to give my files to mozilla, mozilla would actually "log" all of this and associate it with me. Unless mozilla is willing to create a liable subsidiary within my legislation that would store the associated data so that I can actually sue and defend myself based on my juridation and laws, this is a no go.

> > On the client side, Firefox will compute the hashes of add-on files
> > being installed and query the API for it.

So, mozilla will also get finer grained information about users in the process :(

> > If the file is registered, it
> > can be installed, otherwise it can't (there is planned transition period
> > to ease adoption).

Err, what?!

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

You do recognize, that you'll be creating a closed system, after all?
Governments, the US government in particular, can force mozilla to blacklist certain types of add-ons or compel account data. mozilla itself can later decide to just blacklist stuff it finds offensive or morally problematic ('various levels of "bad"').
It might create legal issues in certain areas. Now that mozilla would gain the absolute authority to allow/disallow add-ons, does it need to name a person to oversee and implement legal age checks for porn add-ons, as might required by local law (thinking of German law right now; IANAL)? Is it liable if malware sometimes slips through (false negatives), what is the situation with a false positive impacting my business, etc.?

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

No, they are not, really. I cannot only distribute an add-on to a certain group of people without also "distributing" it to mozilla and mozilla's servers also, which happens to fall under US jurisdiction at the very least.
I can never be certain that a government compels mozilla to provide data. I can never be certain that a disgruntled employee does something nasty with my data. I can never be certain that this additional point of failure won't fail.

Oh, and those overrides suck if you aren't a large enterprise.
How do I distribute my add-on to a couple of friend and colleges that are not necessarily tech-savvy, and without giving my creation to mozilla?
Seems that with this proposal I simply can't.

Also, add-on installations would be allowed if the server fails to respond? And this is supposed to be a feature for enterprises, even?! OSCP *cough*

Am Freitag, 1. November 2013 18:24:04 UTC+1 schrieb jorgev:
...
> We're in a position where something needs to change.

I contest this premise. Show me any data or other evidence that shows there is an actual need for mozilla applications specifically, beyond the general malware problem.
I'm certainly aware of the existence of malware in the add-ons space, but I'm not aware of any data detailing how big this problem actually is right now.

Also, I did not see any compelling technical study of such a system, that actually shows that a malware problem can be addressed this way.
Just look at the Google Play store/Goolge Chrome store and similar walled gardens, and how much they suck at weeding out malware before a significant number of users have been already hit.

I know, for example, how the amo-validator operates and that it only detects a tiny subset of issues reliably and can be gamed pretty easy. That's why we still have human AMO editors in the first place.
I know that those nice Antivirus software packages not only suck when it comes to false positives, but the actual detection rate on previously unknown stuff is abysmal.
I seriously doubt that such a "malware scanning system" (or "badware") would even be good enough to just catch a somewhat polymorphic payload loader "add-on".

As others noted, developer certs would be a more viable, less invasive option at least to some of the "privacy" concerns. However, devcerts would still not address all problems, in particular the legal ones, arising from such a walled garden.

So, what might work better, after legal issues are addressed, and would work for me, and (most of) my use cases:
- Give out devcerts and provide good GUI *and* CLI signing tools, to not force authors to provide their code to mozilla in general and not force them to upload each version to mozilla in particular.
There is already code around that implements regular XPI (modified JAR) signing and other code for update signing...

- AMO can automatically sign stuff.
IIRC there is already code or at least a plan for the marketplace for signing packaged webapps...

- Provide a way to specify a globally trusted add-on signing cert, that can be used by enterprises and other parties who do not want to interact with mozilla at all.

- Make it possible to install add-ons that are unsigned, but make it difficult and scary.
Something like the multi-click certificate warnings and exceptions for TLS might work to scare most non-savvy users away, but I can still instruct people who trust me (!) on how to install the add-on. Since we're at it, make it possible to have a locked pref to disable this, to make enterprises really happy.

- Have your file registration stuff as well, if you like, now that there are viable alternatives.

Cheers
Nils

You cannot honestly believe that taking away control from a users allows the user to exercise more control?
If the police took you into protective custody, you haven't gained more control, have you?

No, what really is proposed here is mozilla taking away control from the user, and balancing out the loss of control (bad) with a more secure environment and experience (good).
If the "good" even works as advertised, and if it really balances out the bad and any related side effects, and if users really think the good is important enough to warrant the bad, well, that is another thing...

On Sun, Nov 24, 2013 at 7:59 AM,  <testnu...@gmail.com> wrote:
> tl;dr
> I *oppose* this whole concept of a walled garden strongly, on legal, technical and "moral" (openess, Manifesto) reasons.

It's a fair point.  I'm pretty sure I've said to people in the past
"Mozilla would never do an Apple-style walled garden system for
add-ons where you have to get official Mozilla approval".  Because I
was confident we wouldn't!

And the technical side of this proposal sounds like a nightmare.  So
many pieces; so many places where it could go wrong.

We already have blocklisting in place, but in the past we've been very
reluctant to use it.  Could we just be more aggressive with its use --
if an add-on is found to be violating any of our policies, blocklist
it without remorse?  E.g. not just gross malware, but things like
toolbars that hijack the default search engine without the user's
consent?  It's reactive, sure, but any pre-emptive system is going to
hit the major technical and moral issues that have been raised
repeatedly in this thread.

Also, I may have missed it, but do we have descriptions of the
different kinds of malware that we see in practice, and their
frequencies?  That would be interesting and helpful.

Nick

  Finally someone has actually come out and admitted what users have
been believing for the Past few years.  Just like this running to out
Chrome, Chrome by spring.

I have both Austrailis and Chrome. I am not adverse to testing. And just
doing screen shots of top section of both they were almost not quite
alike. but Austrialis (nicknamed Khrome was about 95%  a dead ringer for
Chrome.  I surprised Google doesn't have a Lawsuit in the wings.

--
Phillip M. Jones, C.E.T.      "If it's Fixed, Don't Break it"
http://www.phillipmjones.net    mailto:pjon...@comcast.net

On 11/24/13 8:17 AM, testnu...@gmail.com wrote:
> Am Sonntag, 24. November 2013 15:39:08 UTC+1 schrieb Robert Kaiser:
>> Jorge Villalobos schrieb:
>>> We have decided that we can't let users install
>>> whatever they want
>>
>> Now that's putting it in very dangerous words, as it makes you sound as
>> if we did want to take control away from users, when on the contrary,
>> Mozilla's stance is to make people be more in control of their online
>> lives, and AFAIK even the idea behind what you're trying to get here is
>> to give back control to the user by not having third parties mess with
>> their Firefox.
> You cannot honestly believe that taking away control from a users allows the user to exercise more control?
> If the police took you into protective custody, you haven't gained more control, have you?

I don't think that's what kairo intended to say.

There is a difference in "exercising  control",  and "gaining control."

Both positions can be true.  Users *can* "gain control" of their
internet experience better, if third parties are not allowed to install
software unknowingly on the systems of Firefox users. That's what's in
mission.  That was the point that I think kiaro was trying to make.

It's also true that this proposal does have the affect of limiting and
removing the exercising of control over what users can, and can't,
install on their system, unless we insert pref's that work around the
feature.

>
> No, what really is proposed here is mozilla taking away control from the user, and balancing out the loss of control (bad) with a more secure environment and experience (good).

That's also a good way to evaluate the proposal.  Evaluating the balance
between the good and bad effects, and where the effects will show up.

> If the "good" even works as advertised, and if it really balances out the bad and any related side effects, and if users really think the good is important enough to warrant the bad, well, that is another thing...

exactly.   That's where if we share data, and share assumptions about
how we arrived at the decision or plan, plus how we might measure the
affect after the implementation, we will all make a lot more progress on
figuring out if the plan might be effective and its worthwhile giving it
a try, or adjusting the plan to meet shortfalls, or abandoning the plan
if it doesn't look like it could be effective.

These days I'm big on the insight lilly once shared:  Tell me the
assumptions behind your proposal and I can do a lot better job on giving
you feedback...

-chofmann

In my experience that would be the hard part of the plan.

It takes a lot of work to figure out if an add-on is intentionally bad,
neutral and just misbehaving, or really is useful for users and misbehaving.
It takes a lot of work to keep that list current.

https://bugzilla.mozilla.org/showdependencytree.cgi?id=512788&hide_resolved=0
shows a list of bugs I tracked long ago when working in this area.
162 cases shown there, and it probably hasn't been updated much lately.

This work might be sped up by having the addon developers be more
cooperative and responsive in the investigation, but in many cases they
are not.  Especially those developers or organizations that are installing
addons that have the end result of hijacking systems.

But if we are considering putting more work into this area that's
really the trade off to look at.    Where should we put the effort,
and how effective might the effort be?

Jesse's long pitched for another proposal that could help more people
participate
in analyzing and blocking malware  in
https://bugzilla.mozilla.org/show_bug.cgi?id=662819
if we did go the route of aggressive post-blocking v. systematic
pre-approval.

-chofmann
> Nick

On 11/24/2013 7:18 PM, PhillipJones wrote:
> I have both Austrailis and Chrome. I am not adverse to testing. And
> just doing screen shots of top section of both they were almost not
> quite alike. but Austrialis (nicknamed Khrome was about 95%  a dead
> ringer for Chrome.  I surprised Google doesn't have a Lawsuit in the
> wings.
>

Probably because they are afraid of letting it be known that Australis's
design predates the Google Chrome UI? :-P

--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

On Sun, Nov 24, 2013 at 8:31 PM, Joshua Cranmer 🐧 <Pidg...@gmail.com> wrote:
>>
>> I have both Austrailis and Chrome. I am not adverse to testing. And just
>> doing screen shots of top section of both they were almost not quite alike.
>> but Austrialis (nicknamed Khrome was about 95%  a dead ringer for Chrome.  I
>> surprised Google doesn't have a Lawsuit in the wings.
>
> Probably because they are afraid of letting it be known that Australis's
> design predates the Google Chrome UI? :-P

This thread is about add-ons.  Discussion of Australis is off-topic.
Please take Australis comments to the firefox-dev list.

Nick

On 24/11/13 22:50, Nicholas Nethercote wrote:
> It's a fair point.  I'm pretty sure I've said to people in the past
> "Mozilla would never do an Apple-style walled garden system for
> add-ons where you have to get official Mozilla approval".  Because I
> was confident we wouldn't!

That's also something I've said to people in the past.

Gerv

We have heard from other enterprise developers / users who also pointed
out the annoyance and difficulty about dealing with IT to make these
changes. However, that's not a sufficient reason for us to make radical
changes to the proposal. We plan a transition period which should make
it clear for users and developers what is coming, so they can prepare.
Hopefully this will be enough time to coordinate with IT staff to make
this happen.

>
> BTW when you said all AMO addons will be registered as per doc, which I do know. But I wonder if all old versions of all AMO addons would be auto-registered?
>
> Mingyi
>

Yes, the intention is to auto-register all versions we host on AMO,
including old ones.

Jorge

Yeah, bad quote. To expand on it, I would say "We have decided that we
can't let users install whatever they *think* they want".

Malware is often installed using phishing techniques, tricking users
into installing things they think are required, like a video plugin or a
"Mozilla Service Pack".

We're trying to set the bad of registration low enough that all
legitimate developers can submit their add-ons with very little
inconvenience, but high enough that malware can't be registered or
installed. It's a tricky balance to find, for sure.

Jorge

On 11/24/13 4:50 PM, Nicholas Nethercote wrote:
> On Sun, Nov 24, 2013 at 7:59 AM,  <testnu...@gmail.com> wrote:
>> tl;dr
>> I *oppose* this whole concept of a walled garden strongly, on legal, technical and "moral" (openess, Manifesto) reasons.
>
> It's a fair point.  I'm pretty sure I've said to people in the past
> "Mozilla would never do an Apple-style walled garden system for
> add-ons where you have to get official Mozilla approval".  Because I
> was confident we wouldn't!
>
> And the technical side of this proposal sounds like a nightmare.  So
> many pieces; so many places where it could go wrong.
>
> We already have blocklisting in place, but in the past we've been very
> reluctant to use it.

Please look at this list and dates to see how much we use blocklisting
now: https://addons.mozilla.org/firefox/blocked/

Also, if you read the proposal you'll realize why blocklisting is
becoming increasingly ineffective. We can't block add-ons that randomize
their IDs per-install, and we have no way to control that.

> Could we just be more aggressive with its use --
> if an add-on is found to be violating any of our policies, blocklist
> it without remorse?

The main aim of this proposal is malware, and we already block malware
as soon as it is found.

> E.g. not just gross malware, but things like
> toolbars that hijack the default search engine without the user's
> consent?  It's reactive, sure, but any pre-emptive system is going to
> hit the major technical and moral issues that have been raised
> repeatedly in this thread.

Whether we want these add-ons to exist and to which extent is a separate
discussion. This system is mostly aimed at malware, but it will
certainly go a long way in informing us about greyware being distributed
outside of AMO, and facilitate the "contact, fix or block" process.

>
> Also, I may have missed it, but do we have descriptions of the
> different kinds of malware that we see in practice, and their
> frequencies?  That would be interesting and helpful.

The malware we most often deal with, as you can see in the blocklist
link above (the ones with "Facebook" and "Mozilla" in their name), are
malicious extensions being distributed through Facebook. And we know
about them because of the great work of the Facebook Security team, who
are the ones tracking these extensions and filing the bugs with all the
required information. We wouldn't know about them unless they became
widely installed. As for the frequency, it varies a lot, but there are
months like November when we get 5-10 reports.

Second in line would be side-installed add-ons that Kris from the
Add-ons Team discovers from looking at usage stats or testing known
shady installers. Those have generally reached the point where you can
find many reports about them online and have thousands of installations.
In this category there are truly malicious extensions, which are a rare
find (a few per quarter), and then lots of greyware (toolbars, etc.)
which are probably a few per month, some of which are blocked (see the
entries in the blocklist not marked as malware). In many of these cases
we only have an ID or a name to work with, and it can be a daunting task
to find file samples or contact information for the developers. We will
block add-ons that don't follow the guidelines and have no contacts, but
often we can't even determine whether they follow the guidelines or not.

Then we have the unknowns, which is our biggest concern. Add-ons that
have a different ID per-install, making them very difficult to find.
Some we have been able to track by name and found that they have
thousands of installs. The amount of IDs that only have one user has
been growing dramatically (in the millions), and we know they are being
used by both malicious and greyware developers.

If you need more specific data, let me know what you want and I'll try
to get for you.

Jorge

I CHOOSE how I deal with malware.  I have disabled Microsoft's virus
checker inherent in Windows 7 because I installed anti-malware
applications that I CHOSE.

Some Web sites I trust to provide safe downloads of new application
versions; these are Web sites that my long-term experience tells me are
trustworthy.  Other Web sites, I download new applications and then scan
them with two different anti-malware applications (which have their
databases updated daily).

You are proposing to remove my right to CHOOSE.  Instead, you should let
me be the judge of what to install on my computer.  I will accept the
consequences.

On 11/24/13 9:59 AM, testnu...@gmail.com wrote:
> tl;dr
> I *oppose* this whole concept of a walled garden strongly, on legal, technical and "moral" (openess, Manifesto) reasons.
>
> Am Mittwoch, 30. Oktober 2013 22:55:21 UTC+1 schrieb jorgev:
>>> 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".
>
> I don't recall you bootstrapping a discussion about file registration in amo-editors-internal...
> I have to admit that I was recently mostly inactive as an AMO editor, but even a search through my archives yields nothing. I missed it in the 31. Oct add-on update blog post, though.

No, we didn't talk about this in the reviewers list. We have talked
about Squeaky in past events, but I can see how that could have been
easily missed. This the first presentation of this proposal outside of
the Squeaky list / meetings and I didn't think it was necessary to have
other intermediate steps in communicating it.

>>> 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.
>
> Mozilla creating some kind of walled garden, even if the walls are thinner than with other walled gardens?
> Opposed! Simple as that.
>
> There are a couple of add-ons that I cannot legally give the source code or even binary code to mozilla, and a couple of others I simply do not want to share.
>
>>> 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.
>>
>
> So not only would I have to give my files to mozilla, mozilla would actually "log" all of this and associate it with me. Unless mozilla is willing to create a liable subsidiary within my legislation that would store the associated data so that I can actually sue and defend myself based on my juridation and laws, this is a no go.
>
>>> On the client side, Firefox will compute the hashes of add-on files
>>> being installed and query the API for it.
>
> So, mozilla will also get finer grained information about users in the process :(

I don't think we would get more data than we already have from the
Firefox Health Report and other data pings.

>>> If the file is registered, it
>>> can be installed, otherwise it can't (there is planned transition period
>>> to ease adoption).
>
> Err, what?!
>
>
>>> 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.
>
> You do recognize, that you'll be creating a closed system, after all?
> Governments, the US government in particular, can force mozilla to blacklist certain types of add-ons or compel account data. mozilla itself can later decide to just blacklist stuff it finds offensive or morally problematic ('various levels of "bad"').

It's no different from the blocklist, and we haven't been compelled to
block anything, or have blocked anything that didn't deserve it. We have
US-centric regulations for AMO because we distribute those add-ons. If
there are regulations that apply to files stored in non-public servers,
we will need to evaluate our file retention policy to minimize any
potential impact on developers.

> It might create legal issues in certain areas. Now that mozilla would gain the absolute authority to allow/disallow add-ons, does it need to name a person to oversee and implement legal age checks for porn add-ons, as might required by local law (thinking of German law right now; IANAL)? Is it liable if malware sometimes slips through (false negatives), what is the situation with a false positive impacting my business, etc.?

This is not aimed at blocking content, only malicious intent. However,
you bring good points that need to be looked at.

>>> 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.
>
> No, they are not, really. I cannot only distribute an add-on to a certain group of people without also "distributing" it to mozilla and mozilla's servers also, which happens to fall under US jurisdiction at the very least.
> I can never be certain that a government compels mozilla to provide data. I can never be certain that a disgruntled employee does something nasty with my data. I can never be certain that this additional point of failure won't fail.
>
> Oh, and those overrides suck if you aren't a large enterprise.
> How do I distribute my add-on to a couple of friend and colleges that are not necessarily tech-savvy, and without giving my creation to mozilla?
> Seems that with this proposal I simply can't.
>
> Also, add-on installations would be allowed if the server fails to respond? And this is supposed to be a feature for enterprises, even?! OSCP *cough*
>
> Am Freitag, 1. November 2013 18:24:04 UTC+1 schrieb jorgev:
> ...
>> We're in a position where something needs to change.
>
> I contest this premise. Show me any data or other evidence that shows there is an actual need for mozilla applications specifically, beyond the general malware problem.
> I'm certainly aware of the existence of malware in the add-ons space, but I'm not aware of any data detailing how big this problem actually is right now.

I replied to Nick with some data we have, but it can be difficult to
quantify precisely, precisely because there's a very large number of
unknown add-on installs that we know very little about.

>
> Also, I did not see any compelling technical study of such a system, that actually shows that a malware problem can be addressed this way.
> Just look at the Google Play store/Goolge Chrome store and similar walled gardens, and how much they suck at weeding out malware before a significant number of users have been already hit.
>
> I know, for example, how the amo-validator operates and that it only detects a tiny subset of issues reliably and can be gamed pretty easy. That's why we still have human AMO editors in the first place.
> I know that those nice Antivirus software packages not only suck when it comes to false positives, but the actual detection rate on previously unknown stuff is abysmal.
> I seriously doubt that such a "malware scanning system" (or "badware") would even be good enough to just catch a somewhat polymorphic payload loader "add-on".

Yes, the validation step won't be perfect, but it won't need to be. We
will be monitoring file upload to try to detect suspicious patterns from
developers / locations to battle spamming. There is also the idea of
having a waiting period upon first submission to ensure the developer is
legitimate. There will surely be bad add-ons that are registered despite
all that, but once discovered will help us strengthen the system and
make it more resilient.

>
> As others noted, developer certs would be a more viable, less invasive option at least to some of the "privacy" concerns. However, devcerts would still not address all problems, in particular the legal ones, arising from such a walled garden.
>
> So, what might work better, after legal issues are addressed, and would work for me, and (most of) my use cases:
> - Give out devcerts and provide good GUI *and* CLI signing tools, to not force authors to provide their code to mozilla in general and not force them to upload each version to mozilla in particular.
> There is already code around that implements regular XPI (modified JAR) signing and other code for update signing...
>
> - AMO can automatically sign stuff.
> IIRC there is already code or at least a plan for the marketplace for signing packaged webapps...
>
> - Provide a way to specify a globally trusted add-on signing cert, that can be used by enterprises and other parties who do not want to interact with mozilla at all.
>
> - Make it possible to install add-ons that are unsigned, but make it difficult and scary.
> Something like the multi-click certificate warnings and exceptions for TLS might work to scare most non-savvy users away, but I can still instruct people who trust me (!) on how to install the add-on. Since we're at it, make it possible to have a locked pref to disable this, to make enterprises really happy.

Please read my responses to this on the rest of the thread (I'm sorry,
it's a long thread to dig through, but it's also lots of rewriting on my
part).

> - Have your file registration stuff as well, if you like, now that there are viable alternatives.
>
> Cheers
> Nils
>

Thanks.

Jorge

On 28/11/13, 19:12 , David E. Ross wrote:
> I CHOOSE how I deal with malware.  I have disabled Microsoft's virus
> checker inherent in Windows 7 because I installed anti-malware
> applications that I CHOSE.
>
> Some Web sites I trust to provide safe downloads of new application
> versions; these are Web sites that my long-term experience tells me are
> trustworthy.  Other Web sites, I download new applications and then scan
> them with two different anti-malware applications (which have their
> databases updated daily).
>
> You are proposing to remove my right to CHOOSE.  Instead, you should let
> me be the judge of what to install on my computer.  I will accept the
> consequences.
>

I think Jorge has been pretty clear already that it will be possible for
users to override whatever the registration requirements are if/when
those eventually become a reality. We're *not* taking away your choice.

You do need to realize that a lot of our several hundred million users
(I would readily bargain on 90%+) wouldn't even know *how* to disable
Windows 7's virus checker, nevermind be able to distinguish malicious
add-ons from non-malicious ones if they were cleverly phished. Mozilla
needs to act because of all our users, and can't let the majority suffer
because the tech-savvy minority is able to deal with the issue by
themselves.

~ Gijs

Jorge Villalobos schrieb:
> While we'll probably do a virus check in extensions with binaries, the
> majority of checks will be focused on malicious JavaScript patterns. Our
> knowledge of malicious add-ons in the wild gives us a much better chance
> of detecting a malicious add-on than any general antivirus tool.

After reading this thread for a while, just a (possibly naive) question:
Could we perhaps, instead of completely blocking unsubmitted add-ons,
have Firefox automatically submit them to us and enable them if the
check on our side comes up clean?
I know that would not give us sound author info but it surely would at
least be a more open approach, even if it would undoubtedly bring up
voices on "phoning home" or "submitting stuff to Mozilla" and we
probably would need to deal with that carefully in terms of privacy, I
guess we'd need an option to turn off the whole mechanism so people can
save their "nefarious" (or just not-any-of-our-business) deeds from
being submitted to "us" (or our systems). Maybe it would need explicit
UI about that.

You probably have thought about this in more detail, this just popped
into my mind and might actually not be doable or useful at all.


The second thought that comes into my mind is that we often have said
that we are not an "antivirus" company/organization and do not want to
get into that kind of business. It sounds from your messages like we
need to go at least to the very borders of that. Would it make sense to
not do all of this ourselves and instead partner with some established
players in that area to deal with this?


And then, on the completely other side, I have some concerns that by
circumventing the whole mechanism if our servers cannot be reached, we
make it really easy for those we target to close out to force installing
their code by just putting some system code somewhere that will block
the connection to our server. And/or we might just force them to go
hooking DLLs into our process, which is pretty easy on Windows anyhow,
and is a real lot harder to deal with on our side and a larger stability
(and potentially security) issue. What's your thoughts on that?


I waited long with any reply here as I share a lot of your concerns,
also want to give users back more control over their experience just
like you do, and I didn't want my comments to sound negative, but so far
I haven't seen clear answers to those questions that come up in my mind,
though you probably have thought about them long and hard. I'm all for
solving the underlying problem and want to make sure we evaluate open
questions like those before we actually introduce such a system. I'm
sure everyone here would love if users control their own browsing
experience instead of malware/grayware authors. :)

KaiRo

On 11/28/13 8:17 PM, Robert Kaiser wrote:
> Jorge Villalobos schrieb:
>> While we'll probably do a virus check in extensions with binaries, the
>> majority of checks will be focused on malicious JavaScript patterns. Our
>> knowledge of malicious add-ons in the wild gives us a much better chance
>> of detecting a malicious add-on than any general antivirus tool.
>
> After reading this thread for a while, just a (possibly naive) question:
> Could we perhaps, instead of completely blocking unsubmitted add-ons,
> have Firefox automatically submit them to us and enable them if the
> check on our side comes up clean?
> I know that would not give us sound author info but it surely would at
> least be a more open approach, even if it would undoubtedly bring up
> voices on "phoning home" or "submitting stuff to Mozilla" and we
> probably would need to deal with that carefully in terms of privacy, I
> guess we'd need an option to turn off the whole mechanism so people can
> save their "nefarious" (or just not-any-of-our-business) deeds from
> being submitted to "us" (or our systems). Maybe it would need explicit
> UI about that.
>
> You probably have thought about this in more detail, this just popped
> into my mind and might actually not be doable or useful at all.

Mike Connor brought this up elsewhere in the thread, and I think the
main problem with this approach is that it allows malware developers to
use end users as proxies for registration.

The plan is to have admin tools that help us fight malware developers
who try to game the system and register malicious add-ons, and for that
we want to be able to detect things like suspicious quantities of
submissions from a specific account, a specific IP address or IP range.
This allows us to keep track of spammers trying to flood us. We would
lose this (in addition to what you brought up) if we let users submit
unknown extensions that are being installed.

Since we will know about unknown extensions attempting to be installed,
we can look into those logs and try to determine if there are legitimate
add-ons that aren't registered for whatever reason, and perhaps take
some action to correct it on our side.

> The second thought that comes into my mind is that we often have said
> that we are not an "antivirus" company/organization and do not want to
> get into that kind of business. It sounds from your messages like we
> need to go at least to the very borders of that. Would it make sense to
> not do all of this ourselves and instead partner with some established
> players in that area to deal with this?

I wouldn't discard that possibility, though we haven't talked about it
much. It's worth pointing out that most AV vendors bundle add-ons with
their products and are generally on the edge of what we allow when it
comes to add-on installs. We might put ourselves in a tricky position
with such a partnership.

> And then, on the completely other side, I have some concerns that by
> circumventing the whole mechanism if our servers cannot be reached, we
> make it really easy for those we target to close out to force installing
> their code by just putting some system code somewhere that will block
> the connection to our server. And/or we might just force them to go
> hooking DLLs into our process, which is pretty easy on Windows anyhow,
> and is a real lot harder to deal with on our side and a larger stability
> (and potentially security) issue. What's your thoughts on that?

There is a risk of escalation, certainly. However, this escalation means
these add-ons can do whatever they want, which they already do without
escalation. The question is whether we're making things hard enough for
a majority of malware developers so that they give up or choose a
different avenue to distribute their malware. That depends on the
incentives they have for distributing their malware, which varies a lot.

We know that greyware developers have a huge financial incentive to
distribute their add-ons, which is one reason we believe they shouldn't
be blocked altogether but we should work with them to put them in line
with our policies. That has worked well so far.

Malicious developers for the most part spam facebook accounts trying to
get people to "Like" fb pages and visit malicious websites. Their
add-ons are fairly simple, usually Greasemonkey scripts that inject
remote scripts into web pages. So, it's not particularly sophisticated
stuff. Also, out stats indicate that a huge portion of these add-ons are
installed using the regular web install method, which means they would
need to do plenty of work to adjust to the new method.

Our expectation is that most malware developers will either give up or
try gaming the registration system instead of escalating to the other
more complex techniques. Also, if you're a malware developer and you're
developing an installer with admin privileges and the capability of
disabling our checks, there are much more attractive targets in a user's
system than their Facebook wall.

> I waited long with any reply here as I share a lot of your concerns,
> also want to give users back more control over their experience just
> like you do, and I didn't want my comments to sound negative, but so far
> I haven't seen clear answers to those questions that come up in my mind,
> though you probably have thought about them long and hard. I'm all for
> solving the underlying problem and want to make sure we evaluate open
> questions like those before we actually introduce such a system. I'm
> sure everyone here would love if users control their own browsing
> experience instead of malware/grayware authors. :)
>
> KaiRo

Thank you for the feedback. And if you've read the rest of this thread
you shouldn't worry about sounding negative :P.

Jorge

Am 28.11.13 19:49, schrieb Gijs Kruitbosch:

> I think Jorge has been pretty clear already that it will be possible for
> users to override whatever the registration requirements are if/when
> those eventually become a reality. We're *not* taking away your choice.

No, actually he did not, he made it pretty clear that the opposite is to
be the case. This isn't what the proposal says:
> If a user installs a file that is not registered, a message will be
shown explaining that the file can�t be installed for their protection.

So there is no simple override.

> A locked pref that can only be edited in the application directory
would hold a whitelist of add-on IDs to ignore. Only users who are
admins in their systems can use this.

This isn't doable for "users". Also, thinking about this, this will
pretty much conflict with package managers.

> A command line switch (-noaddonreg) that 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.

This isn't a real solution either. If a user clicks a link and the
browser isn't already running it will start in normal mode.
Oh, and not doable for a normal user.

> The API URLs can be blocked in enterprise settings, which effectively
enables all add-on installation (this might require us to have a
dedicated subdomain for the API). Alternatively it could be proxied to
use a internal API instead.

Not doable either.

It is actually far worse than Apple Gatekeeper is right now.


But even if overrides worked for regular users, it will cause less
add-ons to be created. Some authors will be self-censoring, because
there is no point in creating add-on that a normal user cannot install
anyway and because they do not want to enter into a relationship with
MoCo US for whatever sane or insane reason.

E.g. if I was an Iranian dissident creating an add-on, I do not want to
"register" that add-on with some central authority or at least shouldn't
because that leaves more records and traces that can come back to haunt
me than I like. Given the proposal, accounts will be using IPs, so it
seems rather unlikely that I could use something like TOR to register my
add-on.

E.g. there was never a public iOS version of Firefox that I know of (not
counting Home), because the Apple walled garden wouldn't accept it
anyway, and because mozilla (and everybody else who could have forked)
apparently thought that either the smallish jailbreak population doesn't
worth the resources or that the legal situation was too complicated.
If Google would have told mozilla that Firefox for Android cannot be
accepted into the Play store, but hey, there is a way for users to
install stuff using a complicated, non-obvious process, would there be a
Firefox for Android today, and if, would it be of the same quality?

> You do need to realize that a lot of our several hundred million users
> (I would readily bargain on 90%+) wouldn't even know *how* to disable
> Windows 7's virus checker, nevermind be able to distinguish malicious
> add-ons from non-malicious ones if they were cleverly phished. Mozilla
> needs to act because of all our users, and can't let the majority suffer
> because the tech-savvy minority is able to deal with the issue by
> themselves.

Yeah, "Can somebody think of the children, please".
I don't buy your argument at all.
It is not tech-savvy vs. regular. It is about sacrificing freedom,
participation and openness in ways that are not even fully known right
now for the sake of some perceived security improvements.

Also, neither do I buy the premise that something like this really needs
be done (still remains to be demonstrated), nor that the current
proposal will actually achieve even a fraction of the stated goals to
combat Firefox-centric malware (still remains to be demonstrated, but I
seriously doubt it).

Cheers
Nils

Am 28.11.13 19:31, schrieb Jorge Villalobos:

> On 11/24/13 9:59 AM, testnu...@gmail.com wrote:
>> tl;dr
>> I *oppose* this whole concept of a walled garden strongly, on legal,
technical and "moral" (openess, Manifesto) reasons.
>>

>> There are a couple of add-ons that I cannot legally give the source
code or even binary code to mozilla, and a couple of others I simply do
not want to share.
>>

You didn't address this at all. This would be particularly important to me.

>> So, mozilla will also get finer grained information about users in
the process
>

> I don't think we would get more data than we already have from the
> Firefox Health Report and other data pings.

Remains to be seen... Also, I can opt-out of the Health report. Actually
IIRC the browser asks me what data I want to share after creating a new
profile, so it is more of an opt-in.

>>>> 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.
>>
>> You do recognize, that you'll be creating a closed system, after all?
>> Governments, the US government in particular, can force mozilla to
blacklist certain types of add-ons or compel account data. mozilla
itself can later decide to just blacklist stuff it finds offensive or
morally problematic ('various levels of "bad"').
>
> It's no different from the blocklist, and we haven't been compelled to
> block anything

Yet! And even if mozilla had, or had been compelled to turn over
information, I suppose mozilla couldn't legally talk about it anyway, US
Nation Security letters, US FISA secret court rulings, and all that...

> or have blocked anything that didn't deserve it.

Who determines what "deserves" to be blocked?

How will mozilla react when there is an add-on promoting the
legalization of pedophilia?
An add-on helping families to facilitate and plan the forced marriages
of their daughters?
What about that nice new add-on that enables users to circumvent
US-court issued DNS/IP blocks of WikiLeaks and ThePirateBay?
What if Snowden releases an add-on? He's got some time now. It will be a
Tetris-clone, because there aren't enough of that, yet.
Or what will mozilla tell the Turkish authorities about that new PKK
add-on? Alienate the Turkish government and a lot of Turkish users by
taking a stance, or alienate the Kurds instead?

Sure, you got that with a blocklist too, but with this proposal it is
not "should we block it" anymore, but "should we allow it"?

> We have
> US-centric regulations for AMO because we distribute those add-ons. If
> there are regulations that apply to files stored in non-public servers,
> we will need to evaluate our file retention policy to minimize any
> potential impact on developers.

It is vastly different to a blocklist. The proposal requires me, the
author, to provide mozilla with all kinds of information incl. my code.
Mozilla promising to evaluate the file retention policy to minimize
potential impact doesn't really help me after some government or lawyer
obtains the records. Also mozilla is still subject to US and maybe other
laws.

>> It might create legal issues in certain areas. Now that mozilla would
gain the absolute authority to allow/disallow add-ons, does it need to
name a person to oversee and implement legal age checks for porn
add-ons, as might required by local law (thinking of German law right
now; IANAL)? Is it liable if malware sometimes slips through (false
negatives), what is the situation with a false positive impacting my
business, etc.?
>
> This is not aimed at blocking content, only malicious intent. However,
> you bring good points that need to be looked at.

So, lets have the ironclad, legal definition of "malicious intent" when
it comes to software, please?
Why do you think the stated goals somehow supersede the actual laws in
different jurisdictions?

Cheers
Nils

On 11/29/2013 7:55 PM, Nils Maier wrote:
>> You do need to realize that a lot of our several hundred million users

>> >(I would readily bargain on 90%+) wouldn't even know*how*  to disable

>> >Windows 7's virus checker, nevermind be able to distinguish malicious
>> >add-ons from non-malicious ones if they were cleverly phished. Mozilla
>> >needs to act because of all our users, and can't let the majority suffer
>> >because the tech-savvy minority is able to deal with the issue by
>> >themselves.
> Yeah, "Can somebody think of the children, please".
> I don't buy your argument at all.
> It is not tech-savvy vs. regular. It is about sacrificing freedom,
> participation and openness in ways that are not even fully known right
> now for the sake of some perceived security improvements.

Just because you flip the argument to your point of view doesn't mean
that Jorge doesn't have a valid point. And though I agree that real
examples may be useful to illustrate the point of the need, your tone is
such that I don't think any amount of illustration of the competing POV
will be to your satisfaction.

> Also, neither do I buy the premise that something like this really needs
> be done (still remains to be demonstrated), nor that the current
> proposal will actually achieve even a fraction of the stated goals to
> combat Firefox-centric malware (still remains to be demonstrated, but I
> seriously doubt it).
>
> Cheers
> Nils

Well, we know it (malware) happens in IE land. You really think no one
is trying to do in in Firefox land?

I'm not saying this is a great illustration, but I just spent hours
cleaning my father in law's computer of all manner of stupid,
performance stealing mind numbing toolbar crap in IE. I'd bet if he had
Firefox that similar types of things would have been installed.

Am 30.11.13 14:51, schrieb Wayne:> On 11/29/2013 7:55 PM, Nils Maier wrote:
>>> You do need to realize that a lot of our several hundred million users
>>> >(I would readily bargain on 90%+) wouldn't even know*how*  to disable
>>> >Windows 7's virus checker, nevermind be able to distinguish malicious
>>> >add-ons from non-malicious ones if they were cleverly phished. Mozilla
>>> >needs to act because of all our users, and can't let the majority
>>> suffer
>>> >because the tech-savvy minority is able to deal with the issue by
>>> >themselves.
>> Yeah, "Can somebody think of the children, please".
>> I don't buy your argument at all.
>> It is not tech-savvy vs. regular. It is about sacrificing freedom,
>> participation and openness in ways that are not even fully known right
>> now for the sake of some perceived security improvements.
>
> Just because you flip the argument to your point of view doesn't mean
> that Jorge doesn't have a valid point. And though I agree that real
> examples may be useful to illustrate the point of the need, your tone is
> such that I don't think any amount of illustration of the competing POV
> will be to your satisfaction.

Of course, Gijs, Jorge and all the other people in this thread,
including myself, have a valid argument when saying that we must help
users protect themselves and avoid any user "suffering" in the first
place when possible.
But that is the point: Nobody could reasonably argue with that (like
nobody could argue against protecting children in general).

This killer argument doesn't imply, however, that the current walled
garden proposal is the right thing to do and without alternative, or
even a viable thing to do at all.
And undeservedly calling out people disagreeing with or raising concerns
about the current proposal for not thinking of the children... err...
users, doesn't help, either...

There already were alternative proposals, for instance:
- Improving the blocklisting system and process in general first, and
see what happens
- Having actually usable overrides that would still accommodate power
users and not just wizards, while scaring away clueless users or at
least making it harder to mess up accidentally.
- Using Gatekeeper-style developer certificates and code signing instead
of or complimentary to file registration
- And my personal favorite: All of the above!

> Well, we know it (malware) happens in IE land. You really think no one
> is trying to do in in Firefox land?

No, in fact I know that there is some Firefox malware and tons of
Firefox-compatible (what I'd consider) crapware plus a bunch of add-ons
being neither but having security vulnerabilities, privacy issues and/or
performance issues. I reported some myself.
However, I do not think that this warrants creating a walled garden,
ever, as the current proposal would. Aside from being a walled garden,
there were lots of concerns raised about the proposal, incl. technical
issues, legal matters, trust and privacy issues.
At the very least, other viable approaches must be exhausted before such
a radical step.

Also, crapware is not the focus of the proposal anymore, though it was

suggested it might be in the future. Jorge said:
> This is not aimed at blocking content, only malicious intent.

Cheers
Nils

On 30/11/13, 01:55 , Nils Maier wrote:
> Am 28.11.13 19:49, schrieb Gijs Kruitbosch:
>> I think Jorge has been pretty clear already that it will be possible for
>> users to override whatever the registration requirements are if/when
>> those eventually become a reality. We're *not* taking away your choice.
>

> No, actually he did not.
 > <snip>

> It is actually far worse than Apple Gatekeeper is right now.

You're arguing the user-friendliness of the 3 different proposed
override techniques. You acknowledge therefore, I hope, that it *is*
possible to override these restrictions. How we'll implement these
overrides can be discussed, I'm sure, but isn't central to the proposal.
As a sidenote, Gatekeeper's notifications provide no clue how to
override, either (nevermind a direct button to do so) so I strongly
disagree that we're somehow being worse by doing the same.

> E.g. if I was an Iranian dissident creating an add-on, I do not want to
> "register" that add-on with some central authority or at least shouldn't
> because that leaves more records and traces that can come back to haunt
> me than I like. Given the proposal, accounts will be using IPs,  so it
> seems rather unlikely that I could use something like TOR to register my
> add-on.

I read the proposal and saw no mention of this, merely that there'll be
IP-based throttling of account/add-on registration. That wouldn't
preclude TOR at all, AFAICT.

> E.g. there was never a public iOS version of Firefox that I know of (not
> counting Home), because the Apple walled garden wouldn't accept it
> anyway, and because mozilla (and everybody else who could have forked)

There was never a public iOS version because Apple's policies explicitly
forbid creating an app that runs remotely-provided code using anything
other than a crippled webkit webview. It has nothing to do with the
walled-garden-ness, as we're in both Amazon and Google's walled gardens
for Android.

>> You do need to realize that a lot of our several hundred million users
>> (I would readily bargain on 90%+) wouldn't even know *how* to disable
>> Windows 7's virus checker, nevermind be able to distinguish malicious
>> add-ons from non-malicious ones if they were cleverly phished. Mozilla
>> needs to act because of all our users, and can't let the majority suffer
>> because the tech-savvy minority is able to deal with the issue by
>> themselves.
>
> Yeah, "Can somebody think of the children, please".
> I don't buy your argument at all.
> It is not tech-savvy vs. regular. It is about sacrificing freedom,
> participation and openness in ways that are not even fully known right
> now for the sake of some perceived security improvements.
>
> Also, neither do I buy the premise that something like this really needs
> be done (still remains to be demonstrated), nor that the current
> proposal will actually achieve even a fraction of the stated goals to
> combat Firefox-centric malware (still remains to be demonstrated, but I
> seriously doubt it).

David Ross replied to a post by Jorge which explicitly detailed how big
the threat of malware is. It's easy to say that the negatives of the
proposal are "not even fully known" - well obviously they're not, the
policy hasn't been implemented yet and you're speculating about the
potential chilling effect. It's impossible to produce a proposal immune
to such speculating.

If you have constructive suggestions that address the malware concerns
as well as concerns regarding signed add-ons etc. (Would the Iranian
dissidents prefer contacting Verisign or associates for a cert? Would
any reputable CA want to give them a certificate (which is a voucher for
identity) with them providing no identifying data to a central registry?
I somewhat doubt it.) then I'm sure we'd love to hear it. But your
inverse argument "think of all the dissidents" isn't supported by data,
whereas Jorges point "think of all the users affected by malware" is.

~ Gijs

There are several points of interest that I would like to add here.
Note: I am a network/sysadmin, and have to deal with malware, crapware, etc.  I also work on a few personal themes/addons (especially now that Australis has landed).

I think a lot of people are making the same mistake that I did.  This thread is not about the policy decisions of what should be blocked or why, but how to block addons, when blockisting by ID is not sufficient.  There needs to be a discussion thread on the policy, but this is not it.


"Single File" and "All Files" - It looks like this is referring to addons, so each addon is sent, not each file in each addon.  Is the install.rdf excluded?  Otherwise the hash will change for each install for addons that use a random ID.

I feel this is adding hurdles for legit developers, without it being effective for malware vendors.
 - Developers are lazy.  Adding hurdles will push people away from developing addons.
 - Malware (and greyware) develpers are NOT lazy.  They will spend more effort to bypass anything that is put in place, than legit developers will to create their addons.

This proposal really only seems to apply to addons installed from within Firefox.  Any way of adding overrides for organizations or developers means that any installer (that runs as admin) can use the override and permit itself to be installed with no checks being done.  This might make things worse, because now the global preference has change and I (the sysadmin) now has to go in as admin and fix the setting after removing the addon.
 
Does this apply to Extensions/Plugins only?  Would it include themes?  I often make many changes to my theme constantly because I find something to tweak, or something else that has broken because of Mozilla changes.

On Sunday, November 10, 2013 11:30:35 AM UTC-5, Dephormation wrote:
> On the question of freewill, I don't think it should be up to you to protect me from the consequences of my own poor judgement. If I elect to install an item of software on my own computer, who are you to decide whether the consequences are in my best interest or not? Its my computer.
 
As a sysadmin, I see both sides of this.  I don't want Mozilla to determine what I can and can't install, yet I DO want users to be restricted to what Mozilla says (or I say) can and can't be installed.  I can make appropriate decisions, but users cannot (usually).


Here is my thought:
Addons should be signed.  The certificate used to sign the addon must be valid based on the certificate store.  If the certificate is not listed as valid, then the addon cannot be installed ( no certificate prompt).  This will allow developers/organizations to use a self-signed certificate(?) or private root certificate and add it to the store.  The hash of the addon, and the certificate can both be easily blocklisted.  For distribution of the addon, it would need to be signed with a purchased certificate, or signed and distributed on AMO.

What about unsigned addons?

Compile-Time option?
 - Users with old addons will lose them.  Probably not acceptable.  Only really usable by developers.  No config options that can be changed by installers, but if they can change the config option, whats to stop the installer from changing the binary?

Application level preference?
 - Changeable by installers - could negate the entire proposed system.
 
Application level whitelist?
 - Changeable by installers.  Not as friendly for developers, as they would need to update the whitelist every time they made a change.
 
Launch Option?
 - Not very user friendly and changeable by installers.
 
AMO based whitelist?
 - Known existing addons can be hashed and added.  Unknown addons and development addons can't be installed.
 
My thought here would be a combination of an AMO based whitelist, application level whitelist + user level preference.  Unsigned addons would need to be whitelisted at the application level, then be turned on or off at the user level.  Known addons can be whitelisted on AMO so as to not break most users.  The inability to reach AMO would result in failure.  Unsigned addons would always show up under about:addons with a red stripe to indicate that they are not signed.

Hi Jorge,

At this point we’ve been discussing this for a month (and about 145 posts).  We don’t seem to be making any headway toward consensus or changes, so I’m going to propose we call time on the thread.

Is it your intent to come back with a new draft to address some/all of the many concerns raised here, or do you want to push forward as-is without modifications?  If the former, we should stop arguing about the current proposal until there’s a new version.  If the latter, I think we’re at the point where I’d like to see the Firefox product ownership make a call whether to adopt or reject the proposal.

— Mike

On Oct 30, 2013, at 5:55 PM, Jorge Villalobos <jo...@mozilla.com> 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

Am 02.12.13 13:47, schrieb Gijs Kruitbosch:

> On 30/11/13, 01:55 , Nils Maier wrote:
>> Am 28.11.13 19:49, schrieb Gijs Kruitbosch:
>>> I think Jorge has been pretty clear already that it will be possible for
>>> users to override whatever the registration requirements are if/when
>>> those eventually become a reality. We're *not* taking away your choice.
>>
>> No, actually he did not.
>> <snip>
>
>> It is actually far worse than Apple Gatekeeper is right now.
>
> You're arguing the user-friendliness of the 3 different proposed
> override techniques. You acknowledge therefore, I hope, that it *is*
> possible to override these restrictions.

No, I do not acknowledge that the current proposal makes it possible for
regular users to use overrides, exactly because of the lack of
user-friendliness. The result is the same as no overrides at all.

> How we'll implement these
> overrides can be discussed, I'm sure, but isn't central to the proposal.

So, far it sounded pretty central to the proposal and was a major part
of the ongoing discussion. And for me, it is pretty central to the
proposal, because without workable overrides you have a walled garden
that acts as a prison instead of a fortress.

> As a sidenote, Gatekeeper's notifications provide no clue how to
> override, either (nevermind a direct button to do so) so I strongly
> disagree that we're somehow being worse by doing the same.

A somewhat tech-literate user can google and can resolve that in a few
clicks. I can tell people how to override Gatekeeper on the phone.
That's the point here.
We're not doing the same with this proposal.

>> E.g. if I was an Iranian dissident creating an add-on, I do not want to
>> "register" that add-on with some central authority or at least shouldn't
>> because that leaves more records and traces that can come back to haunt
>> me than I like. Given the proposal, accounts will be using IPs,  so it
>> seems rather unlikely that I could use something like TOR to register my
>> add-on.
>
> I read the proposal and saw no mention of this, merely that there'll be
> IP-based throttling of account/add-on registration. That wouldn't
> preclude TOR at all, AFAICT.

Once you have IP throttling, people will work around that. Once people
work around that, somebody will use the IP pool that is TOR if they
currently do not have a botnet at their disposal. Which will either
eventually land all exit nodes on the block list or throttle list, or
will cause OPS to block exit nodes explicitly due to constant abuse. Try
using TOR to use Google with a few different TOR exit nodes, or try to
make a Wikipedia edit if you don't believe this to happen.

>> E.g. there was never a public iOS version of Firefox that I know of (not
>> counting Home), because the Apple walled garden wouldn't accept it
>> anyway, and because mozilla (and everybody else who could have forked)
>
> There was never a public iOS version because Apple's policies explicitly
> forbid creating an app that runs remotely-provided code using anything
> other than a crippled webkit webview. It has nothing to do with the
> walled-garden-ness, as we're in both Amazon and Google's walled gardens
> for Android.

This has everything to do with walled gardens. Without their walled
garden, it would be hard if not impossible for Apple to enforce these
polices.
Google and Amazon just happen to be more lenient in their policies at
the moment, but in theory could at any time decide to kick out any app
they don't like, or be forced to kick out any app.
And Google did kick out non-malware apps already: See the CyanogenMod
installer just a few days ago. Or the porn ban, in particular for Google
Glass. And all that is enforced by having a walled garden. Normal
Android has usually still that override, but Glass does not AFAIK.

This is also why workable overrides are crucial if you want to guarantee
openness and still have a walled garden for those who wish to outsource
their security-related decisions.

> If you have constructive suggestions that address the malware concerns
> as well as concerns regarding signed add-ons etc. (Would the Iranian
> dissidents prefer contacting Verisign or associates for a cert? Would
> any reputable CA want to give them a certificate (which is a voucher for
> identity) with them providing no identifying data to a central registry?
> I somewhat doubt it.) then I'm sure we'd love to hear it.

Gatekeeper style certs would require interacting with mozilla not
<random CA>. Should mozilla become aware that a cert is used to sign
malware, it can revoke the cert, same as blacklisting hashes under the
current proposal. Mozilla does not know about identities to issue certs
the same way it does not know about identities in the current proposal.
Anyway, an Iranian dissident would likely go the overrides route, which
means it has to exist and be viable.

I did propose alternatives and so did other folks. I gave a summary of
some in the very email you're replying and did write up a rough counter
proposal compromise in a grandfather of this thread branch under my
gmail address, which is devcerts + viable overrides. So what exactly are
you asking?

> But your
> inverse argument "think of all the dissidents" isn't supported by data,
> whereas Jorges point "think of all the users affected by malware" is.

Neither claim is supported by any data, right now. Neither my chilling
effects claim nor the claim that the current proposal would noticeably
improve the situation to the extend where creating a walled garden,
which is at the very least a legal and technical burden for all parties
involved, is warranted.
There is a difference though: While not supported by data in this
particular case, chilling effects are a real phenomenon that is
acknowledged and discussed by academia (in particular law and
psychology) and popular culture alike. Research into and discussion
about the tech walled gardens (social networks and app stores in
particular) only recently started to take off, because they exist as a
mass medium only since a couple of years.
To undoubtedly prove there are chilling effects, you'd need to prove
that some add-ons will not be created or delayed as the outcome, which
means to prove a negative of something in the future. Not exactly fair.

Speaking of data: A huge concern is the add-on "dark matter", aka.
add-ons we don't know anything about except for their id, proving their
existence. Have the Health Report or a new tool collect more information
about these add-ons, after the user opting in, from dumping the
install.rdf up to uploading the whole add-on. Have that new report
include installation sources and/or installation file paths where known.
Right now we're talking about a few distinct malware per month that we
actually know of... On average, this is a number I can still count using
only one of my hands.

Cheers
Nils

Again, I disagree. It's possible to provide UI for the locked pref, or
for the commandline switch (like we do for safe mode). Whether and how
we do that is a separate debate to whether the proposal is technically
sound, whether other concerns make it impractical or wrong, or whether
there's a better way to achieve the stated aims than file registration.

>
>>> E.g. if I was an Iranian dissident creating an add-on, I do not want to
>>> "register" that add-on with some central authority or at least shouldn't
>>> because that leaves more records and traces that can come back to haunt
>>> me than I like. Given the proposal, accounts will be using IPs,  so it
>>> seems rather unlikely that I could use something like TOR to register my
>>> add-on.
>>
>> I read the proposal and saw no mention of this, merely that there'll be
>> IP-based throttling of account/add-on registration. That wouldn't
>> preclude TOR at all, AFAICT.
>
> Once you have IP throttling, people will work around that. Once people
> work around that, somebody will use the IP pool that is TOR if they
> currently do not have a botnet at their disposal. Which will either
> eventually land all exit nodes on the block list or throttle list, or
> will cause OPS to block exit nodes explicitly due to constant abuse. Try
> using TOR to use Google with a few different TOR exit nodes, or try to
> make a Wikipedia edit if you don't believe this to happen.

Are all exit nodes on the blocklist for Wikipedia or Google? (presumably
not)

If not, why would that happen here? I don't find the slippery slope
you're using here all that steep or slippery.

>>> E.g. there was never a public iOS version of Firefox that I know of (not
>>> counting Home), because the Apple walled garden wouldn't accept it
>>> anyway, and because mozilla (and everybody else who could have forked)
>>
>> There was never a public iOS version because Apple's policies explicitly
>> forbid creating an app that runs remotely-provided code using anything
>> other than a crippled webkit webview. It has nothing to do with the
>> walled-garden-ness, as we're in both Amazon and Google's walled gardens
>> for Android.
>
> This has everything to do with walled gardens. Without their walled
> garden, it would be hard if not impossible for Apple to enforce these
> polices.
> Google and Amazon just happen to be more lenient in their policies at
> the moment, but in theory could at any time decide to kick out any app
> they don't like, or be forced to kick out any app.
> And Google did kick out non-malware apps already: See the CyanogenMod
> installer just a few days ago. Or the porn ban, in particular for Google
> Glass. And all that is enforced by having a walled garden. Normal
> Android has usually still that override, but Glass does not AFAIK.
>
> This is also why workable overrides are crucial if you want to guarantee
> openness and still have a walled garden for those who wish to outsource
> their security-related decisions.

My point was that the policy and the ease of entry/exit for both users
and developers determines the height of the walls of the walled garden.
To a certain degree the internet in itself is a walled garden because I
need to pay an ISP to get linked up to it (or gain access some other
way). There are always barriers. Google's/Amazon's barriers are lower
than Apple's, and the ones in this proposal are far lower still, so I
find the comparisons you're making unfair. Requiring developers to
obtain certificates from Mozilla has essentially many of the same
problems as requiring file registration. I'll get to this in a bit.

>> If you have constructive suggestions that address the malware concerns
>> as well as concerns regarding signed add-ons etc. (Would the Iranian
>> dissidents prefer contacting Verisign or associates for a cert? Would
>> any reputable CA want to give them a certificate (which is a voucher for
>> identity) with them providing no identifying data to a central registry?
>> I somewhat doubt it.) then I'm sure we'd love to hear it.
>
> Gatekeeper style certs would require interacting with mozilla not
> <random CA>. Should mozilla become aware that a cert is used to sign
> malware, it can revoke the cert, same as blacklisting hashes under the
> current proposal. Mozilla does not know about identities to issue certs
> the same way it does not know about identities in the current proposal.
> Anyway, an Iranian dissident would likely go the overrides route, which
> means it has to exist and be viable.

I don't see how this system is any better than the file registration
one. If there's no guarantee of identity, on what basis do we give out
certificates? How do we stop malware companies from requesting arbitrary
numbers of certificates instead of generating arbitrary add-on IDs? If
we're using IPs or email addresses to throttle, we're back to the same
problems you outlined earlier, because we would have to be able to
connect certificates to add-on IDs (in order to figure out which certs
to block), which means that the same "we have a database, what about law
enforcement" problem or the "we have a database, what if we make the
rules stricter" exists again as well.

You avoid the need for a database (which you contest is a liability) by
requiring true identity verification to obtain a cert, but that makes
life hard for everyone because good identity checks are by nature never
free in both the 'money' and 'time' categories.

> I did propose alternatives and so did other folks. I gave a summary of
> some in the very email you're replying and did write up a rough counter
> proposal compromise in a grandfather of this thread branch under my
> gmail address, which is devcerts + viable overrides. So what exactly are
> you asking?

The problem is that in another branch of this thread signed add-ons and
their problems were already discussed. You didn't provide any detail on
how to address those problems.

>> But your
>> inverse argument "think of all the dissidents" isn't supported by data,
>> whereas Jorges point "think of all the users affected by malware" is.
>
> Neither claim is supported by any data, right now. Neither my chilling
> effects claim nor the claim that the current proposal would noticeably
> improve the situation to the extend where creating a walled garden,
> which is at the very least a legal and technical burden for all parties
> involved, is warranted.

How is Jorge's post that details blocklist data as well as "unknown,
malicious" add-on counts not data?

~ Gijs

Yes, I agree that this has run fairly long and there are some concerns
that we need to revise and see what can be done to address them. We have
been talking to Firefox Product ownership about this in the past weeks,
and we have concluded it's best to take a step back and re-evaluate the
proposal. Whatever we conclude from that will be shared and discussed in
a new thread in this channel.

Thank you all for your feedback. It has been very valuable.

Jorge

On 12/2/13 10:47 AM, Mike Connor wrote:
> Hi Jorge,
>

> At this point we�ve been discussing this for a month (and about 145 posts).  We don�t seem to be making any headway toward consensus or changes, so I�m going to propose we call time on the thread.
>
> Is it your intent to come back with a new draft to address some/all of the many concerns raised here, or do you want to push forward as-is without modifications?  If the former, we should stop arguing about the current proposal until there�s a new version.  If the latter, I think we�re at the point where I�d like to see the Firefox product ownership make a call whether to adopt or reject the proposal.
>
> � Mike

Am 02.12.13 18:48, schrieb Gijs Kruitbosch:
OK, so we were a bit talking past each other, I think...
I don't so much care about what is possible, but what is actually part
of the current proposal.
Overrides are not merely an unimportant implementation detail to me, but
one of the core questions the proposal has to address, and do so
properly and in detail.

>>> I read the proposal and saw no mention of this, merely that there'll be
>>> IP-based throttling of account/add-on registration. That wouldn't
>>> preclude TOR at all, AFAICT.
>>
>> Once you have IP throttling, people will work around that. Once people
>> work around that, somebody will use the IP pool that is TOR if they
>> currently do not have a botnet at their disposal. Which will either
>> eventually land all exit nodes on the block list or throttle list, or
>> will cause OPS to block exit nodes explicitly due to constant abuse. Try
>> using TOR to use Google with a few different TOR exit nodes, or try to
>> make a Wikipedia edit if you don't believe this to happen.
>
> Are all exit nodes on the blocklist for Wikipedia or Google? (presumably
> not)

Getting somewhat off-topic, but Wikipedia at least tries:
http://simple.wikipedia.org/wiki/Wikipedia:Blocks_and_bans#Proxies
I don't use TOR regularly these days, but when I do, I usually cannot
use Google, because the exit node IP is usually blocked (as a bot :p) to
the point where even the "I'm a human" captchas have no effect.

> If not, why would that happen here? I don't find the slippery slope
> you're using here all that steep or slippery.

Because authors of all kinds will (ab)use TOR exit nodes, and there is
only a very finite amount of these. Sooner than later the majority or
even all exits will be on the throttled list or even blocked due to
excessive amounts of registration requests from a single IP. It is
enough to have just the majority of exits on the list instead of every
single one because the burden to reconfigure TOR and find an exit that
still works will be too much for most add-on authors trying to release
through TOR.
I base this on historic observations you can google up yourself but also
on my own historic observations having run different TOR exit nodes for
a couple of years myself in the past, with a valid abuse@ contact.

> My point was that the policy and the ease of entry/exit for both users
> and developers determines the height of the walls of the walled garden.

Then you should have said this, instead of your "nothing to do with
walled gardens" ;)

> To a certain degree the internet in itself is a walled garden because I
> need to pay an ISP to get linked up to it (or gain access some other
> way). There are always barriers.

True. Although the Internet is (or at least used to be) about freedom
and openness, without a single central authority or government
controlling the whole of it (doesn't mean that nobody tries), in
contrast to an app store walled garden.

>> Gatekeeper style certs would require interacting with mozilla not
>> <random CA>. Should mozilla become aware that a cert is used to sign
>> malware, it can revoke the cert, same as blacklisting hashes under the
>> current proposal. Mozilla does not know about identities to issue certs
>> the same way it does not know about identities in the current proposal.
>> Anyway, an Iranian dissident would likely go the overrides route, which
>> means it has to exist and be viable.
>
> I don't see how this system is any better than the file registration
> one.

It is not better, walled garden-wise. It is better, however, when it
comes to other issues, such as not having to turn actual code over to a
Corp. within US jurisdiction, especially when one is not legally allowed
or willing to share code with third parties of any kind.
Combined with viable overrides, I therefore consider signing a
compromise I'd make.

> If there's no guarantee of identity, on what basis do we give out
> certificates? How do we stop malware companies from requesting arbitrary
> numbers of certificates instead of generating arbitrary add-on IDs?

Same (non-)way we would stop malware authors from registering arbitrary
numbers of "randomized", obfuscated files...

> If we're using IPs or email addresses to throttle, we're back to the same
> problems you outlined earlier, because we would have to be able to
> connect certificates to add-on IDs (in order to figure out which certs
> to block), which means that the same "we have a database, what about law
> enforcement" problem or the "we have a database, what if we make the
> rules stricter" exists again as well.

Again, agreed. And that's why overrides are crucial. It is the overrides
that make this a fortress with guarded gates instead of a prison. It is
the overrides which allow users to continue using an add-on even though
some secret court issued mozilla a takedown order for whatever
legitimate or illegitimate reason.

> You avoid the need for a database (which you contest is a liability) by
> requiring true identity verification to obtain a cert, but that makes
> life hard for everyone because good identity checks are by nature never
> free in both the 'money' and 'time' categories.

I don't require "true identity verification", though.
Otherwise, same as file registration: Both are non-free. I need to spend
time and potentially money to upload each and every version of an add-on
to the registration service or spend time and potentially money to hack
together an API client and integrate that into my process.
I may need to get clearance from legal or copyright holders before I can
upload the code. Maybe I can't get the clearance and am hosed.

>> I did propose alternatives and so did other folks. I gave a summary of
>> some in the very email you're replying and did write up a rough counter
>> proposal compromise in a grandfather of this thread branch under my
>> gmail address, which is devcerts + viable overrides. So what exactly are
>> you asking?
>
> The problem is that in another branch of this thread signed add-ons and
> their problems were already discussed. You didn't provide any detail on
> how to address those problems.

IIRC there was no real discussion about code signing Gatekeeper-style,
or I missed that.

I saw some comments about how jetpack repackaging didn't work well in
the past and that code signing would be somehow similar to jetpack
repackaging.
Well, jetpack repackaging is not the same. Jetpack repackaging
essentially modified the code and the zip (XPI) contents/structure, and
failed when the SDK was used in unexpected ways or the XPI was packaged
in unexpected ways, or when the XPI was code signed (because the
signature wouldn't match anymore, obviously). Code signing can be done
without actually touching the code or the contents/structure of the zip.
Even the current NSS signtool-style code signing (essentially Java JAR
code signing), which adds a couple of signature files to the zip in a
known location should be compatible with all XPIs except of course
already signed ones.
There are problems with this approach, e.g. the recent APK signature
vulnerability due to different implementations handling different zip
file entries with the same name differently. (Like XPI, an APK is a JAR
is a ZIP). But you could throw code at that. Most of these problems
originate in the zip format itself and a file registry would also have
to deal with that, or create a new format (derivative) format that has
no such undefined edge cases.
You could also just append the signature to a zip file, placing it after
the [end of central directory record] and not hashing individual zip
files but the whole zip as-is, or reuse the ".ZIP file comment" in [end
of central directory record] for the same purpose.

Another issue with code signing is: If a user modifies the XPI after it
was code signed, the signature won't match anymore. A file registry has
the same "problem" and this can be addressed by either
re-signing/re-registering the modified add-on. Or overrides. ;)

Also, Gatekeeper-style code signing has different properties than
regular CA-issued cert code signing.
Mozilla would be in control over the certificates, cert revocation
procedures and deployed technology, same as with a file registry, hash
revocation procedures and deployed technology. Certs are just a level of
indirection which removes the requirement to pass over code.

>>> But your
>>> inverse argument "think of all the dissidents" isn't supported by data,
>>> whereas Jorges point "think of all the users affected by malware" is.
>>
>> Neither claim is supported by any data, right now. Neither my chilling
>> effects claim nor the claim that the current proposal would noticeably
>> improve the situation to the extend where creating a walled garden,
>> which is at the very least a legal and technical burden for all parties
>> involved, is warranted.
>
> How is Jorge's post that details blocklist data as well as "unknown,
> malicious" add-on counts not data?

Just because there is data, doesn't mean the data supports a claim. Show
me how "there is some malware we know: see blocked list, and we know
some add-ons, malware or just crapware, use random ids, and there is a
lot of add-ons we know nothing about" aka. the "data" supports the claim
that there is a massive enough malware problem so that we need to create
a walled garden, and why that data suggests that improving and enhancing
our existing tools and procedures is not sufficient.
Since you seem to favor the current proposal, which you more or less
admit is a walled garden and therefore not really in the "openness"
spirit of our Manifesto, it should be your job to explain to me and
other folks who don't get it why it is a sound proposal and the right
thing to do(tm), its benefits outweigh the issues it creates and why my
concerns are either invalid or how they are addressed, not the other way
round.

Cheers
Nils

On 12/02/2013 11:06 AM, Jorge Villalobos wrote:
> Yes, I agree that this has run fairly long and there are some concerns
> that we need to revise and see what can be done to address them. We have
> been talking to Firefox Product ownership about this in the past weeks,
> and we have concluded it's best to take a step back and re-evaluate the
> proposal. Whatever we conclude from that will be shared and discussed in
> a new thread in this channel.
>
> Thank you all for your feedback. It has been very valuable.
>
> Jorge
>

Please try to have as much of the discussion as possible on the list and
to try to make the meetings public at least through dial in.

It appeared to me that the original announcement was the result of a
great deal of thought, work and planning but that it came as a complete
surprise to everyone not directly involved. While the approach may be
necessary to alleviate the issues our users are facing, the shock of the
announcement served as a detriment to reaching a consensus. The feeling
that the decision was already made and we were facing a fait accompli
was disturbing to say the least.

/bc

On 02/12/13 19:06, Jorge Villalobos wrote:
> Thank you all for your feedback. It has been very valuable.

Thank you for your constructive and patient engagement :-)

Gerv

We meet every other week and have a meeting next Monday:
https://wiki.mozilla.org/AMO/Squeaky#Meetings. You can also read the
meeting notes and/or post on our newsgroup if you can't attend.

We plan to discuss a draft of the new proposal then, if we manage to
have it ready.

Jorge

Sorry, I haven't dug around a lot, but I ask a quick question on whether the Squeaky site will have a public API?

I'd be especially interested if the malware checks could be generalized so that my AsYouWish add-on (or possibly its users) can make checks for a file's integrity (even if not a fully built XPI) before downloading it for evaluation (or execution if such checks could be possible)?