> In short, I would love to see a way of blocking 3rd party unvetted addon installation, but we
> need to figure out what we're doing with testing first.

> I believe that trying to make doing the Right Thing easy for everybody else is more likely to
> lead to a better experience for the user, rather than trying to make the bad things hard.

On 24/02/2012 1:19 p.m., Jeff Hammel wrote:
> While mentioned in the linked etherpad, currently all of our testing
> infrastructure relies on just shoving some.xpi or some/directory into
> browser/bundles or the extensions folder, etc.  So we'd need a solution
> to that before going forward.  It has been mentioned having a preference
> to toggle allowing 3rd party installation, of course if we can change it
> in automation, others will be able to too.

> An add-on is as powerful as a patch to browser.js.

> Any of the following would be a great improvement, IMO:
>
>   (1) disallowing add-ons installed by third parties, as suggested here.
>   (2) requiring that all add-ons installed by third parties be signed
> by the AMO team [2].
>   (3) testing the most popular add-ons installed by third parties and
> aggressively courting fixes from the relevant developers.

On 2/23/2012 7:05 PM, Nicholas Nethercote wrote:
> Third-party add-on installs can certainly be an avenue for
> crapware/malware.  I was wondering what the legitimate use cases for
> them were, so Blair McBride and I set up an etherpad that discusses
> the pros and cons of all three add-on installation methods, which I
> thought might be of interest.  It's here:
> https://etherpad.mozilla.org/6vA99EFgNT.

On 02/24/12 02:57, Blair McBride wrote:
> On 24/02/2012 1:19 p.m., Jeff Hammel wrote:
>> While mentioned in the linked etherpad, currently all of our testing
>> infrastructure relies on just shoving some.xpi or some/directory into
>> browser/bundles or the extensions folder, etc. So we'd need a solution
>> to that before going forward. It has been mentioned having a preference
>> to toggle allowing 3rd party installation, of course if we can change it
>> in automation, others will be able to too.
>
> I think that's a red herring - whatever we end up deciding to do to
> about 3rd party/foreign installs, keeping the testing infrastructure
> working will be a comparatively easy problem to solve.

 > In the worst case
> scenario, we just have slightly different behaviour when --enable-tests
> is used. Even if it somehow ends up being awkward, I'd still rather
> solve user experience problems first, and worry about tests later.

On 02/24/12 08:36, Benjamin Smedberg wrote:
> I think it's worthwhile to discuss whether these integration addons are
> ultimately helping or hurting our users, in aggregate. But I'm afraid
> that if we remove the integration points we have now, it's likely that
> some of these third-party apps will simply revert to more invasive
> methods of shoving files into the Firefox directory or mucking about in
> the profile directory, which would mean that users have less control.

On 2/24/2012 9:34 AM, Asa Dotzler wrote:
>> I don't deny that the system has problems I just worry a lot too about
>> what the third-party apps will start to do if we make things harder.
>> Frankly I've also never really figured out a way to make things harder
>> that isn't trivial to circumvent, kills our startup performance or
>> removes useful functionality (though perhaps we don't care about some of
>> that).
>
> I know you guys are much smarter than me and have thought about this
> much more deeply than I have, but I'm simply not willing to walk away
> from this problem because it's "too hard."
>

On Sat, Feb 25, 2012 at 4:46 AM, Clint Talbert <ctal...@mozilla.com> wrote:
> I think we need to solve this by turning it around from a "how do we defend
> Firefox against X" question to a "what do the users want from these addons,
> and what do the developers of the legitimate sets of these addons hope to
> provide" question.

ctalbert wrote:
> I don't think anyone is shying away from this because it's hard. People are unwilling to lose
> these defined integration points because by removing the integration point, you're just
> building a higher wall for a developer to leap over to get their extension into Firefox.

But earlier in this thread, Dave Townsend wrote:

> Everytime we've found a bad actor trying to bypass restrictions we've put in place they've
> done so in a hacky way that ended up being even more detrimental to the user's experience > (often force enabling every single add-on they had installed).

> Likewise everytime I can think of that we've seen an issue with a third party add-on we've
> been able to use our existing policy and technical capabilities to push the developers to
> correct their mistake.

ctalbert wrote:
> Assume for a moment that the addon developer has spent several hours/days/weeks on
> whatever this is (be it useful stuff, crapware, malware whatever) and wants to get it into
> Firefox. They will not be deterred. If getting something into Firefox is that important to them,
> then they will. If we really wanted to shut down all external integration points to Firefox we
> could. It wouldn't provide a great user experience, but neither does security by building a
> higher wall and hoping that your adversaries don't build a taller ladder.

On Fri, Feb 24, 2012 at 8:54 PM, Justin Lebar <justi...@gmail.com> wrote:
>
> Any of the following would be a great improvement, IMO:
>
>  (1) disallowing add-ons installed by third parties, as suggested here.
>  (2) requiring that all add-ons installed by third parties be signed
> by the AMO team [2].
>  (3) testing the most popular add-ons installed by third parties and
> aggressively courting fixes from the relevant developers.
>

> Judging by how poorly (2) was received by the add-ons people, I don't
> think (1) or (2) is likely to fly.  (3) seems worse to me, but it
> would still be a huge step forward.

Clint said:

> I think we need to solve this by turning it around from a "how do we defend
> Firefox against X" question to a "what do the users want from these addons,
> and what do the developers of the legitimate sets of these addons hope to
> provide" question. With the users squarely in mind, I believe we can make
> much better decisions.

> If we frame the problem as "defending Firefox from
> malicious crap" then the solution we create isn't going to be as complete as
> it could otherwise be.

> - It's interesting that several add-ons (e.g. Yahoo! Toolbar,
> Microsoft .NET Framework Assistant) are hosted on AMO but the vast
> majority of the installations are not from AMO.  This could mean
> there's a prominent alternative location that the add-on can be
> installed from, but I suspect third-party installs are mostly
> responsible.

>
> - Apart from the anti-virus add-ons, I don't recognize anything in
> that list that provided integration between Firefox and other apps.  I
> could well be missing some, though.

>
> - There are 17 add-ons that have "toolbar" in their name.
>
>
>> If we frame the problem as "defending Firefox from
>> malicious crap" then the solution we create isn't going to be as complete as
>> it could otherwise be.
>
> That's true.  But the evidence suggests that "defending Firefox from
> malicious crap" has to be a sizeable part of the solution.

> If I install a VoIP app, I don't expect it to add functionality to my
> browser.

> If I install an IM app, I don't expect it to add functionality to my
> browser.

> If I install an anti-virus package, I expect it to scan downloads for
> viruses and I might expect it to scan RAM for malware signatures, but
> I don't want it to take screen real estate in my browser (toolbars),
> to make the browser leak memory like crazy or to take over the
> browser's built-in password manager or phishing protection features.

On 2/25/2012 6:01 AM, Justin Lebar wrote:
> ctalbert wrote:
>> I don't think anyone is shying away from this because it's hard. People are unwilling to lose
>> these defined integration points because by removing the integration point, you're just
>> building a higher wall for a developer to leap over to get their extension into Firefox.
> But earlier in this thread, Dave Townsend wrote:
>
>> Everytime we've found a bad actor trying to bypass restrictions we've put in place they've
>> done so in a hacky way that ended up being even more detrimental to the user's experience>  (often force enabling every single add-on they had installed).
> Lots of other people have expressed a similar sentiment in bugs.  So I
> think Asa's point that he rejects the idea that we can't do anything
> about this problem is fair.

> There seem to be several possible problems we're talking about:
>
> 1) the user doesn't know that Firefox is loading addons making their
> software slow
> 2) The user chose to install a 3rd-party app which came with an extension,
> chose to enable the extension, and it's still slow/eats memory/is "bad"

