
The case for limiting your browser extensions - XzetaU8
https://krebsonsecurity.com/2020/03/the-case-for-limiting-your-browser-extensions/
======
quotemstr
Evergreen article:
[https://boingboing.net/2012/01/10/lockdown.html](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?

~~~
gnicholas
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?

~~~
DamnInteresting
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...](https://developer.mozilla.org/en-US/docs/Mozilla/Add-
ons/WebExtensions/Your_first_WebExtension)

~~~
gnicholas
Chrome is much easier (Load Unpacked Extension), and persists across restarts,
IIRC.

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

~~~
derefr
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?

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

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

Maybe right now this stuff is a free-for-all, but shouldn't these scripts +
iframes be executing, in some sense, under the CORS origin of the extension?
(Not quite CORS in the traditional sense—you _do_ want e.g. Greasemonkey to be
able to mess with pages on all domains, even ones that don't want it to—but
you could re-use the CORS origin-tracking, and just relax the rules slightly
where extension:tab interactions are concerned, while still _having_ rules.)

~~~
iudqnolq
How would you implement navigating within the page without executing in the
context of the page? For example, jump to the next form field requires finding
the form fields.

~~~
azinman2
By having chrome build explicit support for this kind of stuff, and creating
an API around it.

It seems plausible for Google to inspect its top 500 extensions, and figure
out a set of APIs that support all of those needs without giving unlimited
read/write/network/execution access to the extension. Just look at how Safari
created their own Adblock API thats faster/more memory efficient without
giving away URLs to the part of the extension that has network access. This
model should be expanded upon.

