
ChromeGalvanizer – Harden your browser against extension backdoors and exploits - mandatory
https://github.com/mandatoryprogrammer/ChromeGalvanizer
======
squarefoot
Being a FF user I can't use it, but it made me think about the dangers of
extensions being hijacked. It would be nice to have as a browser builtin
feature a domain based whitelist that enables access to extensions according
to a trust level, so that for example any new encountered domain can be
accessed by all extensions by default, but if I assign say my bank domain a
level of N, only extensions whose trust level exceed that N number would be
able to access its data while others would be bypassed, then a fixed maximum
value of say 10 would mean all extension bypassed for the paranoid. Probably
even a trusted/not tusted flag would suffice, but just in case one wants to
differentiate between locally written and installed extensions that can't self
update, then official and non official ones. Doable?

~~~
gnicholas
One way to accomplish this is to just use private windows for your banking or
other critical sites, and then don't let extensions run in private windows.
You can configure this per extension in Firefox and Chrome.

~~~
throwaway_pdp09
A simpler, if perhaps unnecessarily heavyweight way of doing this is to have
separate _accounts_ on the same computer. My email has its own account, and
allows cookies there (it's gmail). I have to switch accounts to do mail but
that's not so bothersome, perhaps even an advantage for some as it might help
not jumping every time a mail arrives.

Using private X in the browser requires trusting the browser, this way you can
have the OS isolate processes which has to be stronger.

------
superasn
I've made it a rule to right click all chrome extensions icons and then set
them to "This can read and change data > On www.example.com" on sites I really
intend to use them. This prevents them from reading all sites but also
prevents the annoyance of reloading the page every-time you need to use the
extension. Also some extensions like Likepass inject some really ugly HTML
into form fields (it also takes care of that)

It's a pretty useful feature that many people miss.

~~~
tjbiddle
Phenomenal! Thank you!

I've personally just switched from Chrome to Brave. Funnily enough, Chrome was
causing my computer to seize all the time while Brave does not, even though
it's still built on Chromium. But I took the opportunity to go ahead and clear
out a number of extensions. Feels so much better. Your browser can really get
cluttered over the years!

------
dsun179
This sounds great, I will try. Is it somehow possible to restrict the internet
access of a single extension? For example I have an add-http-header extension
that has no reason to create connection to an outside server.

~~~
gnicholas
Not sure if this answers your specific question, but you can limit the sites
that an extension can run on. I recently discovered that Chrome offers this
feature (right click the extension icon and select Manage Extension to
access), and it saved me from having to build a site whitelist feature for my
extension. [1] It already has a blacklist feature, and I was going to build a
whitelist feature due to user requests. Then I discovered that this
functionality is built into all Chrome extensions.

Unfortunately it doesn’t seem to exist on Firefox.

1: [https://chrome.google.com/webstore/detail/beeline-
reader/ifj...](https://chrome.google.com/webstore/detail/beeline-
reader/ifjafammaookpiajfbedmacfldaiamgg)

------
miles
Just tested in Windows with a registry file generated via the linked web
interface[0]. Dark Reader was not prevented from accessing sites that should
have been excluded based on the imported policy, even after a reboot. Has
anyone successfully tested Chrome Galvanizer?

[0]
[https://thehackerblog.com/galvanizer/](https://thehackerblog.com/galvanizer/)

~~~
szhu
I tested the following on Mac:

1\. Block "(star)" from accessing "(star)://mail.google.com"

2\. Install the config

3\. Go to chrome://policy/ and click "Reload policies"

4\. Open Gmail. Dark Reader doesn't work anymore.

~~~
miles
Thanks very much - will test on macOS next.

EDIT: It must be me, as I am still not having any luck. I just tested in a
slightly older macOS VM (10.12) with Google Chrome 81; even after installing
the profile, Dark Reader continues to work on sites that should be excluded.

------
PappaPatat
> Using Chrome Galvanizer, you can protect yourself from attacks like this by
> specifying specific sites that one or all of your extensions can no longer
> access. For the MEGA case, if users had created a policy restricting access
> for the MEGA extension to access amazon.com, live.com, github.com,
> google.com, myetherwallet.com, mymonero.com, and idex.market then they'd be
> protected from the attack.

You might as well turn off the internet for some.

------
jamieweb
It's a challenge to weigh up the risk of not using an adblocker versus the
risk of the extension getting compromised.

I guess that solutions like DNS-level blocking or custom hosts files are a
fair balance, but I still like the DOM-based per-element control found within
adblock extensions.

And then I see people with like 20 extensions installed...

~~~
ocdtrekkie
Ultimately it's a trust tradeoff. Extensions should only be installed from
incredibly trusted "I'd give this entity my passwords and my bank info for
safekeeping" level trust. Because that's essentially the access a lot of
browser extensions have.

The easiest way to protect your browser from exploits is to disable or
whitelist extensions. At the office we block all but a small handful of
extensions we've vetted, and we're very hesitant to add more without very good
cause. Do this at home too.

~~~
sitkack
Even for extensions you trust, if their domain expires, it can be minutes
later that it is pushing an update.

Actually ... Chrome extensions should have a trust policy wrt domain age,
meaning a newly refreshed domain (via expiration) shouldn't be able to push an
update for X days.

 __edit, forgot to mention that this applies to all plugin systems, many which
provide vectors of attack against programmers, many of whom can affect global
infrastructure.

So VSCode, IntelliJ, etc can be used to inject code into the client as well.

~~~
dogma1138
Chrome extensions should be signed and should prevent updates of extensions if
the new version was signed by a different from the one signed the current one
until the user manually approves it.

~~~
ocdtrekkie
The problem is malicious actors will only buy the extension conditional on the
author handing over the signing key as well.

------
tchaffee
I open Chrome once in while for testing or on the rare occasion something only
works there, so maybe this is useful for those occasions. But if you're
serious about security and privacy shouldn't you be avoiding Chrome as your
regular browser?

~~~
cl3misch
On malicious extensions and stealing login credentials specifically, what's
bad about Chrome?

~~~
judge2020
Since it's the more popular browser for non-tech people (i'd imagine firefox
leans more towards tech/privacy-conscious people than 'normal' users), it's
probably the first one targeted for auto-extension installation by malware.

------
1cvmask
Who uses this?

