Closed Bug 491562 Opened 15 years ago Closed 15 years ago

Allow websites to get list of installed add-ons, with user's permission

Categories

(Toolkit :: Add-ons Manager, enhancement)

Product:
Toolkit
Component:
Add-ons Manager
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: fligtar, Unassigned)

Details

(Whiteboard: [amo:want P2]) 

There are many legitimate reasons a website may want to know what add-ons a user has installed.
* support.mozilla.com could use this information to detect known conflicting add-ons, versions of certain add-ons known to cause problems with Firefox, and for detecting new problems with extensions based on a large number of support threads opened with installed add-ons listed.
* addons.mozilla.org could use this information to enhance the add-ons experience in a bunch of ways, including graying out add-ons you already have, urging you to upgrade old versions, populating a collection with what you have installed, "favorites" integration, etc.
* the website for a particular add-on may want to probe for just that add-on for enhanced functionality. For example, getpersonas.com could check to see if you have Personas installed, and if so, do special stuff.

Below is my proposal for two new methods for retrieving this data from a website and the privacy controls for their implementation.

InstallTrigger.getInstalled(guid)
InstallTrigger.isInstalled(guid)

getInstalled() will return an array or object of installed add-ons (extensions, themes, dictionaries, language packs). I'd say the included properties should be GUID, type, status (userEnabled/Disabled, etc), and version. If the guid is passed, it will only pull info for that GUID. If no guid is passed, it will retrieve all add-ons.

isInstalled will take an add-on's GUID and return boolean true or false if the extension is installed.

When one of these methods is called, a notification bar should come down, similar to the geolocation bar, that says something like "support.mozilla.com wants to know what add-ons you have installed". There should be options to allow and not allow, as well as to always allow for this site. There should be no sites on this whitelist by default, not even AMO or SUMO.

Similar to geolocation, we should have a page with more information about the benefits and dangers in revealing what add-ons you have installed.
I understand the value of this, but I don't think that it's worth the additional code necessary to implement it (and associated security risk that comes with any additional code, especially code that is available to the public web).

I recommend WONTFIX, but I'm going to wait for Mossop to chime in.
Chiming in with I agree wholeheartedly with bsmedberg on this.
Copying in some of the security guys for their impressions
fwiw we had something like this long ago, in the old xpinstall scripted install.js days: InstallTrigger.GetVersion(<pkgid>) and InstallTrigger.CompareVersion(<pkgid>, <version>)

Use was limited to sites whitelisted to do installs in the first place, but the privacy aspects were always troubling. Greatly mitigated by the fact that no one did those kinds of installs in Firefox, it was useless with Extension Manager installs.

Your first and third use-cases are weak: SUMO could have a helper diagnostic add-on, or a code-snippet to paste into the Error Console like the Places stats thing. If an addon developer wants their site to interact with their addon they can leave hooks in content (perhaps active only on some sites). Some actually do, in fact, like Personas/getpersonas.com

Your AMO use-case is strong, it's hard to manage installations if you lack knowledge of what's installed. But it's really kind of limited to "sites like AMO" and there aren't too many I can think of. Could you start with a site-specific addon and push it on the site? I've noticed some software installs site-specific addons or plugins for version checking type stuff. The .NET thing was one, and some of the A-V vendors seem to do it.

