back
95 comments
Evergreen article: https://boingboing.net/2012/01/10/lockdown.html

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 most surprising development on this front has been Firefox's limiting user's ability to install addons that have not been blessed by them. I understand that if you run an app store, you get to review code and refuse to distribute apps/addons that don't meet your standards.

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?

It is possible to load unvetted extensions, but it's inconvenient. If you go to this url in Firefox:

   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 understand that if you run an app store, you get to review code and refuse to distribute apps/addons that don't meet your standards.

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.

It's the reason I decided not to switch back to Firefox. I want to run my own extensions without anyone else's approval.
You can sideload relatively easily even on stable, and I'm fine with the UX being slightly arcane because the average user shouldn't need to do it
> I don't agree with Cory Doctorow on everything

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.

When people dislike a source they will often dismiss the entirety of the content. If you qualify it like this you can get these people to be more open to the information because they identify with you as a member of the tribe who dislike the source, and the people who are already partial to the source don't care. Imagine, for example, Breitbart gets exclusive information regarding something unrelated to their politics. It's very easy for a large number of people to reflexively dismiss the article because of the publisher, but if you qualify it by saying that you're left leaning, then people take a second look.
>> I don't agree with Cory Doctorow on everything

> 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.

People think it boosts the signal of their post to make their agreement seem exceptional. Simple as. It's such an internet comment meme that it probably even works. Just tack it on to any rhetoric for free points.
Google recently removed several hundred extensions which were found to contain malware. Tons of extensions have been caught saving & selling users' browsing history, notably the ironically titled popular "web of trust".

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.

I'm continually surprised that we don't have a clear delineation between extensions that "do" something—maybe relying on well-known third-party SaaS APIs in the process—and extensions that exfiltrate your browsing data.

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?

The issue is typically that the browser itself doesn't cleanly split those roles.

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.

Yes, when trying to write extensions I found the access requirements much to generic.

I think the back-end should also be reviewed and hosted by a trusted party.

Extensions don’t need to auto-update.
Sadly they do because security holes or bugs can be found in extensions, and those can affect third-party websites. Project Zero has found many bugs of that sort and getting them patched on users' machines is very important.

If the extensions' permissions are extremely limited the risk profile becomes low, but that makes them far less useful.

Ordinary Joe is never going to wrap their heads around concepts like permissions or site-level isolation or sandboxing or may not even understand something like extensions or plugins. Any model of software that presents choices to the average user that depends on understanding such concepts is likely to lead to the user clicking "yes" or "allow" without even a rudimentary clue of what they're allowing. Software engineers need to basically bake in the functionality of a portion of the most used extensions.
I disagree, the problem is how those permissions are labeled and presented. Why does my flashlight app need to use my camera? Turns out you need camera permissions to light the flash. Why does this game need to read my photos and files to work? Turns out it needs to write some data to the external storage.

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.

But very often it's sloppiness. On Android you can write data just fine without permissions, just not everywhere.

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.

It also shouldn't be too difficult to restrict mobile apps to specific folders - so those that need to actually access all photos have to ask so explicitly, while others just ask to store files...
This article could also be titled 'The Case for Limiting cautious about software you execute' and with a few tweaks in text could support the below sentence.

"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.

This is an oversimplification of the problem. Malicious websites run under a different security model than extensions.

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.

Yes, soon we will be back at: Don't download code from the internet!
Currently extensions either request access for a hardcoded list of websites, or it can request access for all websites. I really want the ability to install an extension for a particular website of _my_ choosing.
You can do this in Chrome. Just go to Manage Extension and then change the radio button selected from "On all sites" to "On specific sites". Then enter the sites you want to be affected, using wildcards if you want.

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.

I would really want the ability to disable network access for a select extension. So an extension can look at the DOM all it wants or read the webpage but can never communicate to the outside world or access the local file system outside of its directory.
> Currently extensions either request access for a hardcoded list of websites, or it can request access for all websites. I really want the ability to install an extension for a particular website of _my_ choosing.

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.