> It is my understanding that we've already solved (or attempted to solve) #1
> by prompting users to opt in to 3rd-party addons we discover on the system.

> So, assuming that is correct, are you saying that the problem is that users
> chose to keep these addons even though they are actually bad for the user?
> Or that our fix for #1 was insufficient in some way?

> Merely removing the 3rd-party install *install
> locations* will take us straight back to 2004 where these unwanted addons
> use hackery to put themself into a different location.
>
> If we want to actively prevent any unknown code from being run with Firefox,
> we need to focus on the policy implications and signing requirements.

> Indeed, I don't think a user *can* give informed consent without
>
> a) Reading the extension's source, or
> b) Delegating trust to a third-party (e.g. Mozilla), or
> c) Clicking through a Very Scary dialog.
>
> At the moment, none of these criteria are met for third-party add-ons.
>

>
> I don't think our opt-in screen is sufficient to get informed consent
> from a user.  Additionally, it does not fix #1.
>

On 28/02/12 09:20, David Illsley wrote:
> There are plenty of addons that won't/shouldn't be/can't be hosted on

> 'registered developer' program which signs addons in exchange for
> agreement to additional terms, but doesn't provide hosting would allow
> additional terms, simpler revocation rules, and known contact details
> to non-amo hosted addons.

On Mon, Feb 27, 2012 at 1:25 PM, Justin Lebar <justi...@gmail.com> wrote:
>> There seem to be several possible problems we're talking about:
>>
>> 1) the user doesn't know that Firefox is loading addons making their
>> software slow
>> 2) The user chose to install a 3rd-party app which came with an extension,
>> chose to enable the extension, and it's still slow/eats memory/is "bad"
>
> I'd add
>
> 3) The user chose to enable a third-party extension, but did not give
> informed consent.

On Mon, Feb 27, 2012 at 10:21 PM, Robert Kaiser <ka...@kairo.at> wrote:
> Henri Sivonen schrieb:
>
>> If I install a VoIP app, I don't expect it to add functionality to my
>> browser.
>
> _YOU_ don't. A number of users will find it convenient though that they can
> click on any phone number in any website and call it via Sk..., er, I mean,
> that VoIP app.

>> If I install an IM app, I don't expect it to add functionality to my
>> browser.
>
> _YOU_ don't. OTOH, a user might love to be able to search for their IM
> contacts' online profiles from the browser (similar to what we even
> advertised with twitter recently) or have a "send message" on those web
> profiles automatically send via their IM app, or share a website through IM
> instantly from the browser (similar to what have in mind with our share
> functionality in Firefox itself).

>> If I install an anti-virus package, I expect it to scan downloads for
>> viruses and I might expect it to scan RAM for malware signatures, but
>> I don't want it to take screen real estate in my browser (toolbars),
>> to make the browser leak memory like crazy or to take over the
>> browser's built-in password manager or phishing protection features.
>
> Well, I know definitely of users who want to additional "scan for malware on
> websites", "defend against website script malware" and similar functionality
> that some of those "security suites" ("anti-virus package" is ancient
> language) install nowadays. That might even include a "security rating" or
> such displayed inside a browser toolbar.

On Tue, Feb 28, 2012 at 3:13 AM, Neil <ne...@parkwaycc.co.uk> wrote:
>>
>> - An external program "installs" the add-on (by placing it in the
>> appropriate location);  it's disabled within Firefox by default.
>> - The user starts Firefox.
>> - That's it... unless the user genuinely wants to enable the add-on,
>> whereupon they can visit the add-ons manager and enable it there.
>
> How would they know that it was there?

>
> - An external program "installs" the add-on (by placing it in the
> appropriate location);  it's disabled within Firefox by default.
> - The user starts Firefox.

> What if was instead like this:
>

> - An external program "installs" the add-on (by placing it in the
> appropriate location);  it's disabled within Firefox by default.
> - The user starts Firefox.
> - That's it... unless the user genuinely wants to enable the add-on,
> whereupon they can visit the add-ons manager and enable it there.

On Mon, Feb 27, 2012 at 9:21 PM, Robert Kaiser <ka...@kairo.at> wrote:
> Henri Sivonen schrieb:
>
>> If I install a VoIP app, I don't expect it to add functionality to my
>> browser.
>
> _YOU_ don't. A number of users will find it convenient though that they can
> click on any phone number in any website and call it via Sk..., er, I mean,
> that VoIP app.
>

On 02/29/12 07:56, Jonas Sicking wrote:
> There seems like there are a couple of things that we could obviously
> do to help users in this:
>
> 1. Addons should always always be possible to uninstall using
> about:addons. Any addon which can't be completely uninstalled this way
> should be mercilessly blocked. In this scenario the user has clearly
> made a decision not to run a particular addon and so we should enable
> that. Ideally simply disabling the addon should work in which case the
> user can easily reenable the addon again. There are simply no excuses
> for making it hard for the user to disable an addon. If this is due to
> technical limitations at our end, all the better since fixing that is
> in our hands.

> However, looking at the data provided by Nick in this thread, I think
> it's safe to say that it's very common for users to end up with addons
> that they don't want to have.

> * Stop fighting against anti-malware vendors, stop treating their software as though IT is malware (which, honestly, is what we normally do, because we think it tends to slow down Firefox too much), and work directly with them to our integration hooks so that their products integrate directly with Firefox in an optimal way that doesn't have huge performance costs, so that their software can help protect users from bad addons before they get installed.

On Wed, Feb 29, 2012 at 12:48 AM, Brian Smith <bsm...@mozilla.com> wrote:
> Asa Dotzler wrote:
>> I know you guys are much smarter than me and have thought about this
>> much more deeply than I have, but I'm simply not willing to walk away
>> from this problem because it's "too hard."
>>
>> We cannot allow our users to be abused like this. I think all of the
>> interested parties need to get together for a day or 10 and figure
>> something out. We cannot leave things as they are.
>
> Unintentionally bad addons can be dealt with relatively easily, if we are willing to forgo addon compatibility and if we are willing to reduce the functionality available to addons.
>
> But, even if we do that, it will do little to stop intentionally malicious/subversive software. To protect against intentional abuse at the user-mode level (like Firefox normally runs) we can:
>
> * Give users more information about things they are about to download, and explain to users the negative consequences of running an installer before they download and/or run it. This works when the user downloads the installer using a Mozilla product (Firefox and/or Thunderbird).
>

> * Stop fighting against anti-malware vendors, stop treating their software as though IT is malware (which, honestly, is what we normally do, because we think it tends to slow down Firefox too much), and work directly with them to our integration hooks so that their products integrate directly with Firefox in an optimal way that doesn't have huge performance costs, so that their software can help protect users from bad addons before they get installed.
>

On 2/29/2012 10:33 AM, Robert Kaiser wrote:
>
> I think we all agree that users should be in charge of what add-ons they
> get or don't get. We need to make sure they can get those they actually
> want, though, as much as we need to make sure they don't get those they
> don't want.
>
> Robert Kaiser

On 01.03.2012 00:23, Asa Dotzler wrote:
> I think it is important enough by a wide enough margin that I'm support
> making it harder for third party software and non-AMO sites to install
> add-ons into Firefox so as to protect users from unwanted add-on
> infections.

