Adblock Plus and (a little) more
Why app-global extensions are essentially broken · 2010-08-18 12:44 by Wladimir Palant
Should I rather title this blog post “App-global extensions considered harmful”? I hope not because I see some valid use cases for installing an extension in a central location where it will be taken over regardless of the profile used. However, the current implementation in XULRunner/Firefox has some very nasty side-effects which make using this mechanism a bad choice. And there are apparently many people making the same experience.
For me it all started back when I was working on TomTom HOME. We wanted to move parts of the application into extensions that could be updated independently and earlier than the next release of the full application. The logical choice was to install the extensions along with the application in the application directory. These extensions could then get updates as usually. Updates would be installed into user’s profile and take precedence over the older version in application directory. Sounds like a good plan? As it turned out, it wasn’t:
- An update that has been installed in user’s profile always takes precedence over the version installed in the application directory. This is even true if the version in application directory is newer. So if an application update installed a newer version of the extension in the application directory the user will continue to use the old version if that’s what he has in his user profile.
- What will happen if the user decides to uninstall the extension from his user profile? The application restarts and … Right, the extension is back! This time it is the old version from the application directory which took over.
- Usually the user won’t be able to uninstall extensions which are in the application directory. And it seems that a grayed out “Uninstall” button is very frustrating — even if there is a fully functional “Disable” button.
- Even if the user manages to uninstall the extension, an application update will most likely reinstate it.
Granted, there is a use case where all this isn’t a problem, namely extensions that are marked as “app-managed” meaning that they will only be updated together with the application and never on their own. And these extensions should be perceived as part of the core functionality so that nobody would be tempted to uninstall them. You know, like DOM Inspector in the old days. Or JavaScript Debugger in SeaMonkey.
But these cases were always few and seem to become even fewer. Usually however extensions are installed globally for other reasons and people hit all the same issues I mentioned above. Which is why Songbird is trying to address the first issue I mentioned (which is a desperate move given that these changes have no chance of being backported to XULRunner). And the third issue forced Microsoft to design their very own way of getting .NET Framework Assistant into user’s profile, causing lots of user confusion. And Skype designed yet another solution, with less confusing but also less stable results.
I filed bug 474289 early in 2009 to do something about this — and I hope to start the discussion on this issue again. IMHO the most promising solution is having “default extensions”, located either in the application directory or in a location pointed to from Windows registry. When the add-on manager sees a new extension in one of these locations it should install it into user’s profile. And at that point it should behave like any regular extension with an option to disable or uninstall it. I think it is also important to remember extensions that the user uninstalled so that they won’t be installed automatically any more.
Any thoughts? Comments? Anybody willing to start writing patches?
Comment [14]
Commenting is closed for this article.
mash · 2010-08-18 13:39 · #
Also Bug 300967
mash · 2010-08-18 13:43 · #
Пропустил немного, про апдейт уже написано в посте. Просто когда напоролся на этот баг, был очень раздражён. :)
Reply from Wladimir Palant:
Нет, я об этом, конечно, написал, но про баг не знал – так что все равно спасибо.
Рад тебя здесь видеть, давненько мы не пересекались.
Jesper Kristensen · 2010-08-18 13:44 · #
I have seen some comments in mozilla.dev.usability from the Firefox UX team that they want to enable uninstall of global extensions from the user’s point of view. Underneath it would just disable the extension and move its entry from the list of installed extensions to a list of available extensions in the addons manager UI. But I haven’t seen any work on it yet.
glandium · 2010-08-18 14:01 · #
That is something that has been sitting on my TODO list for a while now. On UNIX systems there are global directories to put extensions, and Linux distributions put packaged extensions (extensions that you install through the distro package manager) there. It’s in /usr/{lib,share}/mozilla/extension/{app-id}. There could be something similar on windows, though the issues remain. The issues are shared, though.
Reply from Wladimir Palant:
Yes, this is the Linux equivalent of installing via Windows registry. Same issues of course.
Yansky · 2010-08-18 20:36 · #
What about if Firefox checked the addon folder when doing an update and if it found an extension proxy file, Firefox would then install the update to where the extension proxy file pointed to?
Matěj Cepl · 2010-08-18 20:39 · #
Talking with my Red Hat on my head (of course, just using the experience from an enterprise distro, I am not speaking in the name of my employer), we love centrally installed software neatly packaged in RPM. More from ease of administration point of view rather than space-wise (although even that could be very interesting in Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=466173)
Reply from Wladimir Palant:
Do you set appManaged flag on the extensions you package to disable updates via browser? If not you will still have the problem that the user might install an update in his profile – and all the sudden installing an updated RPM has no effect.
Tony Mechelynck · 2010-08-19 11:11 · #
But these cases were always few and seem to become even fewer.
Not in SeaMonkey nightlies at least:
* ChatZilla
* DOM Inspector
* JavaScript Debugger
* SeaMonkey Debug and QA UI
* SeaMonkey Default Theme
* SeaMonkey Modern Theme
Even if you don’t count the default theme, that’s still five add-ons distributed as part of the app in every SeaMonkey .tar.bz2, .dmg, .zip or .installer.exe (four in Release builds which don’t include DebugQA IIUC).
XT-8147 · 2010-08-19 14:10 · #
I want the exact opposite of this. I want zero globally-installed extensions. I want a standard, non-extension-provided UI in Firefox to prompt me for consent whenever something like Windows Update, Skype, Java, or AVG tries to slip some little bit of code into Firefox, and block the installation when I click No. Applications that install these annoyances are under no obligation to prompt for consent or even obey user consent.
Better yet, remove this insecure functionality from Firefox entirely. If any application can do this, what’s to stop some malware from slipping an activity tracking/password phishing/etc. extension in? Sure, you can disable it or remove it from the registry/global directory/however it’s done on whatever OS, but it could reinsert it just as easily as it inserted it in the first place. Combine that with integrity checking so that dummy files can’t be put in place of the extension, and you’ve got a recipe for disaster.
What makes it worse (on Windows at least): Firefox 4 seems to be changing the registry location where these things are listed.
Reply from Wladimir Palant:
I guess you heard that many times already but just in case: there is no security issue about other applications being able to install extensions – these applications already can do anything with your computer, with or without your consent. And the solution is always the same: do not install applications you don’t trust. If you dislike parts of the functionality, report issues to the application vendor.
To make my point entirely clear: please, if you don’t understand the topic I discuss in my blog post or don’t care about it – move along, don’t comment. Don’t start discussing your pet topic just because you think that it is somehow related. There are plenty of general forums where you can let off steam.
Matěj Cepl · 2010-08-19 18:08 · #
Hmm, it seems like we don’t http://pkgs.fedoraproject.org/gitweb/?p=mozilla-adblockplus.git;a=tree Do you think you could file a bug for it, please? (https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=rawhide&component=mozilla-adblockplus I am afraid I wouldn’t be a good bug reporter on this).
Thank you
Reply from Wladimir Palant:
No, I’m not a good reporter either – I rarely use Linux and even then basically never distribution-supplied Firefox builds. However, seeing the primitive build/install scripts used in mozilla-adblockplus package, filing this bug will probably only result in a request to adjust my build scripts. And this cannot be the solution for all the extensions out there…
Matěj Cepl · 2010-08-19 18:54 · #
No, certainly not … we should fix our scripts, so that they work reasonably well. If anybody wants to fix our work on your site, he should be fired down. If you file that bug anyway, please put me to cc of it, please.
Reply from Wladimir Palant:
Ok, I filed this bug: https://bugzilla.redhat.com/show_bug.cgi?id=625687
Matěj Cepl · 2010-08-19 18:55 · #
we have some standard packaging procedures (e.g., https://fedoraproject.org/wiki/Packaging/EclipsePlugins) for specific cases and we should certainly develop one for Firefox extensions as well.
glandium · 2010-08-20 11:31 · #
Matěj: More simply, the app-global extensions in /usr/{share,lib}/mozilla/extensions/{app-id} could be all marked as appmanaged.
joh6nn · 2010-10-22 19:20 · #
Wladimir, it is currently possible in FF 3.6 to accomplish about half of what you’re asking for, it is simply not documented anywhere (that i could find). I am currently on a windows box, so I will use it as an example.
Firefox creates the following directory during installation:
C:\Program Files\Mozilla Firefox\defaults\profile\
This directory contains files that will be used to construct new FF profiles. If you create an “extensions” sub-directory and load it with extensions, they will be installed for each new profile that is created. It is possible to pre-load the newly created profiles with default preferences (just modify prefs.js), and anything else that you might wish.
Unfortunately, this does not fulfill all your requirements, as profiles that already exist do not monitor that directory for changes.
This information may be a useful addition to both your FF and Redhat bug reports.
Reply from Wladimir Palant:
Yes, I am aware of this possibility – but as you already note, it only solves one (small) part of the problem.
mee · 2010-11-11 23:59 · #
Would a viable [initial] option be modifying the default profile store — that from which all new profiles are built ?