Pros and cons of different add-on install methods

Showing 1-136 of 136 messages
Pros and cons of different add-on install methods Nicholas Nethercote 2/23/12 4:05 PM
Greetings,

"Third-party" add-ons, i.e. those that can be installed into Firefox,
are controversial.  (E.g. see
https://bugzilla.mozilla.org/show_bug.cgi?id=728227.)

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.

Nick
Re: Pros and cons of different add-on install methods Jeff Hammel 2/23/12 4:19 PM
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.

If we're talking about whitelisting the testing addons, that is fine
(though i'm not sure how easy this is to fake too; i'm guessing "not
very" unless we're a little bit careful about it).  But by the same
token we can't block testing workflow if this is going to be a long process.

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.

Jeff Hammel
Re: Pros and cons of different add-on install methods Mook 2/23/12 9:20 PM
I believe most of the use cases are for platform integration.  The Skype
toolbar, for example, seems to be there to scrape for phone numbers in
web pages to open Skype with.  The various anti-virus things seem to do
it to analyze web pages for things similar to the phishing protection in
Firefox.

Firefox doesn't live in an isolated bubble; there's going to be external
developers trying to do things.  There's... significantly more of them,
too.  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.

--
Mook
Re: Pros and cons of different add-on install methods Justin Lebar 2/24/12 1:54 AM
> 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.

Accommodating testing should be totally doable, no matter what path we choose.

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

Even add-ons written in good faith can cause problems [1], so I don't
think that making the Right Thing easy is good enough.

An add-on is as powerful as a patch to browser.js.  We would never
ship an unreviewed, untested patch to browser.js, even from a trusted
Mozilla contributor.  So it seems totally nuts to me that we allow
third parties, malicious and otherwise, to install patches (i.e.,
add-ons) into Firefox with basically no controls and oversight.

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.

[1] http://blog.mozilla.com/nnethercote/2012/02/17/the-mcafee-site-advisor-add-on-has-an-appalling-memory-leak/

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=728227

On Fri, Feb 24, 2012 at 6:20 AM, Mook
<mook.moz+nntp.news.mozilla.org@gmail.com.please-avoid-direct-mail>
wrote:
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
Re: Pros and cons of different add-on install methods Blair McBride 2/24/12 2:57 AM
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.

- Blair
Re: Pros and cons of different add-on install methods Robert Kaiser 2/24/12 7:33 AM
Justin Lebar schrieb:
> An add-on is as powerful as a patch to browser.js.

And that's one of the reasons why we could build such a strong add-on
ecosystem in the first place.

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

One of the large problems seems to be to identify what has been
"installed by third parties", as any application installer in the system
with admin privileges can basically do anything to our install, a user
profile or whatever we require to determine something has been
"installed by third parties".

What I still would find a good thing though is to have an Android-like
flag that by default disables all non-AMO installs. That would at least
make it more difficult to inject add-ons into a default install where
users don't deactivate that pref.

Robert Kaiser
Re: Pros and cons of different add-on install methods Benjamin Smedberg 2/24/12 8:36 AM
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.
Some backstory:

In prior times we identified that we wanted apps to be able to integrate
into Firefox. For instance, we wanted to allow the Thunderbird install
to integrate more tightly with Firefox by making little UI bits
available, such as "email this page". This is similar to the "ideal"
form of a skype addon, for example, which would make it easy to hook up
a telephone protocol, maybe look up microdata, and do linkification so
that it's easy to make calls from within the browser.

At the time, installers were doing this by dropping files into the
Firefox install (appdir/extensions) or the user profile. This was
problematic because often these extensions needed to be updated with
Skype/Thunderbird, not using normal channels. We wanted to provide a
better way to allow this, especially on Windows, so that the extensions
could be installed and updated as part of the normal app install
process, so we introduced the Windows registry method of discovering
integration addons.

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.

--BDS

Re: Pros and cons of different add-on install methods Dave Townsend 2/24/12 8:45 AM
I started filling some stuff into this but then got awfully confused. I
couldn't decide if you are asking for Pros and Cons from the users,
developers or our perspective? Then I realised that that might not
matter as that doesn't seem the same as what you said you wanted, use
cases. Rather than overload the etherpad with that, here are a few I can
think of off the top of my head (and I agree, not all are good ones from
ours or our users perspectives):

* Integration with an application installed on the system (think
Evernote, Skype, AV tools, Java, etc.)
  * Can keep the extension and the applciation versions identically easily
  * Can uninstall the extension at the same time as the application
* Providing a different install experience
  * Downloading a running an exe works from any browser and can install
an extension to multiple browsers
* Bundling an extension with another application
  * Free money from stealing your searches!
* System administrator installs
  * All my users MUST have NoScript!
* Testing
  * Almost all our test harnesses use third-party add-ons
Re: Pros and cons of different add-on install methods Dave Townsend 2/24/12 8:50 AM
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.

I disagree with this actually. If we put hurdles in the way of other
applications on the system then we put hurdles in the way of our testing
infrastructure, it is that simple.

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

We run automated tests against release builds of the application.
Re: Pros and cons of different add-on install methods Dave Townsend 2/24/12 8:50 AM
Forgot one:

* Extension developers for testing purposes
Re: Pros and cons of different add-on install methods Dave Townsend 2/24/12 9:13 AM
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.

I am largely against making things any more difficult at this point for
a couple of simple reasons. 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.

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).
Re: Pros and cons of different add-on install methods Asa Dotzler 2/24/12 9:34 AM
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.

How can we organize a "work week" or similar to work through the
problems and come up with solutions -- (or, possibly, truly convince
ourselves that there really is nothing we can do.)

- A
Re: Pros and cons of different add-on install methods Clint Talbert 2/24/12 6:46 PM
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."
>
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.

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.

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.

I don't want to hijack the thread, but since it came up, let me say a
word about our test infrastructure. We are moving away from addon-based
testing systems. We are currently working on the Marionette project[1]
which will put a test-ability layer directly into Gecko, allowing us to
test *anything* we build on our platform. Marionette is the primary
driver behind the B2G test infrastructure, and once it proves itself
there and lands in m-c[2] we will begin the long process of migrating
all our test infrastructure to use it in place of addon-based systems.

Marionette is not a near term strategy, but since you gave me such a
great way to introduce it, I had to tell you about it. If you disable
the addon integration points in the short term, please rope us[3] in so
we can help you keep our automation running.

Thanks,
Clint

[1] Marionette:https://developer.mozilla.org/en/Marionette
[2] Land Marionette in m-c Bug 712643:
https://bugzilla.mozilla.org/show_bug.cgi?id=712643
[3] We're the Automation and Tools team (Ted's also on our team, but he
forgot to add himself to this list):
https://wiki.mozilla.org/Auto-tools/The_Ateam

Re: Pros and cons of different add-on install methods Henri Sivonen 2/25/12 1:58 AM
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.

I think the fundamental disconnect here is the premise that "users
want" vs. observing that 3rd-party installers that are seem to be
about something other than browsing use running their installer .exe
as an excuse to dump all sort of junk into Firefox and IE (and
nowadays into Chrome, too).

What examples are there of addons that
 1) Are installed by an .exe (as opposed to downloading an .xpi directly)
AND
 2) Are wanted by users
?

If I install a VoIP app, I don't expect it to add functionality to my
browser. I definitely don't expect or want the act of installing VoIP
app to make my browser slow.

If I install an IM app, I don't expect it to add functionality to my
browser. I don't want it to hijack my search defaults and to add a
toolbar.

If I install a PDF reader, I might expect it to offer an NPAPI
plug-in, but I don't expect or want it to stuff toolbars in 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.

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Re: Pros and cons of different add-on install methods Justin Lebar 2/25/12 3:01 AM
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.  FWIW, I agree with him -- we don't need a
100% solution, but we are smarter than malware developers, and if we
make it a priority, I bet we can come up with a solution that works
pretty well.

Dave wrote in the same message:

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

I think this is a key point of difference here.

Even if I accept the truth of this statement, it meets a very low bar.
 Right now, we don't test third-party add-ons, so we have no
systematic way of finding out about these problems.  Even if we did
test every third-party add-on after it was released to users,
convincing the developer to fix a problem and distributing the fix to
users takes time, during which some affected users will become
frustrated and switch to Chrome.

Moreover, I question assertion that we're able to get all issues with
third-party add-ons fixed.  I bet there's sampling bias here -- we do
so little testing of third-party add-ons at the moment, and we place
so few limits on what they can do, that the problems we choose to try
to get fixed are precisely the ones which we think we *can* get fixed.
 If we really stood up against malware/greyware, I doubt we'd be able
to claim that add-on authors are so accommodating.

If the claim is that we *have* standards for third-party add-ons and
think we should enforce those, nobody has been able to explain to me
why enforcing those standards in a patchwork, post-facto way is better
than enforcing them in a systemic way before the add-ons get into
users' hands, as I suggested in bug 728227.

Indeed, we already have a set of standards that add-ons have to meet:
The AMO guidelines.  These are there to protect users and ensure they
stay in control of their browser.  Nobody has explained to me why it's
OK for third-party add-ons, which we agree users by and large don't
ask for, to meet less-stringent standards than AMO add-ons.  If
third-party add-ons are so important to our ecosystem, shouldn't we
relax the AMO guidelines so we stop limiting the AMO developers with
our petty rules?  Nobody has explained to me why users ought to be
protected from AMO add-ons but not from third-party add-ons.

