Hacker News Reader

Comment by singularfutur | Hacker News Reader

This is why I only run open source extensions that I can actually audit. uBlock Origin, SponsorBlock, the kind of tools where the code is available and the developer isn't anonymous. The Chrome Web Store is basically unregulated and Google doesn't care as long as they get their cut. Open source at least gives you a chance to see what you're installing before it starts exfiltrating your data to some server in a country you've never heard of.

View on HN

An extension from a trusted, non anonymous developer which is released as open source is a good signal that the extension can be trusted. But keep in mind that distribution channels for browser extensions, similarly to distribution channels for most other open source packages (pip, npm, rpm), do not provide any guarantee that the package you install and run is actually build verbatim from the code which is open sourced.

Actually, npm supports "provenance" and as it eliminated long lived access tokens for publishing, it encourages people to use "trusted publishing" which over time should make majority of packages be auto-provenance-vefified.

https://docs.npmjs.com/trusted-publishers#automatic-provenan...

pypi also added this last year [1] and encouraging people to use trusted publishing as well.

[1] https://docs.pypi.org/trusted-publishers/

If the build doesn't happen without network access, it doesn't really work.

key word "encourages"

when someone uses `npm install/add/whatever-verb` does it default to only using trusted publishing sources? and the dependency graph?

either 100% enforcement or it won't stick and these attack vulnerabilities are still there.

Unless the Chrome web store integrates with this, it puts the onus on users to continuously scan extension updates for hash mismatches with the public extension builds, which isn’t standardized. And even then this would be after an update is unpacked, which may not run in time to prevent initial execution. Nor does it prevent a supply chain attack on the code running in the GitHub Action for the build, especially if dependencies aren’t pinned. There’s no free lunch here.

If the RPM/deb comes from a Linux distribution then there is a good chance there is a separate maintainer and the binary package is always built from the source code by the distro.

Also if the upstream developer goes malicious there is a good chance at least one of the distro maintainers will notice and both prevent the bad source code being built for the distro & notify others.

Browser extensions come from the Chrome/Firefox addon store, though and not through distros.

And maybe that's why we have the problem that is being discussed ? No third party that would audit and build extensions from source.

Everybody seems to hate distributions though.

How do you check that the open sourced code is the same one that you are installing from the extension repository and actually running?

This kind of nihilistic comment doesn’t do anything for me.

There’s always a possibility of problems along the chain. You are reducing your risk not eliminating it.

> This kind of nihilistic comment doesn’t do anything for me.

Got to say, mischaracterising a neutral question as a nihilistic comment doesn't do anything for me.

I agree but let me play the devil's advocate. I'll channel Stallman:

Same argument can be applied to all closed source software.

In the end its about who you trust and who needs to be verified and that is relative, subjective, and contextual... always.

So unless you can read the source code and compile yourself on a system you built on an OS you also built from source on a machine built before server management backdoors were built into every server... you are putting your trust somewhere and you cannot really validate it beyond wider public percetptions.

Don't forget to channel Ken Thompson ("Reflections on Trusting Trust") -- you can read the source code, but where did you get the compiler?

This can be mitigated by Bootstrappable builds: https://news.ycombinator.com/item?id=41368835

> How do you check that the open sourced code is the same one that you are installing from the extension repository and actually running?

Extensions are local files on disk. After installing it, you can audit it locally.

I don't know about all operating systems but on Linux they are stored as .xpi files which are zip files. You can unzip it.

On my machine they are installed to $HOME/.mozilla/firefox/52xz2p7e.default-release/extensions but I think that string in the middle could be different for everyone.

Diffing it vs what's released in its open source repo would be a quick way to see if anything has been adjusted.

Extensions are trivial unless they have to run external software or services. Download the extension, extract the source, audit it with a good thinking model and either strip out all third party URLs/addresses or have the agent clone the functionality you want.

CRX Viewer is handy for quickly checking what's been published:

https://robwu.nl/crxviewer/

I'm running Uniget on Win11 and this is my worry there. Provenance of installs vs the actually released files.

I wish we had something like "source hash" available in all repositories.

The open source one automatically publishes to the Chrome Store from GH actions so that there is no human involvement in the deployment process.

I'm currently in the process of setting that up for the one I'm building, because this transparency is very important to me) and it is a pain in the butt to do so. You have to go through a few verification processes at Google to get the keys approved.

This is why it's so sad that Tampermonkey isn't open source. https://github.com/Tampermonkey/tampermonkey/discussions/173...

TM is capable of doing most of what other extensions do, so it's too bad it's not open source because the ecosystem is inherently transparent.

Do you also audit every part of every car you buy or medicine you take? Or do you rely on large well-established institutions to do that for you?

"Dont trust google" imo is the wrong response here. We are at the mercy of our institutions, and if they are failing us we need mechanisms to keep them in check.

My car can't login to my bank account.

Your car and fellow road users' cars generally have your life, your passengers' lives, and other road users' lives in its hands while in use.

