If we didn't provide an autoupdate mechanism, then developers would just implement their own. Frequently, these handrolled systems would have security flaws. We have an existence proof of this: it happened in the Greasemonkey ecosystem.
We might propose that we could prevent these hand-rolled systems by restricting eval(). Well, we already restrict eval for different reasons. What we see is a lot of people working around the restriction by injecting code into websites (!!).
My bet is that basically any significantly sized extension would implement a workaround for any autoupdate restriction we tried to employ. Developers really like the ability to update their product, and the workarounds are not that hard. And these workarounds would be worse than the original problem - that sometimes good people turn bad.
It would also destroy the value that autoupdate provides which you are forgetting about: most of the time it is used by good people to do good things. We frequently find extensions with security problems, tell the author, and then they fix and push them to users. Without autoupdate this wouldn't be possible.
===
As for your proposal for how to restrict the levels of access extensions have... As I said above, we do this kind of thing already. You can read all about it here: http://developer.chrome.com/extensions/permission_warnings.h.... We have a very granular security system.
For example, it has been always been possible to write a youtube downloader Chrome extension that only has access to youtube.com.
However designing the right APIs that have narrow risk, yet are flexible enough for developers to want to use remains a difficult problem that is unsolved except in specific cases.
Thanks for the info. I had no idea chrome had that, I don't think I recall installing an extension that DIDNT give me a warning about access. It seems like developers just stick to the more unrestricted system out of convenience or narcissism ("must phone home my youtube downloader, for science!"). There's definitely something out of whack here if developers won't use the restricted access when their extension fits nicely within that model. It would be nice if it could be shown that extensions are penalized in terms of downloads by requiring unnecessary access. As it is I've stopped using all extensions in chrome except adblock.
We might propose that we could prevent these hand-rolled systems by restricting eval(). Well, we already restrict eval for different reasons. What we see is a lot of people working around the restriction by injecting code into websites (!!).
My bet is that basically any significantly sized extension would implement a workaround for any autoupdate restriction we tried to employ. Developers really like the ability to update their product, and the workarounds are not that hard. And these workarounds would be worse than the original problem - that sometimes good people turn bad.
It would also destroy the value that autoupdate provides which you are forgetting about: most of the time it is used by good people to do good things. We frequently find extensions with security problems, tell the author, and then they fix and push them to users. Without autoupdate this wouldn't be possible.
===
As for your proposal for how to restrict the levels of access extensions have... As I said above, we do this kind of thing already. You can read all about it here: http://developer.chrome.com/extensions/permission_warnings.h.... We have a very granular security system.
For example, it has been always been possible to write a youtube downloader Chrome extension that only has access to youtube.com.
Flashblock would theoretically be possible with the upcoming declarativeWebRequest API (http://developer.chrome.com/extensions/declarativeWebRequest...).
However designing the right APIs that have narrow risk, yet are flexible enough for developers to want to use remains a difficult problem that is unsolved except in specific cases.