(There's an obvious answer to this: Mozilla puts its stamp of approval
on AMO add-ons, but not on third-party add-ons, therefore AMO should
have standards but third-party add-ons should not.  But this is an
is-ought fallacy: Mozilla *ought* to put its stamp of approval on
every add-on that the user did not explicitly go out and install,
because every add-on is a patch to Firefox.  It's OK if we break
Firefox, it's OK if a user builds their own Firefox with a broken
patch, but it is not OK if a corporation which happens to have
software installed on a user's computer breaks Firefox.)

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.

To make sure I understand this:  You mean to say you think we could
stop even a determined adversary from installing something into
Firefox, but that it would necessarily come at a high UX price?

I don't think this is true (and the argument is merely by analogy) but
even if it is, I'd gladly accept a one-time UX penalty that we control
in exchange for keeping out a permanent UX penalty we don't control,
such as a toolbar or a search-hijacking add-on.

-Justin

On Sat, Feb 25, 2012 at 3:46 AM, Clint Talbert <ctal...@mozilla.com> wrote:
Re: Pros and cons of different add-on install methods Nicholas Nethercote 2/26/12 7:15 PM
On Fri, Feb 24, 2012 at 8:54 PM, Justin Lebar <justin...@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.

I gathered a list of the ~100 top add-ons and filed
https://bugzilla.mozilla.org/show_bug.cgi?id=730737 for this.

----

This has been an interesting thread.  It's also been very abstract.
Let's make things more concrete.

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.

Here's my answer to what users want from add-ons:

  Adblock Plus
  Video DownloadHelper
  Greasemonkey
  Firebug
  Download Statusbar
  Personas Plus
  FlashGot
  NoScript
  DownThemAll!
  WOT - Know Which Websites to Trust
  Tab Mix Plus
  Flagfox
  Easy YouTube Video Downloader
  Flashblock
  Element Hiding Helper for Adblock Plus
  ImTranslator - Online Translator, Dictionary, TTS
  FireFTP
  Web Developer
  IE Tab
  IE Tab V2 (FF 3.5, 4, 5, 6, 7+)

That's the top 20 most popular add-ons on AMO.  These are excellent
add-ons, you've probably heard of a lot of them, you may have some of
them installed yourself.  These are add-ons that users have taken
effort to install.  Every add-on on that list makes me happy (well,
except for https://bugzilla.mozilla.org/show_bug.cgi?id=669730).  When
people say things like "The only reason I haven't switched to Chrome
is because of Firefox's add-ons", this is what they're talking about.
In many cases even if you've never heard of one of these add-ons, you
can tell just from its name roughly what it does.

In contrast, when I look at the top 20 most popular add-ons (including
AMO and non-AMO add-ons) my heart sinks.  The only ones I'm genuinely
happy to see are the AMO ones.  A few others make me think "hmm" and
the rest make me think "oh god".  Unfortunately this list is
considered sensitive so I can't discuss it directly in a public forum.
 But I can point you at
https://bugzilla.mozilla.org/attachment.cgi?id=600823, which has the
top ~100 add-ons, including non-AMO ones, listed in alphabetical
order.  I spent some time looking some of these up.  I've put some
interesting links and data points in a list at the bottom of this
email.  I did some cherry-picking when making that list, certainly,
but I still feel like I've been diving through dumpsters in the bad
part of town.  Some notable things I learnt:

- For many of these, even the ones where the name is known, it's hard
to find any kind of official website to deliberately download the
add-on.

- The fact that third-party add-ons cannot be uninstalled from within
Firefox is hugely confusing to users.  The number of "how do I disable
the XYZ add-on" hits you see is astounding.

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

In my opinion, user control should be the #1 principle when it comes
to add-ons -- users should be able to run exactly the add-ons they
want to, no more and no less.  Third-party add-ons are an enormous
loophole in the "no more" part of that.  The Firefox 8 opt-in check
made that loophole much smaller (and if we lived in a perfect world
where users always read and understood all warnings it would even
smaller).  Do we have any data about how effective that opt-in check
is?  E.g. how many third-party installs were disabled and how many
were re-enabled by users?  I'd love to see any such data.

Nick


----

Results of my searches.  Most of the links were in the top handful of
Google search results.  I randomized this list so they're in no
particular order.

- Conduit Engine: 6 of the top 10 Google search results are about how
to remove it.

- Anti-banner (Kaspersky):
http://www.ghacks.net/2010/10/02/remove-kaspersky-anti-banner-and-url-advisor-from-firefox/

- PC Sync 2 Synchronisation Extension (Nokia) - AMO: #4 Google hit:
How to remove PC Sync 2 Synchronisation Extension
(http://www.techyforums.com/index.php?showtopic=307)

- Java Quick Starter: #1 hit on Google is "Removing the Java Quick
Starter Add-on"
(http://forums.mozillazine.org/viewtopic.php?f=38&t=921325&start=15)

- Microsoft .NET Framework Assistant:  Remarkably popular for an
add-on that doesn't do much.

- {22C7F6C6-8D67-4534-92B5-529A0EC09405} , a.k.a. Trend Micro NSC
Firefox Extension:
http://community.trendmicro.com/t5/Home-and-Home-Office-Forum/how-to-remove-Trend-Micro-NSC-Firefox-Extension-6-5-0-1234/td-p/38616

- Ask toolbar: http://blog.mozilla.com/sumo/2012/02/21/ask-toolbar-is-changing-the-firefox-add-on-process/

- DataMngr (???): SpyBot Search and Destroy classifies it as malware:
http://forums.spybot.info/showthread.php?t=62634.  And it was
nominated for blocklisting last year due to crashes but nothing
happened: https://bugzilla.mozilla.org/show_bug.cgi?id=665775.

- Babylon: #1 hit on Google is
http://www.ghacks.net/2011/08/17/how-to-uninstall-the-babylon-toolbar-completely/.
 #3 hit is "Manual Removal Guide for Babylon.Toolbar"
(http://forums.spybot.info/showthread.php?t=64962)

- {4ED1F68A-5463-4931-9384-8FFF5ED91D92}, a.k.a. McAfee SiteAdvisor:
The old version was by far the leakiest add-on I've ever seen:
https://bugzilla.mozilla.org/show_bug.cgi?id=727938.  The new version
(3.4.1.195) is better, but still easily the 2nd leakiest add-on I've
ever seen: https://bugzilla.mozilla.org/show_bug.cgi?id=729608

- Java Console:  Lots of Firefox installations have multiple old
versions hanging around uselessly.  Remarkably popular for an add-on
that doesn't do much.

- Garmin Communicator: has 51,249 AMO users, and *many* more non-AMO
users.  https://addons.mozilla.org/en-US/firefox/addon/garmin-communicator/reviews/295748/
is interesting, too.

- ShopperReports:  7 of the top 10 google hits are about how to remove
it.  (At least it has a home site, www.shopperreports.com.)

- Search Helper Extension:
http://arstechnica.com/microsoft/news/2010/06/microsoft-slips-ie-firefox-add-on-into-toolbar-update.ars
Re: Pros and cons of different add-on install methods David Illsley 2/27/12 12:20 PM

On 27 Feb 2012, at 03:15, Nicholas Nethercote wrote:
> <snip>
> - 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.

Is there an existing mechanism for 3rd party installers to request firefox install (with user consent) an addon from a URL/amo? It seems at least possible that doing so would result in fewer out-of-date addon installs.

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

Skype Toolbar? Or is it truly the most poorly named addon in existence

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

+1

Apple's recently announced Gatekeeper approach seems like a possibility to be looked at. There are plenty of addons that won't/shouldn't be/can't be hosted on amo, but which come from responsible authors e.g.[1]. Providing a '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. Firefox could, by default, only install signed/or amo addons. Users could allow unsigned extensions, but that would require *in advance* flipping a setting, and there would be no easy prompted mechanism. That could go with a hard and fast rule that any installer which works around this setting gets blacklisted.

I wouldn't want to go further than this, but for me an approach like the above protects users, but provides for user sovereignty in that they can, if they truly wish, install anything.

David

[1] https://addons.mozilla.org/en-US/developers/docs/policies/submission
Is the add-on useful to an appropriately wide portion of Firefox's users? Your add-on doesn't need to be the next Greasemonkey or Firebug, but if  it is only useful to people at your company or who are part of a small web community, we may feel that it's not yet appropriate to put it in front of all of our users.
 
Re: Pros and cons of different add-on install methods Robert Kaiser 2/27/12 12:21 PM
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.

Don't take what _YOU_ think as granted for "the user" out there.

Actually, I've read a ton of messages on webmaster@m.o of people who
"threatened" to leave Firefox for something else just because their
Google Toolbar, Norton/McAfee/etc. in-browser functionality or similar
didn't work after an update (well, often they complain that "Mozilla
disabled my Norton" or such). Those comments are just about as many as
those that complain about search hijacking (why have you changed my home
page to that stupid ASK thing?) and as UI changes ("what is that new
home page where I don't find anything?" - yes, enough people see the
browser UI as "the home page").

You can't take yourself as an example for "the common web user", as
there is no such thing as the latter. There's all kind of different
people out there who want different things. Sure, the vast majority
don't want malware, but some of that third-party add-on stuff is
actually the reason to use Firefox and/or a certain third-party
application for a good number of people.

Robert Kaiser
Re: Pros and cons of different add-on install methods Benjamin Smedberg 2/27/12 12:38 PM
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 isn't a clearly defined problem yet, so talking about "this
problem" probably isn't the best language.

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?

We technically can require all addons to be signed, or some
non-authenticode equivalent where we ask AMO whether an addon is "ok".
But that's a pretty different discussion than what *install locations*
we support, which is how this thread started. 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.

--BDS

Re: Pros and cons of different add-on install methods Justin Lebar 2/27/12 1:25 PM
> 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.

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.

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

Do you mean #2?  Opting in to a third-party add-on does not solve the
problem of users not knowing that an add-on is making Firefox slow.

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

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

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

No disagreement here.
Re: Pros and cons of different add-on install methods Jorge Villalobos 2/27/12 1:30 PM
+100
Re: Pros and cons of different add-on install methods Gijs Kruitbosch 2/27/12 2:21 PM
On 27/02/2012 22:25 PM, Justin Lebar wrote:
> <snip>
> 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.
>
> <snip>
>
> I don't think our opt-in screen is sufficient to get informed consent
> from a user.  Additionally, it does not fix #1.
>
> <snip>


Note that in the bug cited in the beginning (
https://bugzilla.mozilla.org/show_bug.cgi?id=721258 ) an add-on chose to modify
the (perception of the) opt-in UI because they already felt that was too scary.
Their argument seems to have been that the users already had a choice when they
installed the software (an opt-out screen in the setup program, AIUI) and
shouldn't have to click-through twice.

I agree that informed consent is good and important. However, I do think that
helping the user in this respect is Hard. What information does the user need,
exactly? How would we obtain that information for a given add-on? How do we
authenticate the add-on as being linked to that information?

Worst of all, I think the bug suggests that if we were to make the dialog/UI
scarier, external parties would go further in order to give users a more
'streamlined' experience when installing such an add-on.

I'm wondering if it would be better to do something more invasive post-facto:
detect performance/crash problems with add-ons and automatically disable them
for the user, and notify them about this in some way (offer them the option to
re-enable and/or completely remove the add-on). This could be a mechanism
similar to the blocklist we currently have, based on central testing. In
essence, this would mean invoking (b), but post-facto rather than doing vetting
beforehand.

The current blocklist system is a pretty harsh measure and affects users who
have intent (if not, perhaps, fully informed). Scary/scarier dialogs will
encourage vendors to bypass them. I wonder if this could be a good middle way.

Thoughts?

Gijs
Re: Pros and cons of different add-on install methods Geoff Lankow 2/27/12 2:54 PM
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
> amo, but which come from responsible authors e.g. Providing a
> '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.

This, or something like it.

If we clearly mark addons that haven't been AMO reviewed as such (at
every opportunity - about:addons,  about:newaddon, choose-your-addons
dialog, others?), and create a way for third party addon devs to obtain
such a review without hosting on AMO, users will be better informed and
addon quality will improve (also, participating developers would be
agreeing to our terms). From an AMO point of view, I guess it'd require
a new type of addon listing, so while we're at it each addon could have
a page stating what it does (written by the developer or AMO reviewer),
how to remove it, performance etc.. We could also do this for popular
third-party addons we know about that haven't been submitted to be reviewed.

GL

Re: Pros and cons of different add-on install methods Nicholas Nethercote 2/27/12 6:56 PM
On Mon, Feb 27, 2012 at 1:25 PM, Justin Lebar <justin...@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.

Yes!  IMO the 3rd-party opt-in warning was a great step forward.  In a
perfect world, all users would read and understand the 3rd-party
opt-in warning, and this problem would be much smaller.

The current 3rd-party installation flow is 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.
- Firefox pops up the warning screen.
- The user opts in or out.

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.

Pros:
- It's a small change, much smaller than some other changes that have
been suggested.
- It's simpler than what we currently have -- no warning screen.
- It should further (greatly?) reduce the number of people who consent
to an add-on install without understanding what it means.

Cons:
- It's a tiny bit more work for a user who wants to accept a 3rd-party
install.  (But we already make people do some work.)
- It doesn't solve the "I don't know how to uninstall add-on X" problem.

Nick
Re: Pros and cons of different add-on install methods Henri Sivonen 2/27/12 11:07 PM
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.

Do users in general *expect* a VoIP app install to modify their
browser or do some of them just find the result convenient on
occasion? Do we have Mac and Linux users complaining that when they
installed Skype, they didn't get modifications dumped into their
Firefox?

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

I meant Trillian dumping the Ask.com stuff into Firefox. It has very
little to do with IM functionality.

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

Fair enough.

Still, I think we should do something effective to steer our user base
to anti-virus programs that don't make the Firefox UX suck.
Re: Pros and cons of different add-on install methods Neil 2/28/12 3:13 AM
Nicholas Nethercote wrote:

>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.
>  
>
How would they know that it was there?

--
Warning: May contain traces of nuts.
Re: Pros and cons of different add-on install methods Robert Kaiser 2/28/12 11:03 AM
Henri Sivonen schrieb:
> 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.
>
> Do users in general *expect* a VoIP app install to modify their
> browser or do some of them just find the result convenient on
> occasion? Do we have Mac and Linux users complaining that when they
> installed Skype, they didn't get modifications dumped into their
> Firefox?

Not sure. You know, nobody did *expect* an awesomebar before we created
it and people got used to it - now they expect something like it. The
same is true for stuff like this - it's a convenient feature, people
will only complain when they had it and suddenly lose it. Just like the
Google Toolbar, for example.

> I meant Trillian dumping the Ask.com stuff into Firefox. It has very
> little to do with IM functionality.

Search hijacking is something we need to solve, that's clear anyhow.

> Still, I think we should do something effective to steer our user base
> to anti-virus programs that don't make the Firefox UX suck.

Nowadays that mostly means dumping Windows XP and using MSE on Win7.
Almost every other security suite is on record for causing one or the
other problem with us at times.

Robert Kaiser
Re: Pros and cons of different add-on install methods Nicholas Nethercote 2/28/12 4:01 PM
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?

If they deliberately installed the add-on, whatever instructions they
are following can tell them.

If they didn't, they won't know.  That's the whole point :)

Nick
Re: Pros and cons of different add-on install methods db_cooper 2/28/12 5:16 PM
A telling comment from Ars Technica's article on "the challenges of policing the Firefox ecosystem":

http://arstechnica.com/business/news/2012/02/add-ons-behaving-badly-the-challenges-of-policing-the-firefox-ecosystem.ars?comments=1#comments-bar

"Is there a third-party plugin like Adblock plus, but functions for add-ons? I would LOVE to be able to set up my familys' browsers and install some 'pluginBlock Plus' that will keep them from being afflicted by the ask toolbar, yahoo browserplus, Site Advisor and all the other crapware that can accumulate."
 
Re: Pros and cons of different add-on install methods Brian Smith 2/28/12 9:48 PM
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.

* Investigate the application sandboxing mechanisms in Mac OS X Lion and later, and in Windows 8 and later, and take full advantage of them when they are available.



At the business/partnership level:

* Create partnerships with anti-malware vendors that provide useful tools for stopping bad Firefox addons, that would enable us to give their software (perhaps a version with targeted functionality) to our users for free.

* Do co-marketing with venders of operating systems that offer protections against these problems. E.g. if Windows 8's sandboxing is effective at preventing this kind of abuse, then start a "Firefox Recommends Windows 8" campaign with Microsoft.



At the operating-system level, we can:

* Build our own operating system (e.g. B2G) with security and malware-prevention as a primary focus, and convince users to use it.

* Have our installer (which runs with admin rights) scan for badware and help facilitate its removal each time we do an update.



Notice that all these suggestions are about general anti-malware, and not about addons. That is because, for many purposes, you don't even need to build a Firefox extension to abuse Firefox users. For example, if *I* were going to build software that hijacked the Firefox search box, I would do it this way:

   1. Run a process in the background that watches for
      Firefox windows.
   2. Overlay a transparent window on top of (the title
      bar and toolbar of) each Firefox window then they
      are opened.
   3. Forward most mouse from my transparent window to
      the Firefox window underneath, except for
      clicks on the search box.
   4. Forward most keyboard events to Firefox, except
      for ones that would set focus on the search box.
   5. Overlay my own search box on top of the Firefox
      search box which handles the keyboard input, and
      when a search is done (e.g. enter is pressed),
      loads the URL in Firefox.
   6. If there were ever an imminent update to Firefox
      that could somehow protect against my software,
      I would immediately disable Firefox's update
      checking.

This could also be done by writing a custom mouse driver and/or mouse hook and/or assistive technology plugin, AFAICT. Developing such software wouldn't be that expensive, and it would be nearly impossible to defend against, or even detect. (We don't have ANY idea how much software is already doing this to us.)

- Brian
Re: Pros and cons of different add-on install methods Brian Smith 2/28/12 10:04 PM
Nicholas Nethercote wrote:
> The current 3rd-party installation flow is 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.
> - Firefox pops up the warning screen.
> - The user opts in or out.

I think this does a reasonable job of keeping honest add-on developers honest.

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

I think even well-intentioned addon developers would try to subvert this, just like Mozilla subverts Microsoft's restrictions against applications pinning themselves to the taskbar in Vista/7.

- Brian
Re: Pros and cons of different add-on install methods Justin Lebar 2/28/12 11:15 PM
I think maybe the reason I'm still hopeful we can do something useful
on the technical side to protect our users is: I have difficulty
believing that many malware authors are as smart as bsmith.

If we were only able to block 50% of the add-ons we tried to block,
and only for one year, wouldn't that still be worth doing?

I think it might be folly not to do anything because we're afraid of
malware authors finding a way around it.  Shouldn't we have used this
same logic to argue against the third-party add-on confirmation screen
added in FF8?  (Perhaps you did!)

Of the many good suggestions here, a few involve relying more on
anti-malware software.  But of course anti-malware is also a
cat-and-mouse game.  I understand that virus scanners run with higher
privilege than Firefox and invest a degree effort into this
cat-and-mouse game that we probably don't want to.  But if you believe
these tools are effective (I honestly have my doubts), then that's
evidence that *someone* is capable of keeping up with malware authors,
at least to some degree.
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
Re: Pros and cons of different add-on install methods Jonas Sicking 2/29/12 7:56 AM
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.
>
>> 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).

It's definitely true that we don't know what users want in all situations.

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. I don't think that we can with good
conscience look at the data and still throw up our hands and say
"well, the users chose to install the software, they must want it".

Freedom of choice is extremely important. I think none of us want to
become gate-keepers in the same fashion as Apple's App store. However
freedom of choice is only meaningful if we provide users the ability
to make informed decisions. Given the looks of the list of installed
addons people are making, I think we can safely say that many of them
are not making informed decisions.

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.

2. When we find significant problems with an addon, such as crashes or
significant performance/memory problems have the capability to inform
users about this. I haven't heard the latest of the by now well known
problem in a McAfee Site Advisor so it's quite possible that the
problem has been fixed since. However in similar situations, it would
be great if we could display a dialog to the user which explains the
problem with the addon, what functionality the addon provides (I think
we have anecdotal evidence that people are worried that disabling the
Skype toolbar makes it impossible to use skype at all) and explain
that if they choose to disable the addon for now, it will be
automatically enabled when a fix for the problem is provided by the
vendor.

Providing users with tools to customize their firefox experience the
way they want to, and providing the information needed to use those
tools should hopefully be an obvious win.

Additionally I think it would be awesome if we could require addons to
provide a honest description of what the addon does. Right now users
have very little information to go on when deciding if they should
enable an addon or not. However given all the trouble we have with
enforcing much less controversial policies like "shouldn't cause big
performance/memory problems", having a policy like "must not lie when
providing description of what addon does" seems dead on arrival.

/ Jonas
Re: Pros and cons of different add-on install methods db_cooper 2/28/12 5:16 PM
Re: Pros and cons of different add-on install methods Dave Townsend 2/29/12 10:16 AM
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.

This is something we have to fix, not the third-parties. We don't give
them a way to install extensions that can then be uninstalled by users.
Re: Pros and cons of different add-on install methods Henri Sivonen 2/29/12 10:18 AM
FWIW, non-support for toolbar junk is now a marketable characteristic of IE10:

"Why don’t toolbars and add-ons work?"
"Internet Explorer 10 provides an “add-on free” experience."

http://windows.microsoft.com/en-US/windows-8/faq

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Re: Pros and cons of different add-on install methods Robert Kaiser 2/29/12 10:33 AM
Jonas Sicking schrieb:
> 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.

Sure, and search hijacking is only one example of that (and you'll see
that I mentioned both that and the more general thing as also being
high-volume factors is misdirected webmaster@m.o email).
I didn't say anything to the contrary. I just stated that Henri's view
or depiction of things is also way too simplistic as there are good
reasons for users to want some of the add-ons installed by third parties.

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
Re: Pros and cons of different add-on install methods Robert Kaiser 2/29/12 10:39 AM
Brian Smith schrieb:
> * 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.

If we would provide hooks to security suites to implement their stuff
without crashing if we changed binaries (e.g. after an update) and
across versions (so that people won't damn Firefox because "it disabled
their Norton" on every update), I'd be incredibly happy.

Robert Kaiser
Re: Pros and cons of different add-on install methods Justin Lebar 2/29/12 11:59 AM
Note that at the moment, many malicious/questionable add-ons can still
claim to be following our rules.  So if I were an AV vendor, I'd be
hesitant to brand them as a "virus".

On the other hand, if an add-on actively subverts Firefox's
protections, then we could rightly claim that it's unquestionably
malicious and should be blocked.

So if you think we should get AV vendors involved on our side, there's
an argument for escalating things.  I'm not convinced it outweighs the
dangers of provoking escalation,  but then again, I have very little
faith in AV in general.

-Justin

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.
>
Re: Pros and cons of different add-on install methods Asa Dotzler 2/29/12 3:23 PM
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

It's not as simple as agreeing that both are important. Because one
necessarily trades against the other, we have to decide which is more
important and by how much.

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

Raising the barrier for the few add-ons that legitimately want to be
hosted outside of AMO is the next step we will have to take in order to
slow the spread of unwanted add-ons.

We should increase the barrier both in product (more features like our
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.

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
Re: Pros and cons of different add-on install methods Dao 2/29/12 3:52 PM
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?
Re: Pros and cons of different add-on install methods Robert Strong 2/29/12 3:58 PM
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.

Robert

>
> 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
Re: Pros and cons of different add-on install methods Brian Smith 2/29/12 4:25 PM
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.

Then the malicious addons will disable and/or filter the blocklist. It isn't even hard, because we give them the APIs to do so.

- Brian
Re: Pros and cons of different add-on install methods Justin Lebar 2/29/12 4:27 PM
At which point we publicly shame them, try to get AV vendors to block them, etc.

By blacklisting, we're no worse off than we were before, right?  The
blacklist can be a public sign that we disapprove, even if it's not
effective technically.

-Justin
Re: Pros and cons of different add-on install methods Brian Smith 2/29/12 5:27 PM
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/

Cheers,
Brian
Re: Pros and cons of different add-on install methods Nicholas Nethercote 2/29/12 5:45 PM
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.

This comes down to your definition of "malware".  I'm interested in
fixing the more blatant malware and crapware that really degrade
Firefox, not add-ons that poke their toes over a line.


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

What's your point?  Any platform will have rules and ways to punish
those that violate the rules.  (E.g. we have the add-on blocklist.)
That doesn't mean our rules are the same as Apple's.

And no-one's arguing that Firefox add-ons should only be available via
AMO, which is what would be required for us to be equivalent to the
iPhone and the App Store.  (Furthermore, IMO, these Apple/iPhone
analogies are as likely to confuse as they are to illuminate.)

Nick
Re: Pros and cons of different add-on install methods Asa Dotzler 2/29/12 5:52 PM
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. If we can manage to lower the warning "tone" of the
confirmation dialog for add-on installs that we review at AMO, I have no
intention of making the warning any less scary (and could imagine making
it even scarier) for non-AMO sites.

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. Right now we're
treating non-AMO installs (after the "let this site prompt for installs
clickthough) with the same "warning" as AMO installs and that's wrong.

- A
Re: Pros and cons of different add-on install methods Asa Dotzler 2/29/12 5:57 PM
Malware that is truly malware with dedicated people behind it will
circumvent a lot. But crapware that doesn't want to be labeled as
malware and targeted by AV software and Mozilla in the public sphere
will conform or give up.

- A
Re: Pros and cons of different add-on install methods Asa Dotzler 2/29/12 6:07 PM
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.


I disagree. That's not a security feature in any way. That's not even a
"pro-user" feature. It's a blatant anti-competetive move that Microsoft
very carefully crafted to be able to advantage IE against other
browsers, violating the spirit but not the letter of the Consent Decree
they agreed to with the US DOJ more than a decade ago.

We're not arbitrarily blocking software. We will have rules that are
clearly pro-user and which we will can feel good about defending.


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


AV software vendors do not want to subvert Firefox. They are trying to
work with us. They would appreciate not having their users jump through
dialogs and other hoops when they have achieved actual real informed
user opt in and I'm more than happy to carve out exceptions for those
who behave well.

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

That's just silly. We are not Apple or Windows. We are a public-benefit
organization looking out for our users. That's what our mission demands
of us. Any comparison of our actions in support of our users for the
promotion of our mission to those of profit-driven monopolists trying to
hold on to or increase their control over users is horse shit, IMO.

- A
Re: Pros and cons of different add-on install methods Dao 2/29/12 6:35 PM
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.

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

Sure, allowing one-click installs on random sites would be insane.
Re: Pros and cons of different add-on install methods Asa Dotzler 2/29/12 6:44 PM
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.

Sorry, I got to the final paragraphs where I was talking about both
third party software installs and non-AMO installs and thought I should
just insert it into that earlier paragraph and it would make sense.

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

- A
Re: Pros and cons of different add-on install methods Justin Lebar 2/29/12 7:08 PM
> 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.

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

Right now, the untrusted cert warning is way scarier than the non-AMO
warning, and it's roughly as easy to accept a bogus cert as it is to
install a non-AMO add-on.  So if you think that the untrusted SSL flow
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).

(Now, maybe you'll say that we shouldn't assume that all non-AMO
add-ons are malicious.  But should we similarly assume that untrusted
certs are not malicious?  Many of them are perfectly benign, but
that's not the point.  The point is, we can't trust them, just like we
can't trust non-AMO add-ons.)
Re: Pros and cons of different add-on install methods Brian Smith 2/29/12 8:28 PM
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).

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.

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

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]." This is much better than a dialog that says something vague about the addon being untrusted. Users are used to clicking through those kind of vague warnings all day every day to get stuff they want.

I really like the already-done work that was done to prompt the user to enable an addon. Like I said before, it is a good trade-off for keeping honest people honest. The main thing I am arguing against in this thread is the idea that user-mode Firefox can protect itself against admin-rights malware/grayware installers in any way that can be controlled by end-users. I think it is a waste of energy to implement any additional protections against third-party installers that can be subverted by doing anything other than replacing existing Mozilla-signed EXE and DLL files in C:\Program Files\Firefox (these actions should automatically get the software classified as malware by AV software, which we should help users enable). So, for example, it doesn't make sense to require only non-AMO software to be signed, or to allow the user to disable those checks; instead, to be effective, all addons (including addons from AMO) would have to be signed, and there must not be a pref to disable the signature checks. In other words, we would be implementing a signature system very similar (technically) to Apple's iOS system; obviously, there would be significant fallout from that.

The secondary thing I am arguing against is the idea that we could force venders of security software to wait days or weeks for us to review their addon updates to sign them, just because we are worried that they might cause a memory leak or some other problem. It sucks when there are bad bugs in these addons, but I don't think the risk of such bugs outweighs the venders' needs to ship updates as fast as possible. Those venders generally need to be able to ship updates to their addons as fast as possible, for the same reasons we must be able to turn around chemspill releases as fast as possible.

Cheers,
Brian
Re: Pros and cons of different add-on install methods Dao 3/1/12 3:14 AM
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).

You already made the relevant distinction. Here the user actively
installs software, there the user is told that the connection may be
insecure when the user likely expects it to be secure.

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.
Re: Pros and cons of different add-on install methods Benjamin Smedberg 3/1/12 4:55 AM
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.
That's a true long-term statement, and is something that we've actively
been addressing with the jetpack design (if not the current SDK
packaging implementation). But it doesn't really help us figure out what
to do right now in terms of policy and UI.

> 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]."
How would we  possibly know what functionality an addon has in the
install dialog (unless it came from AMO)? I think it's good to be more
specific about the warning, but "is likely to" seems like a pretty far
overreach...

--BDS
Re: Pros and cons of different add-on install methods Justin Lebar 3/1/12 6:05 AM
> 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.

Assuming that the add-on opt-in in FF8 is not being routinely
circumvented, every non-AMO add-on listed there was explicitly enabled
by the user.  So the fact that there's so much crap listed indicates
to me that we're not doing a good enough job protecting our users from
crap.

-Justin
Re: Pros and cons of different add-on install methods Dao 3/1/12 6:14 AM
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...

Most of our users get reasonably scary OS-level warnings that we don't
control, fwiw.

You also wrote "way scarier (and way harder to get around)". So, again,
we should make downloading harder (not just scarier), shouldn't we?

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

Many of these are drive-by installations, not in-browser installations
from non-AMO sites. We had successfully made this distinction some time
ago in this thread.
Re: Pros and cons of different add-on install methods Jorge Villalobos 3/1/12 6:37 AM
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.

- Jorge
Re: Pros and cons of different add-on install methods Jorge Villalobos 3/1/12 6:37 AM
On 3/1/12 8:05 AM, Justin Lebar wrote:
Re: Pros and cons of different add-on install methods Jorge Villalobos 3/1/12 6:41 AM
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.

- Jorge
Re: Pros and cons of different add-on install methods Jorge Villalobos 3/1/12 6:41 AM
On 2/29/12 7:45 PM, Nicholas Nethercote wrote:
Re: Pros and cons of different add-on install methods Asa Dotzler 3/1/12 9:06 AM
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
Re: Pros and cons of different add-on install methods Robert Kaiser 3/1/12 10:35 AM
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.


I have said it repeatedly before, and I will reiterate that I think we
need to go Android-style and disable installation of non-AMO add-ons by
default, with a setting that needs to be flipped to even enable those at
all, and then some distinct warnings (better than what we have now) even
when that setting is enabled.
I like Justin's parallel to the cert warnings a lot, as I think we have
a pretty good UX there for making it hard to do the wrong thing but
still allowing exceptions for people who know what they are doing.
Perhaps we should deploy a very similar experience here.

Robert Kaiser
Re: Pros and cons of different add-on install methods David Illsley 3/1/12 11:11 AM
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.

I suspect a lot of the public good will towards companies saying 'trust us,
we're not evil' is used up, regardless of the details (and I do trust
Mozilla). I'd find selling the openness message, particularly around
mobile, more difficult if the discussion isn't around principles, but
around the intentions of the gatekeepers.

David
Re: Pros and cons of different add-on install methods Asa Dotzler 3/1/12 12:17 PM
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.

Well, you'd be wrong. Apple has said publicly that they will not allow
for apps that compete with built in iOS functionality and have
disallowed apps which did that from their store. They have also censored
content that they found objectionable even though the "code" of the app
would have passed a detailed technical review.

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

We already have a system that allows us to block bad acting add-ons.
There is already a regime. The issues at hand is the scope of the
policies and the enforcement mechanisms.

- A
Re: Pros and cons of different add-on install methods Asa Dotzler 3/1/12 12:21 PM
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.

And I'll repeat: those two things are in conflict. We cannot optimize
for both of those things. They trade against each other. 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. If we want to make it super easy to get some non-AMO add-ons they
do want, we're going to see them get more add-ons they didn't want.

I think you think we can have both. We cannot. We have to decide which
is more important and optimize for that case -- even at the expense of
the other side.

- A
Re: Pros and cons of different add-on install methods Nicholas Nethercote 3/1/12 3:24 PM
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.

Nick
Re: Pros and cons of different add-on install methods Jorge Villalobos 3/1/12 3:45 PM
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.

Agreed. I don't have that data, and I don't know if anyone has been
tracking this.

- Jorge
Re: Pros and cons of different add-on install methods Jorge Villalobos 3/1/12 3:45 PM
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.

Re: Pros and cons of different add-on install methods Asa Dotzler 3/1/12 8:37 PM
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

I think this is the wrong balance. I would prefer that we put an
additional burden on "capable" users -- those most able to deal with the
burden, to protect those less capable who end up with add-ons they
didn't knowingly install.

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

Yes. Precisely.

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

I realize that this is not what you and other add-on development
evangelists and add-on authors want to hear, but our mission clearly
puts the user first.

- A
Re: Pros and cons of different add-on install methods Jorge Villalobos 3/2/12 8:42 AM
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.

Not only optimizing for developers, but also giving more choice for the
users who install these developers' add-ons. It's worth reiterating that
there are users on both sides of this scale.

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

The might be unwilling to work with us for many other reasons than "not
caring about our users". I deal with the frustration many developers
have to go through in order to list their add-ons on AMO on a daily
basis. While for the most part they appreciate our input and our free
publishing and distribution platform, many have to deal with constant
delays and seemingly arbitrary policies. I defend our right to do that
on our site, but I also defend the right of others to deal with their
self-hosted add-ons in their own terms.

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.

- Jorge

Re: Pros and cons of different add-on install methods Justin Lebar 3/2/12 9:13 AM
> Users *are* giving consent by choosing to install the add-on.

I disagree.  This is misconception is key to understanding those of us
who want tighter restrictions on drive-by add-ons.

Let's put aside what "consent" means and agree that strict "clicked
OK" is not the bar we want to set for users' "consent".  What we want
is *informed* consent.

Like I said earlier, I think a user can give informed consent to
install an add-on by either:

 a) Reading the add-ons source code, or
 b) Understanding the risk of installing the add-on and
     b.1) explicitly delegating trust for the add-on's evaluation to a
