An egregious and nearly unbelievable oversight on Google's part. :-\
As a developer, it's unimaginable to me to not test the extreme high and low numbers of inputs cases to ensure things look and operate as expected. Especially for a security sensitive UI element.
The chain of humans who've been responsible for developing and testing Chrome Extension functionality and security has been asleep at the wheel this whole time, for something like 15 years.
There are so many risk-reduction controls in place; tons of red tape and umpteen security and privacy reviews required to ship even minor features or updates, yet here we are.
How many hands have been in the pot and not noticed/raised/resolved what amounts to a pretty obvious security vulnerability? And if this kind of issue can fly undetected for so long, what can organizations with drastically less resources than $GOOG do to ensure adequate velocity while not leaving the proverbial barn doors open?
The author deserves the highest tier of bug bounty reward for bringing this to light. What's that? It wasn't submitted through the proper channels to be eligible? Right.
<insert relevant Dildbort cartoon>
As the first in this chain of humans, I can tell you that (a) we obviously considered this in the first version of extensions and did not allow permissions "below" the fold, (b) Chrome's extension model dramatically improved on the previous state of the art which was Firefox's "every extension can do everything, extensions can't be uninstalled completely, and there's no review" [1], and (c) the install dialog is just one part in a bigger system which includes the review process.
I encourage the author to try and get this onto the store and get meaningful usage, then we can complain about how well the entire system works end to end. Examining just the install dialog alone is missing the point. I'm not even certain that an extension that requests more than 5 permissions would be approved in the first place.
I also encourage readers to remember that generally speaking, you all _want_ extensions. When Chrome didn't have them, they were the top feature request in the bug tracker. Real security is hard. If you don't solve user needs, users solve them themselves with solutions that are even worse (ie native code). Managing the browser extension system is a thankless painful job of delicately balancing incentives. Extensions need to work well enough that developers don't reach for more powerful and dangerous tools, but have enough controls that the majority of malware can be controlled. It sucks. Trust me you really don't want this job. Please spare a bit of empathy for the "chain of humans" that have had it.
[1] https://static.googleusercontent.com/media/research.google.c...
Irrelevant.
> (b) Chrome's extension model dramatically improved on the previous state of the art which was Firefox's "every extension can do everything, extensions can't be uninstalled completely, and there's no review"
Irrelevant.
> (c) the install dialog is just one part in a bigger system which includes the review process.
"Our MFA system is broken and will accept wrong input, but that doesn't matter because you without the correct password you won't get in."
Would that fly?
> I also encourage readers to remember that generally speaking, you all _want_ extensions. When Chrome didn't have them, they were the top feature request in the bug tracker.
What are you trying to say? That because users want it then overlooking security issues is excusable?
> If you don't solve user needs, users solve them themselves with solutions that are even worse (ie native code).
That falls under the realm of 'their fault.' This problem does not.
> Please spare a bit of empathy for the "chain of humans" that have had it.
OK, I feel bad for the poor Google worker with the thankless job and a six figure salary. Now fix it.
My understanding at the time (I realize I could be mistaken about any of these):
* Users have no idea what code they're installing. Extensions aren't required to be open source, where the community can audit them for malicious behaviour. Even if an extension claimed to be open source, there's no verification system to ensure the code actually being executed is the code displayed on their github.
* Automatic updates. Maybe this isn't the case now, but at one point I remember extensions were updating themselves automatically. Users of popular extensions are frequently contacted to add an "analytics" dependency from some shady company, in return for a nice payout. Users don't have the ability to opt out of these kinds of updates when some of their extension devs inevitably cave into the pressure. In my mind, these kinds of updates should only be shipped with user's full consent and understanding that they are being asked to install updates which have no practical utility to them
* Code obfuscation. I don't see why every extension shouldn't be shipped fully unobfuscated, at least as an option. Perhaps minified bundles could also be shipped as a way of supporting users on low-spec devices which really need those extensions, but then again, if disk space is so short for those users maybe they shouldn't be installing extensions in the first place
* Better observability of interactions between user-requested websites and extension background pages. If I look in my network panel I want to see communication with installed extensions happening
But anyhow, you work on the system and can't point out if this is an issue or not in the end-to-end sense? Like, why say OP is "missing the point" if you are not sure if they are missing the point?
TBF you do say "I'm not even certain that an extension that requests more than 5 permissions would be approved in the first place." Which if true, would make this pretty low priority.
(On the Empathy note, I just want to add: stating "Trust me you really don't want this job." In this context to random members of a forum is a bit of an empathy-lacking thing to do)
As for the review process, I don’t think it’s good enough. I don’t use Chrome as a daily driver but I’m often seeing out-of-store extensions. Is there external process that would capture and mark/flag such 3rd party extensions?
"Public criticism (however valid) of something I worked on hurts my feelings. Just so you know, we already thought through ALL these possible "problems" (and more) and we chose the "one true way". So your criticisms are just, waves hands, whatever.
Plus, these "issues" could never happen anyway (just try it lol!), so your criticisms are basically imaginary. Also and anyway this is YOUR fault (not mine, no!) because YOU wanted extensions. Also, also: the other guys were worse. Your fault, shame on you, other guys worse, I'm a good person.
And finally, this is hard work, no-one ever said thank you to me."
Exception here. Never asked for them. Never wanted them. Do not and cannot use them.^1 Seems moot anyway as I doubt anyone ever asked for Chrome itself.
When an extension collects data under the radar it's "malware" but when Google does this, it isn't malware. Funny.
There's really no greater "danger" to www users than Google because it's nearly impossible to stop Google from doing what it wants. The company is embedded in every aspect of using the web. Malware authors might be a threat but they hold no such omnipotent control. Google is the largest threat.
1. Occasional Chrome user via Guest mode that does not permit Extensions.
I agree it's egregious, but it's quite easy to believe.
It's surely just using a standard modal and passing a string. The thing is, this is on a Mac that has scroll bars that are invisible until you scroll. It's easy to imagine testing was done other OS's where the scroll bars are obvious and the bottom line might be only partially hidden which makes it even clearer. And/or that testers never caught it on a Mac because they themselves never realized there were more.
I would hope somebody sees this now and prioritzes a Chromium bug for it. Because on a Mac at least, this is pretty serious.
(And I'm well aware this is a good example of a negative side effect of Apple's choice to make scroll bars visible by default only while scrolling.)
Rather, one would hope that Apple sees it realizes that their short-sighted, bone-headed, pea-brained idea to eliminate scroll bars should be rolled back. Of course, I'm not holding my breath. Yet another example of their crusade to prioritize form over function, exemplifying why I find their products to be infuriating to deal with.
I don't get why people say something like this, especially on HN where lots of people are SDE themselves.
Every single feature is hand-crafted by a/some real person(s), and is usually only reviewed by a handful people. It only makes sense sometimes it has serious oversight.
I try to live with the defaults as it makes switching machines so much less painful, however turning scroll bars in is an absolute requirement for sane usage. At least you don’t have to do it in Terminal anymore.
Edit: I can’t find any evidence that the preference could only be toggled via Terminal in some macOS versions. I’m thought that around version 10.6 this was the case, but maybe I’m wrong?
Settings > Appearance > Scroll bar behavior > Show scroll bars > Always
If I were in charge of fixing this bug for Chromium, I might start by prioritizing which permissions are the most nefarious, list them first, perhaps in red. Then ensure the entire dialog expands vertically to fit as much content as possible.
this has got to be one of the worst UX decisions of the past 10 years, come at me. You can just hear the meeting discussion:
A: make the scrollbars invisible until you scroll, that nets us 4% more width!
B: but it reduces discoverability by 50%, and its also an attack vector...
C: ship it!
Undoubtedly the stupidest UI decision made in the last 20 years.
What modern UI even has visible scroll bars by default?
And assuming it's even visible (either by default or user-configured after the fact if that's even possible), what modern UI even has scroll bars wider than 1px?
If $GOOG can't do it with practically infinite resources then I'm of the opinion that nobody can. Computing is broken.
APIs which would make it easy for extensions to exfiltrate user information might be the same APIs they would use to do the same. APIs that allow the user to enhance their web experience (think uBlock origin) are being kneecapped by manifest v3
You can't make a computing environment allowing anyone to write and distribute code that has the ability to do all the things users want it to do, without having a good chunk of bad actors trying to trick/persuade users into granting malicious code enough permissions to hurt the user.
You have to either severely limit what code can do (the iOS model), or allow users to shoot themselves in the foot (the windows download a random .exe and run it model). Chrome falls in between.
Besides the oversight of hiding some permission requests, this highlights that the order they’re presented matters too. Even if it weren’t scrollable with ~invisible indication of that, people stop reading at some point. If N lines (I’m gonna guess ~5 for most people) seem totally innocuous, the rest are probably effectively invisible.
Looking at the list I think they're sorting by ~alarmingness, so it seems hard to push an alarming one below the fold with innocuous ones?
There should be liability for negligence.
If you were told about a security hole and you have not fixed it, and you have not informed your users, in months, you should pay statutory damages.
And if you lied about your app (claiming encryption where there is none) you should be liable too, even if the app is free
I see where you are coming from, but increasing liability for free software does not feel like a good idea to me at all. There's basically no way you could extract money protected by Googles lawyers army, but any small open-source project or even medium sized company will be extremely vary of releasing anything.
I'm not saying you should never go there - GDPR does and it's a net improvement -, but it's extremely easy to massively overshoot.
Even if there were 20 items in the list, people would hit "OK," it's like accepting terms and conditions. Most people won't read them, they're trained to hit "Agree"
The whole model needs an overhaul. Extensions should be required to ask whenever they need the specific resource, rather than asking up-front. And each gated resource should get its own prompt with its own informative design. Similar to permissions on mobile
This describes Google's entire approach to browser extensions. It's so cosmically and hilariously bad, and because extensions grant post-decryption access, renders basically every other security and privacy effort they've ever done with web standards completely pointless.
All that garbage about encrypting everything in transit is entirely irrelevant when the endpoint is a masterpiece of bad security design.
Almost entire point of bug bounty programs is to encourage researchers to submit vulnerabilities using a proper channel and adhering to a proper procedure.
"Security at the expense of usability comes at the expense of security."
If you maximize security, so that there is poor convenience/usability, people will find usability workarounds which compromise security.
You're giving Google way too much credit here. Do you not think they use some of these techniques here? Or that they're an endpoint for other people's usage of these techniques?
> security has been asleep at the wheel this whole time, for something like 15 years
All is as intended.
I like this project, but I also worry that eventually we’re going to lose access to extensions entirely because people will take away the wrong message.
Safeguards are good, but at a certain point I want my devices to trust that I know what I’m doing.
The most important thing is whay you tell the user -
Windows says "We don't know where Trojan.exe came from, it could be a virus, are you sure you want to run it?"
Chrome says: "You downloaded Trojan.exe from our store, we manage it and check it for viruses. It only asks for harmless permission, install it!"
One is warning you, the other is entrapment.
> It only asks for harmless permission, install it!
Not true. It lists all the permissions being requested. Sure the scrollbar issue is real and should be an easy fix.
I don't understand why people are so confused about permissions. If the user grants your extension permission to read your browsing history so it can provide value to them, why is that a problem? It's not. The problem is if the user grants a malicious extension the same permission because the extension is fraudulent. The author said this extension would never pass chrome store review, so it seems that the user would never be in this position in the first place and your example doesn't really match reality.
Windows says "Now I know I say this for literally every program you download, but I'll say it again. It might be harmful because all programs can do anything at all. Good luck!".
Chrome says: "This might be harmful and it can do these things: X, Y, Z."
Apart from the stupid scrollbar issue that's clearly better.
The only problem is they have done the permission model that we've known for like a decade is broken: ask for permissions up front, you can grant all or deny all.
Could they not have spoken to the Android team who spent like a decade fixing that mistake and moving to fine grained on demand permission prompts?
I see it asking for two very scary permissions, two somewhat scary permissions, and one annoying one?
Maybe the middle ground is all extensions have a legal entity in your country so you can sue them for spyware.
The same can happen with any piece of software in the world. Why single out extensions?
Or pwned
There will always be a forked browser or an independent browser that supports/allows extensions as long as the web uses HTTP.
My guess is this wouldn't even get close to getting through the review process for the Chrome Webstore. From our experience with Streak, this would def get picked up in review.
Seeing other comments in the thread pointing to this article as a reason why MV3 is bad I think misses the point. Personally I think MV3 is a step in the right direction (even though it negatively affects us!). But it's only one piece to make extensions more secure - the others being manual review, policy adjustments and automated scanning. Even though the APIs allow for all sorts of functionality doesn't mean you'll be able to get through the rest of checks.
"This extension would be laughed out of the review queue."
I do agree about the permission UI box. Surely that's a completely simple fix on Google's part to force the user to scroll through the permissions box before accepting.
It's not like users are getting their data stolen left and right out there and man these extension trojans are winning the battle against good extensions and we just can't shake 'em. All your base... are belong to us.
It seems the status quo is that extension fraud, while entirely possible as this article demonstrates, is not actually a problem. If you don't trust a piece of software to access your webpage content then don't grant it the permission to do so. I think the onus is on alarmist pieces like this to bring the data supporting the existence of a problem to be alarmed about in the first place.
I mean, raise your hand if you've been pwned by a malicious Chrome extension recently...
Something else used to do that. Java, maybe? Whatever it was had regular enough updates that I _habitually_ drag the scroll bar directly or simply hit the end key to this day when I get to EULAs and other long modal popups.
For every permission in your manifest you need to provide the chrome web store reviewer with a written justification for why your extension needs that permission. Even the ones that don't prompt the user. And they definitely read it, and your code.
Shipping malicious extensions is almost entirely a social engineering problem and not a technical one.
The code below this text is highly inefficient and may lead the user detection solely from page interactivity slowdown alone. A more efficient implementation could read input using the 'input' event[1]. For example, here[2] is how you would use the input event to detect changes to any fields in a page.
1. https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement...
2. https://gist.github.com/eligrey/615fcc9fa9edbfb5153478109b5b...
My idea was that separate inputs should have separate debounced handlers, but it's likely you could do away with that and just listen for input events globally with no adverse effect on data collection.
But it isn't stealing if you clicked something somewhere sometime so "stealing" is wrong will be the PR response because people are being paid to not understand "stealing is wrong"
If you want to give 3rd parties access to all that stuff, you can run chrome. But I don't - I want the bare minimum that will run normal websites. I know that will break some pages, I'll accept that. (And that would give me a smaller & faster browser.)
In Firefox, you can go to about:config and set the default permission to deny to a lot of stuff (notifications, clipboard, etc.). You can also disable webgl and other features like those.
Router based adblockers work well, Flint by GL.net comes with nice UI and adhlock and VPN built in.
Some people complain about its chinese origin but at least I know only 1 government is spying on me - my provider supplies a router with a linux kernel older than this house. There could be an entire ensemble of Trojans partying there
If you are willing to accept quite a few pages breaking, Lynx is probably the smallest and fastest browser:
Sample of accounts: ChillNilly, LadyXaga, NerdAlerts, SuperDud, QueenBean, Moonshining, LetFree, FoxyFox22, TurkeyTurtle, LovableLily, BeingBean, CandyRandy, AdorableLama, WiseWolfie, WoozyWarrior, PenguinPeace, SunnyHorsey, SunnyMaylor, WiseSnail, ZappyHippo, FriendlyFlame, PudgyPanda, FriendlyFlame
Well done!
Sure.
uBlock Origin, Multi-containers, Temporary Containers and cookies.txt on Firefox, which I only use for specific purposes. History and all data is wiped frequently.
None on Chromium, which I always use in incognito mode. I use this daily, but don't need even uBlock on it, since I run a DNS ad blocker on my network.
And none on my main browser, Luakit, since it doesn't support extensions. :) Technically, I have some user scripts, which I've all reviewed or written myself.
Browser extensions are the number one security and privacy risk for all users, more than any OS exploits. The fact they've historically been handled so poorly, and these issues exist even today, should be terrifying.
Great article and extension! <3
I did not know such thing is possible. I want to make an extension which undeletes some chat messages in typical chats (usually that happens because of moderation)
I mean, why?
In theory it’s kind of neat.
https://developer.chrome.com/docs/extensions/reference/syste...
Stronger passwords is useless when the session is stolen, when the actual data is read and sent off
For example, the author of FB Purity hasn't explained to anyone why his plugin is not available via Firefox's extension store, only via his page. Presumably, he didn't meet some requirements they had...but he won't say what they were...
It would be trivial for Google to find all the extensions using that kind of crap, but they don't care.
Oh yeah, got bitten hard myself on that one a couple years back, it took Google days to respond to the extension buyer uploading a malware'd version. The worst problem is that extensions auto-update silently so you as an user don't even have the chance to spot anything in time.
iOS got this right from the start: ask on the first attempted access of the gated resource, allow the user to grant the permission once or on an ongoing basis, respect the choice. Don't allow permission prompt spam.
Even Android recently moved to this model from up-front permissions, so Google is aware of it.
I recently had an incident where WhatsApp Web was open in a tab in the background in a different browser window to the one I was actively using. I received and replied to a message on my phone. So imagine my surprise when I went to paste what I had previously copied from a web app in one Chrome tab to into a textfield in another, both in the active Window, to find that what was pasted was the second last message that I had sent in WhatsApp on my phone.
I have since deleted my Chrome profile at a system level, and the only extension currently installed is a well known password manager, but it bothers me to think what could have caused this aberrant behaviour, and whether there's something still installed on my system that's stealing data.
> Manifest V3 represents one of the most significant shifts in the extensions platform since it launched a decade ago. Manifest V3 extensions enjoy enhancements in security, privacy, and performance...
https://developer.chrome.com/docs/extensions/mv3/intro/
Web developers (see uBlock origin for one) have been complaining that Manifest v3 breaks chrome extensions for no discernible benefit and Manifests v3 exists entirely to protect Google's ad business. This review gives fresh evidence to support that assertion and showcases Google's deception. As seen in this blog post, extensions can request literally every permission and the user permission warning actively hides the permissions beyond the content fold.These changes haven't been made for security's sake.
I wish the entire Manifest v3 was scrapped, but that likely won't happen. I'll settle for people assuming Google is lying by default.
I'm pretty sure the point of making a declarative content blocking API for adblockers is not to block all possible ways of writing a malware extension. It is just to make the most popular category of extensions safe by design. Once that has been done, it's then much easier to improve the situation with the remaining niche use cases.
What would those improvements look like? It could be finding other common ways of dangerous permissions being used by legit extensions, and extracting these patterns out as explicit and safe capabilities. It could be changing the messaging to make it easier for users to understand how dangerous the requested permission is (which they can't reasonably do while those dangerous permissions are still used by adblockers!). Or it could be a stricter review process for any extensions needing such permissions.
This extension that the author themselves think would never pass review doesn't really rebut that in any way.
Edit: Removing just OnBeforeRequest() js injection does sort of uniquely harm mostly heuristic ad blocking and things like tampermonkey. It's not hard to feel like that was probably the real goal.
Very secure, indeed! But at least those pesky adblocks are defeated.
How can I even be confident beyond reasonable doubt that the uBlock Origin extension I have installed won't suddenly start exfiltrating any passwords I enter on websites, for example.
You can't, just like you can't be confident that any other piece of software on your computer won't start doing it. This problem isn't specific to extensions in any way and I don't understand why people act like it is. If the risks are too much for you, don't install them, just like you wouldn't install any other software you don't trust. Don't try to ruin it for other people who understand and are willing to take the risk.
Keywords are "beyond reasonable doubt".
uBO is a Recommended Extension, and even has a badge that says it's only granted to extensions that meet their standards of security.
But do we know if Firefox manually reviews updates as well, for changes in their source code? Or do they only review them once (at the moment where they grant that badge)?
I can't find conclusive info on that front.
I would be happy to know that a few extensions get their updates manually reviewed.
I can't be bothered doing that, but then I'm willing to take the maintainer at their word when they say their software doesn't just have a Free license, but also respects my freedoms. https://github.com/gorhill/uBlock/wiki/Can-you-trust-uBlock-...
In the case of your example, I think gorhill is a prime example of a trustworthy author. He has a very good track record, never betrayed the users, explains his thought process and behaved consistently in the users (my) interest in the past. uBlock Origin is the one extension I trust the most, even more than say the Multi Container extension from Mozilla.
If someone were to add an extention with this manifest, would it even be reviewed, or would it need to be flagged first?
In response to the article itself: you might even be able to get such an extension on the Firefox Extensions store and just maybe get a "Recommended" status too. Refer to my comment in another post from a few days ago for other such current violations: https://news.ycombinator.com/item?id=34832280
Anyone knows what is the actual legitimate use case for this API ? Seems very dangerous to allow extensions access to it.