>
> We should also make it much easier to install add-ons from within
> Firefox or from AMO, providing a carrot for developers to use our
> system where possible. We should also work with the few legitimate
> add-ons hosted outside of AMO (like the AV guys) to give them the APIs
> they need so they don't break the Firefox experience and potentially
> providing them with somewhat lowered barriers to third party software
> installs if they agree to live by the spirit of our policies.
>
> This is a problem with no one-size-fits-all solution. There is no
> requirement that we treat all add-ons equally.
>
> Firefox is our product and we have the right to protect it and our
> users from infection by unwanted crap. We should have policies and
> technology that bias towards user control, but knowing that will
> negatively impact some legitimate use cases, we should be willing to
> make exceptions for specific add-ons where we have confidence in their
> origin and user impact.
>
> If an add-on author wants to piggy back on the success of Firefox,
> they have to play by our rules. If they don't want to play by our
> rules, let them build and ship a browser of their own.
>
> - A

Robert Strong wrote:
> If we want an add-on identified as malware by AV vendors our first
> step should be to blocklist them and on the blocklist page we should
> state that the add-on is categorized as malware especially since this
> has been possible for quite some time.

Asa Dotzler wrote:
> Firefox 8 conformation) and in policy. If add-ons attempt to
> circumvent Firefox's security features or violate our policies,
> we should work with AV vendors to have them identified as
> malware and we should use our very capable public voice to
> shame them into fixing their behavior or to put them out of
> business.

> potentially providing them with somewhat lowered barriers to
> third party software installs if they agree to live by the
> spirit of our policies.

> If an add-on author wants to piggy back on the success of Firefox,
> they have to play by our rules. If they don't want to play by our
> rules, let them build and ship a browser of their own.

On Wed, Feb 29, 2012 at 5:27 PM, Brian Smith <bsm...@mozilla.com> wrote:
>
> If Microsoft did this, then Firefox would be blocked as malware for pinning itself to the taskbar.

>> If an add-on author wants to piggy back on the success of Firefox,
>> they have to play by our rules. If they don't want to play by our
>> rules, let them build and ship a browser of their own.
>
> s/add-on/app/ ; s/Firefox/iPhone/ ; s/browser/smartphone/
> s/add-on/application/ ; s/Firefox/Windows/ ; s/browser/operating system/

On 2/29/2012 5:27 PM, Brian Smith wrote:
> Asa Dotzler wrote:
>> Firefox 8 conformation) and in policy. If add-ons attempt to
>> circumvent Firefox's security features or violate our policies, we
>> should work with AV vendors to have them identified as malware and
>> we should use our very capable public voice to shame them into
>> fixing their behavior or to put them out of business.
>
> If Microsoft did this, then Firefox would be blocked as malware for
> pinning itself to the taskbar. Just because company X disagrees with
> what company Y is doing, doensn't mean that AV vendors should/will
> flag company Y's software as malware. See also
> http://en.wikipedia.org/wiki/360_v._Tencent.

>> potentially providing them with somewhat lowered barriers to third
>> party software installs if they agree to live by the spirit of our
>> policies.
>
> AV software venders don't need us to lower our barriers for them,
> because there is no barrier that we could implement in user-mode
> Firefox that they could not subvert, without greatly restricting the
> configurability and exensibility of Firefox (which is something I
> support, BTW). And, anything that AV software can do,
> malware/grayware can do.

>> If an add-on author wants to piggy back on the success of Firefox,
>> they have to play by our rules. If they don't want to play by our
>> rules, let them build and ship a browser of their own.
>
> s/add-on/app/ ; s/Firefox/iPhone/ ; s/browser/smartphone/
> s/add-on/application/ ; s/Firefox/Windows/ ; s/browser/operating
> system/

On 01.03.2012 02:52, Asa Dotzler wrote:
> On 2/29/2012 3:52 PM, Dao wrote:
>> On 01.03.2012 00:23, Asa Dotzler wrote:
>>> I think it is important enough by a wide enough margin that I'm support
>>> making it harder for third party software and non-AMO sites to install
>>> add-ons into Firefox so as to protect users from unwanted add-on
>>> infections.
>>
>> Why are non-AMO sites suddenly part of the discussion again? Where's the
>> data proving that they are a problem?
>
> I'm interested in lowering the barrier for add-on installs at AMO, but
> not for non-AMO sites. If, for example, we can work out a single-click
> install for AMO, I have no intention of expanding that to random
> websites.

> Non-AMO installs are a problem. One of the reasons people opt to host
> outside of AMO is because they are not interested in conforming to our
> "no surprises" policy or being reviewed in any other way (including by
> our community of users giving ratings and other warnings to users)

> and so non-AMO installs should be assumed less trustworthy.

On 2/29/2012 6:35 PM, Dao wrote:
> On 01.03.2012 02:52, Asa Dotzler wrote:
>> On 2/29/2012 3:52 PM, Dao wrote:
>>> On 01.03.2012 00:23, Asa Dotzler wrote:
>>>> I think it is important enough by a wide enough margin that I'm support
>>>> making it harder for third party software and non-AMO sites to install
>>>> add-ons into Firefox so as to protect users from unwanted add-on
>>>> infections.
>>>
>>> Why are non-AMO sites suddenly part of the discussion again? Where's the
>>> data proving that they are a problem?
>>
>> I'm interested in lowering the barrier for add-on installs at AMO, but
>> not for non-AMO sites. If, for example, we can work out a single-click
>> install for AMO, I have no intention of expanding that to random
>> websites.
>
> Ok. That's not what you wrote above.

>
>> Non-AMO installs are a problem. One of the reasons people opt to host
>> outside of AMO is because they are not interested in conforming to our
>> "no surprises" policy or being reviewed in any other way (including by
>> our community of users giving ratings and other warnings to users)
>
> People being uninterested in getting reviewed and hosted by a third
> party isn't necessarily a problem. People installing something from a
> source /they/ trust isn't necessarily a problem either.

> But our installation dialog is our communication to the user and we have no
> basis for trust for those add-ons not hosted at AMO (unless we do have some
> other relationship with them). That means our add-on installation dialog
> should convey that these are not trusted in any way by Firefox (Mozilla) and
> could be harmful.

Justin Lebar wrote:
> By way of comparison, installing a malicious add-on is way, way more
> dangerous than accepting an untrusted SSL cert.  The malicious add-on
> can snoop on every connection, permanently (and can install arbitrary
> software on your computer).

> we currently have is reasonable, then that's an argument in favor of
> making the non-AMO add-on dialog way scarier (and way harder to get
> around).

On 01.03.2012 04:08, Justin Lebar wrote:
> By way of comparison, installing a malicious add-on is way, way more
> dangerous than accepting an untrusted SSL cert.  The malicious add-on
> can snoop on every connection, permanently (and can install arbitrary
> software on your computer).

On 2/29/2012 11:28 PM, Brian Smith wrote:
> Right. That's a very serious deficiency in the design of our addon
> system. An addon should not be able to do those things without
> explicit user approval of those specific actions, and there are some
> thing (e.g. disable the blocklist) that addons shouldn't be able to do
> at all.

> I do think it would be a good idea to make the dialog much more informative instead of more scary: e.g. "This software is likely to *hijack your search engine*, *install toolbars* into your web browsers, and *slow down Firefox*. Mozilla recommends that you *do NOT install it* without verifying elsewhere that it is safe. Here are some alternative addons with similar functionality: [...] [Cancel] [Install it anyway]."

> Do you also think we should make it harder to download software based on the
> fact that Mozilla doesn't trust sites it doesn't control? I hope not, but it
> seems like you have to by your logic.

> Again, please show the data suggesting that the current warning isn't
> sufficient. Otherwise you're trying to fix what isn't broken.

On 01.03.2012 15:05, Justin Lebar wrote:
>> Do you also think we should make it harder to download software based on the
>> fact that Mozilla doesn't trust sites it doesn't control? I hope not, but it
>> seems like you have to by your logic.
>
> I'd be OK making a scarier warning when people try to run software
> they downloaded from the Internet; that only makes sense.  You should
> be able to turn the nagging off...

