Let's build a Chrome extension that steals as much data as possible
mattfrisbie.substack.com
mattfrisbie.substack.com
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>
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.
Furthermore, Chromium is free software, Chrome isn't. Perhaps Google should be liable for distributing Chrome in such a sorry state, but not for what lands in Chromium.
And why does it being a monopoly matter in this context? Not to mention that it isn't a monopoly.
You market them as iButter knives. They are actually carving knives. Half of the users are 14 years old.
You give the knives away for free, but the knives steal 1% of any food they cut.
Sometimes butter knife needs an software update in the middle of cooking.
If you sharpen the knives you lose warranty. Company says you should buy a new one regularly.
They come with a bug, when iButter knife is used on Cheese, they spontaneously transform into chainsaws.
The company says it's not a real problem because using iButter knife on anything else is against EULA
Suppose developers of smart locks make an error, and all smartslock unlock on Fridays. When users ask the Company, they lie and claim their locks are flawless and users are to blame.
Millions of houses are robbed, people loose their life possesions, and home robbers kill some grandma.
Should the Grandma's family get just a $100 refund (price of the lock)?
> There's basically no way you could extract money protected by Googles lawyers army
That's defeatist. If thats true, then this whole discussion is pointless.
If there are 'nobles' that don't answer to justice, we live in feudalism. Freedom and capitalism are dead.
Stick to the actual situation wherever possible.
https://en.m.wikipedia.org/wiki/British_Post_Office_scandal
I think it should be obvious that a poorly designed product can do much more damage than it costs, both through stolen data and by causing legal action
As software intrudes into physical world, the potential for damage will keep growing.
There are of course escape hatches, because sometimes you want apps to interact.
2. Desktop platforms do not universally sandbox applications (though they are trying). You can install a desktop app that steals all the data in your home directory, including your entire browsing history, with no permission dialog whatsoever.
3. That aside, browsers sandbox extensions just like mobile applications. One extension cannot access another extension's data.
4. Furthermore, by default, a browser extension can only access content from its own origin. It is in fact sandboxed from the rest of the sites you visit.
5. If the user grants permission, a browser extension may access other sites.
So in short, browser extensions are in fact sandboxed.
And your idea of mobile apps accessing data is entirely dependent on the qualifier "when they shouldn't", which, arguably if given permission, they should so it's a moot point.
The vast majority of extensions require the ability to read and modify the dom on any website to do anything. This is so much worse than the average app permissions.
If $GOOG can't do it with practically infinite resources then I'm of the opinion that nobody can. Computing is broken.
Edit: @dogecoinbase: What you propose is a shallow and dismissive analysis of the oversimplicative variety. Please put in a little more effort before derailing an otherwise thoughtful conversation.
I'm genuinely curious how much Google spends on their privacy org, and esp. how that compares with the other big tech companies.
No other company I can think of has invested in such a rigorous Privacy review and support structure in an attempt to reduce risk. Other BigCorps do take it seriously, but get by with much less investment. Despite this, FB et. al. are keen to poach Google Privacy employees, because there are very few Privacy Engineer in existence and Big-G pioneered modern day corporate privacy efforts. Google is a huge target for hacking and public criticism or even loss of human life due to product decisions, especially because the products are so ubiquitous and widespread (browser, mobile OS, search engine, Gmail, ad network, etc). See subjects such as Differential Privacy.
Source: I have a few friends who've worked in the G-Privacy org.
> They are the arbiters who can to block a production releases if privacy and security issues are discovered and not remedied.
Every company I’ve worked at outside of tiny startups has had this level of gating by the security team.
> No other company I can think of has invested in such a rigorous Privacy review and support structure in an attempt to reduce risk.
Which companies have you worked at in the last 8 or so years? It sounds like you’ve just watched the industry mature a bit in PII from the perspective of the inside of Google.
In recent court cases Google employees admitted they have no idea where user data is stored (specifically location data), which systems have access to it, and how to fully turn tracking off.
80-90% of Google's revenue comes from online ads. There's a huge conflict of interest between Google's business model and whatever "arbiters" pretend they want to block.
And of course the number of privacy things that Google pioneered is minuscule to non-existent. Google has been dragged into caring about privacy against its will, kicking and screaming, by government actions like GDPR and CCPA.
Facebook poaches Google's privacy people because Facebook is the only one of mega corps who are worse than Google, and wants to continue its practices as much as Google.
Really? Do you happen to have a source for that?
Edit: a better article https://www.businessinsider.com/unredacted-google-lawsuit-do...
Short quote:
--- start quote ---
Jack Menzel, a former vice president overseeing Google Maps, admitted during a deposition that the only way Google wouldn't be able to figure out a user's home and work locations is if that person intentionally threw Google off the trail by setting their home and work addresses as some other random locations.
Jen Chai, a Google senior product manager in charge of location services, didn't know how the company's complex web of privacy settings interacted with each other, according to the documents.
--- end quote ---
The first is not anyone "admitting" anything in a "court case". Nor does it discuss "where user data is stored" or "what systems have access to it". It is quotes from an email discussion on some article, about the behavior of a UI toggle, with no indication that these are people working on that system who would be expected to know where data is stored but don't.
In the second link you've at least got a deposition, but how is either of those paraphrases relevant to your claim about "not knowing where user data is stored" or "what systems have access to it"?
There were a few over the years. If I can find one, I will update you with the link.
Meanwhile Google has settled for $85 million in this case https://eu.usatoday.com/story/money/2022/10/05/google-arizon... A whooping 0.6% of their profir for 2022
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.
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.)
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?
Pretty much all of them except Mac.
Can speak personally for KDE, Sway, GNOME, and Windows 10.
And when they are invisible, they usually show up on mouse motion/window interaction, so it's still not as egregious.
Shout out to Xfce for being so boring/consistent for more than a decade.
iOS is way more prevalent and has hidden scroll bars unless scrolling. Thanks Apple.
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.
Eight person startup? Sure. But not these folk who "only hire the best"
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.
> apple sucks and is the reason for all evil because scroll bars
we dont have scroll bars on mobile as in days of yore. maybe browsers need to finish playing catchup to the threat and interaction models. having a vm on your machine with access to everything you do without sandbox is pretty bad
The air travel industry uses the Swiss cheese security model.
EVERYONE does what they can to improve security. The equivalent would be both Google and Apple making improvements.
Both of the problems might be leveraged in a future attack. Fix along the whole chain of events, not just break it - defense in depth.
Most Macs ship with a trackpad, which means I can’t remember when I last deliberately gripped a scroll bar. They are just a waste of space most of the time, even as an affordance/reminder that scrolling is possible.
I stand by the original argument that for most people, a minor twitch of their fingers on the trackpad reveals this information if they want it. I very rarely do want this though, and on average I prefer that it's not shown by default, or until I move.
This discussion was prompted by a UI fail in presenting relevant security information. Relying on permanent scroll bars would still be a UX fail, even if it were the default on Macs.
Today I was again reminded that many years ago some UX designer thought it would be a great idea to remove back/forward buttons from the context menu in Firefox if I accidentally select some text on a page I visit.
No one was asked and when someone filed a bug it was ignored because ux designers had already decided.
Result:
- a few times every month back/ forward buttons are missing
- the look and feel of the context menu changes for no good reason
https://superuser.com/questions/1074338/disable-back-in-chro...
But we are only "users", even if each if us converted 10 or more IE6 users and bothered IT departments to allow Firefox, web sites to write for web standards and not IE etc etc.
When they ask for money, we are "valued community members". When we have a question we are just annoying "users" it seems.
And the worst part: if you donate to Mozilla it doesn't go to Firefox. It goes to some other project.
Because Firefox is a profit center for Mozilla and they are milking it dry year after year and our donations comes on top of that.
Still I use Firefox. It is still better for my purposes (large hierarchies of related pages that lives from hours to weeks).
And it is not like using Google Chrome would improve the situation.
But lately (maybe the last twelve months?) I have started to use LibreWolf too. I use it as my research browser while using Firefox for all logged in work. It feels good, like using Firefox back in the days.
And if I can work against both Mozilla and Google simultaneously, maybe I should cut Firefox completely :-]
Critiques of Apple from people that have this sort of wide-ranging vitriolic hate for Apple are a dime a dozen, and don’t make for any sort of interesting or enjoyable conversation.
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.
Users _should_ understand what an extension having access to this stuff implies, and if that means they only use "official" extensions or stop using them that's fine.
Also "clicking stuff is a lot of work for users" made me laugh a little. How many damn cookie consent buttons do users have to click every day? An extension should be orders of magnitude more "work" to allow than that.
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!
Still a bad idea though.
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?
Undoubtedly the stupidest UI decision made in the last 20 years.
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.
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
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...
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.
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.
Even though he didn't take responsibility I walk away convinced that he's doing a good enough job.
Well, the OP's tone was flippant, and I thought it was dismissive. Who cares how thankless the job is -- it is your job. Stop blaming it on the users for wanting things and fix the problem and stop making excuses and acting put out.
> whereas the paragraphs you have labeled as "irrelevant" sound extremely relevant. Why don't you use a few words to explain why you think that paragraph is irrelevant?
It is irrelevant because the issue exists now. Who cares what they accounted for 8 years ago, and who cares what their competitor does?
P1: My lock opens with any key. It should only open with my key.
P2: But the competitor's lock opens without a key!
P1: I don't care? Fix it.
> Even though he didn't take responsibility I walk away convinced that he's doing a good enough job.
You should raise your standards.
1. I agree the bug should be fixed.
2. I don't work on Chrome anymore and have not for 8 years. I should have made that more clear.
3. I was responding to the claim: 'the entire chain of people working on this has been asleep at the wheel'. OP was assuming this bug has existed forever. I know for a fact it hasn't, because I remember caring about getting this right and implementing custom UI for it. I also listed some other things we improved over status quo at the time, which refute this claim.
4. Based on my knowledge of how this all used to work, it's not as big an issue as the original article and several people in this thread are making it seem, because the review process is really the primary safety check in the system. It needs to be because, as many have noted, most users don't read the dialog. Extensions are required to have a single purpose and extraneous permissions aren't allowed. And if an extension with a large number of permissions was approved, extensions (and updates) are reviewed both with automated and manual processes, and it would be difficult to get a malicious extension through the process or to get large numbers of users on it.
I still agree the bug should be fixed. We cared a lot about getting this UI right when we originally implemented it, and it's unfortunate that it regressed.
> Irrelevant
No, it is directly relevant. He is responding to someone who said that this problem with the permissions UI goes all the way back to the everyone who was involved from the very beginning.
He is one of those people who were involved at the beginning and is pointing out that they did not have that problem back then.
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?
Edit:
I didn’t go through manual process but based on this (rather recent) Adblock guide [1] it’s not very hard.
Of course one could argue that “developer mode” is deterrent enough but - as for contrast - in order to get state mandated esignature to work I had to install some sketchy 3rd party system extensions on MacOS. On Windows it almost felt like malware (as some of the security settings had to be disabled in order for Java installers to run).
My point is - sure Chrome might have secure golden path but people are lured into skipping a lot for freebies/weird requirements and thus permission dialogue should be more informative.
[1]: https://helpcenter.getadblock.com/hc/en-us/articles/97385388...
Chrome is unfortunately limited here by the security of the OS. No popular desktop OSes have application isolation: all apps have the same permissions. Any app can write to any other apps' storage.
This means that if Chrome makes sideloading too difficult, developers will just tell users to run their native code which will hack into Chrome, making even understanding what extensions users have or uninstalling them impossible. Sideloading on desktop OSes has to be hard enough to discourage most users but easy enough that developers like adblock don't start looking for an even bigger hammer.
This is what I meant by delicate balance of incentives.
More info here: https://news.ycombinator.com/item?id=4954915
Thus, it should be easy to classify and make that specific dialog more visible - especially when side-loading.
I think it definitely is hard job to reach consensus on all the fronts.
It's true that as MacOS continues to discourage non-sandboxed software, Chrome can make sideloading more cumbersome to match.
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
I love this idea fwiw. Browser vendors should totally do this. Requiring OSS seems like a fair tradeoff for the power that extensions wield.
> Automatic updates.
In my day, extensions could auto-update but not change permissions. Also all updates had to be reviewed. The bribery issue is serious and sad, but killing updates seems like the wrong tradeoff. Ability to fix and deploy bugs is important for extensions just like any other software.
> Code obfuscation.
Obfuscated code is already disallowed: https://blog.chromium.org/2018/10/trustworthy-chrome-extensi...
> Better observability of interactions
It is already possible to know which extensions are active on a page: https://i.imgur.com/73lmozH.png. This is a better level of observability than what you describe because once an extension has access to a page, there is no way to prevent it from exfiltrating data from that page. The communication with background page is not relevant. There are myriad ways to exfiltrate just given access to normal DOM, unfortunately.
To be precise, I wasn't advocating requiring OSS, just source-availability. Extensions should have at a minimum a visible repository displaying the source code, where users and auditors can publicly comment or leave issues (ideally, which the maintainers can't remove). Chrome should verify that the extension code matches the code in the repo (without an additional build/compile step - the repo should reflect the exact code being shipped in the extension). This way prospective users can inspect the code of an extension without installing the extension first and mucking about in dev tools.
> Ability to fix and deploy bugs is important for extensions just like any other software.
Ability to fix bugs, sure. Ability to deploy bugs (without user consent or knowledge) is an antipattern ;P Third-party browser code should never be shipped to the user without their consent and full transparency into what is being shipped. Users who don't intend to inspect the updates can opt-in to automatic updates, sure.
> Obfuscated code is already disallowed
This is great! Though they distinguish between minification and obfuscation, which is bizarre. Intentionally obfuscated code is hard to detect. I was suggesting they also disallow any form of minification (or at least require extensions to distribute with minified and unminified options, and have minified bundles verified)
> It is already possible to know which extensions are active on a page: https://i.imgur.com/73lmozH.png. This is a better level of observability than what you describe because once an extension has access to a page, there is no way to prevent it from exfiltrating data from that page. The communication with background page is not relevant. There are myriad ways to exfiltrate just given access to normal DOM, unfortunately.
This is true, but even background scripts which don't have access to the DOM can communicate with the content script through sendMessage.
A user looking at the network panel on the page might not see a network request sending their password to a strange server if the message is being sent to the background script and the request is being made from there. All communication in and out of the sandboxed extension environments should be logged and inspectable from any page where the extension contexts are being communicated with.
> Ability to deploy bugs is an antipattern
Disagree then. One doesn't come without the other.
> even background scripts which don't have access to the DOM can communicate with the content script through sendMessage
If by "content script" you mean the web page script, then this is true, but in that case the web page is collaborating with the extension. Whatever the web page is sending to the extension it could just as easily send anywhere on the internet.
>
Content script would be part of the extension that runs in the context of the webpage, and has access to the DOM
Yes, I agree this could be sent anywhere, but when sent to the background script with the sendMessage API, you don't get visibility into that with devtools out of the box
To ensure that the code matches, Chrome servers could download the source code and build the extension themselves. This is what F-Droid does. For each version of the extension, they could also archive the source code they used to build it. Even if the repository gets rewritten or taken down later, the archive remains.
If should be just as easy to inspect extensions as it is for web pages, including all the network requests they have made.
"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."
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.
"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.
Almost entire point of bug bounty programs is to encourage researchers to submit vulnerabilities using a proper channel and adhering to a proper procedure.
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.
There will always be a forked browser or an independent browser that supports/allows extensions as long as the web uses HTTP.
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.
I don't understand why people (read: devs) still assume permissions are read and understood.
The vast majority of people simply do not read nor understand permissions and just instantly hit the OK button. Even Linus from LinusTechTips doesn't read permissions, and he's even a tech guru unlike most people.
The only thing that has permission to read and modify website data on my browsers is my password manager. I trust it. Without that permission it could not operate and provide me immense value. Yes, I would be hosed if it got pwned. It's a calculated risk on my part.
One cannot live in a world where we have the benefits of browser extensions and also disallow all behavior that could ever possibly be used for bad. It's an inconsistent worldview.
This is very disrespectrull.
When you supply exhaustive documentation of your software, how it works, what it does, to users, then you can mock them.
It is not unusual to see stories of malicious applications or extensions with hundreds of thousands of happy users and good reviews.
Ask the not-tech-savvy.
I see it asking for two very scary permissions, two somewhat scary permissions, and one annoying one?
The user isn't giving informed consent, because even if, like you, they are informed about what the worst case is for granting this permission, they have no reasonable knowledge about whether the worst case is likely, even knowing that they've been asked to give permission. The questions are simply too generic for informed consent to be possible. (Mobile apps are getting better here as well, but there's still a long way to go.)
So the permissions aren't actually about managing your risks; they're about managing Google's risks.
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?
Maybe the middle ground is all extensions have a legal entity in your country so you can sue them for spyware.
Or pwned
The same can happen with any piece of software in the world. Why single out extensions?
Regarding extensions code: indeed, I do read the code of extensions that require some elevated permissions, if these extensions are not otherwise vetted. This is why I avoid installing excessively complicated extensions, unless they ask for minor permissions. Having the list of tabs if no big deal; accessing data in your tabs, even for a particular site, triggers scrutiny.
It also makes it easier to deal with it after the fact. You can fork an open source project the minute it's detected that it's doing something it shouldn't. When closed source software goes bad you can't pick right up from the last known good version and move on, you have to find a product that entirely replaces what you had and hope that it does everything you need at least as well which isn't always likely since you were presumably using the other software because it was better than existing alternatives.
As well as almost all regular software is backed by some large company with legal presence to hold responsible. The same can not be said for most extensions.
This is also true of web extensions. I suspect you've never developed one. You can't read another extension's data. It's also not true on desktop platforms. The user is still the security domain in desktop computing.
> As well as almost all regular software is backed by some large company with legal presence to hold responsible. The same can not [sic] be said for most extensions.
Is this true? All the browser extensions I use are published by a real legal entity that can be sued if they are negligent. What corner of the web are you on?
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...
Here's a past example: https://bugs.chromium.org/p/project-zero/issues/detail?id=15...
I have nothing against Grammarly; it's a legitimate company and they seem to respond well to security vulnerabilities, but it still bothers me because a user doesn't think through the potential ramifications of using software that records every keystroke.
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
You can still block those by doing IP-level blocks for known ad domains, but that starts to become a problem if one of those domains are run from a shared cloud host (i.e. Cloudflare etc.) because you will also block legitimate domains.
Most in-app ads and tracking will still use HTTPS so if you use SNI sniffing + certificate validation (to prevent domain fronting) you can still do network level blocks, but that's quite resource intensive, especially at modern internet speeds.
You can still access LUCI openWRT UI if you need advanced features.
If you need a new router, they are a decent choice, better than average performance, no need to flash anything.
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.
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.
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.
Reducing the attack surface has similar benefits for this case. There will be fewer extensions with dangerous permissions around for bad actors to buy, and the the reviews for the remaining legit use cases for those dangerous permissions can be stricter.
If we as outsiders try to reason about that decision, it makes sense to pick the strongest version of those motives, not just strawmen. There's a good security argument to be made, and a silly security argument. If you pick the latter one to argue against, of course it will look like a bad excuse, leaving the more venal explanations as the only possibilities.
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.
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.
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-...
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.