I can't help but roll my eyes at these "turing completeness" arguments. The obvious way to prevent auto updating is to simply disallow an extension from modifying its own storage and to prevent it from running any code it manages to download. We don't operate on abstract turing machines, we can impose whatever limits we want on the code we allow to run. Now, I'm not saying this is easy to accomplish, but impossible it is not. If Google can manage to allow machine code downloaded over the internet to run securely like it claims, I'm sure it can handle a little javascript.
"The obvious way to prevent auto updating is to simply disallow an extension from modifying its own storage and to prevent it from running any code it manages to download."
You can remove eval() (In fact eval() is disallowed in Chrome extensions, for different reasons).
But how do you prevent an extension from including an interpreter for some other language and simply downloading and interpreting code in that language? This isn't crazy. It's common for games to include interpreters, for example.
Including an interpreter for a simple language is just one step in complexity beyond downloading configuration files. Is downloading configuration files that change the behavior of the code forbidden in your proposed system too? How is that accomplished?
"If Google can manage to allow machine code downloaded over the internet to run securely like it claims, I'm sure it can handle a little javascript."
NaCL has the same properties I'm describing. NaCL enforces a sandbox on what a hunk of code has access to; it doesn't enforce that that code won't change its behavior over time, possibly in response to data from the network. That is not possible to do.
What you say is certainly true in general, but it doesn't take into account the threat model of a supposed malicious extension. The threat model here is that someone decides to significantly alter the behavior of an extension after it gains traction and a certain level of trust. For this to work would require the extension to include an interpreter or some other mechanism from the start. They would essentially have to think "if this gains traction I may want to start silently injecting ads/stealing information, so why don't I include this interpreter in it now just in case". While possible, it isn't very likely.
The other problem with the security model is that all extensions are seemingly created equal. I would think that a large majority of extensions do not require access to any external resources besides the ones downloaded from the webpage itself. Think of a youtube downloader, flashblock, etc. These types of extensions should have a different security model that is constrained to restrict any web request calls besides to the domain of the page and perhaps any domains that page calls (to take into account cdns). These types of extensions shouldn't need any consideration of security implications to install. There's no reason why a youtube downloader should have the potential to steal my passwords down the line. More involved extensions that would require generic http requests could have the warning about data access.
I see in your profile that you know a thing or two about chrome extensions, so I will defer to your expertise on whats possible. It just seems like with the proper constraints for different levels of access one can have much greater security than we have now just treating all extensions the same.
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.