>> Again, please show the data suggesting that the current warning isn't
>> sufficient. Otherwise you're trying to fix what isn't broken.
>
> The data is our list of the top 100 add-ons.
>
> https://etherpad.mozilla.org/hSOVNzKZen
>
> There's a ton of greyware and malware in there.  In fact, suspicious
> software far outnumbers useful software.  Nick posted about this
> earlier in the thread.

On 3/1/12 8:05 AM, Justin Lebar wrote:

On 2/29/12 7:45 PM, Nicholas Nethercote wrote:

On 3/1/2012 6:41 AM, Jorge Villalobos wrote:

> Requiring all add-ons to go through a review or certification process
> conducted by us before they are installable, or "easily" installable is
> not that far from the level of control that Apple exerts over iOS
> developers. The only real difference would be that we would allow them
> to distribute their add-ons elsewhere, as long as we approve of them.

> I assert that protecting users from add-ons they do not want is more
> important than making it easy to get infected with add-ons they do want.

On 3/1/2012 11:11 AM, David Illsley wrote:
> On Thu, Mar 1, 2012 at 5:06 PM, Asa Dotzler<a...@mozilla.org>  wrote:
>
>> On 3/1/2012 6:41 AM, Jorge Villalobos wrote:
>>
>>   Requiring all add-ons to go through a review or certification process
>>> conducted by us before they are installable, or "easily" installable is
>>> not that far from the level of control that Apple exerts over iOS
>>> developers. The only real difference would be that we would allow them
>>> to distribute their add-ons elsewhere, as long as we approve of them.
>>>
>>
>> No it's not the same or even close. We'd be reviewing to put users in
>> control not to police content or defend our apps from competition. I wish
>> those of you comparing us to bad actors would stop. It's not helpful --
>> further, it's insulting to well-meaning people on the other side of the
>> argument from you.
>>
>> - A
>
>
> I'm pretty sure Apple would assert they're not doing it to prevent
> competition, or to police content beyond that required to protect users
> from undesirable content.

> Whether you choose to believe that or not, and regardless of whether you
> find it insulting, the public positions of MoCo and Apple would definitely
> be comparable.

On 3/1/2012 10:35 AM, Robert Kaiser wrote:
> Asa Dotzler schrieb:
>> I assert that protecting users from add-ons they do not want is more
>> important than making it easy to get infected with add-ons they do want.
>
> Nobody disputes that, but this is something entirely different to what
> you talked about in the paragraph above where it was protecting them
> from what they don't want vs. giving them those they want. I say we do
> need to care that both those things work.

On Thu, Mar 1, 2012 at 6:41 AM, Jorge Villalobos <jo...@mozilla.com> wrote:
>
> Requiring all add-ons to go through a review or certification process
> conducted by us before they are installable, or "easily" installable is not
> that far from the level of control that Apple exerts over iOS developers.
> The only real difference would be that we would allow them to distribute
> their add-ons elsewhere, as long as we approve of them.
>
> At least that's what some people are proposing, so I don't think that
> comparison is that far-fetched or unproductive.

> You're assuming that data comes only from Firefox 8+ users, which is wrong.
> You're also assuming that all of those add-on installations are enabled,
> which is also not true. In fact, the opt-in screen you get after upgrading
> to Firefox 8 doesn't give you the option to uninstall, only disable IIRC, so
> that data provides no insight into how effective that feature was.

On 3/1/12 5:24 PM, Nicholas Nethercote wrote:
> On Thu, Mar 1, 2012 at 6:41 AM, Jorge Villalobos<jo...@mozilla.com>  wrote:
>>
>> Requiring all add-ons to go through a review or certification process
>> conducted by us before they are installable, or "easily" installable is not
>> that far from the level of control that Apple exerts over iOS developers.
>> The only real difference would be that we would allow them to distribute
>> their add-ons elsewhere, as long as we approve of them.
>>
>> At least that's what some people are proposing, so I don't think that
>> comparison is that far-fetched or unproductive.
>
> Which "some people"?  I think you're conflating third-party installs
> with first-party installs.  "Some people" have been suggesting we
> restrict third-party installs, e.g.
> https://bugzilla.mozilla.org/show_bug.cgi?id=728227.

> But if anyone has suggested restricting first-party installs, I've
> missed it, and I disagree with it.  I'll repeat what I said in
> https://bugzilla.mozilla.org/show_bug.cgi?id=728227#c29:
>
> "IMO, the single most important thing when it comes to add-ons is user
> control:  a user should be able to run exactly the add-ons they want,
> no more and no less.  Third-party installs completely violate that
> principle.  So I think the FF8 check was a great improvement, but that
> it's still too easy for a user to agree to a third-party installation
> request without understanding it what they're agreeing to and thus end
> up enabling an add-on they didn't ask for."
>
> Principles 4 and 5 from the Mozilla Manifesto are relevant here:
>
> 4. Individuals' security on the Internet is fundamental and cannot be
> treated as optional.

> 5. Individuals must have the ability to shape their own experiences on
> the Internet.

> (And third-party installs are why iPhone analogies are misleading.
> AFAIK the iPhone has nothing like a third-party install -- if you
> install app A it can't change the behaviour of app B.)
>
>
>> You're assuming that data comes only from Firefox 8+ users, which is wrong.
>> You're also assuming that all of those add-on installations are enabled,
>> which is also not true. In fact, the opt-in screen you get after upgrading
>> to Firefox 8 doesn't give you the option to uninstall, only disable IIRC, so
>> that data provides no insight into how effective that feature was.
>
> Ah, that's useful to know.  Indeed, the FF8 opt-in check is central to
> this whole discussion, because it sets precedent -- it's clear that
> agreement was reached that the third-party installation situation was
> unacceptable, and something was done about it (I think
> https://bugzilla.mozilla.org/show_bug.cgi?id=476430 and
> https://bugzilla.mozilla.org/show_bug.cgi?id=596343 were the relevant
> bugs).
>
> So the question is now:  was the FF8 opt-in check enough?  I asked
> earlier in the thread if we had any data on its effect.  Do we?  If we
> do and it says, for example, that 90% of third-party add-ons got
> disabled, then we don't have much of a problem.  (Well, there's still
> the "how do I uninstall add-on X?" problem.)
>
> But without that data we're just going to end up arguing in circles.

On 3/1/12 5:24 PM, Nicholas Nethercote wrote:

> On Thu, Mar 1, 2012 at 6:41 AM, Jorge Villalobos<jo...@mozilla.com>  wrote:
>>
>> Requiring all add-ons to go through a review or certification process
>> conducted by us before they are installable, or "easily" installable is not
>> that far from the level of control that Apple exerts over iOS developers.
>> The only real difference would be that we would allow them to distribute
>> their add-ons elsewhere, as long as we approve of them.
>>
>> At least that's what some people are proposing, so I don't think that
>> comparison is that far-fetched or unproductive.
>
> Which "some people"?  I think you're conflating third-party installs
> with first-party installs.  "Some people" have been suggesting we
> restrict third-party installs, e.g.
> https://bugzilla.mozilla.org/show_bug.cgi?id=728227.

I might be misinterpreting some of the comments in that bug and in this
discussion, but it can be hard to track who's talking about what, and
who meant "third party" in which context.

You should be aware, though, that the technical solutions that are being
proposed, like requiring all add-ons to be signed or reviewed by us,
would be very difficult to implement in such a limited context, and can
be easily manipulated by those installing software in your computer. For
example, they could just launch Firefox with the installation page for
their add-on, instead of externally installing it. Since we are trying
to protect users who just click through anything without reading, I
don't see how that wouldn't work for them, and I don't see why we would
block an add-on installed that way. Users *are* giving consent by
choosing to install the add-on.

