3 ms·

> They already disallowed remote code loading in extensions with a Chrome Web Store policy update nearly two years ago. They didn't have to invent a new API ful

> They already disallowed remote code loading in extensions with a Chrome Web Store policy update nearly two years ago. They didn't have to invent a new API full of breaking changes to do it. Blog post author here. This comment is incorrect on two main fronts. First, the Chrome Web Store's Developer Program Policy did not prevent the use of remote code, it only forbade the obfuscation of remotely loaded code. An alternative, stricter reading of the policy was that extensions could not use remotely hosted code to obfuscate it's operations. Regardless of which of these interpretations you favor, using remotely hosted code in Manifest V2 extensions is not forbidden by our policies. Second, I strongly disagree with the implication that policy changes could have addressed the abuse issues we're seeing. Even if we did have policies disallowing the use of remotely hosted code, that does not somehow compel developers to comply or simplify the enforcement process. I have a ton of respect for my colleagues in review, but policy enforcement is complex and virtually impossible to get right 100% of the time. So, some amount of malware will get through review, some number of users will be exploited, and some amount of harm will result. How much harm should we accept as "the cost of doing business", especially when we have a way to address a major exploit vector? Speaking as a developer, I'm not exactly thrilled to lose capabilities that I've been using responsibly because other people are exploiting them. On the other hand, as a member of the team maintaining this platform I don't see a practical alternative to address the problems that arbitrary code execution presents for the average user.

somehnacct3757 5y ago
Here is the remote code policy on your own website: > Your extension should avoid using remote code except where absolutely necessary. Extensions that use remote code will need extra scrutiny, resulting in longer review times. Extensions that call remote code and do not declare and justify it using the field shown above will be rejected. [End quote] This has nothing to do with code obfuscation. Remote code in general is heavily discouraged. Your extension can be outright rejected if your 'justification declaration' is insufficient (Google's discretion). And if that isn't enough to deter you, the review time will also suffer (Google's discretion.) Does this policy not work? Surely it has led to a reduction in remote code exploits. And also given the enforcement team a straightforward path to take down an app in violation. To your second point, you _don't_ have a way to address a major exploit vector. You've thrown the baby out with the bathwater. You've banned cars and introduced chariots as the solution to hit and run accidents. Now nobody can be run over! We've fixed Google Roads! I would also like to know what API did exploiters share with ad-blockers? At the time, we were told the ad-blocker APIs had to be removed for performance reasons. Has the argument changed to a purely security one? Was it both? The MV3 genie has sadly been let out of the bottle. We can't go back. But we can reduce its capability diff with MV2. It will involve sacrificing some of Google's secret objectives, which is why it's important to know them. Listening to performance arguments one day, then security arguments the next, in carefully worded statements that don't quite add up; is what gives the impression there are secret objectives.

somehnacct3757 5y ago

Here is the remote code policy on your own website: > Your extension should avoid using remote code except where absolutely necessary. Extensions that use remote code will need extra scrutiny, resulting in longer review times. Extensions that call remote code and do not declare and justify it using the field shown above will be rejected. [End quote] This has nothing to do with code obfuscation. Remote code in general is heavily discouraged. Your extension can be outright rejected if your 'justification declaration' is insufficient (Google's discretion). And if that isn't enough to deter you, the review time will also suffer (Google's discretion.) Does this policy not work? Surely it has led to a reduction in remote code exploits. And also given the enforcement team a straightforward path to take down an app in violation. To your second point, you _don't_ have a way to address a major exploit vector. You've thrown the baby out with the bathwater. You've banned cars and introduced chariots as the solution to hit and run accidents. Now nobody can be run over! We've fixed Google Roads! I would also like to know what API did exploiters share with ad-blockers? At the time, we were told the ad-blocker APIs had to be removed for performance reasons. Has the argument changed to a purely security one? Was it both? The MV3 genie has sadly been let out of the bottle. We can't go back. But we can reduce its capability diff with MV2. It will involve sacrificing some of Google's secret objectives, which is why it's important to know them. Listening to performance arguments one day, then security arguments the next, in carefully worded statements that don't quite add up; is what gives the impression there are secret objectives.