I don't agree with Cory Doctorow on everything, but he was absolutely right back in 2012 that platform owners would converge on the idea that the general public is not to have access to general purpose computers. These pushes for locked-down phones, key escrow, neutered browser extensions, mandatory code signing, remote attestation, and so on are all steps toward this convergence.
Yes, yes, there's an argument to be made about protecting devices against owner tampering keeps users safe. But throughout history, haven't most measures against the public been justified by safety concerns? And haven't we been better off, overall, discarding these measures in favor of personal freedom and responsibility?
The surprising thing is that Firefox does not let you install a non-blessed addon, even if you are downloading it from the developer's website (i.e., not from Mozilla). They don't give you a warning about installing software from un-vetted sources — they straight up don't let you install. I understand this is the case even if you're running the developer version of Firefox, which is obviously not meant for mainstream users.
AFAIK, the only way to install a Firefox addon that has not been blessed is to get your hands on the XPI and install it in debug mode, which means that it automatically uninstalls itself every time you restart your browser.
I would have expected MS Edge, Google Chrome, and Apple Safari to have done something like this before Mozilla Firefox. What happened to the open web?
about:debugging#/runtime/this-firefox
You can install a "Temporary Add-On", which is any add-on/extension you have stored on your local disk[1]. So you can download an extension from a third party, rename the .xpi to a .zip (Firefox extensions are just zip files with a different extension), unzip it, and use the "Load Temporary Add-on" button to point to the manifest.json file in the unzipped extension.Add-ons installed this way will work as though you installed it via normal means, with the caveat that it will not automatically reload when you restart Firefox, it must be added manually again.
I have developed a few extensions, and this is the standard process for testing extensions during development. There is a similar process in Chrome, etc.
1: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
I think that you lose the moral right to curate your app store when you make it impossible for users to switch to alternative app stores.
Curation or no-sideloading: there should be a law that says a company should get to choose only one.
Honest question, why this qualifier? Nobody expects a human to agree with everything another person says.
Is it unfashionable on hn to agree with this Cory guy, whoever he is?
EDIT: For anyone else wondering, he seems to be a writer.
> Honest question, why this qualifier? Nobody expects a human to agree with everything another person says.
These types of disclaimers are anti-intellectual and you should continue to point them out when you see them.
It's sadly not uncommon for malware hosts to acquire extensions and then use them to inject ads to spread their malware.
The Epic Privacy Browser presciently blocked almost all extensions citing those vulnerabilities and its desire to provide a reliably high level of privacy. It's kept its users safe while Chrome, Brave and other browsers' users were vulnerable.
99% of extensions don't need to send the URL anywhere without the user clicking to activate them; nor do they need to send the whole content of the page to a server, ever.
You know how macOS now has a capability-model for apps, where it sometimes says "X wants Y, and it's been denied it; you can go into System Preferences to manually give it Y"? That tends to neatly fix the "99% of apps don't need Y" problem, by increasing the friction to getting Y to the point that users won't generally bother unless the whole point of the app is Y.
I'd love to see that implemented for browser extensions—or, in fact, for individual tuples of {extension, trigger, data, third-party origin}.
In the sane case, that'd look something like: {Instapaper, on click of the extension's button, current tab's URL, instapaper.com}
It'd be pretty clear, just from looking at one of those entries, whether it's something that contributes to the functionality of the extension or not. Extension authors would undoubtedly write "installation instructions" urging users to enable these; but if the instructions say to enable a stanza like {MalwareExt, on page load, sends everything it can, to badserver.info}... well, even the most guileless user would think twice, no?
Take something like Vimium - it's an extension that lets you use keyboard shortcuts to navigate webpages. You could "scope" it's interactions to adding keyboard shortcuts and modifying the page to indicate links: no external calls, etc.
But it could still add a script to the dom (and it would execute) or it could open a hidden iframe and do a bunch of wild stuff with that.
I think the back-end should also be reviewed and hosted by a trusted party.
If the extensions' permissions are extremely limited the risk profile becomes low, but that makes them far less useful.
These permissions should never have been lumped together. At this point, the browser's "this extension needs access to all sites" is a joke, as every extension requests such a laughably broad permission.
When I encounter an Android App which needs file permissions for no apparent reason I assume malicious intent.
Edited to add: I wrote an Android App which has data import and export. You don't need file permissions for both, at least not on newer Android versions.
"If you go to a bad website, it might cause bad things" is ~=~ "If you use a bad extension, it might cause bad things"
I think that the advice to be wary of extensions adding permissions is quite astute and a good reminder to each of us to make sure we are using well-vetted (to our own satisfaction) software, in-browser and out.
But I'd posit on the whole that browser extensions do much more good than harm. uBlock Origin has stopped many a grandma from clicking a false download button-in-banner-ad.
Add to that the heavyweight tools of NoScript, uMatrix, Privacy Possum/Badger, absolute enable right click, SingleFile, Decentraleyes, and more that I've yet to learn about, and they greatly outweigh the drawbacks of the likes of extensions mentioned in the article and 'web of trust' etc. that have gone to pot.
I react so strongly to this not because I disagree with vetting software, but because I don't want browsers having yet another excuse to yank control and features away from me as a user. I'm already nervous that Mozilla will coyly refuse to support all extensions in their new browser, replace Fennec with a worse system and I will be stuck with it.
Chrome on Android supports no extensions, and is tightening the screws on extensions in desktop, so this is not a slippery slope I'd like to get on.
Not to say I am for restricting extensions more, but just to vouch for the idea that there is, in fact, a valid and novel point to treating extensions cautiously versus other kinds of software. Even programs running locally and unsandboxed will have to work quite a bit to compromise a browser.
I recently discovered this because a few of my extension's users wanted us to create a whitelist feature. We had previously built a blacklist feature and were dreading creating a whitelist also, and figuring out how to educate users about what these two features are, and how to use them. Then I discovered that Chrome (and Brave) offer this whitelist feature on all extensions. Problem solved!
Sadly (and surprisingly), Firefox appears not to offer this feature.
Extension can list this permission, and request access to specific website on demand.
Chrome has supported this for a long time, but I'm not sure if Firefox supports this permission or not.
After all when I run apt-get update any of the updates could install malware that could do anything at all.
Instead of programmatically limiting what extensions can do, which seems very difficult to do while preserving useful functionality, they should study what makes the debian packaging system so trustworthy and implement that.
Why would you attack a store where you can be burned in less than a week when you can attack stores where there are millions of less technically users who are more easier to fool and exploit?
The fact that it just isn’t regularly targeted?
If you look at npm & co. you’ll see that the few attackers going after targets like this kind of suck.
thousands upon thousands of hours of unpaid manual labour...
I'm sure most HN readers are like this.
Our nontechnical friends just add extensions and other cruft willy-nilly with no thought to the implications or risks.
Autoupdate is the first thing I disable in any software.
Also, I generally rely heavily on access controls, so that vulnerable software is only really accessible once strong authentication has been performed. Pretty much tls/ssh endpoints are the only thing exempt from that.
- extension developers must upload a fee that gets forfeited if extension does anything shady (seriously? Who would care to make extensions then?)
- Stricter and more granular rules (it soon get to complicated)
Worse still, the correct approach - specifically listing pages you need access to - has been broken for ages, such that if you add a new URL your extension will silently break until users go into a popout menu and turn it on manually. This discourages doing the right thing. If you want your extension to keep working you need to request wildcard access from the beginning, because Google's update flow for new permissions is broken by design.
Sadly Mozilla followed in their footsteps and the warning for that permission isn't much better. In my opinion any extension with that permission should be forced into a slower manual review cycle. Google does have the ability to do this - my extension was forced into a slow manual review cycle for a month after a fraudulent DMCA claim - but for some reason they opt not to do it. It would also be very beneficial for them to apply additional controls like requiring use of two-factor authentication and a code-signing key before uploading extensions with those permissions to reduce the risk of malicious code sneaking in. You can't completely safeguard it but manual review + aggressive authentication would help.
As-is, thousands of extensions used on a daily basis have the ability to steal people's gmails (including password reset emails), issue password reset requests, send emails, or manipulate your bitcoin wallet. A well-crafted extension could do this near-invisibly in a way the average user would not understand. Google has taken some steps to mitigate this, but it's taken them far too long and they haven't been aggressive enough.
Security-wise, web extensions are worse than desktop software has been in over a decade. UAC, sudo, the iOS app store - all dramatically more effective at protecting users. With web browsers being used daily by a billion+ people it's really unfortunate that this security blindspot has remained so long.
EDIT: It's kind of sobering to consider AddonJet's promised payout of $2500/day for 100k users. I maintained an extension with roughly 120k weekly actives across the globe for about 3 years and it mostly cost me money. Monetizing that would have covered medical expenses and rent for my family, plus potentially college for my nieces and nephews... oh well.