> But if anyone has suggested restricting first-party installs, I've
> missed it, and I disagree with it.  I'll repeat what I said in
> https://bugzilla.mozilla.org/show_bug.cgi?id=728227#c29:
>
> "IMO, the single most important thing when it comes to add-ons is user
> control:  a user should be able to run exactly the add-ons they want,
> no more and no less.  Third-party installs completely violate that
> principle.  So I think the FF8 check was a great improvement, but that
> it's still too easy for a user to agree to a third-party installation
> request without understanding it what they're agreeing to and thus end
> up enabling an add-on they didn't ask for."
>
> Principles 4 and 5 from the Mozilla Manifesto are relevant here:
>
> 4. Individuals' security on the Internet is fundamental and cannot be
> treated as optional.

We have the blocklist for this, and it has protected users well in the
past. I don't think the Zynga Toolbar or the McAfee add-on cases that
triggered these discussions fall into this category. Do you?

> 5. Individuals must have the ability to shape their own experiences on
> the Internet.

By placing limitations on the way add-on developers distribute their
add-ons online, we are limiting that ability, for the sake of user
experience.

Asa has already described very well what the tradeoff is in this
discussion: how much do we want to limit what all users can install
externally, so that some users are protected from installing things they
didn't intend to install?

Our current policy is to maximize the ability of capable users to shape
their experiences at the expense of less capable users who install
things unknowingly, even when presented with the choice not to. We have
the blocklist as a mitigation mechanism, but we use it only in clear
cases of malicious intent or severe instability.

The proposal is to shift the balance of this policy to give better
protection for those users who end up with unexpected add-ons, at the
expense of those who might want to create, distribute or install add-ons
outside of our control.

If there's an adequate solution that doesn't change this balance, I
haven't heard it yet. My opinion is that the current policy does a
better job of fostering an active and diverse community than the
alternative, and moving to a more controlled approach will lead to a
decline in add-on development.

> (And third-party installs are why iPhone analogies are misleading.
> AFAIK the iPhone has nothing like a third-party install -- if you
> install app A it can't change the behaviour of app B.)
>
>
>> You're assuming that data comes only from Firefox 8+ users, which is wrong.
>> You're also assuming that all of those add-on installations are enabled,
>> which is also not true. In fact, the opt-in screen you get after upgrading
>> to Firefox 8 doesn't give you the option to uninstall, only disable IIRC, so
>> that data provides no insight into how effective that feature was.
>
> Ah, that's useful to know.  Indeed, the FF8 opt-in check is central to
> this whole discussion, because it sets precedent -- it's clear that
> agreement was reached that the third-party installation situation was
> unacceptable, and something was done about it (I think
> https://bugzilla.mozilla.org/show_bug.cgi?id=476430 and
> https://bugzilla.mozilla.org/show_bug.cgi?id=596343 were the relevant
> bugs).
>
> So the question is now:  was the FF8 opt-in check enough?  I asked
> earlier in the thread if we had any data on its effect.  Do we?  If we
> do and it says, for example, that 90% of third-party add-ons got
> disabled, then we don't have much of a problem.  (Well, there's still
> the "how do I uninstall add-on X?" problem.)
>
> But without that data we're just going to end up arguing in circles.

On 3/1/2012 3:45 PM, Jorge Villalobos wrote:
> Asa has already described very well what the tradeoff is in this
> discussion: how much do we want to limit what all users can install
> externally, so that some users are protected from installing things they
> didn't intend to install?
>
> Our current policy is to maximize the ability of capable users to shape
> their experiences at the expense of less capable users who install
> things unknowingly

> The proposal is to shift the balance of this policy to give better
> protection for those users who end up with unexpected add-ons, at the
> expense of those who might want to create, distribute or install add-ons
> outside of our control.

> My opinion is that the current policy does a
> better job of fostering an active and diverse community than the
> alternative, and moving to a more controlled approach will lead to a
> decline in add-on development.

On 3/1/12 10:37 PM, Asa Dotzler wrote:
> On 3/1/2012 3:45 PM, Jorge Villalobos wrote:
>> My opinion is that the current policy does a
>> better job of fostering an active and diverse community than the
>> alternative, and moving to a more controlled approach will lead to a
>> decline in add-on development.
>
> This is another point that we're not discussing enough. You clearly want
> to optimize for add-on developers while I and others on this thread want
> to optimize for our users.

> If we have to slow the growth or even shrink the size of our add-on
> developer community (losing those few developers who are unwilling to
> work with us to better help our users) in order to protect our users
> from unwanted add-ons, I think that's completely appropriate.

> Users *are* giving consent by choosing to install the add-on.

On Fri, Mar 2, 2012 at 11:42 AM, Jorge Villalobos <jo...@mozilla.com> wrote:

> If we want to
> protect users from add-ons they do not want, we will necessarily have to
> make it a bit more difficult to get some of the non-AMO add-ons they do
> want.

On 3/2/2012 8:42 AM, Jorge Villalobos wrote:
> I also question the effectiveness of us protecting users who are clearly
> incapable of understanding visual cues. If you look at the
> Trillian/Ask.com video, the user is presented with 2 different
> opportunities not to install this toolbar. Those who installed it and
> later complained about it clearly don't understand what they did, and I
> don't see how we can create any technical limitations to protect these
> users short of closing Firefox for everything except AMO. Half-measures
> are easily to work around, and continuing with the cat and mouse game
> will do little to protect our mainstream users, while harming the more
> knowledgeable ones and our developer community.

On 03/02/12 09:24, Justin Lebar wrote:
> I'd like to move this thread towards a conclusion, if I can.  We've
> reached the point of almost exclusively rehashing old arguments, and
> that's a waste of everyone's time.
>
> The goal is not to get everyone in the debate to agree.  The pros and
> cons of the various options at our disposal have been well laid out;
> now module owners need to make a decision.

> It seems to me that those on the Firefox / Gecko side are in favor of
> tighter controls of drive-by add-ons; in particular, Asa is the
> ranking owner on the Firefox side, and he's in favor of this.

> I'd
> love to have the add-ons team on-board with whatever we do in Firefox,
> because we'll be able to design a better experience for users if we
> could, for example, use the add-ons team's expertise to help us
> distinguish between "good" and "bad" drive-by add-ons.  But this is
> not a requirement for us to take action in Firefox.

> Asa, can we file a bug and start thinking technically about how we
> want to implement the changes you think we should implement?

>> I'd
>> love to have the add-ons team on-board with whatever we do in Firefox,
>> because we'll be able to design a better experience for users if we
>> could, for example, use the add-ons team's expertise to help us
>> distinguish between "good" and "bad" drive-by add-ons.  But this is
>> not a requirement for us to take action in Firefox.
>
> I disagree here. We can't give users any more information to make decisions
> about what add-ons they should use without this. The only way this isn't a
> requirement is if you just want to block third-party add-ons entirely.

On 03/02/12 10:39, Justin Lebar wrote:
>>> I'd
>>> love to have the add-ons team on-board with whatever we do in Firefox,
>>> because we'll be able to design a better experience for users if we
>>> could, for example, use the add-ons team's expertise to help us
>>> distinguish between "good" and "bad" drive-by add-ons.  But this is
>>> not a requirement for us to take action in Firefox.
>>
>> I disagree here. We can't give users any more information to make decisions
>> about what add-ons they should use without this. The only way this isn't a
>> requirement is if you just want to block third-party add-ons entirely.
>
> I think the proposal is to change the flow that happens when a
> drive-by add-on is installed, so that users have to give informed
> consent in order to install the add-on.
>
> At least, that's what I propose based on the discussion here.  It
> doesn't require any changes from the add-ons team, because the flow
> would be the same for all add-ons.  At a later date, if AMO wanted to
> help us identify "trusted" drive-by add-ons, maybe we'd do something
> with that data to make those add-ons easier to install.