Well, I see how, especially for people who are close to death and want to provide for their loved ones, the answer to "Your money or your life" might lean in the other direction.

My car probably could be hacked to murder me in secret but frankly I'm not worth expending that kind of access on.

The threat model is really very different.

Give it a few years. After all how will Tesla get that $99 every month for your self driving susbscription?

>Do you also audit every part of every car you buy or medicine you take? Or do you rely on large well-established institutions to do that for you?

Cars are under quite strict laws that software isn't. And there is only a small number of car vendors, while there are several orders of magnitude more extension vendors. Also a car vendor is a big company with many audits and controls, an extension "vendor" could just be some guy in his garage office, who just sold it to scammers, even for popular extensions.

And I still wouldn't trust a modern car using subscriptions and code updated.

Also, car companies have a lot at stake and are a clear target. The scammer is hard to even identify, and has no reputation to worry about. Of course in case of a sold extension, the original author of the extension may have a reputation they care about, but only if they're still making other extensions.

There are no established institutions for checking add-ons. The stores claim doing some checks, but seems enough is slipping through their net. It's also common sense to not buy something critical from a random anonymous source on the internet.

“Don’t trust Google” is table stakes for being on the Internet over the past couple decades.

> "Dont trust google" imo is the wrong response here.

Straw man. The argument is that by installing random extensions you trust anonymous developers *because* Google doesn't audit. I'll cite the parent to spare you the effort of reading it again:

> The Chrome Web Store is basically unregulated and Google doesn't care.

Yes, I trust the contents of the medicine I buy at the drug store more than I trust the drug dealer on the corner. That's why they hand out test kits for free at raves.

> This is why I only run open source extensions that I can actually audit.

How far does your principle extend? To your web browser too? Google Chrome itself is partly but not entirely open source. Your operating system? Only Linux? Mac and Windows include closed source.

On HN of all places it's not that implausible that someone might be running Linux and Chromium or Firefox, surely?

I didn't claim that it's implausible. I asked a question.

On the other hand, it's not that implausible either that someone might be running Google Chrome, Windows, Mac, etc. We know that many HN commenters do. Thus, while the OP may be 100% consistent, "I only run open source extensions that I can actually audit" would not be a consistent principle for those who also use closed source software.

Why do you think it’s not consistent? You don’t have to apply the same policies to everything you use.

> You don’t have to apply the same policies to everything you use.

What's the reasoning behind it, though?

You can arbitrarily apply different policies to different things, but there's no rhyme or reason to that.

If the difference ultimately comes down to trusting certain developers to an extent that you don't need to audit their source, then I'm not sure why that couldn't also be true of certain extension developers.

Linux distros have a good reputation, browser extensions don’t. Might be simple as that.

It appears that you may have misunderstood the preceding discussion. Linux is open source and thus can be audited.

One might choose not to however, yet still audit their extensions.

One benefit that FOSS provides is that there’s more eyeballs on the source code, so yeah, it’s a very strong trust signal. But sometimes priorities are a bit different, and ultimately you need to trust something.

IMO it still makes sense to personally vet browser extensions and trust the OS/browser:

1. It’s hard to create a new operating system or browser, so we don’t see many new ones. (Not taking into account Firefox forks / Chromium reskins here.) For browser extensions, the entry barrier is much lower, and the chance that one of them will be malicious is higher.

2. It’s also much harder to audit all of Linux, or Firefox/Chromium, especially if you’re not too familiar with the domain. For browser extensions on the other hand, it’s usually possible to go through them in one night.

If they live in California, they're most assuredly borrowing prestige through licenced usage of apple hardware.

Because let's get real, no one ever gets a job in tech if they're not an iPhone user right?

This is the safest way. You also want to disable auto update to version lock, which means using Firefox or Safari or loading unpacked if you use Chrome.

consider how the xz supply-chain attack occurred 2 years ago [0]. the malware isn't auditable with a `git clone` as easily as you might want.

[0] https://research.swtch.com/xz-timeline

It’s one of the reasons I run Safari, which strictly limits what extensions can do for these reasons

No, Safari is really no different here from Chrome, and indeed there's broad compatibility between the extension API, such that in many cases you can use a Chrome extension unmodified in Safari.

Ah, thanks interesting. I remember the kerfuffle when Safari introduced its new model and I didn’t realise Chrome had followed suit

And you audit every update? Ahem.

Annoyed with how the AWS console sometimes changes regions on its own, I recently decided that I need an extension to make the current region displayed prominently. After a bit of research, I found the AWS Colorful Navbar [0] extension, which does pretty much exactly what I wanted, but (understandably) requires granting it "This extension can read and change your data on sites" on `://.console.aws.amazon.com/*`, which I'm not willing to give to an external extension. So my solution was forking the repo [1], carefully auditing the code, and then installing it from a local clone (which they actually have a nice explanation for). Going forward, I think I'll try using this approach for all sensitive extensions.

[0] https://chromewebstore.google.com/detail/aws-colorful-navbar...

[1] https://github.com/nalbam/aws-navbar-extension

Reply on news.ycombinator.com