third-party (e.g. Mozilla), or
     b.2) explicitly choosing to trust the add-on itself.

Users are not giving informed consent under the current scheme.

Again, consider the bogus-SSL cert page.  A dialog saying "This cert
is bad.  Continue? [Yes] [No]" would explicitly *not* be sufficient to
get informed consent from a user.  That's why we have this complex
click-through page -- we have to inform before we get consent.
Re: Pros and cons of different add-on install methods Justin Lebar 3/2/12 9:24 AM
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?

-Justin

On Fri, Mar 2, 2012 at 11:42 AM, Jorge Villalobos <jo...@mozilla.com> wrote:
Re: Pros and cons of different add-on install methods Robert Kaiser 3/2/12 9:35 AM
Asa Dotzler schrieb:
> 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.

If you read carefully those statements where I proposed anything we
could do, that's exactly what I was proposing (disabling non-AMO-hosted
add-on installation by default, possibly displaying a
cert-warning/exception-style UI if that default is being changed and an
installation is being made).

I also think that we should improve the installation experience of
AMO-hosted add-ons, but that's yet another discussion.

Robert Kaiser
Re: Pros and cons of different add-on install methods Asa Dotzler 3/2/12 10:01 AM
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.

I think we should make AMO more attractive and make not-AMO a lot less
attractive. There is no perfect solution here but we can and should do
more to help users who are getting add-ons they don't want -- even if
that makes things somewhat more difficult for add-on authors who don't
wan to jump through our AMO hoops.

