Yeah parts of the article would still be as valid if this was about regular extensions.
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.
If a calculator extension is caught sending any data at all over the network they immediately would be suspicious, but evey AI extension has plausible deniability when making any requests, most can send all the webpage including form inputs and still have such deniability.
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.
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.
>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.
> 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.
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.
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."
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.
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.
shout out to the Arc browser, which has it's own browser sandbox and WYSIWYG tools to build JS snippets that run in your browser. I'm not affiliated with them in any way, but they're really changing the way I look at browsing online.
Already commented something similar in another thread:
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.
you can make a warning as big and scary as you can, and people will just blindly hit accept/agree/ok. the look/design of the banner is not what will stop people from hitting ok, as at this point, i don't think anything will
While this is historically true, if the text is human readable - ‘may be able to read and transmit to a third party any data you input, including credit card numbers and passwords’ - is fairly likely to raise awareness. It’s not effect, but it’s better than nothing.
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.
In isolation this is true, but for most people they just want the product the extension is offering - skipping past boring warnings is a means to an end. There is also the issue of warning fatigue when extension authors normalise asking for more permissions - more warnings leads to less engagement.
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.
Yes you are right, that came down to me after I hit the submit button. But consider my train of thought more an associative one.
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.
an extension developer can scope their extension to only run on certain URLs, and if that list changes then chrome will automatically disable it until the user re-authorizes for the new set of URLs.
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.
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.