I'm wary because I thought InstallTrigger.GetVersion() was going to be useful and we never ever used it (nor it's Netscape 4 predecessor). All it was was a source of privacy freak-outs when people found out about it.
(In reply to comment #4)
> privacy aspects were always troubling. Greatly mitigated by the fact that no
> one did those kinds of installs in Firefox, it was useless with Extension
> Manager installs.

That's bit of an overstatement wouldn't you say?
http://www.google.com/search?hl=en&q=installtrigger.*+site%3Asupport.mozilla.com&btnG=Google+Search

And some people file bugs like bug 440349, referencing http://developer.mozilla.org/en/docs/XPInstall_API_Reference:InstallTrigger_Object:Methods:getVersion , because they believe it still works. Does that article need to be updated?
(In reply to comment #4)
> Your first and third use-cases are weak: SUMO could have a helper diagnostic
> add-on, or a code-snippet to paste into the Error Console like the Places stats
> thing. 
>
Yes, there's no shortage of complicated things we could ask the user to do, but since they're confused and at the support site to begin with, they probably shouldn't be pasting code in the error console.

SUMO is actually my strongest reason for wanting this. I agree that if this was just for AMO, we could build this into an AMO add-on. We had a meeting with the SUMO team last week and this is something they'd really like.

> If an addon developer wants their site to interact with their addon they
> can leave hooks in content (perhaps active only on some sites). Some actually
> do, in fact, like Personas/getpersonas.com
> 
Yes, but how many will do it correctly? I suspect leaving hooks in websites like this is a pretty common cause for Firefox performance issues when someone does this incorrectly. If the only thing a website wants to know is if you have the extension installed, it should be an easy optimized check, rather than having the developer trying to find code that does this in another extension to drop in without understanding what it does, or tacking something onto the user agent string.
fligtar - would it be useful to add this information to about:plugins so that SUMOish use-cases are served slightly less painfully?  Still too complicated?  I think elsewhere in SUMO we already employ about:plugins as a diagnostic step?

I know you'd prefer automatic access, I'm just wondering if there's a low touch solution that gets us partway there.
I think a section of about:plugins or about:addons that could be easily copied and pasted with the important info listed for installed add-ons would be helpful in the SUMO case, yes.

It wouldn't be much use for the other 2 cases, but as I mentioned I'm primarily interested in improving the SUMO experience and it seems the automatic process isn't likely to happen, so I'd be happy with that idea.

David, Laura, SUMO folks -- would copying/pasting the list of installed add-ons be useful in SUMO at all, or do you think no one would bother using it?
(In reply to comment #5)
> And some people file bugs like bug 440349, referencing
> http://developer.mozilla.org/en/docs/XPInstall_API_Reference:InstallTrigger_Object:Methods:getVersion
> , because they believe it still works. Does that article need to be updated?

The top-level XPInstall article indicated that large parts were removed from Firefox 3.0. I just updated the InstallTrigger pages specifically, thanks.
(In reply to comment #8)
> I think a section of about:plugins or about:addons that could be easily copied
> and pasted with the important info listed for installed add-ons would be
> helpful in the SUMO case, yes.

> 
> David, Laura, SUMO folks -- would copying/pasting the list of installed add-ons
> be useful in SUMO at all, or do you think no one would bother using it?

Yes, I think this would be really useful.
(In reply to comment #7)
> fligtar - would it be useful to add this information to about:plugins so that
> SUMOish use-cases are served slightly less painfully?  Still too complicated? 
> I think elsewhere in SUMO we already employ about:plugins as a diagnostic step?

about:plugins would be less painful than the use case today (opening the Add-ons window and manually type the names of all items listed under Extensions), but it's still a very complicated procedure for mainstream users. 

Having a helper/diagnostics add-on for SUMO wouldn't really be a straightforward procedure either, since many problems are related to extensions (we ask people to start in Safe Mode, for example, and some bugs make it impossible to install extensions).

I'd much rather have a solution where it can be auto-detected when submitting a question in the forum or when standing in line for Live Chat. Is that not possible?

To clarify, a copy/paste function would definitely be an improvement, but I'd much rather see an automated mechanism in place.
An automatic/prompted mechanism is not wise. I think we should either not do this at all, or do this in the most minimal way possible as an addendum to about:plugins or a separate about:extensions page.
Chiming in on the SUMO usecase: Unless we could somehow _link_ to an about:extensions page from inside sumo (Click [link], copy the page and paste into this box:), we're not going to get many people who provide the list of extensions when asking a question.  Even going to about:plugins/about:config is way too difficult for most SUMO users -- I can't even begin to count how many times I've typed the phrase "it seems like you did a search for about:config, it's about(colon)config with no spaces, no http://, no www.".  That said, once we have this, we can ask specifically for extensions and when people are asked specifically by a helper to do something, they usually put in the extra energy to do so especially when guided with screenshots/screencasts.

Until recently, a frequently used way to get a list of plugins for LiveChat was actually: "Post in the forums with my username in the Question field".  There, we had autodetection of UA and plugins.

An alternate proposal:

Have about:support and have that _accessible from the Help menu_.  about:support can have all sorts of diagnostic information (list of plugins -- not as much detail as about:plugins, lists of extensions, a button to start in safe mode on next boot and maybe even a button to check your internet connection)  All of which can be copied and pasted.
See also bug 367596 on the topic of "about:support".
Whiteboard: [amo:want P2]
I am not sure why being able to list the installed/active extension is such a bad idea compared to, say, being able to list the installed/active plugins (which is already possible with Javascript today). Could someone please explain the difference and potential risks?

Having that ability would make a *huge* difference for SUMO because we could skip one of the hardest steps for users when asking a support question. A lot of the support problems in the forum are caused by extensions, but many users hardly know what extensions are, let alone how to list them.
Websites interact with plugins intentionally: they could gather the same information by creating a bunch of <object> tags and seeing which ones ended up with plugins.

OTOH, extensions frequently don't want websites to know they are installed. e.g. some websites upset about flashblock/adblock try to detect it and display "I'm sorry, you can't use this website with an ad-blocker" message instead of their normal content. This is something we'd really like to avoid.

As filed this bug is WONTFIX. Please feel free to file a bug on about:extensions or an export format from the extension manager.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
How about making it work like the geolocation feature -- the user is asked whether he/she wants to share the info with the site?
That would require a significant amount of UI support, which I don't think is warranted just for SUMO: we should do about:extensions or have some similar copy/paste workflow.
(In reply to comment #18)
> That would require a significant amount of UI support, which I don't think is
> warranted just for SUMO: we should do about:extensions or have some similar
> copy/paste workflow.

Yeah - that's bug 367596, also documented as the (not yet started) about:support project in the Firefox team's list of projects (https://wiki.mozilla.org/Firefox/Projects/about:support). I agree that creating that page, with a help menu entry to point the user to, is the straightforward play here; and substantially less contentious.
It's not just about support, it's about enhancing the add-ons experience in a browser where customization is increasingly becoming the main differentiator.

As this request has been deemed not worthwhile, AMO will be implementing this in our extension sometime next year for personal add-on recommendations, among other things. Which is sad for personal recommendations' chances of making an impact on anything but hardcore add-on users.
(In reply to comment #19)
> (In reply to comment #18)
> > That would require a significant amount of UI support, which I don't think is
> > warranted just for SUMO: we should do about:extensions or have some similar
> > copy/paste workflow.
> 
> Yeah - that's bug 367596, also documented as the (not yet started)
> about:support project in the Firefox team's list of projects
> (https://wiki.mozilla.org/Firefox/Projects/about:support). I agree that
> creating that page, with a help menu entry to point the user to, is the
> straightforward play here; and substantially less contentious.

While I still hope that this can be fixed (as it would dramatically reduce the complexity of asking a new support question for users), we're also working on creating a list of diagnostics items for the about:support project that would help our support community troubleshoot users more efficiently. Expect a finalized list by the end of this week, and thanks in advance for considering it.
You need to log in before you can comment on or make changes to this bug.