Hacker News new | ask | show | jobs
by shadowgovt 692 days ago
Ironically, this is exactly the failure pattern that the changes in Chrome extensions to manifest v3 try to prevent. You can't provide a guarantee to the end-user of pre-vetted safety when the application is downloading and executing arbitrary code from a third-party source. That's like expecting a static code verifier to prevent all runtime errors.

It is, perhaps, a guarantee that no vendor should be expected to make.
1 comments
SoftTalker 691 days ago
> You can't provide a guarantee to the end-user of pre-vetted safety when the application is downloading and executing arbitrary code from a third-party source.

So a web browser can't be trusted or certified, ever. Unless JavaScript is disabled?

link
blackoil 691 days ago
JS lives in a sandbox, that will require a bug to escape. Plugins are out of sandbox and random plugins should be disabled if security is a concern.
link
shadowgovt 691 days ago
Correct, and I should have been more clear. By the nature of what they do, Chrome extensions operate outside the sandbox designed to make attacking the underlying operating system running the browser very hard.

Sandboxing is such a way to attempt to enforce a guarantee (modulo sandbox bugs, of course). Since crexs aren't entirely in the sandbox, vetting and signoff is supposed to provide the added assurance of security the sandbox can't provide. And those assurances are hollow when the vetted crex is running arbitrary code from a third-party source.

link