- A
Re: Pros and cons of different add-on install methods Asa Dotzler 3/2/12 10:03 AM
Great! We're on the same page then. I do have plans (working through
them with Unfocused and Mcoates) to make the AMO experience much better.

- A
Re: Pros and cons of different add-on install methods Dave Townsend 3/2/12 10:09 AM
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.

Could you summarise those options for us please, I'm having trouble
finding actual concrete options in this giant thread.

> 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 am not the module owner of the extension manager any longer, but I am
still the toolkit owner, and I'm against tighter controls right now. I
haven't heard the current module owner of the extension manager give any
input yet.

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

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

I think what has come out of this thread is that we don't actually know
if we need to take action yet. There has been a lot of pointing at the
list of the top 100 add-ons that users have installed but we've shown
that we don't actually know what percentage of those are actually
enabled. I think we need to get that data before we start talking about
making any changes.
Re: Pros and cons of different add-on install methods Justin Lebar 3/2/12 10:39 AM
>> 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.
Re: Pros and cons of different add-on install methods Dave Townsend 3/2/12 10:47 AM
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.

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

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

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.
Re: Pros and cons of different add-on install methods David Mason 3/2/12 11:12 AM
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.

I have to agree with what Dave said. We have 3rd parties who act in good
faith and provide functionality that many users want and appreciate. We
should understand the issues and scale *completely* before trying to
push something as fast as we can.


