As I've explained to others, this was a considered decision taken to protect our users. I don't claim that the WebStore is immune from malicious extensions, but all our data very clearly showed off-store extensions to be the major vector by a very large margin.
I don't think this marginal increase in friction for off-store installs is a bad compromise. However, if you have a better suggestion, I'd be happy to hear it. Also, I'd ask that you report the WebStore extension you believed to be malicious, in the interest of protecting other users.
In my case the .crx I want users to install is for an internal application and is a small "hosted app" in the terminology of Chrome. It can only access the domain of our internal app and that's the domain that serves the extension. I don't know how this got lumped in with extensions that access all user data. If it's just a wrapper around my own app and that's all I can access, I don't see how I can do anything malicious.
We just use it to manage permissions and in some cases make use of the full screen feature. There has to be a better way than to treat all .crx files as the same. I don't have a problem with the web store other than that the app is completely inappropriate for the web store (it's only useable to people who are using an internal app).
The point of this change was to add controls for managing trusted installation sources. So, you can use the enterprise policy support to push your installation source out to all your users, or install the extension as part of your Chrome deployment.
I don't think this marginal increase in friction for off-store installs is a bad compromise. However, if you have a better suggestion, I'd be happy to hear it. Also, I'd ask that you report the WebStore extension you believed to be malicious, in the interest of protecting other users.