Hacker News Reader

Comment by shadowgovt | Hacker News Reader

In manifest v2, downloading and executing arbitrary code is a feature.

What you're describing is the migration path from v2 to v3. "Detect if the extension downloads and executes arbitrary code, and ban it if it does" is isomorphic to "deprecate the eval arbitrary code permission, cease supporting it in the store, and provide an alternative declarative model to get some of the behavior back;" it's what Google is trying to do.

View on HN

It's a composition of two features, both of which are useful on their own. Removing this "feature" requires removing at least one of those sub-features, in this case eval. We could alternatively allow eval to be used, but ban it from being used on code downloaded from the internet. This would require vetting the code, rather than a fully automated check. The goal of such a removal is, supposedly, to enable manual vetting to be more effective. However, the only reason to prefer an outright removal over a conditional ban is that it obviates the need for manual review. Do you see the contradiction?

> This would require vetting the code, rather than a fully automated check.

Then it's a non-starter for the manifest format supported by the chrome web store. Because Google's goal is to automate as much as possible.

Naturally. Thus, it doesn't much matter whether code is shipped in the extension package, or downloaded off the internet, since nobody will be checking what it does regardless.

Of course it matters. One of them allows looping in data from arbitrary external sources, and the other one (Mv3) has a permissions model that disallows that. It's a completely different risk domain.

Don't forget, the mere act of requesting data from an external uncontrolled third-party source is leaking user information. Under Mv3, those leaks are fully documented.

Reply on news.ycombinator.com