> I'm working on getting the data on active add-ons.  We're not
> collecting it through telemetry, it seems, but we should be able to
> change that.  It'll take some weeks before we have reliable data,
> though.  I don't think that should block us on starting to make this
> change, though: It strikes me as unlikely that once we restrict to
> active add-ons, *all* of the greyware/malware will disappear from our
> list.

On 03/02/2012 01:47 PM, Dave Townsend wrote:

> Unlikely yes, but we should be taking a measured response based on an
> understanding of the scale of the problem we are facing rather than
> rushing to cause problems for those that play by the rules already.

> Users already have to give consent to these add-ons. What more information do you expect to be able to give them?

On 03/02/12 11:58, Justin Lebar wrote:
>> "explicitly choosing to trust the add-on itself". I really have no idea how
>> you expect to solicit the latter.
>
> Thus this is the only option I have left.  And like I've said, I'd
> want to make this expression of trust explicit by making the dialog
> "scarier".  I'm sure we'd spend a lot of timing considering exactly
> what threats the dialog would call out, but for the purposes of
> illustration, we could say something like:
>
> "If you enable this add on, it could
>
> * Track everything you do within Firefox, including your passwords,
> even when you're on a secure site like your bank
> * Redirect your Google searches to another search engine
> * Cause Firefox to run slowly or crash
> * Mess up Firefox, so it doesn't work properly even after you disable the add-on
>
> Mozilla has verified that [name of add-on] is safe.  If you are not
> 100% sure you trust [name of add-on provider], we recommends you not
> enable it.
>
> [Get me outta here!]  [Okay, I'm sure]"
>
> But again, let's not get hung up on exactly these words.

On 03/02/12 10:39, Justin Lebar wrote:

> I'm working on getting the data on active add-ons.  We're not
> collecting it through telemetry, it seems, but we should be able to
> change that.  It'll take some weeks before we have reliable data,
> though.  I don't think that should block us on starting to make this
> change, though: It strikes me as unlikely that once we restrict to
> active add-ons, *all* of the greyware/malware will disappear from our
> list.

> Mozilla has verified that [name of add-on] is safe.

> It's exactly the use of words like this that will alienate some of the
> third-parties that we work extremely closely with, which is why I wouldn't
> like to see us make such changes blindly.

On 03/02/12 12:17, Justin Lebar wrote:
>> Mozilla has verified that [name of add-on] is safe.
>
> Er, "Mozilla has **not** verified that [name of add-on] is safe".
>
>> It's exactly the use of words like this that will alienate some of the
>> third-parties that we work extremely closely with, which is why I wouldn't
>> like to see us make such changes blindly.
>
> I'll work on getting us this data.  But it is not, IMO, essential to
> this debate.  We know that there are going to be a bunch of
> questionable add-ons in the top 100 list.  We know there's going to be
> malware.  The question is only whether it's going to be "some" or "a
> lot".  But even if the problem were just "some", we'd still want to do
> something about it.  Every user is worth protecting.

> So perhaps we can consider this: If we work closely with some parties,
> then couldn't we ask for them to give us access to pre-release
> binaries and/or source?  Then we *could* verify that the add-on is
> safe.  Then we *could*, in good faith, display a less scary message to
> users.

> As is, we do no testing on non-AMO add-ons.  We know that they can, at
> the very least, cause performance issues.  The message I floated
> earlier is, at the moment, the best we can honestly say about any
> add-on, even those from our close partners.
>
> Could we agree on making the message scarier for un-vetted add-ons
> while adding a less-scary message for add-ons we've vetted?

On 3/2/12 2:17 PM, Justin Lebar wrote:
> I'll work on getting us this data.  But it is not, IMO, essential to
> this debate.  We know that there are going to be a bunch of
> questionable add-ons in the top 100 list.  We know there's going to be
> malware.  The question is only whether it's going to be "some" or "a
> lot".  But even if the problem were just "some", we'd still want to do
> something about it.  Every user is worth protecting.

On 3/2/12 2:17 PM, Justin Lebar wrote:

> I'll work on getting us this data.  But it is not, IMO, essential to
> this debate.  We know that there are going to be a bunch of
> questionable add-ons in the top 100 list.  We know there's going to be
> malware.  The question is only whether it's going to be "some" or "a
> lot".  But even if the problem were just "some", we'd still want to do
> something about it.  Every user is worth protecting.

>> So perhaps we can consider this: If we work closely with some parties,
>> then couldn't we ask for them to give us access to pre-release
>> binaries and/or source?  Then we *could* verify that the add-on is
>> safe.  Then we *could*, in good faith, display a less scary message to
>> users.
>
> We should reach out and see if they would be willing to do this (this of
> course requires the add-ons team's involvement) and we should evaluate the
> costs of us doing it.

On 3/2/12 3:07 PM, Justin Lebar wrote:

> As I have stated before, I'm all for offering non-AMO developers a way for
> them to get their add-on reviewed by us, as long as it is not an obligation
> and it doesn't change the install experience of their add-on (if we were to
> eventually sign reviewed add-ons, I'd be OK if we signed them and the
> install dialog said "Reviewed by Mozilla" or something like that).

> Having a
> schedule where they send us a pre-release version and we can review their
> add-on with enough time for them to make changes would be ideal

> I also
> believe the extra workload for reviewers would be fairly small.

> That's something I can discuss with fligtar next week when he's back from
> MWC, on top of many other things that have been brought up in this
> discussion.

On 3/2/12 4:55 PM, Justin Lebar wrote:
>> As I have stated before, I'm all for offering non-AMO developers a way for
>> them to get their add-on reviewed by us, as long as it is not an obligation
>> and it doesn't change the install experience of their add-on (if we were to
>> eventually sign reviewed add-ons, I'd be OK if we signed them and the
>> install dialog said "Reviewed by Mozilla" or something like that).
>
> Specifically, I'm proposing that
>
> * If the add-on is un-reviewed, we display a scary dialog
> * If the add-on is reviewed, we display a less-scary dialog
>
> Would this count as "changing the install experience of the add-on"?

On 3/2/12 4:55 PM, Justin Lebar wrote:

>> As I have stated before, I'm all for offering non-AMO developers a way for
>> them to get their add-on reviewed by us, as long as it is not an obligation
>> and it doesn't change the install experience of their add-on (if we were to
>> eventually sign reviewed add-ons, I'd be OK if we signed them and the
>> install dialog said "Reviewed by Mozilla" or something like that).
>
> Specifically, I'm proposing that
>
> * If the add-on is un-reviewed, we display a scary dialog
> * If the add-on is reviewed, we display a less-scary dialog
>
> Would this count as "changing the install experience of the add-on"?

On 3/2/2012 12:17 PM, Justin Lebar wrote:
>> Mozilla has verified that [name of add-on] is safe.
>
> Er, "Mozilla has **not** verified that [name of add-on] is safe".
>
>> It's exactly the use of words like this that will alienate some of the
>> third-parties that we work extremely closely with, which is why I wouldn't
>> like to see us make such changes blindly.
>
> I'll work on getting us this data.  But it is not, IMO, essential to
> this debate.  We know that there are going to be a bunch of
> questionable add-ons in the top 100 list.  We know there's going to be
> malware.  The question is only whether it's going to be "some" or "a
> lot".  But even if the problem were just "some", we'd still want to do
> something about it.  Every user is worth protecting.
>
> So perhaps we can consider this: If we work closely with some parties,
> then couldn't we ask for them to give us access to pre-release
> binaries and/or source?  Then we *could* verify that the add-on is
> safe.  Then we *could*, in good faith, display a less scary message to
> users.
>
> As is, we do no testing on non-AMO add-ons.  We know that they can, at
> the very least, cause performance issues.  The message I floated
> earlier is, at the moment, the best we can honestly say about any
> add-on, even those from our close partners.
>
> Could we agree on making the message scarier for un-vetted add-ons
> while adding a less-scary message for add-ons we've vetted?