Seems like a culture problem created by improper management by Mozilla and Google.

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.

Debian package maintainers who allow malware to slip through are likely to be forced out of their post by the community backlash. Similar accountability for Mozilla/Google addon reviewers isn't there. The addon gets taken off but what is the accountability from the employee who allowed it to pass review? A company apology is fine from a PR point of view but it also means that employees will not take their job as seriously as a real demotion or consequence.
How much of a 10$ wrench attack / rubber hose attack / bribery do you think it takes to target a Debian packager? This seems like a pretty weak defense.
Debian simply is less juicier to attack than consumer focused stores. Debian has much more technically aware and vigilant user base. It's also probably being used somewhere where there's constant monitoring for security and breaches etc. Not to mention that Debian can move really slow. Default repos have nginx at 1.10 (when 1.16 is the latest), node is stuck at v4, postgres is at 9.6 (when v10,v11,v12 exist)

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?

>what makes the debian packaging system so trustworthy

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.

> what makes the debian packaging system so trustworthy and implement that.

thousands upon thousands of hours of unpaid manual labour...

Data Handling Transparency? Great discussion in terms of how to "regulate" extensions. I feel that it shouldn't technically be that difficult to put in data handling transparency, basically to analyze the code fast and figure out that this extension sends x,y,z data a,b,c servers named/owned by 1,2,3. That would be a start. Google doesn't allow for code obfuscation, controls the code/calls that can communicate with servers and thus can limit it to be easily found and analyzed, and they host all the code so they can analyze each update/extension and provide an automated "data handling transparency" report for each extension (with comments/details filled in, that may be mandatory, from the extension owner).
It's just wild how blind we are to our privilege on this. To me, it's pretty clear that I should be SUPER circumspect about allowing software on my machine or in my browser. I need to trust the author, and figure if the additional complexity really pays for itself in additional utility.

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.

It turns out that automatic updates are RCE and all of the vulnerabilities that come along with that.

Autoupdate is the first thing I disable in any software.

How do you stay up-to-date with security patches?
I periodically update my software. It’s worth mentioning that major version updates can frequently bring new unknown security bugs, too.

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.

Time to stop calling them user agents and start calling them vendor agents. There is a conflict of interest in these vendors' control of web standards; it is in their interest to keep the barriers of entry into the user agent market very high, so that there can be no timely effective response when they overstep their bounds.
Is some of the responsibility on the browser (company)? Or should there be an extension consortium which all browsers fund that vets extensions?
Chrome and Firefox both vet browser plugins on their platforms. I've found Firefox to be much more thorough in this regard, to a fault. In some ways they are even more difficult to deal with than the Apple App Store, in my experience. For example, they sometimes decide to re-review your add-on, even if you haven't submitted a new version in months. At least with Apple, you can (mostly) control when your software is and is not reviewed.
Like Mozilla? :)
I don't feel I have a good solution to the problem of browser trustworthiness for now but here are some ideas in case anyone can build on them:

- 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)

All it takes is the ability to revoke permissions without the extension knowing. That way users can't be conned into unlocking broad swathes sensitive data with the threat of not working. This works well for apps on LineageOS.
A root cause for this is the incredibly unwise decision Google made to allow extensions to request access to All Websites (including https) without even a scary nag warning. The description for that permission kind of understates the danger and because it had no negative impact on installs many extensions requested it that didn't need it.

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.

to me seems a very simple first step: just require extention devs to notify people on owner change, possibly with a standard way... just a lil popup or icon asking "extention X has been aquired by Y, it has permissions A, B, C, D, are you OK with this?"
Is there anything here that doesn't generalize effectively to a case for preventing the user from installing arbitrary software on their own devices ?
Yes, all of it. The title is actually "The Case for Limiting Your Browser Extensions" and it suggest the user should limit them, not that the browser vendor should restrict what is allowed. The current HN title made me jump to that conclusion as well.