Actually, aren't all browser extensions a security nightmare?
Or has something changed recently?
Or has something changed recently?
The main difference is that AI extension, by design, send the content of the pages you browse to a server.
A malicious "calculator" extension could also send all the content to a server, and extension users don't really have an idea of what each extension is actually doing.
So skip the "Malware posing as AI browser extension" section, it's same kind of security issues as a malware calculator extension.
The legitimate AI extension's problems are more interesting.
Article wastes a bit more time on other security issues you get from using AI LLM in general. Those apply whether you're using a browser extension or chat.openai.com directly.
The valid point that applies to narrowly AI browser extension are:
1) it could send sensitive data you wouldn't have sent otherwise. Most people would know what they're doing when they explicitly paste the stuff on chat.openai.com. But when it's now automated via the extension DOM scraping, it's a bit harder to realize how much you're giving away.
2) And the hidden text prompt injection. That's interesting as now your attacker could be the website you browse, if you have configured too many plugins (Zapier plugin giving access to your email)
These 2 parts of TFA are imo novel security issues that only exist with AI browser extension, and are interesting.
Without this feature, extensions will keep insisting they need access, and the user will eventually fall for it.
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.
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."
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.
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.
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.
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.
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.
Why is the security policy for extensions still not architected like other web permissions?
There has been a shift on mobile already from "take it or leave it"-style permissions on install towards more fine grained control not overidable by the app manifest.
I think Browser extensions should behave similarly. Especially when it comes to which origins an extensions is allowed to act on.
The user should be able to restrict this regardless of the manifest, even forced to do.
Extensions that need to act on all or an unknown set of origins should require a big and scary prompt after installation, regardless of what the user agrees to during installation.
I say this as a happy user of uBlock origin and React DevTools.
But for the common user the default should be to deny permissions and require user interaction.
I'd like an UI similar to the mobile one. I brought up the origin thing because for lots of extensions I would like that kind of UI for origin control. Origin control is part of WebExtension API, but it's during installation, which forces even well-meaning developers to request overly broad permissions for some kinds of extensions.
It’s worth contrasting clear communication such as the above to a EULA designed by scummy companies to not be read, browsers presumably have nothing to gain by exposing malicious plugins, so they’re a good candidate for the former.
If only we could get Mozilla executive to implement something actually useful instead of whatever meme tech they’ve lost their nut over this week, that’d be nice.
One way to avoid this would be to have an extension market which highlights alternative extensions and how they differ in permissions. But it would be hard to maintain those relationships, create a new oppportunity to game trust, push responsibility onto the market owners, etc. And ultimately, many interact with proprietary products without a direct competitor e.g. if FAANGs made them. So I can't see it happening.
so they're not a total security nightmare if they're only authorized to run on sites where you don't enter any private data. for example, looking through my extensions list, the py3redirect that autmatically redirects python2 documentation pages to python3 pages doesn't request access to anything other than python.org.
but otherwise, yeah, you're giving permission to execute arbitrary code on any website you visit, which is about as compromised as your browser can get.