>> So perhaps we can consider this: If we work closely with some parties,
>> then couldn't we ask for them to give us access to pre-release
>> binaries and/or source? Then we *could* verify that the add-on is
>> safe. Then we *could*, in good faith, display a less scary message to
>> users.
>
> We should reach out and see if they would be willing to do this (this of
> course requires the add-ons team's involvement) and we should evaluate
> the costs of us doing it.

On 3/2/2012 3:27 PM, Jorge Villalobos wrote:
> On 3/2/12 4:55 PM, Justin Lebar wrote:
>>> As I have stated before, I'm all for offering non-AMO developers a
>>> way for
>>> them to get their add-on reviewed by us, as long as it is not an
>>> obligation
>>> and it doesn't change the install experience of their add-on (if we
>>> were to
>>> eventually sign reviewed add-ons, I'd be OK if we signed them and the
>>> install dialog said "Reviewed by Mozilla" or something like that).
>>
>> Specifically, I'm proposing that
>>
>> * If the add-on is un-reviewed, we display a scary dialog
>> * If the add-on is reviewed, we display a less-scary dialog
>>
>> Would this count as "changing the install experience of the add-on"?
>
> Yes, that is exactly what I mean.
>
> In my opinion, *all* add-on installs need at least one warning that says
> you're installing software in your computer and that carries some risk.
> This includes add-ons that we review.

> Just because we have reviewed them doesn't imply that nothing wrong can
> happen. Mistakes can happen during review. Things can be overlooked. We
> can't guarantee that everything will be fine, and therefore users should
> always get a fair warning.

> For externally-installed add-ons, we need a second warning (which we
> already have). Do we need more? I don't think so. However, we first need
> to study the Firefox 8+ data to be sure. Like I said in my previous
> comment, I'd be OK with adding a note that indicates the add-on was
> reviewed by us in order to give users some extra assurance to opt-in.
> I'm not OK making the opt-in scarier just because we didn't look at the
> file.

> I'd be OK with adding a note that indicates the add-on was reviewed by us in order to give users some extra assurance to opt-in.
> I'm not OK making the opt-in scarier just because we didn't look at the file.

On 03/02/12 18:30, Justin Lebar wrote:
>> I'd be OK with adding a note that indicates the add-on was reviewed by us in order to give users some extra assurance to opt-in.
>> I'm not OK making the opt-in scarier just because we didn't look at the file.
>
> So basically, you're OK making it easier to install a reviewed add-on,
> but not making it harder to install an un-reviewed add-on?
>
> That's not really what I'm hoping for here.
>
> Are there any circumstances under which you would be OK making it in
> any way scarier or harder to install an add-on which we have not
> explicitly found to be malicious?
>
> I'd pose the same question to the relevant module owners in Firefox.

On 3/2/12 7:44 PM, Asa Dotzler wrote:
> On 3/2/2012 3:27 PM, Jorge Villalobos wrote:
>> On 3/2/12 4:55 PM, Justin Lebar wrote:
>>>> As I have stated before, I'm all for offering non-AMO developers a
>>>> way for
>>>> them to get their add-on reviewed by us, as long as it is not an
>>>> obligation
>>>> and it doesn't change the install experience of their add-on (if we
>>>> were to
>>>> eventually sign reviewed add-ons, I'd be OK if we signed them and the
>>>> install dialog said "Reviewed by Mozilla" or something like that).
>>>
>>> Specifically, I'm proposing that
>>>
>>> * If the add-on is un-reviewed, we display a scary dialog
>>> * If the add-on is reviewed, we display a less-scary dialog
>>>
>>> Would this count as "changing the install experience of the add-on"?
>>
>> Yes, that is exactly what I mean.
>>
>> In my opinion, *all* add-on installs need at least one warning that says
>> you're installing software in your computer and that carries some risk.
>> This includes add-ons that we review.
>
> Justin's saying "add-ons we haven't reviewed need a stronger warning
> than add-ons we have reviewed" and your answer is that is not OK?

> If there's any value at all in reviews, which is what I'm sure you
> believe, then it should hold that the messages could be at least
> somewhat different between reviewed and un-reviewed add-ons, no?

> So, what this comes down to for me is the precise value our review
> system offers compared to no review.
>
> I think un-review add-ons should be scary as hell -- virtually
> impossible to install for all but the most intrepid users. The warning
> should list all the possible evil things the add-on could do.

> I think reviewed add-ons that are closed source and can only be
> evaluated based on use analysis (including perf testing, feature
> testing, etc.) should have a moderate warning -- something like what we
> have today.
>
> I think add-ons that have inspect-able source and have had thorough
> reviews (like what Firefox gets, for example) should be one-click
> installs with no warnings.

> What would your ideal warning regime be for those three cases?

>> For externally-installed add-ons, we need a second warning (which we
>> already have). Do we need more? I don't think so. However, we first need
>> to study the Firefox 8+ data to be sure. Like I said in my previous
>> comment, I'd be OK with adding a note that indicates the add-on was
>> reviewed by us in order to give users some extra assurance to opt-in.
>> I'm not OK making the opt-in scarier just because we didn't look at the
>> file.
>
> The problem with our current opt in dialog is that it's scary but with
> no information about why. That makes users abandon installs for no good
> reason or agree to installs with no understanding of what they're doing.
> It's not just about making it scarier. It's about making it actionable.
> It needs to get helping users make good decisions.

On 3/3/12 10:51 AM, Jorge Villalobos wrote:
> Like I mentioned in a previous message, all add-on installations should
> carry a warning about software being installed. Period. If we want to
> have a checkbox or something so they dismiss all warnings for a domain,
> or for add-ons reviewed by a given entity, I'm OK with that. It should
> be up to users to decide who they trust.

> It should be up to users to decide who they trust.

On 3/3/12 11:33 AM, Justin Lebar wrote:
> Are you saying that, if the Firefox module owners decide that they
> would like to show different warnings for reviewed and un-reviewed
> add-ons, and if you feel that their idea or its implementation is an
> unacceptable imposition of trust on users, you will not assist with
> communicating with partners and setting up the necessary reviews?

On 3/3/12 11:33 AM, Justin Lebar wrote:

> Are you saying that, if the Firefox module owners decide that they
> would like to show different warnings for reviewed and un-reviewed
> add-ons, and if you feel that their idea or its implementation is an
> unacceptable imposition of trust on users, you will not assist with
> communicating with partners and setting up the necessary reviews?

On 3/3/2012 8:51 AM, Jorge Villalobos wrote:
> On 3/2/12 7:44 PM, Asa Dotzler wrote:
>> Justin's saying "add-ons we haven't reviewed need a stronger warning
>> than add-ons we have reviewed" and your answer is that is not OK?
>
> Correct. While I have great confidence in our review system, I disagree
> that by default we should assume that it is better or reflect users'
> desires any better than other QA departments or personally built and
> distributed add-ons.

