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