Browser extensions are underrated: the promise of hackable software
geoffreylitt.com
geoffreylitt.com
No, it hasn't. Almost every single extension I install tells me some variant of "This extension can intercept and modify all of your browsing traffic". That's not "well balanced", it's completely broken. This is happening clearly for extensions by well intentioned people that do not need those permissions. I can't help but cynically interpret the current situation as intentional on Google's part because having the security model be "trust Google to vet the extensions" happens to centralise all the power with them. If you can't trust an extension from the wild then they might as well not exist, right?
People laughed Java out of the browser because it took 500ms to start, but at least it had an actual security model.
Extensions should be able to have their permissions limited by domain (e.g. to customize YouTube or Reddit) at a minimum.
And I'd also really like a way to track both injected scripts and elements so that they wouldn't be able to make any HTTP requests without additional permissions, not even an <img src="..."> tag if the src isn't just a data URL or local extension resource.
E.g. I want to be able to install an extension that stops YouTube videos from playing as soon as I navigate to the page, without worrying my entire browsing history or worse is being sent to a third-party.
Does Chrome not support this? One more reason not to use it.
The non-reddit domains are for expando capability.
This seems like a good idea until you realize that the behavior you might want to modify is coming from a different domain loaded by the page and you have no control over how they set that up.
They already can: extension authors can specify that their extension only operates on specific URL's.
The problem is that most extensions are designed to work on all web sites, so you have to choose between security and convenience.
Most users pick the latter and trust the former.
This model works pretty well overall since harmful extensions never take long before getting flagged by the community.
No, this model works pretty well for stealthy extensions which take malicious actions without getting detected.
This would break adblockers, which are by far the most commonly used extensions
Java applet loading felt like 30 seconds of staring at a gray reactangle while your entire browser ui locks up, sometimes ending in "applet uninited"
Flash game loading was just a few seconds of a black rectangle, browser ui did not lock up, then custom loader, and it usually worked.
Isn't the situation the same with Mozilla? I thought that the reason was that most extensions do, in fact, need to be able to view and modify all your web browsing traffic. For example, my essential addons are uBlock origin, uMatrix, and Tree Tabs. Clearly the first needs to modify web pages, the second needs to intercept traffic, and the last needs the entire list of web pages I have open.
Can you give an example of an extension which requires permissions it shouldn't need?
Whether it should be done in a more finely grained way, not sure, but if you have the permissions to modify then by definition you have the permission to remove or add content.
That's an unfair comparison. Any piece of software could try and 0day you. The point is that in a permission-based system, the permissions for browser extensions are in practice far too permissive to the point of being broken.
>You can't blindly trust anything "from the wild" yet you can't really live without it.
The point about permissions is to provide granularity to trust. I may trust an app to use my camera without trusting it to track my location in the background.
>Every app can abuse its permissions and track you/upload your photos/eavesdrop on your conversations.
This is the best comparison - mobile phone permissions - and on this front browser extensions are far worse. The majority of every single extension I install wants complete control to everything. In contrast, most apps only require a few things as appropriate. Yes, there are those flashlight apps which require _every_ permission, and those are basically the standard of extensions.
It should be added that UXSS (basically a malicious extension) is basically an RCE in the browser which in some cases is more beneficial than a full RCE, e.g. easier to steal banking creds.
In my younger years, I used to crack and hack software just for fun. Those were my Softice years. Later, when Opera was not Chromium based, I also had several site customisations, since it was very easy to add my own JS and CSS to any web site.
Nowadays, I have 4 extensions created and tailored for my needs. One that deals with cookies (mostly "delete everything" outside of my white list) and three that add functionalities to specific sites (automating, managing lists, hiding or highlighting content, etc). Building them was fun, though not as much fun as playing against "copy protections" long ago: like going from competitive chess to creative DIY.
The only pain with custom made extensions is that Firefox is very reluctant to load them. I don't want to upload them them on some Mozilla server, so I have to enter some cryptic "about:..." URL, then click and navigate to my extension, for every extension at every browser start. This is one of the main reasons I'm using more Vivaldi than Firefox these past months.
But, when Google tried to implement an ad blocking architecture that wouldn’t allow third parties access to your browsing history similar to that of Safari, geeks were up in arms.
I’m not going to defend Google’s overall business practices, but from what I understand, it’s the same type of architecture that Apple has had for four years and no one said Apple’s intentions were nefarious.
I am also a developer. I would like to continue to have the right to code such extensions for myself.
A personal computer has always been very complicated and using it has always been a risk in itself. I remember a time when a virus could damage the computer's hardware, and someone who knew how to program in BASIC (edit: or LOGO) was not considered as a "minority".
My point of view is that we need to make users aware of the risks and make them more responsible because things will not get any easier.
No need to optimize, I switched to Firefox, the browser for the minorities ;). I really liked Chrome though.
How has that been working for the last 30 years? Why would it start now?
Computers have been mainstream consumer appliances since the “multimedia PCs” were a thing in the mid 90s. Most people no more want to program computers than they want to fix their own cars.
There is arms race and you want adblockers (good guys) to give up any improvements in perpetuity, that is a recipe for losing.
Me installing uBlock for parents has improved their browser experience and security. I'd rather risk uBlock being compromised and having to phone them to uninstall it than have them being at the mercy of adtech, spyware, and scammers companies in 5 years.
So, no -- Google's method is not sufficient.
I think a lot of people would say that Google is a pretty evil company in many respects, whereas Apple isn't exactly 100% saintly, but at least their profit and business goals align more closely with what is generally considered to be good for customers.
So now, when safari comes in with these changes that only add value compared to their previous offering (which again was substantially behind the competitors), users respond positively because the only users that remain don't know the difference between blocking the rendering of an ad and blocking the request to the ad server. So, when they hear "Ads are blocked", they don't understand the nuances that reveal to you that ads are not really blocked at all from a privacy perspective.
The reason Chrome didn't have a similar response is because the people who cared about these changes were already using chrome. So, when chrome announced an update that removes these privacy-protecting features, the users were knowledgeable enough to realize what the changes actually meant from a privacy perspective, and so responded poorly.
And even if the users were the same, safari added a feature (you can now kind of block ads in safari, compared to the zero adblocking you could do before), whereas chrome is removing a feature (you can no longer block requests to ad servers, something you could do for years). So of course the reaction to safari will be at worst lukewarm, because compared to the previous editions of safari it was an improvement.
But speaking of “closed”, where is the ad blocking extension for Chrome on Android and embedded web views?
The proposed change that would have made ad blocking impossible still allowed non blocking request interception, it would have absolutely 0 impact on people trying to sell your browsing data via an extension, and a huge net increase in people selling your browsing data by people selling your browsing data by website embedded trackers.
We already see what happens when users download extensions and toolbars willy nilly.
If you want the computer to be "bicycle for the mind", you want to reduce friction so that "advanced" use isn't really "advanced", but normal. See also Hypercard, or how people use Excel in offices, or secretaries that extended Emacs because they didn't know writing Lisp was "programming", or countless other stories of end-user improvements.
If you want the computer to be a digital television set, or a digital collection of appliances, then sure - let's lock everything down, so that you can only do what you're allowed to by the vendors, and only through means allowed by the vendors. This is the scenario in which you want to add friction to end-user "advanced" use.
> How is the browser suppose to know whether the user wrote the extension or downloaded it from the internet?
It cannot be done in general - if a user can do something manually, a sophisticated piece of malware running outside of the browser can simulate too. But I think there's ways to add warnings without increasing friction. Having to manually re-enable each and every user-created extension on browser restart is IMO way too much friction. Being shown a warning about those extensions on each browser restart, but keeping them running sounds more reasonable.
Yes, I agree that having to re-enable extensions every time is too much, but going through contortions once isn’t.
Why optimize for the 1% instead of the 99%?
That being said, it's entirely possible that I'm overestimating the intelligence of the average user and that many of them wouldn't blink even in the face of a warning made up to look scary.
Typically, when Mozilla finds out about software installing extensions without user consent, the extension is added to the blocklist, but if the extension is unsigned it can just claim that it is ublock origin or adblock plus or some popular extension, leaving no practical way to block it.
This is described in greater detail at https://blog.mozilla.org/addons/2015/04/15/the-case-for-exte...
(in full disclosure, I am a Mozilla employee)
I do wish the requirements around signing were less stringent, but I'm fine using Dev Edition as a daily driver for now.
[0]: https://support.mozilla.org/en-US/kb/add-on-signing-in-firef...
At the absolute least, Mozilla should make Unbranded auto-update.
In other words, there is presumably a reason the release channel exists. As long as it does, the desire to use the release version alongside unsigned extensions is reasonable, and there should be a supported pathway.
Even that would have taken multiple thirdparty extensions to accomplish - and probably would have required giving very broad permissions to them. Worth noting that Stylish, one of the extensions I might have used, was compromised with spyware a few years ago.
As for publishing, I don't publish mine because it forms a kind of personal fingerprint. The more I add to it the more personal it gets. I rather support the idea of everyone having their own custom extension. You can really improve your online quality of life and with the WebExtension API it's pretty painless.
I use Stylus to add custom CSS to sites and Violentmonkey (https://violentmonkey.github.io/) to add custom JS. They both make it fairly easy to start writing code for a new site. However, there is no easy way to set up both custom CSS and custom JS for a single site – a custom browser extension like you made could potentially support that better.
Pros of TamperMonkey/userJS:
- Allows live editing (with syntax highlighting) with immediate refresh, all in the browser. This is handy for minor changes on small files, but slow for big files.
- Direct access to some HTML5 APIs that are restricted in extensions. I don't recall if that was the case with TamperMonkey, but OperaJS allowed plain AJAX and WebStorage usage, just as if the file was included in the web page.
Cons:
- Slower than extensions.
- Less powerful (cannot add a button in a browser bar, etc)
- Painful as code grows. An extension allows simple splitting of code into several files. I found UserJS harder to maintain.
- Cannot load JS _and CSS_ like an extension does. Another extension like Stylus is needed.
Obviously that's no help if you want to distribute the extension (we have to jump through hoops at our organization to push out a manifest) but for personal use I find it to be a good workaround.
That sounds a lot like the "Cookie AutoDelete" FF extension.
- One would switch to an existing tab with the same URL, instead of opening a duplicate. This made it easier to click URLs in error/debug messages without making the browser unmanageable (IIRC this was just a copy/paste of someone else's extension, which didn't work without me fiddling it)
- One would add keybindings to the output of Drupal integration tests. These tests would say things like 'visit X', 'click the Y button', 'enter Z in the form', etc. and would save each page, so if a test failed each step could be viewed in a browser. The only problem was this is tedious, so I made an extension which bound the left/right cursor keys to stepping through these pages. Made it much easier to skip through the setup and get to the bug (e.g. adding items to cart, when the problem is in checkout).
Unfortunately, the big mobile browsers do not support extensions, which is a huge blow to accessibility. I think Firefox for Android is the only mainstream-ish browser that supports extensions. Apple prevents them from doing the same on iOS because it would be considered "an app store within an app", which is forbidden.
The only thing Apple allows is action and share extensions, which have to be manually activated on every single page (2-3 taps to do so — which is super user-unfriendly, esp. for PWD). It's great that Apple does a lot for accessibility in general, but I really wish they would open things up a bit more so that users could customize the iOS experience to make it more accessible.
As a dev, I would be more than happy to have my code scrutinized even further in order to ensure that what we're doing doesn't create security, privacy, or performance issues. We'd just like to make our accessibility software as useful for folks on mobile as it is on desktop!
Take the example of the Android ecosystem: If plugins were allowed for apps, pretty sure there'd be a better story around privacy today. An astonishing 40% of connections from an Oppo/Vivo or Xiaomi phones are to ad networks and trackers. And there's nothing you could do (without root) except to firewall it (apps have started working around pi-hole esque setups). XposedMod has brought plugin based development to Android [2], but it is niche and requires not just root, but replacing key framework components. Using it might still be worth it, though, given the relentlessness of OEMs and carriers.
And that's just sad.
[0] One way to tackle the problem of developers selling away rights to their extensions is to legally make it binding to publicly declare whenever ownership changes hands. Disable extensions across all installs, and let the users enable after the fact is made obvious to them.
[1] https://www.eff.org/deeplinks/2019/06/adversarial-interopera...
Honest question : Can you expand on how this would work please?
If anything, extensions as in chrome extensions is something I try to avoid as much as possible : giving access to all of my data to a third party extension promising that is going to increase my privacy but that I need to trust 100% with a complete access is less than ideal.
Such a thing is already possible today. Some require root, some require breaking PlayStore's terms of use.
One such example is: XPrivacyLua [0] by the creator of NetGuard. It helps fake location data, hide contacts and calendar, fake device-id, IMEI, MAC addresses etc on a per-app basis.
Another example is how VPN in Android [1][2] is widely used to block trackers and ads.
A third example would be how the accessibility service APIs are (ab)used to temporary grant permissions to apps [3].
A fourth would be reversing engineering tools like Frida [4] that help with inspecting apps, and even change their behaviour.
A fifth is repackaging APKs with advertisement and tracking code removed, like with YouTube [5].
I am attempting to build an app with most of these features combined in to one, lets see how far I get. My aim is probably to build something as close as possible to uMatrix/uBlockOrigin but without requiring root.
---
[0] https://github.com/M66B/XPrivacyLua/blob/master/README.md
[1] https://github.com/M66B/NetGuard
[2] https://github.com/blokadaorg/blokada
[3] Sam Ruston's Bouncer app: https://samruston.co.uk/
[4] https://securitygrind.com/bypassing-android-ssl-pinning-with...
[0] https://code.tutsplus.com/tutorials/quick-tip-theme-android-... [1] https://developer.sony.com/posts/sony-contributes-runtime-re...
Repackaging, leveraging a security flaw to use xposed, etc, all of these add more vectors that can compromise your data.
You need to have complete trust in the person that wrote these, way more trust than just in the creators of an app that can just use the permissions you give them :/
There are many intrusive permissions that already are major privacy and security risks-- Launchers, SMS apps, VPNs, and even alarm clocks that mine location data. The playing ground isn't level, right now, to counter this intrusion.
One way to affect what other apps do, without root, is to route the traffic via VPN and firewall as appropriate. That's possible only when a user enables a VPN to do so. Similarly, the plugins could also require a user to explicitly grant or deny permission for them to work. This is enough of a security measure as its on par with the current system in Android (regardless of its notoriety).
> None of these answer my question though.
May be I understood you wrong. I hope I made my point clear to you above?
Chrome for example has a ton of limitations:
https://getpolarized.io/2019/04/05/Google-Will-Kill-Chrome-E...
If you want to do anything significant you have to get their 'permission' and at that point they throttle your extension release updates.
You can't just push an update immediately that gets sent out. They take a week to approve your extension.
This might sound reasonable until you realize that a week is an eternity for a continuous development shop. That might as well be a year.
ESPECIALLY if something is broken.
Imagine if you had a bug that destroys data and you need to rush out a fix. Nope.. You need to wait one week for that to go out.
They state that the extension update is under compliance review, which may take several business days, though the similar approval times indicate that this is actually an arbitrary publishing delay, and that no human review takes place in all cases, otherwise there would be more variation between approval times.
I'm suspicious that they might be doing this for other reasons more likely to punish people for more aggressive permissions.
ESPECIALLY if something is broken."
I get what you are saying, but this is more of an artifact of people being used to unregulated platform as a service and the - being blunt here - terrible quality practices that are rampant there. If a week is an "eternity" then try internally iterating a few times and shore up that test coverage if that extremely mild release cadence constraint is more than you can bear. Browser extensions are risk in security, authenticity of content, a new avenue for phishing (look alikes in low volume/poorly curated areas), and browser stability.
It isn't Chrome's fault if someone pushes a bug that destroys data, it's the development teams fault. There responsibility is the the user of Chrome.
While async review is better than no review, if someone pushed a malicious update and it got caught in the async review a few days later, the damage has already been done. Just a trade-off to think about.
As long as you have that, you can pretty much do whatever you like to the devs as long as you don't piss off the users
That'd show Apple.
Not so long ago, people distributed software on physical media. Time to update was counted in months to years. This had a nice side benefit of people not being able to "test in production"; software either worked mostly well, or it didn't sell. That wasn't a bad thing, because it forced companies to do actual QA - something that today is increasingly being pawned off to end-users, with help of deeply invasive telemetry.
That exact article you linked was posted to HN a few months back. I remember someone dug into it and found the permissions it requested. The full list was rather broad and as a result the extension could have basically hijacked the entire browsing experience. A malicious extension with those permissions would have been a potential goldmine. I think it is perfectly reasonable for Google to want to review extensions like that.
Compared to native apps, I think browser extension based apps reduce a lot of headaches for developers and users.
The Chrome store lets you take payments but it's not very flexible and it's tied to Chrome.
I wouldn't be surprised if Google killed Chrome store payments in the future as well - I pretty much never hear mentions or updates about it. I wouldn't want to lose all my subscribers if that happened.
No wonder the half of the companys in this world run on excel.
It's a thought I keep repeating that is probably worth expanding into an article - modern software eschews interoperability, and in particular, SaaS is based on preventing interoperability. What used to be a desktop application operating on an independent source of data (filesystem) now vacuums the data and offers it back over an official interface and an extremely limited and locked-down API.
Wrt. those APIs, note that what just a decade ago on desktop was considered normal interop, nowadays often requires the interoperating parties to sign contracts, adding a legal dimension that further shuts out end users.
Am I wrong?
yeah? they are tangential goals but that's the problem. in moving away from browser extensions to webextensions you have a completely diverging codebase that's almost impossible to keep patched because the architecture is fundamentally incompatible and the patches will not be able to be applied in all but the most trivial of cases.
The threat is absolutely real. Bad actors regularly offer large paydays to lone developers with popular extensions so they can roll out an update that quietly adds a backdoor.
There's at least some publicly documented evidence that Raymond Hill (uBlock Origin) isn't likely to cave to this sort of pressure, but do you really believe that none of the other authors of your fifteen favorite extensions would look the other way for $100k?
Keep in mind that these offers don't look like "Here's some money, please let us roll out an evil update to your extension." They look like "Our company has a product with a similar name. We love your extension and would like to offer to acquire it from you so that we can use the name. We'll even let you keep the rights to your software so that you can re-release it under a different name if you'd like!" They'll make it really easy for the developer to remain in denial about what they're actually facilitating.
Another problem is that requesting a new permission in an extension update has extremely bad UX, to the point that any thoughtful extension developer will just ask for everything they could possibly need up front. If you request a new permission Chrome just silently shuts off your extension until the user goes digging around in the UI for the permission request. The last time I tried this about 5% of my users figured it out and the rest thought it was broken.
I get messages like this every now and then for mobile apps and browser extensions I manage and they're painfully obvious to spot.
They're often from sketchy looking generic email addresses, have no information about the buying company, don't even attempt to demonstrate knowledge of the app, and most importantly mention nothing about how they plan to grow the app.
It's always just "would you like to sell?" and "how many users do you have?".
A recent one:
> From: *@gmail.com
> My name is John.
> I have noticed your google extension "https://checkbot.io/ Checkbot: SEO, Web Speed & Security Tester ", its looks interesting would you considering to sell it?
> Best regards
I've had more elaborate ones but they're always generic with no obvious business interest in the specific app they're asking to buy.
Most extension developers are not getting any significant income from their work, despite serving millions of users, and unless browser vendors will begin to recognize the value of that labor and provide better tools for sponsoring developers, we will continue to be vulnerable to such offers.
Any ideas what specifically could be done to help? You can integrate your own payment systems into extensions and there's some ad vendors that support browser extensions.
A great example for how Mozilla is deprioritizing contributions for extension developers is the new design of Firefox Add-ons. The contribution button was pushed down below the fold. Previously it was at a very prominent place next to the install button, and several modes for requesting contributions before or after installation have been deprecated.
Yes, adding a donation button to your extension is a possibility, but it would send a whole different signal if Mozilla would encourage users to support developers, from a unified and trusted user interface, and experiment with better ways to ensure that users are aware of support options for their favourite extensions.
Mozilla directly supporting extensions which they consider to be of great value could also be explored.
The money doesn't have to come directly from the users.
It's uBlock Origin because the uBlock name itself got taken over by swindlers. So even well-intentioned actors aren't immune to this kind of abuse.
at least extensions exist within an ecosystem where they are subject to manual review and approval / removal. and in terms of updates, any changes to the permissions show a prompt to the user as though they were newly installed
To first order, there is no permissions model for browser extensions. You should assume that an extension can see and do everything that your browser can see and do.
This is also a huge problem with mobile apps, but the problem is at least acknowledged, and there's some degree of permissions and sandboxing, even though it's not completely effective, and even though most apps ask for every single permission anyway. But in general, yes, you should take a similar approach to mobile apps, and only use the minimal set that you absolutely can't live without. Don't install games or stupid shit. We already know that basically every weather app on Android contains malware.
This is also a problem in free-for-all developer library ecosystems like npm, as we keep seeing. Popular dependencies get taken over or sold and then all of a sudden lots of servers are running malware.
Software may be eating the world, but it's really important to know what software you're actually running. You can't just build a house of cards and hope for the best.
Hell I already saved a whole day of fuckery by being immune to Mozilla's "disable all extensions everywhere by having the certificates expertise of a four year old" screw-up.
I think he might not be willing to engage with this further, because extensions sit close to the border defined by the minimum of "security + usability"[0]. Making extensions more secure eats into their usability; to resolve all the security issues, you'd have to kill extensions altogether.
> Bad actors regularly offer large paydays to lone developers with popular extensions so they can roll out an update that quietly adds a backdoor.
I don't think there is a way to avoid that. It boils down to the rule that security is measured in dollars - the ultimate attack is bribing the controlling party; the ultimate defense, making it not worth it for the controlling party to sell out for any amount of money the attacker could assemble.
--
[0] - I.e. after accounting for obvious wins-wins, you reach a situation where security is opposite to usability. Once you're there, it becomes a trade-off.
You can turn off automatic updates on an extension-by-extension basis.
I just noticed Xlambda which was featured very recently on HN: https://news.ycombinator.com/item?id=20316920 I wonder if there is compositor I could talk to as well... compton doesn't do the kinds of things I want to do...
Do you mean to say that extensions do nothing?
I agree that extensions do need to be adequately audited more, though Firefox does audit every browser extension they offer through their store. Safari similarly does, and Chrome just needs to catch up.
I understand the broader extension security situation is pretty atrocious, but I like to think there's some small improvement from url-limited extensions like mine (that would otherwise exist as scripts that ask for plaintext credentials).
So, autofill, autotranslate, HTML-only mode in gmail, (?), literally just bookmark it, any html5 video player, and of course, block ads (which most browsers seem to be moving to do by default). These are all either offered by the browser by default, or will be (though firefox seems more interested in adblocking than chrome right now).
Obviously they may not do it the same, but as someone who is suggesting addons offer a lot of power, the writer is not actually using most of that power. I kind of agree with browser developers that more often than not, extensions just offer a new vector for malware and no one really understands what power they have so they make bad choices.
I primarily built it for myself but maybe some of you folks might find it useful too https://chrome.google.com/webstore/detail/refined-twitter-li...
It is open source of course https://github.com/giuseppeg/refined-twitter-lite
It's a reminder that the websites you make don't just go into a black box, they have to co-exist with individual user preferences/needs.
I think that risking this by updating manually is more acceptable than getting the mallicious code directly auto-installed as soon as it's released by the attacker no matter what you do.
Also, most of my extensions are not 3rd party code and I want them to have full access.
For the rest I update them once in a while and go check
~/.mozilla/**/*.xpi
find -maxdepth 1 -mindepth 1 -type d ! -name .git -print0 | xargs -0r rm -rf
for f in ../extensions/*.xpi ; do
unzip "$f" -d "$(basename "${f%.xpi}")"
done
git add -Af .
git commit -m "Changes"I can already make webpages.