On 3/3/2012 3:54 PM, Neil wrote:
> Asa Dotzler wrote:
>
>> On 3/2/2012 12:17 PM, Justin Lebar wrote:
>>
>>> Could we agree on making the message scarier for un-vetted add-ons
>>> while adding a less-scary message for add-ons we've vetted?
>>
>> I fully support this approach.
>
> Would it be possible to collect votes on 3rd party add-ons to give new
> users of those add-ons additional information?
>

>> Please help me understand what you're saying here because it sounds to
>> me like you're saying there's no value in AMO reviews. If there's no
>> reason to assume our reviews are better than those of the add-on's
>> author, why are we doing AMO reviews at all?
>>
>> - A
>
> What I'm saying is that we know reviewing add-ons is necessary and valuable
> for our users, and that we should absolutely do it for distributing add-ons
> on our site. We're taking the necessary steps to protect our users, not only
> from a security standpoint, but also to protect their privacy and their
> freedom of choice.
>
> What I am *also* saying is that there should be no assumption that add-ons
> distributed elsewhere are not being held to similar standards, or that all
> users want add-ons that are held to the same standards we have.
>

>
> Having a good review system is no reason IMO to say nobody else does.

On 3/4/2012 7:12 AM, Jorge Villalobos wrote:
> On 3/3/12 2:54 PM, Asa Dotzler wrote:
>> On 3/3/2012 8:51 AM, Jorge Villalobos wrote:
>>> On 3/2/12 7:44 PM, Asa Dotzler wrote:
>>>> Justin's saying "add-ons we haven't reviewed need a stronger warning
>>>> than add-ons we have reviewed" and your answer is that is not OK?
>>>
>>> Correct. While I have great confidence in our review system, I disagree
>>> that by default we should assume that it is better or reflect users'
>>> desires any better than other QA departments or personally built and
>>> distributed add-ons.
>>
>> Please help me understand what you're saying here because it sounds to
>> me like you're saying there's no value in AMO reviews. If there's no
>> reason to assume our reviews are better than those of the add-on's
>> author, why are we doing AMO reviews at all?
>>
>> - A
>
> What I'm saying is that we know reviewing add-ons is necessary and
> valuable for our users, and that we should absolutely do it for
> distributing add-ons on our site. We're taking the necessary steps to
> protect our users, not only from a security standpoint, but also to
> protect their privacy and their freedom of choice.
>
> What I am *also* saying is that there should be no assumption that
> add-ons distributed elsewhere are not being held to similar standards,
> or that all users want add-ons that are held to the same standards we have.

>>> Whether you choose to believe that or not, and regardless of
>>> whether you find it insulting, the public positions of MoCo and
>>> Apple would definitely be comparable.
>>
>> They are not comparable. That's like saying that France and China
>> public policies are comparable because both countries have
>> governments.
>
> Well no. It's not at all like that. Apart from anything else, the
> public positions of those governments are pretty dissimilar.

On 03/03/12 16:51, Jorge Villalobos wrote:
> It should
> be up to users to decide who they trust.

> That they *can* review their own add-ons capably doesn't necessarily mean
> that they *do*. The problem I see in your reasoning is that you seem to lump
> together all developers that self-host their add-ons. So they are either all
> bad actors and we need to have almost impossible to overcome warnings in
> order to install their add-ons, or they're all responsible and capable and
> we don't need to bother with code reviews at all. We'll always have a
> combination of both.

> I don't want our policy to *assume* that all non-AMO hosted add-ons are
> risky to install, because they're not. We can't assume all add-ons carry no
> risk to install either, which is why we review all the add-ons that are
> distributed in our official repository.

> So they are either all
> bad actors and we need to have almost impossible to overcome warnings in
> order to install their add-ons

On 3/5/12 9:27 AM, Justin Lebar wrote:
> But what we disagree on is what action to take when presented with a
> self-hosted add-on.  Do we warn the user about the harm this add-on
> *may* cause?  Or do we pretend, as we currently do, that the add-on
> won't cause harm?

> The proposal is to have a *somewhat different* flow for un-reviewed
> drive-by add-ons than for reviewed add-ons, possibly with *somewhat
> different* warnings and perhaps *somewhat extra* clicking necessary to
> install the add-on.  Is this acceptable to you?  If not, do you have
> any new arguments to make?

>> But what we disagree on is what action to take when presented with a
>> self-hosted add-on.  Do we warn the user about the harm this add-on
>> *may* cause?  Or do we pretend, as we currently do, that the add-on
>> won't cause harm?
>
> If I install an add-on today, any add-on, I'm presented with a dialog that
> has a warning sign and the following texts:
>
> "Install add-ons only from authors whom you trust"
> "Malicious software can damage your computer or violate your privacy."
>

> That doesn't look like we pretend add-ons cause no harm at all.

> It's also
> clear to me that any warning we put in place will be eventually ignored by
> users.

>> The proposal is to have a *somewhat different* flow for un-reviewed
>> drive-by add-ons than for reviewed add-ons, possibly with *somewhat
>> different* warnings and perhaps *somewhat extra* clicking necessary to
>> install the add-on.  Is this acceptable to you?  If not, do you have
>> any new arguments to make?
>
> That has too many variables to be considered a proposal. If you have
> something more concrete to look at, please share it here.

> One thing I haven't mentioned but it's worth noting: I'm responsible of
> getting the add-on usage stats that will help us better understand the scale
> of this problem.
>
> The data I want is the usage stats for <all/only-enabled> add-ons on
> <between 4 and 7/8 and above> versions of Firefox. I'll revisit this thread
> once I have that data.

On 3/5/2012 8:06 AM, Jorge Villalobos wrote:
> On 3/5/12 9:27 AM, Justin Lebar wrote:
>> But what we disagree on is what action to take when presented with a
>> self-hosted add-on. Do we warn the user about the harm this add-on
>> *may* cause? Or do we pretend, as we currently do, that the add-on
>> won't cause harm?
>
> If I install an add-on today, any add-on, I'm presented with a dialog
> that has a warning sign and the following texts:
>
> "Install add-ons only from authors whom you trust"
> "Malicious software can damage your computer or violate your privacy."

> That doesn't look like we pretend add-ons cause no harm at all. It's
> also clear to me that any warning we put in place will be eventually
> ignored by users.

On 3/5/12 11:50 AM, Jorge Villalobos wrote:
> One thing I haven't mentioned but it's worth noting: I'm responsible of
> getting the add-on usage stats that will help us better understand the
> scale of this problem.
>
> The data I want is the usage stats for <all/only-enabled> add-ons on
> <between 4 and 7/8 and above> versions of Firefox. I'll revisit this
> thread once I have that data.
>
> - Jorge

On 05/03/12 15:27, Justin Lebar wrote:
> But what we disagree on is what action to take when presented with a
> self-hosted add-on.  Do we warn the user about the harm this add-on
> *may* cause?  Or do we pretend, as we currently do, that the add-on
> won't cause harm?
>
> Warning the user that the add-on may cause harm is not "lumping
> together all developers that self-host their add-ons."  When we have
> no reason to trust an add-on, it is a statistical fact that there is
> some non-negligible chance it is bad.

On Mar 6, 2012 4:35 PM, "Gervase Markham" <ge...@mozilla.org> wrote:
> Now, if addons were signed...

On 06/03/12 18:48, Justin Lebar wrote:
> I think Gerv was referring to
> https://bugzilla.mozilla.org/show_bug.cgi?id=728227

>>
>> Justin's saying "add-ons we haven't reviewed need a stronger warning
>> than add-ons we have reviewed" and your answer is that is not OK?
>
> Correct. While I have great confidence in our review system, I
> disagree that by default we should assume that it is better or reflect
> users' desires any better than other QA departments or personally
> built and distributed add-ons.
>

> It should be up to users to decide who they trust.
>