Dave Mason
Re: Pros and cons of different add-on install methods Justin Lebar 3/2/12 11:58 AM
On the question of,

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

I wrote to Dave privately and pointed him to my previous posts about
the criteria I'd say need to be met in order for a user to consent to
installing an add-on.  Dave told me these weren't sufficient, so here
we are:

> You've said below that the only way users can give informed
> consent is if we either show them the add-ons source (I would disagree with
> this, users can't read source code)

Agreed, users can't read source code.  I'm just saying that a user
*could* give informed consent after having read the source.  But this
isn't the only way to give informed consent, naturally.

> delegate trust to Mozilla (but you've
> said we don't need the add-ons team to be involved with these changes) or

Right, we can't do this without the add-ons team.

> "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.
Re: Pros and cons of different add-on install methods Dave Townsend 3/2/12 12:02 PM
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.

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.
Re: Pros and cons of different add-on install methods Dave Townsend 3/2/12 12:05 PM
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.

Waiting a few weeks seems totally fine to me btw. We should be taking at
least that long to think carefully about what changes we make here. It
would also be quite important to get the install date of the enabled
add-ons here. Data about those installed after the user got the opt-in
controls in Firefox 8 will be most useful in helping us understand the
problems with the current messaging.
Re: Pros and cons of different add-on install methods Justin Lebar 3/2/12 12:17 PM
> 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?
Re: Pros and cons of different add-on install methods Dave Townsend 3/2/12 12:46 PM
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.

Yes every user is worth protecting, assuming that we can do so in a way
that doesn't harm more users. I believe it is in the best interests of
our users for us to maintain a close working relationship with as many
of the third-parties as we can. Making their release process harder,
making it harder for their users to use their add-ons hampers that. If
it comes down to a choice between being able to work with, say, McAfee
to help them solve a memory leak in their add-on and letting a few bad
add-on installs through (that we can blocklist) then I fall on the side
of the number of affected users, and we don't have that information.
True it isn't black and white like this, but we don't even know the
levels of grey at this point.

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

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

We can talk honestly all we like, but I think the message that users
would take away from a message such as you propose is that Mozilla has
determined that this particular add-on includes the functionality you're
describing. Yes, you just made that up on the spot so sure it needs
changing but I'm not sure how we can make specific warnings like that
without users misunderstanding them. A challenge for the UX team to be sure.
Re: Pros and cons of different add-on install methods Jorge Villalobos 3/2/12 12:58 PM
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.

Malware (as in, /real/ malware) is handled through the blocklist, and we
shouldn't expect such software to abide by our rules and present itself
through the third-party install dialog.

As far as I understand this discussion is about externally-installed
add-ons that users may not want to install but end up installing anyway.
Coming up with a language we can all agree with about what we're trying
to address and what we're not would help narrow down and understand the
problem, I think.

Here's a suggestion:

* Malware add-ons - installed with malicious intent and aimed to disrupt
a user's system or steal their data.

* Greyware add-ons - push users into getting themselves installed and/or
change user defaults and/or violate other privacy or choice policies we
enforce on AMO.

* Non-AMO add-ons - all add-ons distributed outside of AMO.

* Externally-installed add-ons - installed from an EXE, MSI or other
installer file. Normally handled by Firefox with an opt-in screen.

- Jorge
Re: Pros and cons of different add-on install methods Jorge Villalobos 3/2/12 12:58 PM
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.

Re: Pros and cons of different add-on install methods Justin Lebar 3/2/12 1:07 PM
>> 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.

Jorge, do you agree with this in principal?  Are you willing to reach
out to our partners and ask if this would be acceptable to them?
Re: Pros and cons of different add-on install methods Jorge Villalobos 3/2/12 2:13 PM
Reaching out to them would be Kev's responsibility, since he's the one
with most of the contacts.

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.

- Jorge
Re: Pros and cons of different add-on install methods Jorge Villalobos 3/2/12 2:13 PM
On 3/2/12 3:07 PM, Justin Lebar wrote:
Re: Pros and cons of different add-on install methods Justin Lebar 3/2/12 2:55 PM
> 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"?

> 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

Agreed.

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

Awesome!

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

We eagerly await.  :)
Re: Pros and cons of different add-on install methods Jorge Villalobos 3/2/12 3:27 PM
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.

- Jorge

Re: Pros and cons of different add-on install methods Jorge Villalobos 3/2/12 3:27 PM
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"?

Re: Pros and cons of different add-on install methods Asa Dotzler 3/2/12 5:17 PM
We've been saying that for 3 years now and every year it's getting worse
and worse.

- A
Re: Pros and cons of different add-on install methods Asa Dotzler 3/2/12 5:21 PM
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?

I fully support this approach.

- A
Re: Pros and cons of different add-on install methods Asa Dotzler 3/2/12 5:28 PM
This seems completely wrong to me. It sounds like something from one of
those other companies. We should not put the success of commercial
entities like McAfee ahead of our users. If McAfee stops working with us
because we put the well-being of our users over their bottom line, then
let them walk. On the other hand, if they want badly enough to
piggy-back on our market penetration they'll come into the fold and work
with us, and we can get them into a low-friction installation path.

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

The cost is "do we care enough about that particular add-on to do the
review work to ensure it's safe for our users" just like any other
add-on that goes through AMO. We're blowing add-on review hours at AMO
on add-ons with no users and no future. Surely that time could be doled
out to higher profile add-ons from cooperating vendors. I'd make that
trade just about any day of the week.

- A
Re: Pros and cons of different add-on install methods Asa Dotzler 3/2/12 5:44 PM
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?


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

Mistakes happen even in Firefox reviews. Things are sometimes
overlooked. We can never guarantee everything will be fine. But that
does not mean reviews are useless or that reviewed features are no safer
than un-reviewed features.


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

- A

Re: Pros and cons of different add-on install methods Justin Lebar 3/2/12 6:30 PM
> 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.
Re: Pros and cons of different add-on install methods Dave Townsend 3/3/12 8:02 AM
I can't say I've recognized such a trend, perhaps you have numbers to
back that up?

Either way that doesn't in my eyes constitute a reason to jump the gun.
We have introduced a change in Firefox 8 which we think will have
improved the situation. We have a bug on file that will help us gather
data on what kind of a problem that leaves us with. We should wait for
that data before making any further changes.
Re: Pros and cons of different add-on install methods Dave Townsend 3/3/12 8:09 AM
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.

"not explicitly found to be malicious" covers all add-ons, even reviewed
ones. Assuming you just mean un-reviewed add-ons then I'd be ok with
making the dialog scarier (not way scary) but it must be done in a way
that users understand and in consultation with the third parties that we
work with
Re: Pros and cons of different add-on install methods Dave Townsend 3/3/12 8:18 AM
You're misunderstanding me. I don't think if they stop working with us
they will walk away, I think they'll just start circumventing us and
ignore us when we try to talk to them about issues we've found with
their add-on.
Re: Pros and cons of different add-on install methods Jorge Villalobos 3/3/12 8:51 AM
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?

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.

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

Like I said, telling people "This add-on has been reviewed by Mozilla"
or "This add-on has been reviewed by X" is informative and give users
more tools to make an informed decision whether to install the add-on or
not. I think that's the right way to go. Telling people "this add-on is
riskier" just because we haven't reviewed it is disingenuous at best.

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

Disagree.

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

Disagree.

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

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.

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

Making UI more informative and empower users is a good goal to have.
Doing so without confusing the hell out of users is a tricky situation,
and something that UX people work very hard to get right. I agree with
the idea of improving that dialog, but I disagree with the solution that
is being proposed.

- Jorge
Re: Pros and cons of different add-on install methods Jorge Villalobos 3/3/12 8:56 AM
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.

Addendum: I do think we still need the externally-installed add-on
warning page. I mentioned this before, but I don't want someone to read
only this and think I meant it should be taken out.

- Jorge
Re: Pros and cons of different add-on install methods Justin Lebar 3/3/12 9:33 AM
> It should be up to users to decide who they trust.

I don't think that this is incompatible with showing different warning
messages for add-ons Mozilla has reviewed versus ones we haven't.  I'd
hope instead we could agree on this in principal and let the UX
designers figure out how to implement it in practice.

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?
Re: Pros and cons of different add-on install methods Jorge Villalobos 3/3/12 9:37 AM
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?

That would be silly and unprofessional. I don't see how that's even a
valid question.

- Jorge
Re: Pros and cons of different add-on install methods Jorge Villalobos 3/3/12 9:37 AM
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?

Re: Pros and cons of different add-on install methods Mook 3/3/12 11:48 AM
On 3/2/2012 9:13 AM, Justin Lebar wrote:
>> Users *are* giving consent by choosing to install the add-on.
>
> I disagree.  This is misconception is key to understanding those of us
> who want tighter restrictions on drive-by add-ons.
>
> Let's put aside what "consent" means and agree that strict "clicked
> OK" is not the bar we want to set for users' "consent".  What we want
> is *informed* consent.
>
> Like I said earlier, I think a user can give informed consent to
> install an add-on by either:
>
>   a) Reading the add-ons source code, or
>   b) Understanding the risk of installing the add-on and
>       b.1) explicitly delegating trust for the add-on's evaluation to a
> third-party (e.g. Mozilla), or
>       b.2) explicitly choosing to trust the add-on itself.
>
> Users are not giving informed consent under the current scheme.

