Hacker News Reader

Comment by shadowgovt | Hacker News Reader

Without the additional constraints manifest v3 puts on what code an extension can run at runtime, an extension author can just slip some "grab some code from a server I control and eval it" logic into their extension, which Google can't vet. That makes it possible for an extension that was fine yesterday go to "harvesting your PII to send to a company that is building an AI based on your click frequency" today with no change indicated; just a silent "Oops I'm malicious now" shift.

All cards on the table: Google does a not-great job of protecting against intentional malicious changes last I checked, i.e. they'll pass through a lot of new extensions and extension updates that do shady stuff behind the scenes. But without some lockdown on arbitrary code execution (which Mv3 provides), the problem is theoretically impossible to solve.

View on HN

Detect if the extension downloads and executes arbitrary code, and ban it if it does. That should be just as easy to detect as detecting that the code does something bad directly. In fact, the way extension policing works is (afaik) completely reactive: if someone reports that an extension is doing something bad, then the extension/the developer thereof is banned. No/minimal policing is done at the time of publishing. The exact same policy applies unchanged to extensions that download malicious code instead of packaging it directly: wait until someone complains about the malicious code, ban the extension for having malicious code.

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.

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