Putting the user back in control: confirming "backdoor" add-on installs
David Tenser
the scenes without the user being in control of it:
http://arstechnica.com/microsoft/news/2010/06/microsoft-slips-ie-firefox-add-on-into-toolbar-update.ars
I was told by Mike Beltzner that this has been discussed before, but I
think it's worth revisiting to figure out what we can do to put the user
back in control of their browsing experience with Firefox.
Since there are ways for third parties to install additional software in
Firefox without the user knowing about it, we're constantly exposed to
the risk of malicious companies forcing stuff on our user's computer
which will affect the stability, performance, privacy, and security of
Firefox. And who will the user ultimately blame..?
I'd suggest something along these lines:
1. User installs software that secretly inserts an add-on to Firefox.
2. User (re)starts Firefox, and is presented with a dialog a la
http://people.mozilla.com/~faaborg/files/20070305-notification/level4ModalWarningDialog.jpg
(though likely less intense/red), which explains what's been added and
asks the user to enable the new add-on.
3. User either confirms or rejects the add-on (rejecting = disabling).
As has been discussed before, there might be valid use cases for keeping
the current functionality (quoting Mike here):
> - you download FooBarBaz program
> - during the install, it asks you if you want to add the FooBarBaz integration with Firefox
> - you say yes!
> - then we don't let that happen
However, I'd argue that it's still appropriate for Firefox to ask the
user about the add-on when restarting, since there's no reliable way for
us to ever know if the third party installer asked the user or not.
Ultimately, we should be the ones defining what the Firefox experience
should be like, not third parties (malicious or not). It's about putting
the user in control, which has always been one of our objectives.
Would be great to discuss and try to get this into the Fx4 roadmap!
Thanks,
David
Michael Kohler
Hash: SHA1
On 06/10/2010 03:45 PM, David Tenser wrote:
> [...]
>
> I'd suggest something along these lines:
>
> 1. User installs software that secretly inserts an add-on to Firefox.
>
> 2. User (re)starts Firefox, and is presented with a dialog a la
> http://people.mozilla.com/~faaborg/files/20070305-notification/level4ModalWarningDialog.jpg
> (though likely less intense/red), which explains what's been added and
> asks the user to enable the new add-on.
Really nice idea! (If there is a previous answer from me in this thread,
please ignore what I said there, I didn't look close to the warning
dialog mockup.)
> 3. User either confirms or rejects the add-on (rejecting = disabling).
Mh, I'm not sure if rejecting here should mean "disabling". I would want
Firefox to uninstall it and delete the appropriate files.
>
> [...]
Sincerely,
Michael Kohler
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJMEPHuAAoJEGWzJcLqVYffk5cH/AmfOWdIigD0BdBeUIJXGYlG
3EZqRuoJ3mlosmxMLMB7cdxjZ9+qN0AgkJsgyLBTAGMZ2y5N+bjxpTg8FOXrPPOz
ugRZcWEQvpWK2RZjw2AlXXZldPGtZvHrULJt6xRZyCzzThReSBAKcyz+BDr/5tDs
mRmAXu3mibX1uCwmp1RlmdZVMaOfeuYw+DoI9NhZVwUc24RbPJRnu/NSehQ4+tr6
G74qmLNOaUoYhSU3eXOY5OApNVzb6Lk0ltbGacrJ9+EZPYG03r6rKO5AOpqRo4VQ
31U4e4l8QEOJ++cNaQLNpeNcsSgQr7w9Mg/3TJpV97UJH6odnYVlwinTdR8vG5M=
=jTmZ
-----END PGP SIGNATURE-----
Chris Coulson
>
> As has been discussed before, there might be valid use cases for keeping
> the current functionality (quoting Mike here):
>
> > - you download FooBarBaz program
> > - during the install, it asks you if you want to add the FooBarBaz integration with Firefox
> > - you say yes!
> > - then we don't let that happen
>
Another use case for Linux distributions is that addons can currently be
distributed and installed via the distributions package manager (we do
this in Ubuntu, and Debian distribute a lot more addons this way as
well). Installing these essentially happens behind the scenes too.
Regards
Chris
David Tenser
Yes, but I'd still argue that a confirmation in Firefox itself is
warranted: Unless there's a reliable way for Firefox to know that an
add-on was installed with the user's consent, we can't assume that it
was, since ultimately it affects the stability, security, and
performance of *our* product.
Michael Kohler
Hash: SHA1
On 06/10/2010 04:09 PM, David Tenser wrote:
> On 2010-06-10 16:01, Michael Kohler wrote:
>>
>> On 06/10/2010 03:45 PM, David Tenser wrote:
>>>
>>> 2. User (re)starts Firefox, and is presented with a dialog a la
>>>
> http://people.mozilla.com/~faaborg/files/20070305-notification/level4ModalWarningDialog.jpg
>
>>> (though likely less intense/red), which explains what's been added and
>>> asks the user to enable the new add-on.
>>
>> Sounds good for me. But maybe we could just use a notification bar to
>> indicate that. That would be better, because that wouldn't disturb the
>> user's flow too much, but it still gives a visible notification.
>
> Agreed. I'm frankly unsure of whether or not the normal notification
> bars will remain in Firefox 4. If they are, I would have suggested that
> instead.
We will be using "Doorhanger" notification. See
https://wiki.mozilla.org/Firefox/Projects/Doorhanger_notifications .
>>> 3. User either confirms or rejects the add-on (rejecting = disabling).
>>
>> Mh, I'm not sure if rejecting here should mean "disabling". I would want
>> Firefox to uninstall it and delete the appropriate files.
>>
>
> I was assuming that removing wouldn't be possible due to it being
> installed globally (not within the active profile). Either way, the
> add-on would be disabled when Firefox is started, and the user would
> have to explicitly enable it if he/she wanted to.
Oh, that's true. I'm sorry.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJMEPSeAAoJEGWzJcLqVYffI5oH/1SdVEmq1/bCgwkC4a0z8yLR
38RM15QGlf2R+eveN2FnGDxBWEXKwx0nkUP5/fo9ZwPYww+cDYCZeB5qA5F0vKMR
DFnX1eB7pWH086fsyD0WvlJdFBj/XO9U8oxBUnMZzpEhJ+8WAX/PBEnLxp7Ntglp
0UQMcL7kxuYBDCNitU9gzN2wCLx8DchXdlk5Zwq+YQIhOTN6egumpC+fSIVzdeLj
DMfO1QuhaCsh3YEFLoO/PEjrDNaWELNJ0uf9+67rhdyeVFV+D+Cp/wwDNSTb1wOL
bMNkaoCa62tFG+W7mk3SrxUjVd0U+pEO66GnwcVLpmspxZho/+PjxOh5zR1abKA=
=U0Ac
-----END PGP SIGNATURE-----
Mike Shaver
> I'd suggest something along these lines:
>
> 1. User installs software that secretly inserts an add-on to Firefox.
>
> 2. User (re)starts Firefox, and is presented with a dialog a la
> http://people.mozilla.com/~faaborg/files/20070305-notification/level4ModalWarningDialog.jpg
> (though likely less intense/red), which explains what's been added and asks
> the user to enable the new add-on.
>
> 3. User either confirms or rejects the add-on (rejecting = disabling).
>
> As has been discussed before, there might be valid use cases for keeping the
> current functionality (quoting Mike here):
>
>> - you download FooBarBaz program
>> - during the install, it asks you if you want to add the FooBarBaz
>> integration with Firefox
>> - you say yes!
>> - then we don't let that happen
>
> However, I'd argue that it's still appropriate for Firefox to ask the user
> about the add-on when restarting, since there's no reliable way for us to
> ever know if the third party installer asked the user or not.
I think that installing system-wide add-ons should perhaps make them
available to the user, but leave them disabled. We can tell the user
that there are new add-ons available on the system, and perhaps
indicate them differently in the EM (perhaps leading to a help link
explaining that it was installed outside FF, so we can't update it;
contact your system administrator, whatever). The user can then
enable it, giving them a stronger attachment to the add-on as well!
The (bootstrapping, natch) add-on can use that enabling trigger to
interact with the user, since they are currently focusing on the
add-on in question, and so it won't be rudely interrupting something
else and giving the user a negative impression of the add-on from the
beginning.
It's all win! Woo! *\o/*
Mike
David Tenser
I like that idea of indicating that it's a system-wide add-on which
Firefox can't manage/update itself. Having a SUMO link explaining things
in more detail would be great!
> The user can then
> enable it, giving them a stronger attachment to the add-on as well!
Good point.
Another point: this would challenge these add-on producers to make a
strong case for why the user should enable it. In this particular case
with the "Search Helper Extension 1.0", it's likely that many users
would think "what the heck is this for?" and never activate it,
especially since the extension description is completely meaningless:
"Search Helper Extension".
> The (bootstrapping, natch) add-on can use that enabling trigger to
> interact with the user, since they are currently focusing on the
> add-on in question, and so it won't be rudely interrupting something
> else and giving the user a negative impression of the add-on from the
> beginning.
That's smart!
>
> It's all win! Woo! *\o/*
>
Which leads to the question: is this straightforward and small enough to
squeeze into Fx4?
- David
Boriss
> On 2010-06-10 17:50, Mike Shaver wrote:
>
>
>
>
>
>
>
>
>
> > On Thu, Jun 10, 2010 at 9:45 AM, David Tenser<djst.mozi...@gmail.com> wrote:
> >> I'd suggest something along these lines:
>
> >> 1. User installs software that secretly inserts an add-on to Firefox.
>
> >> 2. User (re)starts Firefox, and is presented with a dialog a la
A combination of Shaver's suggestion and Tenser's might be best.
Indeed, we can't know if an application has taken the nice route of
asking the user specifically about Firefox integration or the naughty
route of installing in the background - even installing an add-on
unrelated to the application the user downloaded. So yes, it is
warranted to ask the user to confirm installation and not to active an
add-on until the user confirms. Once a third-party application wants
to install something, the user could be asked whether they want to
install the add-on via a door hanger notification. If they select no,
the add-on should be deleted from the add-ons manager (on next
restart). If they select yes, it should be enabled (on next
restart). If they ignore the notification, we can leave the add-on in
their add-ons manager but, as Shaver said, disabled. It won't impact
performance but will still be accessible. So, if the user installed
FooBarBaz program and wanted FooBarBaz integration but ignored the
notification, FooBarBaz's documentation could tell the user to go to
the add-ons manager and just press enable.
Jason Oster
> Ultimately, we should be the ones defining what the Firefox experience
> should be like, not third parties (malicious or not). It's about
> putting the user in control, which has always been one of our objectives.
>
> Would be great to discuss and try to get this into the Fx4 roadmap!
>
> Thanks,
>
> David
administrator control. Actually, administrator control takes priority
over user control in a corporate environment. I support any progress
toward giving users the ability to be warned about these stealth
extensions *before* they are ever enabled/activated.
What worries me about this whole thing is that it will be difficult to
reach a balance where evil third parties cannot stealthily install
extensions, but system administrators can.
Boris Zbarsky
> What worries me about this whole thing is that it will be difficult to
> reach a balance where evil third parties cannot stealthily install
> extensions, but system administrators can.
Especially because the two sets aren't actually disjoint....
-Boris
Mike Shaver
> User-control is extremely important, but then again, so is system
> administrator control. Actually, administrator control takes priority over
> user control in a corporate environment.
Depends on the corporate environment, I daresay.
> What worries me about this whole thing is that it will be difficult to reach
> a balance where evil third parties cannot stealthily install extensions, but
> system administrators can.
I don't especially care about sysadmins being able to *sneak* things
onto the users' machines, tbqh. If they want to pre-bundle add-ons,
though, then things like BYOB (or even just the fact that they control
the bytes on the drive via imaging) should give them the ability to
control the horizontal and the vertical.
Mike
Bill Braun
> User-control is extremely important, but then again, so is system
> administrator control. Actually, administrator control takes priority
> over user control in a corporate environment. I support any progress
> toward giving users the ability to be warned about these stealth
> extensions *before* they are ever enabled/activated.
>
> What worries me about this whole thing is that it will be difficult to
> reach a balance where evil third parties cannot stealthily install
> extensions, but system administrators can.
Is it feasible to give sys admins command line switches for
a corporate environment and users the ability to control
through the UI? If the sys admin wants an addon to stick,
their command line switches could add a line in about:config
to override user preference. Not completely fool proof, but
functional.
Bill B
Jason Oster
extracting the XPI directly into the FX/TB extensions directory. The
nice thing about this (for silent admins installs) is that it never
annoys the user with "extension Foo has been updated" dialogs. That is,
it's entirely silent.
There's not a whole lot that can be done to prevent evil third-party
installers from doing the same thing, short of the user account running
the installer not having create/write privileges in the extensions
directory. This is especially troublesome on Windows XP, where the
default user account is created with administrator privileges. And UAC
is often disabled or ignored by users, anyway.
In theory, anything that we sys admins can do, so too can evil third
party installers. Adding new command line switches, preferences, hidden
registry keys, or just any magic voodoo bits on the system won't change
that little hiccup.
All I'm saying is, there are legitimate uses for silent extension
installation. I would love to hear any ideas that can keep that
functionality available, while still limiting the evilness of third parties.
Ron Hunter
Installation level password, for one thing. Even MS isn't going to be
able to get the password that is written on the postit note on the
sysadmin's monitor....
Storing a hash total of the list of approved extensions also comes to mind.
It's not that difficult.
Alex Faaborg
well, but David beat me to it. As both Boris and Shaver have said, it is
key that third party extension installs are opt-in, not opt-out. The reason
for this is that comprehension of what is happening (especially since the
install may be otherwise unprompted) shouldn't be a prerequisite for the
user maintaining control over Firefox.
For some additional context, I recently ran into a pretty scary situation.
A very non-technical mainstream user friend of mine had given up on Firefox
and switched to Chrome because Firefox wasn't starting fast enough. I tried
launching Firefox and found that it had a 30 second start time. I then found
three more things:
1) the 30 second start up time was entirely the result of a single third
party extension that was installed for all profiles and came packaged with a
very mainstream software application.
2) this extension had been deployed widely enough that the ADU count was
roughly the size of the population of a pretty major city (and those are the
people who were still putting up with it, and hadn't left yet).
3) when I asked the user if they had installed any extensions her answer was
along the lines of:
"no, I haven't, Firefox is just super slow now. But, what's an extension
again?"
I think we should move to a model where users are of course free to modify
Firefox at any time, but if a third party tries to modify Firefox, we should
do everything in our power to prevent or revert the change. Otherwise, we
have absolutely no control over protecting our user experience. We will
pick up the blame, and users will leave.
With 400 million users, we are a now a pretty large target for injecting
crapware. There are a lot of solid economic reasons for people to try to do
massive scale backdoor installs, so I'm worried that this problem is only
going to get worse over time.
-Alex
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>
Gavin Sharp
>> Agreed. I'm frankly unsure of whether or not the normal notification
>> bars will remain in Firefox 4. If they are, I would have suggested that
>> instead.
>
> We will be using "Doorhanger" notification. See
> https://wiki.mozilla.org/Firefox/Projects/Doorhanger_notifications .
The current plan is to only use the new notifications for some things
(geolocation and password manager notifications to start) - the
old-style notification bars will still be supported (and used).
Gavin
Alex Faaborg
extensions that need them, but we are transitioning many of the current uses
of the bar to other interfaces. Site level notifications (password manager,
http-auth, geo location, account manager protocol, local storage, etc.) will
be presented as door hanger style panels that come from the site identity
button.
Firefox level notifications, like asking if the users wants to opt-in to
adding an extension that another application tried to install, would
probably be placed on the home tab (or bar above the user's customized home
page). This way the notifications wouldn't block the user going forward,
would still be noticeable, and would also be reasonably easy for an
uninterested user to ignore if they weren't interested.
-Alex
On Thu, Jun 10, 2010 at 4:17 PM, Gavin Sharp <gavin...@gmail.com> wrote:
> On Thu, Jun 10, 2010 at 10:20 AM, Michael Kohler <michae...@live.com>
> wrote:
> >> Agreed. I'm frankly unsure of whether or not the normal notification
> >> bars will remain in Firefox 4. If they are, I would have suggested that
> >> instead.
> >
> > We will be using "Doorhanger" notification. See
> > https://wiki.mozilla.org/Firefox/Projects/Doorhanger_notifications .
>
> The current plan is to only use the new notifications for some things
> (geolocation and password manager notifications to start) - the
> old-style notification bars will still be supported (and used).
>
> Gavin
Dave Townsend
> On Thu, Jun 10, 2010 at 2:25 PM, Boriss<flying...@gmail.com> wrote:
>> Indeed, we can't know if an application has taken the nice route of
>> asking the user specifically about Firefox integration or the naughty
>> route of installing in the background - even installing an add-on
>> unrelated to the application the user downloaded.
>
> that it wanted to add an add-on for the current user, sort of like
> something between OAuth and UAC or something. Firefox could then
> throw up a little window to ask the user, etc.
I haven't checked but I think just telling launching Firefox passing it
an XPI file in the command line should open Firefox and show the install
confirmation dialog.
Dave Townsend
This is certainly possible to do, dare I say fairly easy to do in fact.
My only concern is the case where a company decides they don't like
Firefox defaulting their extensions to disabled and tinkers around in
the user's profile to make it start enabled, randomly breaking things as
they go.
Justin Dolske
> This is certainly possible to do, dare I say fairly easy to do in fact.
> My only concern is the case where a company decides they don't like
> Firefox defaulting their extensions to disabled and tinkers around in
> the user's profile to make it start enabled, randomly breaking things as
> they go.
Well, we already have examples of companies doing tinkering & breaking,
so that ship has sailed. :)
I don't think there will ever be a robust solution for software/admins
who are determined to be sneaky. But I think we can make it hard for
people to use such tactics without looking like slimy malware.
EG, when mainstream software drops in a global extension, they are
arguably simply using a feature that's explicitly supported by Firefox.
But if they hack to hack the app to bypass supported install mechanisms,
I think that makes it harder for them to defend their actions and easier
for us to blocklist them on Day 0.
Justin
Philip Chee
> This is something that I've been wanting to bring up on dev.apps.firefox as
> well, but David beat me to it. As both Boris and Shaver have said, it is
> key that third party extension installs are opt-in, not opt-out. The reason
> for this is that comprehension of what is happening (especially since the
> install may be otherwise unprompted) shouldn't be a prerequisite for the
> user maintaining control over Firefox.
>
> For some additional context, I recently ran into a pretty scary situation.
> A very non-technical mainstream user friend of mine had given up on Firefox
> and switched to Chrome because Firefox wasn't starting fast enough. I tried
> launching Firefox and found that it had a 30 second start time. I then found
> three more things:
>
> 1) the 30 second start up time was entirely the result of a single third
> party extension that was installed for all profiles and came packaged with a
> very mainstream software application.
>
> 2) this extension had been deployed widely enough that the ADU count was
> roughly the size of the population of a pretty major city (and those are the
> people who were still putting up with it, and hadn't left yet).
Why are you guys all tip-toeing around trying not to mention the name of
this elephant^Wextension/mainstream software application? It's all over
the news sites.
<http://www.osnews.com/story/23436/Microsoft_Secretly_Installs_Firefox_Extension_Through_WU>
Note this is *not* the original DOTNET extension. It's a new extension
that "updates" your Firefox Bing toolbar (even if you haven't installed
it in the first place).
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]Points Rule #1: Hit Your Boss To Continue...
* TagZilla 0.066.6
Boris Zbarsky
> On Thu, 10 Jun 2010 14:25:38 -07005, Alex Faaborg wrote:
>> This is something that I've been wanting to bring up on dev.apps.firefox as
>> well, but David beat me to it. As both Boris and Shaver have said, it is
>> key that third party extension installs are opt-in, not opt-out. The reason
>> for this is that comprehension of what is happening (especially since the
>> install may be otherwise unprompted) shouldn't be a prerequisite for the
>> user maintaining control over Firefox.
>>
>> For some additional context, I recently ran into a pretty scary situation.
>> A very non-technical mainstream user friend of mine had given up on Firefox
>> and switched to Chrome because Firefox wasn't starting fast enough. I tried
>> launching Firefox and found that it had a 30 second start time. I then found
>> three more things:
>>
>> 1) the 30 second start up time was entirely the result of a single third
>> party extension that was installed for all profiles and came packaged with a
>> very mainstream software application.
>>
>> 2) this extension had been deployed widely enough that the ADU count was
>> roughly the size of the population of a pretty major city (and those are the
>> people who were still putting up with it, and hadn't left yet).
>
> Why are you guys all tip-toeing around trying not to mention the name of
> this elephant^Wextension/mainstream software application? It's all over
> the news sites.
>
> <http://www.osnews.com/story/23436/Microsoft_Secretly_Installs_Firefox_Extension_Through_WU>
As it happens, the extension Alex was talking about is NOT the Microsoft
extension you just linked to.
-Boris
Mook
> On Thu, Jun 10, 2010 at 9:45 AM, David Tenser<djst.m...@gmail.com> wrote:
>> However, I'd argue that it's still appropriate for Firefox to ask the user
>> about the add-on when restarting, since there's no reliable way for us to
>> ever know if the third party installer asked the user or not.
>
> I think that installing system-wide add-ons should perhaps make them
> available to the user, but leave them disabled. We can tell the user
> that there are new add-ons available on the system, and perhaps
> indicate them differently in the EM (perhaps leading to a help link
> explaining that it was installed outside FF, so we can't update it;
> contact your system administrator, whatever). The user can then
> enable it, giving them a stronger attachment to the add-on as well!
> The (bootstrapping, natch) add-on can use that enabling trigger to
> interact with the user, since they are currently focusing on the
> add-on in question, and so it won't be rudely interrupting something
> else and giving the user a negative impression of the add-on from the
> beginning.
>
Would add-ons installed by / with the application still need to be
whitelisted, assuming there was no existing profile (i.e. first run)? I
ask because Songbird does do this for partner distributions (so we end
up shipping the vanilla app plus extensions), and was curious how much
of this flow needs to be changed when we get there.
Obviously, ugly hackarounds in our app is always possible - it's all XUL ;)
--
Mook
Mike Shaver
> On Thu, 10 Jun 2010 14:25:38 -07005, Alex Faaborg wrote:
>> For some additional context, I recently ran into a pretty scary situation.
>> A very non-technical mainstream user friend of mine had given up on Firefox
>> and switched to Chrome because Firefox wasn't starting fast enough. I tried
>> launching Firefox and found that it had a 30 second start time. I then found
>> three more things:
>
> this elephant^Wextension/mainstream software application? It's all over
> the news sites.
>
> <http://www.osnews.com/story/23436/Microsoft_Secretly_Installs_Firefox_Extension_Through_WU>
Not to speak for Alex, but he's *probably* "tip-toeing around" because
that's not the add-on he's talking about. The WU-added thing from
Microsort does affect startup time, but not nearly to that degree;
he's referring to another, much more problematic one.
Mike
johnjbarton
Just another use case to add: in IBM's product that integrates with
Firebug, we write a new profile directory, copy our addons into the
profile, and launch Firefox with -no-remote. Our intent was to insure
that our addons would not interfere with user's own browsing. (Oh, and
prevent user's addons from messing with us ;-).
If Firefox puts up a dialog in this case we will have to put up a
matching one explaining to users that they need to bypass the Firefox
warning. Unfortunately this will help train users to press "ok" on
these mysterious boxes as currently happens with the https warnings.
jjb
David McRitchie
> that's not the add-on he's talking about. The WU-added thing from
> Microsort does affect startup time, but not nearly to that degree;
> he's referring to another, much more problematic one.
Which is what I thought from the way it was posted, but whether it gets
blocked or not think it should be in and marked with serious startup delay
http://kb.mozillazine.org/Problematic_extensions
Though it very likely that the startup delay is not the most serious problem
and only listed in the numbered links in the rightmost column. Even finding
something afterwards helps to put user in control.
johnjbarton
As an add-on developer I'll tell you that the page cite above contains
numerous errors and unsubtantiated gossip. It's not putting users in
control. It's propagating mis-information displayed as if it was somehow
validated. The entire attitude of that page wrong, convincing users that
addons are bad rather than helping users be successful with the addons
that *user have chosen* to install. Don't encourage its use.
jjb
Alex Faaborg
> because that's not the add-on he's talking about.
>
Indeed, that is not the add-on I'm talking about. Let me check what I can
disclose and then I'll try to provide more details if people are curious. I
would love to shout from the roof tops how much [company] sucks for
packaging this [piece of shit] with [application that nearly everyone has],
but I also want them to work with us, and ideally disclosure the propriety
information of *exactly* how much damage they did to our user base. (our
ADU pings for the add-on give us the number of people who successfully
waited 30 seconds, or were unaffected, not the number of people who quickly
left Firefox for another browser).
-Alex
On Fri, Jun 11, 2010 at 5:25 AM, Mike Shaver <mike....@gmail.com> wrote:
> On Fri, Jun 11, 2010 at 1:14 AM, Philip Chee <phili...@gmail.com>
> wrote:
> > On Thu, 10 Jun 2010 14:25:38 -07005, Alex Faaborg wrote:
> >> For some additional context, I recently ran into a pretty scary
> situation.
> >> A very non-technical mainstream user friend of mine had given up on
> Firefox
> >> and switched to Chrome because Firefox wasn't starting fast enough. I
> tried
> >> launching Firefox and found that it had a 30 second start time. I then
> found
> >> three more things:
> >
> > Why are you guys all tip-toeing around trying not to mention the name of
> > this elephant^Wextension/mainstream software application? It's all over
> > the news sites.
> >
> > <
> http://www.osnews.com/story/23436/Microsoft_Secretly_Installs_Firefox_Extension_Through_WU
> >
>
> Not to speak for Alex, but he's *probably* "tip-toeing around" because
> that's not the add-on he's talking about. The WU-added thing from
> Microsort does affect startup time, but not nearly to that degree;
> he's referring to another, much more problematic one.
>
> Mike
Alex Faaborg
> Let me check what I can disclose and then I'll try to provide more details
> if people are curious.
>
It was the eBay Browser Highlighter that was deployed when the user installs
Skype. As one would expect for anything deployed along with Skype, the ADU
count is very large.
-Alex
On Fri, Jun 11, 2010 at 10:45 AM, Alex Faaborg <faa...@mozilla.com> wrote:
> because that's not the add-on he's talking about.
>>
>
> Indeed, that is not the add-on I'm talking about. Let me check what I can
> disclose and then I'll try to provide more details if people are curious. I
> would love to shout from the roof tops how much [company] sucks for
> packaging this [piece of shit] with [application that nearly everyone has],
> but I also want them to work with us, and ideally disclosure the propriety
> information of *exactly* how much damage they did to our user base. (our
> ADU pings for the add-on give us the number of people who successfully
> waited 30 seconds, or were unaffected, not the number of people who quickly
> left Firefox for another browser).
>
> -Alex
>
>
>
> On Fri, Jun 11, 2010 at 5:25 AM, Mike Shaver <mike....@gmail.com>wrote:
>
>> On Fri, Jun 11, 2010 at 1:14 AM, Philip Chee <phili...@gmail.com>
>> wrote:
>> > On Thu, 10 Jun 2010 14:25:38 -07005, Alex Faaborg wrote:
>> >> For some additional context, I recently ran into a pretty scary
>> situation.
>> >> A very non-technical mainstream user friend of mine had given up on
>> Firefox
>> >> and switched to Chrome because Firefox wasn't starting fast enough. I
>> tried
>> >> launching Firefox and found that it had a 30 second start time. I then
>> found
>> >> three more things:
>> >
>> > Why are you guys all tip-toeing around trying not to mention the name of
>> > this elephant^Wextension/mainstream software application? It's all over
>> > the news sites.
>> >
>> > <
>> http://www.osnews.com/story/23436/Microsoft_Secretly_Installs_Firefox_Extension_Through_WU
>> >
>>
>> Not to speak for Alex, but he's *probably* "tip-toeing around" because
>> that's not the add-on he's talking about. The WU-added thing from
>> Microsort does affect startup time, but not nearly to that degree;
>> he's referring to another, much more problematic one.
>>
>> Mike
Mike Shaver
<johnj...@johnjbarton.com> wrote:
> Just another use case to add: in IBM's product that integrates with Firebug,
> we write a new profile directory, copy our addons into the profile, and
> launch Firefox with -no-remote. Our intent was to insure that our addons
> would not interfere with user's own browsing. (Oh, and prevent user's addons
> from messing with us ;-).
>
> If Firefox puts up a dialog in this case we will have to put up a matching
> one explaining to users that they need to bypass the Firefox warning.
> Unfortunately this will help train users to press "ok" on these mysterious
> boxes as currently happens with the https warnings.
Good data, thank you!
If installing an add-on by calling Firefox with an XPI on the command
line works, as I believe it does/will (Mossop?), then in that case we
could offer to remember that IBMWebSphereDevelotron is allowed to
install add-ons.
Mike
Philip Chee
> On 6/11/2010 10:11 AM, David McRitchie wrote:
>> http://kb.mozillazine.org/Problematic_extensions
>
> As an add-on developer I'll tell you that the page cite above contains
> numerous errors and unsubtantiated gossip. It's not putting users in
> control. It's propagating mis-information displayed as if it was somehow
> validated. The entire attitude of that page wrong, convincing users that
> addons are bad rather than helping users be successful with the addons
> that *user have chosen* to install. Don't encourage its use.
John, It's a *wiki*. If you see something inaccurate, go edit it! duh.
johnjbarton
> On Fri, 11 Jun 2010 10:40:06 -0700, johnjbarton wrote:
>> On 6/11/2010 10:11 AM, David McRitchie wrote:
>
>>> http://kb.mozillazine.org/Problematic_extensions
>>
>> As an add-on developer I'll tell you that the page cite above contains
>> numerous errors and unsubtantiated gossip. It's not putting users in
>> control. It's propagating mis-information displayed as if it was somehow
>> validated. The entire attitude of that page wrong, convincing users that
>> addons are bad rather than helping users be successful with the addons
>> that *user have chosen* to install. Don't encourage its use.
>
> John, It's a *wiki*. If you see something inaccurate, go edit it! duh.
Sorry, but I contacted the people who built that page and they
specifically asked me not to edit it. From their point of view the page
is 'accurate' if it correctly summarizes user complaints, whether or not
those complaints actually relate to the addon and whether or not the
suggested fix has any chance of success.
In addition to not wanting to have a wiki-war with them, the entire
concept of the page is well-intended but misguided. It starts right with
the title "Problematic Extensions". It's not "Solving Issues with
Extensions" or "Contacting Extension Developers" or "Working with The
Best Browser Extensions".
jjb
>
> Phil
>
johnjbarton
We install three extensions currently (firebug, crossfire, and an
integration extension). We'll probably move to 'swarm' based install, so
maybe one XPI could ok by the time the confirm-backdoor lands.
Or could we do something sensible via the "write a new profile
directory", -no-remote path? In this use case the user's experience is
being tailored for integration, we aren't altering the user's normal
profile. If there was a "-allowDirectAddons" command line flag, then no
normal users would be affected. (I realize options have a cost for
testing, support).
jjb
Jason Oster
hack-tactics elsewhere on this thread.)
Jesper Kristensen
> Recently we saw another example of an add-on that installs itself behind
> the scenes without the user being in control of it:
> http://arstechnica.com/microsoft/news/2010/06/microsoft-slips-ie-firefox-add-on-into-toolbar-update.ars
>
>
> I was told by Mike Beltzner that this has been discussed before, but I
> think it's worth revisiting to figure out what we can do to put the user
> back in control of their browsing experience with Firefox.
>
> Since there are ways for third parties to install additional software in
> Firefox without the user knowing about it, we're constantly exposed to
> the risk of malicious companies forcing stuff on our user's computer
> which will affect the stability, performance, privacy, and security of
> Firefox. And who will the user ultimately blame..?
I just watched a video from a guy creating Firefox user guide videos,
where he explains all the nice things you can do with Firefox. In his
video on installing Firefox for the first time, the Skype extension pops
up when he starts Firefox. He does not find the experience good, and
claims that Mozilla receives money from Skype for bundling the extension
with Firefox.
http://knowware.dk/video/firefox-download-og-installation.shtml
(It is in Danish)