If we apply this to Firefox itself, does that mean Firefox users have
not given informed consent to install Firefox?  I doubt anybody has read
_all_ of the sources in mozilla-central, so only point b) can apply:
They delegate trust to the people they got their software from (Mozilla,
Oracle, or McAfee).

It does sound like MS wants to head that way with Windows 8, and Apple
with their AppStore...  But those things didn't sound very aligned with
Mozilla's principles.

--
Mook
Re: Pros and cons of different add-on install methods Asa Dotzler 3/3/12 12:54 PM
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
Re: Pros and cons of different add-on install methods Neil 3/3/12 3:54 PM
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?

--
Warning: May contain traces of nuts.
Re: Pros and cons of different add-on install methods Asa Dotzler 3/3/12 5:56 PM
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?
>

We could create entries for all known add-ons at AMO and provide users a
chance to review and rate add-ons not hosted at AMO.

- A
Re: Pros and cons of different add-on install methods Daniel Cater 3/3/12 8:27 PM
On Thursday, March 1, 2012 2:05:07 PM UTC, Justin Lebar wrote:
> Assuming that the add-on opt-in in FF8 is not being routinely
> circumvented, every non-AMO add-on listed there was explicitly enabled
> by the user.  So the fact that there's so much crap listed indicates
> to me that we're not doing a good enough job protecting our users from
> crap.
>
> -Justin

