I really wish we could get something like this for local, desktop apps. I'm super tired of most every new desktop "app" being just an electron runtime (which, of course, can read and write all over my filesystem) that runs now-unsandboxed js both from its own bundle, as well as downloaded willy-nilly from the internet.

Let's give engineers more credit, here. The majority of desktop applications have the same capabilities, including writing all over your filesystem and executing code from remote sources. Electron gives those same capabilities to apps written in JavaScript.

Electron: The safety of desktop applications with the user experience of web applications.

So, worst of both worlds?

> Let's give engineers more credit, here. The majority of desktop applications have the same capabilities, including writing all over your filesystem and executing code from remote sources.

Capability, sure.

But more often than not, it is Electron-based applications which are happy to include remote scripts... Because that's often as easy or easier than vendoring your dependencies and bundling them.

In practice, Electron apps probably poses a bigger security risk, at least for that threat-vector.

For a while you could get persistent native code execution (effectively root) in Slack, Discord and Microsoft Teams by dropping a text file in a specific spot in AppData/homedir/etc. Didn't even need to be chmodded or anything, just drop the file there and the electron apps would run it at startup with full permissions. Really dramatically lowered the difficulty of running code on an end-user's machine, especially since that directory is writable by virtually anything, including an electron app you've XSS'd.

I think all 3 have been patched to prevent that particular attack, but it's astonishing to me that electron apps don't seem to use any form of code signing.

my HackerOne reports were all Out Of Scope, naturally, until parts of the attack got assigned CVEs later and someone else got the bug bounty :) At least it's fixed!

On MacOS they could and should be sandboxed by the OS.

Yes and no. Chrome does a ton of stuff to prevent foreign processes from messing with it, so exfiltrating your gmail session tokens or emails via a native app is very difficult. In a chrome extension? Laughably easy, tons of extensions have read/write access to all your gmail tabs because Google does nothing to warn users about how dangerous that permission is. The extension APIs are poorly designed such that you need that wildcard access for all sorts of things, too.

They did eventually try to shut the barn door after the horse bolted by changing the wildcard permissions system to have manual domain filtering but I never saw them actually shut it off by default (doing so would break existing extensions). Maybe they will in Manifest v3 since they're perfectly happy breaking ad blockers.

The restriction worth for security, but also pain for some extensions. For example, A Google Translator add-on on Firefox can't be regitered to Mozilla's store.

https://github.com/andreicristianpetcu/google_translate_this

Indeed, it is not possible to use Google translate without running a remote script. However, this is not justified from a technical point of view as far as I know.

Then how does S3 Translate on Firefox do the same thing & has no trouble being in the store?

They don't have any trouble because they don't run remote scripts. This problem is specific to the implementation (and the TOS) of the Google translate API.

Um, question, does remote code (as defined by the Webstore and Mozilla) refer to JS that is downloaded and eval()ed in the background and content script contexts, or <script> tags that are injected into the page, or both?

You can't eval in extension context, but injecting a <script> would work given the permission that lets you edit the page's DOM.

Ah, thought it was allowed with 'unsafe-eval' in extension CSP. Never had a need for it. Remote code refers to injecting <script> tags into the page then?

When running as a WebExtension you have a higher set of permissions than a regular script (you can to some degree control the browser, after all), so certain parts of JavaScript is off-limits.

eval() is one of those things.

Wouldn’t this neuter the most useful Chrome extensions? Cash back/coupons, adblock, etc.

These extensions don't need to run remote scripts to work properly, and they work perfectly in Firefox. Typically, "legitimate" extensions use remote scripts to dynamically insert trackers or ads.

You can still return text data, you don't need to execute it.

But think of the great excuse for killing off V2!