~~~
jefftk
I can't tell whether you're being serious or sarcastic, but in case it's the
former Google has proposed doing this
([https://blog.chromium.org/search/label/manifest%20v3](https://blog.chromium.org/search/label/manifest%20v3))
and it's been very unpopular here.

(Disclosure: I work for Google, speaking only for myself)

~~~
azinman2
I'm being serious. It's been a long time since I've developed a Chrome
extension so I don't follow them, but it seems to be me that is a good start
but there are many areas where Chrome (and other browsers) could go even more
fine-grained.

I'm not sure why it's unpopular here (perhaps its implementation vs concept?),
but it seems to me that with the realities of malware constantly being
distributed through extensions in addition to the obvious privacy issues, that
many reasonable people would wish to see this evolution.

Personally I use almost zero browser extensions because of these issues.

~~~
TeMPOraL
In a nutshell, it's unpopular because it neuters adblockers, and Google
doesn't have the reputation of a benevolent actor anymore.

~~~
azinman2
So if that’s true, then they’re not doing as I suggested: take a fine-grained
approach to the top 500 extensions (including adblocking) to make it possible
to create them without having full read/write dom + networking. I believe the
content blocking APIs in Safari are a great start and could be taken so much
further.

~~~
TeMPOraL
This _might_ work if Google didn't have ulterior motives here, but would still
amount to neutering the browser as a general-purpose computing platform.

~~~
azinman2
Not at all! Webpages can still do as they like. That’s general purpose!

We’re talking about extensions distributed on a store that often end up with
malware. I’m not even necessarily advocating for them to remove the ability to
anything they wish (yet)... but let the browser catch up to already do what
these extensions want in a more secure way. What’s wrong with that?

~~~
TeMPOraL
> _Webpages can still do as they like. That’s general purpose!_

That's general-purpose _for the third party_. Not for _the user_! This is the
whole thing the "war on general-purpose computing" is about - whether the
software serves the user, or whether it serves its creator and third parties
it trusts.

> _let the browser catch up to already do what these extensions want in a more
> secure way. What’s wrong with that?_

There's nothing wrong with that per se. I have the problem with the part
involving removing user's ability to arbitrarily alter the behavior of a
website.

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

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

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

~~~
StavrosK
Oh yes, I imagine it's sloppiness in the large majority of cases.

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

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

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

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

~~~
rocqua
You would need read-only access to the DOM. At which point it becomes hard for
your extension to have any effect.

The moment you can start modifying the DOM you can essentially start sending
network traffic.

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

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

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

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

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

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

~~~
saagarjha
How do you stay up-to-date with security patches?

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

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

------
donclark
Is some of the responsibility on the browser (company)? Or should there be an
extension consortium which all browsers fund that vets extensions?

~~~
miohtama
Like Mozilla? :)

~~~
donclark
Like any browser that allows for extensions or addons. Chrome, Mozilla, Opera,
etc.

~~~
cxr
Mozilla is not a browser. Firefox is.

In the early days of mozilla.org and even well into Firefox's heyday, Mozilla
was more akin to a co-op. It was a neutral ground where folks associated with
different vendors and institutions participated from all corners. Students.
Independent researchers. Engineers from Google. Engineers at HP. Engineers at
Red Hat. Even folks from Opera. Some people _were_ being paid to work on
Firefox full- or part-time, but most of their paychecks were signed by those
other companies, not Mozilla. People who were on Mozilla payroll were
generally employed by the Foundation with an official job title that involved
keeping mozilla.org infrastructure running.

Some people might superficially look at the Mozilla Corporation and assume
that this all ended there, but they're wrong. When Mozilla Corp. got spun up
and Google signed a deal for search engine royalties, employee numbers stayed
in the very low hundreds for years, and the search deal was largely seen as
similar to another donation of sorts—Firefox had already defaulted to Google
before the deal, because it was the only thing that made sense for the
developers and other people actually using Firefox.

Somewhere along the way, though, between Google pulling engineers off Firefox
and launching Chrome, to the introduction and rapid adoption of the iPhone and
mobile Safari, the powers that be at Mozilla decided to make a business play,
which is more or less where the stillborn FirefoxOS came in. Whereas before
Mozilla was a vendor-neutral org working on what amounted to a reference
implementation of a modern user agent as its contribution to the digital
public infrastructure[1], the company began pursuing a role as a Bay Area bit
player, formed a business plan, and began competing for part of the pie, both
on the desktop and mobile. It went on a hiring spree, shifted most things out
of the mozilla.org governance model to live underneath the Corporation's org
structure, othered contributors not employed @mozilla.com, and hired execs
from places like Adobe—folks with with business experience to try and run the
show and make it all work.

Of course, it didn't really work. It just destroyed the Mozilla that used to
exist.

So now we have Mozilla today, which is still limping along in that space. It's
got the same name, but it's really just running on steam and trading on that
name and the goodwill that the Mozilla community fostered in the earlier era.
But that doesn't mean when you see people talk about "Mozilla" that they're
referring to the floundering business that we see today.

1\.
[https://news.ycombinator.com/item?id=22389779](https://news.ycombinator.com/item?id=22389779)

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

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

~~~
nishmastime
No, an extension that has good reason to inject a script into every webpage
can, with the same permissions, exfiltrate user data under a new owner. Almost
all extensions thus users are vulnerable to this. There is no higher priv the
script needs to ask for.

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

------
jan6
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?"

------
seemslegit
Is there anything here that doesn't generalize effectively to a case for
preventing the user from installing arbitrary software on their own devices ?

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

~~~
seemslegit
But the entire article is a demonstration that most users don't have the
ability to do meaningful due diligence on their extensions, and even then they
are helpless when the ownership changes hands to nefarious actors.

~~~
Causality1
Frankly I'd be in favor of a piece of regulatory legislation requiring that
all software which features an automatic update mechanism be required by law
to inform their users of a change in ownership and obtain affirmative consent
to begin receiving new versions from the new owner.

~~~
TeMPOraL
I'd be in favor of a piece of regulation that requires the extension declare
its scope of behavior (e.g. "no analytics", or "no data exfiltration"), and
then any automatic update that breaks this declaration means the developer is
subject to fines and/or imprisonment.

Most of the extension problems boil down to either a) malicious developers,
and b) developers of popular extensions which take money to include malicious
functionality, or sell the extension to a third party.

~~~
seemslegit
Regulation of whom ? The extension vendor registered in Estonia ? Of software
vendors in general ? Expect some riders in that bill that you're not gonna
like.

~~~
TeMPOraL
From whoever is responsible for various international agreements around
pursuing crimes on the Internet. I'd like to see malware and adware
criminalized.

But yeah, this isn't going to happen in the real world.

~~~
6510
Of course it will happen. The only question is how long it is going to take.