I've seen a few examples of extensions getting mistakenly treated as first-party installs so I wouldn't assume that all enabled extensions have been explicitly enabled. E.g.: http://i.imgur.com/AiCiS.png

I don't know whether this is due to a Firefox bug, or that the extensions actively circumvent the checks.
Re: Pros and cons of different add-on install methods Daniel Cater 3/3/12 8:27 PM
Re: Pros and cons of different add-on install methods Jorge Villalobos 3/4/12 7:12 AM
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.

We review add-ons because they are being distributed on our site. We are
giving users a reasonable expectation that these add-ons are safe and
respect their choices and privacy. This doesn't mean that add-ons
offered in other places can't have that level of quality, or that
following our guidelines is the only way to create great add-ons that
users love.

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

- Jorge
Re: Pros and cons of different add-on install methods Justin Lebar 3/4/12 7:51 AM
>> 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.
>
> [snip]
>
> Having a good review system is no reason IMO to say nobody else does.

Okay, but the position that we shouldn't warn more strongly for
add-ons not reviewed by AMO is stronger than this.

I'd like to warn users that an add-on not reviewed by the AMO team
*might* be low-quality.  And it seems that your position is that any
such warning will imply to most users that such an add-on *is*
low-quality, therefore, we shouldn't show different warnings for AMO
and non-AMO add-ons.

I think users can understand the difference between "might be" and "is".


In my mind, this is a simple question of, should we fail open or
closed?   Fail open means, assume that third parties might hold their
add-ons to the same high standard as AMO, and don't try to scare the
user about installing either type of add-on.  Fail closed means,
assume third parties might not hold their add-ons to AMO's standards,
and display a scary dialog for non-AMO add-ons.

IMO, fail open protects the add-on developers, and fail closed
protects (unwitting) users, so the decision is easy.
Re: Pros and cons of different add-on install methods Asa Dotzler 3/4/12 10:32 AM
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.

This still doesn't make sense to me. If we have confidence, as you seem
to, that add-on authors are quite capable of reviewung their own add-ons
to ensure the level of quality that we do, why do we need a review system?

Why waste Mozilla resources on reviews when everybody else should, as
you suggest, be able to do perfectly adequate reviews themselves? Why
not just assume that the AMO-hosting authors -- like those authors who
host their own, will do a fine job reviewing their own add-ons?

- A
Re: Pros and cons of different add-on install methods da...@illsley.org 3/4/12 2:43 PM
> > 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.
>
> Well, you'd be wrong. Apple has said publicly that they will not allow
> for apps that compete with built in iOS functionality and have
> disallowed apps which did that from their store. They have also censored
> content that they found objectionable even though the "code" of the app
> would have passed a detailed technical review.

I'm not particularly interested in defending Apple, and IANAL, but if they've not framed rejections in terms of user protection/benefit, I suspect they have some painful lawsuits coming.

I can pretty easily come up with at least reasonably credible 'user protection' reasons to prevent multiple phone dialers or other key system functionality on the grounds of user protection/system performance. Once you cede the principle that such the user can't make the final decisions, you're laying people open to other (future) actors who start out 'nice' and over time put user freedom below other business priorities.
 
> > 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.

> We already have a system that allows us to block bad acting add-ons.
> There is already a regime. The issues at hand is the scope of the
> policies and the enforcement mechanisms.

Sure. The current regime is too ad-hoc for my taste. The criteria and decision making process are not as transparent as I'd like. And they get applied to addon authors and users who have explicitly opted out of the AMO process.

There are good reasons why some addons aren't distributed via AMO, and I don't believe simply scaring users to avoid them is a productive route, nor is it in line with the hacker/free to tinker environment many people want to see.

There likely are addons out there, or will be in the future which lie in difficult legal waters in terms of mozilla being able to host and distribute despite them being compatible with the manifesto/having broad support in the community.

This is why I'm interested in having a third category of addons. Those which are created by a registered developer, but which aren't distributed by mozilla/been reviewed. That wouldn't tell the user anything about the quality or content of the addon, but would provide a clearer framework for engaging with the developer if there are problems, and a clearer 'right' to take action against an addon (I know some think there's a clear right based on what's deemed good for users, but it sometimes makes me nervous).

That would allow a 3-option choice by the user - amo only, amo + registered developer, arbitrary 3rd party, with my suggested default being amo+registered developer (though retaining a warning about what it might do). If that setting was in preferences, without the ability for a site to prompt to change the setting in a convenient dialog, I'd be surprised if many people at all actually use it.

Anyway, now I'm just repeating myself,
David
Re: Pros and cons of different add-on install methods Asa Dotzler 3/4/12 2:55 PM
>>> 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.

Yes, and that is my point. The public positions of Mozilla and Apple are
and will always be quite dissimilar. Just because we want to have a set
of rules doesn't mean that we're just like Apple (because Apple has a
set of rules too.)

- A
Re: Pros and cons of different add-on install methods Gervase Markham 3/5/12 4:27 AM
On 03/03/12 16:51, Jorge Villalobos wrote:
> It should
> be up to users to decide who they trust.

Although this example comes freighted with baggage, I would point out
that this is not Mozilla policy in other areas, e.g. with root CAs. If
we had this policy, every time Mozilla encountered a cert chaining to a
new root, even a built-in one, we would pop a dialog saying:

"Do you trust Verisign?"

or

"Do you trust Comodo?"

or whoever, as appropriate. But we don't; the user delegates the trust
decision to us and, within the currently-possible technical parameters,
we attempt to do a good job of choosing who to trust for them, and not
bothering them with it. The system has flaws, but millions of dollars of
commerce a day successfully transacted suggest that it works for lots of
people.

Gerv
Re: Pros and cons of different add-on install methods Jorge Villalobos 3/5/12 6:49 AM
Well, if you visit, say, AMO and you're asked if you trust Verisign, I
don't think users can make any meaningful decisions there, given that
there's no apparent connection between the two. The groups handling
these certs are unknown to most and are for the most part unrelated to
the sited being visited.

In the case of add-on installation, I would expect most review
signatures would either say Mozilla or the name of the add-on developer,
so it would make more sense to ask the question. "You are trying to
install ScriptScan, reviewed by McAfee". This is not dissimilar to the
security dialog that shows up when you try to install software on
Windows, where signed binaries will have messaging that indicates who
signed them and (I think) have a way to opt out of the warning for
specific signatures.

Also, prompting users to accept every cert would make the web unusable
for them, and would just learn to automatically dismiss the dialogs, so
there are practical considerations. Add-on installations should be rare
enough that it shouldn't be that big of a deal to have a single warning.
But we do suffer the same problem with users getting used to the
warnings and actively ignoring them, which is one of the reasons we're
having these discussions.

- Jorge
Re: Pros and cons of different add-on install methods Jorge Villalobos 3/5/12 6:56 AM
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.

Outside of AMO there's a wide range of add-ons, from the truly excellent
to the malicious, going through all shades in between. Our policy should
take that diversity in consideration.

- Jorge
Re: Pros and cons of different add-on install methods Justin Lebar 3/5/12 7:27 AM
I agree with almost every word here, but they miss the point.  So it
seems to me that our argument is not getting through.

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

We agree that some add-ons are good and some add-ons are bad.

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.

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

Great.  I don't want to assume all non-AMO hosted add-ons are risky to
install either.  I want to give add-on authors a chance to send us
their add-on so we can review it.  If we decide that it's unlikely to
be risky, we don't have to warn the user as much.

Indeed, it's precisely the alternative to this, that we must display
the same warning for non-reviewed and reviewed add-ons, which "lumps
all non-AMO add-ons together".

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

I hope we don't have to argue here about the meaning of "almost
impossible to circumvent."   Let us agree to a plan in principal and
then we can work with our designers on an appropriate flow.

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?
Re: Pros and cons of different add-on install methods Jorge Villalobos 3/5/12 8:06 AM
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."

I had to open Firefox and read the text because I have installed so many
add-ons that all I remember from that dialog is where the install button is.

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.

- Jorge

Re: Pros and cons of different add-on install methods Justin Lebar 3/5/12 9:37 AM
>> 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.

You're right.  OTOH, it's not a particularly scary warning.

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

Thus we'd need to make the warning somewhat difficult to click
through, as we do with the untrusted cert dialog.  Whether it's
precisely as difficult is something we can figure out later.

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

What I'd proposed earlier in this thread was listing some things which
malicious add-ons can do.  I'd presented text to the following effect,
with the caveat that I'd like us not to argue over the specific text
here, but rather the general idea.

"This add-on has not been reviewed by Mozilla.  If this add-on is
untrustworthy, it could

 * Read information from secure sites, such as your bank.
 * Make Firefox run slowly and/or crash.
 * Redirect your searches to a different search engine.
 * Mess up Firefox so it doesn't work properly even after you
uninstall the add-on.

You should only install this add-on if you are sure you trust [name of
add-on developer]."

I'd want to require more than one click to get around this warning,
but not obfuscate things to the point of flipping a bit in
about:config.

If instead the add-on has been reviewed by Mozilla, we could display a
less-scary warning message, perhaps similar to the one we display now.

-Justin
Re: Pros and cons of different add-on install methods Jorge Villalobos 3/5/12 9:50 AM
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
Re: Pros and cons of different add-on install methods Justin Lebar 3/5/12 10:45 AM
> 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.

See also https://bugzilla.mozilla.org/show_bug.cgi?id=732592
Re: Pros and cons of different add-on install methods Asa Dotzler 3/5/12 10:49 AM
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."

