[jprete]

No, because a typical safe-to-run browser extension is written in such a way that it can be examined to see what it does. AI-based tools can’t be analyzed based on their code, so the only way to make them safe is by limiting their capabilities. Any such capability limit is likely to be either too constraining, not constraining enough, or require as much planning ability as the AI itself.

[majormajor]

When you talk about not being able to analyze these based on their code do you mean because today they're all just calling out to OpenAI or whoever?

The risks listed in the article itself mostly seem to fall under the same, non-AI-extension, core problem of "you're given them all your data." And that's a risk for non-AI-based extensions too, but if you look at the code of an AI one, it's gonna be obvious that it's shipping it off to a third party server, right? And once that happens... you can't un-close that door.

(The risks about copyright and such of content you generate by using AI tools are interesting and different, but I don't know that I'd call them security ones.)

The prompt injection one is pretty interesting, but still seems to fall under "traditional" plugin security issues: if you authorize a plugin to read everything on your screen, AND have full integration with your email, or whatever, then... that's a huge risk. The AI/injection part makes it triggerable by a third-party, which certainly raises the alarm level a lot, but also: bad idea, period, IMO.

[GTP]

>When you talk about not being able to analyze these based on their code do you mean because today they're all just calling out to OpenAI or whoever?

I think that the issue here is that AIs are probabilistic in nature, meaning that you can't fully predict their behavior in a particular situation just by reading the code. Instead in a tipical (non AI poweered) extension, the code is a precise description of what the extension will do in every possible situation.

[jprete]

> When you talk about not being able to analyze these based on their code do you mean because today they're all just calling out to OpenAI or whoever?

I mean that ML models are inherently inscrutable, it is extremely hard to determine how they operate internally, so no-one can identify any definite boundaries of what it will and will not output, or why. Hence prompt engineering, Bing's Sydney alternate personality, and weird hallucinated image artifacts.

Sure, if a user is calling OpenAI, they obviously can't understand the details of how it generates text. But neither can OpenAI! And if it produces something surprising, there's no way to fix it by directly modifying the model, the only way to do it is via ML techniques in the first place.

[amelius]

The problem is the permission system. Like apps, extensions have an all-or-nothing attitude to permissions. Browsers should allow the user to be more specific about permissions, and let extensions think the user gave more permissions than they actually did. E.g. if extension insists that they need "access to entire filesystem", the browser should make the extension believe they have access to the entire filesystem, but of course the entire thing is sandboxed and the user can restrict the access behind the scenes.

Without this feature, extensions will keep insisting they need access, and the user will eventually fall for it.

[josteink]

> Like apps, extensions have an all-or-nothing attitude to permissions

Browser extensions needs to declare their permissions. With Manifest V3 we’re seeing even more need to declare permissions.

Any extension cannot do anything not explicitly granted to it by the user upon installation.

[actionablefiber]

The issue is those extensions can withhold valuable functionality needlessly.

If I download $usefulWikipediaCompanionExtension whose functionality only depends on access to *.wikipedia.org but whose manifest demands permission on all sites, I'd like to be able to tell my browser "if I'm not really on Wikipedia, only show the extension a blank page."

[hgsgm]

That's a lot more work than saying "No" to using the malware.

[actionablefiber]

It's common for various counterparties, including software, to ask for much more information than they need and possibly be doing untrustworthy things with it while also providing legitimate value to the end user.

I've lied about my birthday while signing up for websites before. I've also made ad-hoc email addresses with forwarding to conceal my main email address. I've given fictitious phone numbers and I've used the names of fictional characters. I do this because I benefit from the service but I don't trust the provider to use my information responsibly.

Not a logical leap to go from there to feeding fake data to extensions when they request data that the user deems unnecessary for their functionality.

[saurik]

Yeah: while declaring permissions sounds cool and tries to fit into the narrative of helping protect end users who don't know how to manage anything themselves, at the end of the day it first requires an extremely opinionated central entity in charge of listings which takes a role in attempting to mediate the incentive incompatibilities (something which should raise serious ethical red flags and begs the question of conflicts of interest with respect to that player and the market that they get to fully control) but then still not only doesn't work to prevent users from getting abused, it will never work: "this app has requested access to your birthday" might be easy for end users, but (if this must be an API; but like, to the extent to which birthday is a bad example, this generalizes to every other thing that people currently must grant as "permissions") the only actually-correct solution is to always provide a concrete random date to every app by default and then allow the user to go out of their way--and this must not, under any circumstance, be something the app is allowed to prompt for or have any visibility into: this must be something the user has to initiate through external UI--to say "I grant this app access to my real birthday" (which, to the app, would have to look like the user merely changed the setting on their birthday to some other random date, as opposed to "the user finally gave us permission to see the same date that they can share to every other app").

[josteink]

> It's common for various counterparties, including software, to ask for much more information than they need

I believe if you ask for very wide permissions, at least when publihsing a browser-extension in the Google Chrome-store, you will have to justify why those are needed (from a user-facing POV), and your extension will be subject for additional review.

The same also applies when creating other Google-related apps which uses APIs which Google deems sensitive or restricted: You will have to justify their usage and be prepared for a review.

It's not bullet-proof, but it's more than nothing.

[iudqnolq]

Yes but this extension needs to send the content of webpages you visit to APIs. You're gonna give it explicit permission to effectively do whatever the hell it wants.