Chrome 25 to disable silent extension installation actively and retroactively | Hacker News Reader

Chrome 25 to disable silent extension installation actively and retroactively

thenextweb.com

90 pointsPr026 comments

Here's the Firefox version of this:

https://blog.mozilla.org/addons/2011/08/11/strengthening-use...

you can also disable plugins from being loaded from the local machine's registry by setting "plugin.scan.plid.all" = false in about:config. especially useful for portable installs.

Why did they even allow it in the first place? Or was it a matter of "not stopping it" until now? I've noticed more and more programs have been trying to install Chrome extensions in the browser lately.

This could, in principle start a war similar to the ones Microsoft has been fighting for years, although Chrome's faster update system might help Google win.

In principle, given Chrome is often installed as the current user, there is nothing to stop any other user program from changing Chrome in any way it sees fit, simply adding an extension and marking it "user accepted" in whatever way.

Microsoft has had trouble with this kind of thing for years, as I say.

also, if you can modify chrome to this effect and you noticed the chrome team pushing live updates that make your silent update fail, you fix your silent update and you break chrome's update feature and win. only solution is application level isolation as others have said on this thread...

It is not possible to stop this in the general case. All user-level software on legacy (e.g., Windows, OS X, Linux, etc) operating systems effectively has the same permissions to persistent storage. There's no application-level isolation, so Chrome cannot protect its own data files from other applications. In the limit, Chrome cannot tell whether a user installed an extension or some rogue software did.

Because of this, stopping sideloading is all about delicate balancing of incentives. "Carrots and sticks" so to speak.

We want to make it easy and effective for people to do the good thing (carrots), and hard and dangerous enough to dissuade them from doing bad things (sticks).

Previously our approach was to provide easy APIs [1] to install extensions into Chrome that we controlled. The result was that the Chrome team could monitor usage and see if it got out of hand.

Unfortunately, as Chrome became more popular, it did in fact get out of hand. So what you see here is us basically adding a few sticks, trying to reduce overall bad behavior. (We're also working on other things in other areas so that we don't just push the bad behavior into harder to monitor channels).

[1] http://developer.chrome.com/extensions/external_extensions.h...

One approach to this would be to just ban extensions that are caught installing themselves without the user's permission. If the banned list is kept up to date it would make life hard for people abusing the system.

What do you ban? How do you establish identity for an extension? Remember that the bad guy can just change his ID each time he installs. Soon you are shipping blacklists with hundreds of thousands of entries to every client (or sending the ID of each install to the server to ask permission).

Also, where do you store the blacklist? Remember that the bad guy can just modify it to remove his entry. Or he can modify Chrome itself to not check the blacklist.

There are a long series of escalations you may propose here (encrypt the profile, try to detect changes, store the profile on the server, add a developer key system, etc). I'm just going to summarize and say there is no perfect solution to this problem. You can make bad behavior somewhat harder, but you cannot eliminate it without true application isolation.

At each escalation you increase the complexity of the product, make genuine features harder to introduce, add bugs, and make the experience for legitimate developers worse. It's a challenging environment to write software in.

That said, the team has some pretty clever ideas in development for future releases. We fight on.

i'm seeing a lot of the good old "ie toolbar" behaviour lately: chrome extensions (typically developed by big portals) get installed with third-party applications without user consent.

this looks like a proper (if a bit delayed) measure to me.

This is welcome news. Us browser vendors should probably get together and try to standardize on what we consider acceptable user consent. Far too many extensions get installed into browsers in ways that are just not OK.

I think we get enough WONTFIX's from browser devs as-is. How about just ship sane defaults, enforce permissions as configured, and let us determine what's acceptable on a case-by-case basis?

I'd be happy if installing Chrome didn't install a Google Update plugin in Firefox without asking me.

I'd be happy if the updated chrome for android to anything above 18. With that new update I'll be 7 versions behind. WTF Google?

"Chrome 25"

Wow. Version numbers are a joke these days.

This is beyond welcome. The title doesn't really convey what they're doing here, though I'm not sure how I'd phrase it either.

This is blocking the sort of extensions that get installed with other desktop software. So, like, for whatever god damn reason Microsoft thinks it needs to install Office addons into Firefox when I install Office. That wouldn't fly in Chrome now.

Interesting. I guess Microsoft wants you to believe that "you can read Office docs on the web" or something, when in fact it's the plugin opening them in the browser. This is what worries me about Windows 8, too. That they will try to tie too many "HTML5" apps with OS-related plugins.

Why does that worry you? They started out with all plugins, including their own, entirely disabled on Windows 8 and only added plugin support back after much begging and crying from Flash developers. How do you make the leap from that to Microsoft secretly sneaking proprietary plugins into HTML5 applications?

Yeah I'm not entirely sure I understand what you're referring to either. the only plugins in Windows 8 are in the IE RT app. And that's just Flash.

There aren't really plugins for JS apps though there are obviously WinRT specific APIs and some CSS models that are only implemented in IE...

> That they will try to tie too many "HTML5" apps with OS-related plugins.

ActiveX failed back when Microsoft had a monopoly on practically all end-user systems. Now, with Android devices and iPads and Mac laptops some people actually use and so on, how well could it possibly work these days?

Yeah, I really hated Skype extension that would install itself without my explicit consent or considering the fact that I don't use laptop to make phone calls.

The Skype extension also significantly slows down page renders. It needs to die in a fire.

It also has a nasty habit of inserting its markup in places it doesn't belong, like textareas and inline editable elements (WYSIWYG editors).

I'd never run into that, but yowza, that's ugly.

One instance of this behavior (involving the Firefox toolbar) is referenced here:

http://en.wikipedia.org/wiki/MediaWiki:Abusefilter-warning-s...

Administrators on the English Wikipedia set up a filter to simply block edits which were tainted by that bug.

Your post doesn't fully convey what they're doing here either.

According to the article, it is still possible to package extensions with a software installer, but now when the user runs their browser they will be asked to confirm that they want the extensions to be added.

So it isn't really blocking those extensions, which I think is a good thing.

> This is blocking the sort of extensions that get installed with other desktop software. So, like, for whatever god damn reason Microsoft thinks it needs to install Office addons into Firefox when I install Office. That wouldn't fly in Chrome now.

As someone else commented below, Firefox has blocked this for a while now. So this will no longer fly in any major desktop browser (except perhaps IE, but in your example it's made by the same company installing the addon ;)

Reply on news.ycombinator.com