This warning is going to get far less scary (and completely removed in
some cases) for AMO hosted add-ons (reviewed by us in addition to
reviews -- good, poor, or not at all, by the add-on author) and I think
it's not scary enough for not-AMO hosted add-ons (un-reviewed by us but
with reviews -- good, poor, or not at all by the add-on author).

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

You discount our ability to warn well? Maybe take a look at the warning
we offer when users attempt to visit a badware site or the warning we
offer when users try to visit a site with a self-signed cert. I think we
can certainly put warnings in place that cannot be ignored by users.

- A
Re: Pros and cons of different add-on install methods Asa Dotzler 3/5/12 10:53 AM
I think you've missed Gerv's point. As I read it, what he's said is a
direct response to your claim "It should be up to users to decide who
they trust." He points out that is simply not true and has never been
true. Mozilla makes many trust decisions on behalf of users and blanket
statements that suggest otherwise are plainly incorrect. We have plenty
of precedent for making trust decisions on behalf of our users.

- A
Re: Pros and cons of different add-on install methods Jorge Villalobos 3/5/12 1:51 PM
My point was that we should give users choice and control when
reasonable and effective. I gave some reasons why I think that it isn't
reasonable not effective to do so with CAs.

The real question is, why should we make these trust decisions for our
users in this case?

- Jorge
Re: Pros and cons of different add-on install methods Asa Dotzler 3/5/12 2:30 PM
For add-ons we've reviewed and trust, we should communicate that to
users so they benefit from our having invested significant time and
effort developing that trust (just like CAs, for example.)

In a better world, we don't even have to prompt with a "do you trust or
not" prompt for add-ons we've well reviewed because we've determined
that they're trustworthy, and users could get a nice one-click install
experience.

For add-ons we have not reviewed, we should communicate a complete lack
of Mozilla trust because we know nothing about them.

- A
Re: Pros and cons of different add-on install methods Jorge Villalobos 3/5/12 3:21 PM
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

Quick update on this.

* The add-on ping data that we get is for all add-ons, regardless of state.
* We don't get add-on state with this data, so that won't help us in
this case.
* According to bug 732592, we get telemetry data (different than the
add-on ping data), and it only reports enabled add-ons. While this
suffers from selection bias, it might be the best data we have to work with.

Since Justin filed bug 732592, I assume he's looking into getting this
data, so that we can compare it to the add-on ping data and see if
there's anything we can infer from it.

- Jorge
Re: Pros and cons of different add-on install methods Gervase Markham 3/6/12 6:33 AM
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.

That is true; but saying "might" doesn't affect its actual badness.

In other words, if we say it's OK, go right ahead, 100% of good addons
would get installed, and 100% of bad ones.

If we say "there's possibly something dodgy here", some people will be
scared off - so say 90% of good addons will get installed, and 90% of
bad ones.

If the number of good addons out there is much greater than the number
of bad ones, you could argue this is a net loss.

Or, to put it another way: saying "might" is forcing the user to make a
decision without any data on which to make it. As a user, what am I
recommended to do when faced with this "might"? Always say Yes? Always
say No? Flip a coin?

Now, if addons were signed...

Gerv
Re: Pros and cons of different add-on install methods Henri Sivonen 3/6/12 10:45 AM
On Mar 6, 2012 4:35 PM, "Gervase Markham" <ge...@mozilla.org> wrote:
> Now, if addons were signed...

By whom? Whether the leaky McAfee extension came from McAfee is not in
doubt, so signing that proves origin wouldn't help.
Re: Pros and cons of different add-on install methods Justin Lebar 3/6/12 10:48 AM
Re: Pros and cons of different add-on install methods Justin Lebar 3/6/12 5:09 PM
For those following along at home, I've requested our add-on data from
telemetry and crash reports, both of which, afaict, report only
enabled add-ons.

I understand that neither of these data sources is unbiased, but I'm
hopeful we'll be able to get a general picture of what the landscape
looks like using the data here.

https://bugzilla.mozilla.org/show_bug.cgi?id=733516
https://bugzilla.mozilla.org/show_bug.cgi?id=733616
Re: Pros and cons of different add-on install methods Gervase Markham 3/7/12 9:05 AM
On 06/03/12 18:48, Justin Lebar wrote:
> I think Gerv was referring to
> https://bugzilla.mozilla.org/show_bug.cgi?id=728227

Actually, no, I wasn't. :-) I was simply pointing out that signing
addons does actually give the user _some_ data on which to decide
whether to trust the addon or not - because they know who created it. It
may not be sufficient data, and they may ignore it, and so we may decide
this isn't the right route... but it is some data.

Gerv
Re: Pros and cons of different add-on install methods Steve Fink 3/7/12 10:37 AM
On 03/03/2012 08:51 AM, Jorge Villalobos wrote:
> 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?
>
> 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.
>
>> 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?
>
> Like I said, telling people "This add-on has been reviewed by Mozilla"
> or "This add-on has been reviewed by X" is informative and give users
> more tools to make an informed decision whether to install the add-on
> or not. I think that's the right way to go. Telling people "this
> add-on is riskier" just because we haven't reviewed it is disingenuous
> at best.

Disingenuous? Why? Isn't that the very definition of risk?

You have addons A and B. You know nothing about A. You have reviewed B
and accepted it. Either the review is worthless, or the probability of B
doing something harmful is lower. Now, if you happen to know something
*else* about A, perhaps that it is released by a reputable company with
a clear motivation to provide something useful and incentive to not
provide something harmful, then you can certainly argue that
probability(A kicking your dog) < probability(B kicking your dog). But
that's not the point; the point is that the single bit of information
"this addon has passed review" really does mean that it can be
considered lower risk. The existence of a reviewed addon that is in
reality more harmful than some set of unreviewed addons does not
contradict this.

I strongly agree with your first sentence, and would conceptualize it
like this: when an addon install attempt is made, we have some useful
pieces of information about that addon. Examples:

  - source code has been reviewed by AMO reviewer (and accepted)
  - source code has been reviewed by some other hypothetical reviewing
organization
  - automated perf/memory tests have passed
  - addon is latest known version
  - addon was explicitly requested by user vs being dropped into a
directory by an installer
  - known bugs implicate addon in some negative user impact
  - crash reports have found a correlation with the addon
  - users have/have not complained about addon
  - addon is from a source (verified/signed or not) that has a known
track record
  - user has already agreed to install the addon by some other means

The specifics don't matter; the point is that we have a set of variables
from which you can infer the probability of causing harm. (Note that
this is just the cost side of the equation; the amount of benefit
expected from an addon is also relevant to the user.)

At the other end, we have an opportunity to inform the user of
information relevant to making an "accurate" decision. But it's not just
what information to present that matters, it's also how to present it so
that the user is likely to notice the relevant portions. Some simple
rules of thumb apply: if you have unvarying text that shows up more than
a few times, the user will stop reading it and always choose the learned
response. Long text will not be read. Claiming the possibility of
something is interpreted as meaning that it is probable or even certain.
(As a result, if that thing turns out to be false, the user will stop
trusting the claim and believe it to be a fearmongering lie.) Many, many
users will ignore anything you show them and pattern-match for
OK/Accept/Continue.

So the task is to figure out what information to surface through a
dialog or set of dialogues, and how to convey that information. Our
current implementation conveys very little information in a fairly
repetitive, easy-to-ignore way, which in many ways is a good thing. But
it appears that the end result (ie, many many users being screwed over
by crapware) indicates that there is room for improvement. It may not
even take very much to move the needle.

In short, I am recommending: figure out what the most important bits of
information are, balance that against the good actors out there, and
chuck it over to UX people to figure out how to get users to pay at
least enough attention to avoid the worst crap.

Also, stop thinking of this as a punitive measure against addon authors,
and think of it as an added set of services we have available. We'll
review your addon for free, sign your addon proving that we did so, and
let the user know! We'll cut out some of the crap addons so your users
can find your addon more easily and feel more comfortable about
installing it! We'll run your addon through our automated test harness
if you can tell us (preferably in an automated way) how to exercise it,
and give you the results for free! We could even manage an opt-in list
of 3rd-party addons that have passed AMO review, pointing to their
native 3rd party sites. The whole section would be labeled "these addons
are hosted by a 3rd party and therefore are not known to satisfy AMO's
criteria for inclusion, but we have reviewed them and found them to at
least pass the same code quality checks that we use for AMO-hosted
addons" or something.

By the way, I would suggest not restricting the informed consent options
to just the initial dialogs that pop up when a foreign-installed addon
is detected or a user-initiated install is requested. It may very well
be that we just can't provide something that people will pay attention
to at those times (at least, the people who need the protection). So we
might want to look further, eg by detecting when the browser is
struggling and only at that time popping up a dialog saying "something
is wrong, and you have at least one addon installed. Would you like to
see what we know about your addons, and check if you want to reconsider
any of them?". It's after the fact, and some irreversible damage may
have already been done, so it's not ideal. But it's a golden opportunity
when the user actually has *motivation* to read what we tell her or him,
probably for the very first time.

To alleviate the "too little, too late" aspect, it would be nice to have
pointers to knowledge base articles about cleaning up after a specific
addon when uninstalling it isn't good enough. (Resetting the search
engine and config settings, for example.) Or heck, how about
Windows-style recovery checkpoints?

>
>> 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.
>
> Disagree.
>
>> 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.
>
> Disagree.
>
>> What would your ideal warning regime be for those three cases?
>
> 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.
>
>>> 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.
>
> Making UI more informative and empower users is a good goal to have.
> Doing so without confusing the hell out of users is a tricky
> situation, and something that UX people work very hard to get right. I
> agree with the idea of improving that dialog, but I disagree with the
> solution that is being proposed.
>
> - Jorge
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

More topics »