If I can miss subtle and not-so-subtle bugs in my own team's code that I'm working on every single day, what are the chances I'll get it right on somebody else's project?
Being able to MITM any HTTPS request on my system is a privilege I'd not grant lightly. It's up there with browsers, browser extensions (with "all content on all sites" access), and password managers in terms of blast radius in case anything goes wrong.
No one will do this, and those that read source code during installation do not review it for every upgrade. It's one of those 'just do this!' arguments that has little to no basis in reality. There's more of them replying to the parent comment: "Just do this! Just compile a thing! Just verify signatures for every update!". Come on... Meanwhile the negatives immediately implicate anyone with access to the executable.
You don't know this person, and I see no personally identifiable information to make me trust them. They could literally be a state actor right now! We've also seen so many large supply-chain attacks over the last decade which could easily target a tiny project like this.
But doesn’t that apply to chromium / firefox as well (or any other big application). Web browsers are insanely huge, nobody is reading the entire code. What makes this different?
If we start with the reasonable assumption that "being malicious" !== "hacking a bank account", then the answer to your question does not matter at all.
They're going to do everything they can to learn how much money you have in your account and then they'll relentlessly try to manipulate you into losing more of your money.
If you think you can trust Google because they are not interested in robbing your bank account, then you have fallen well for their deceptive campaigns. Google is just a next level robber that operates on corporate level.
To take a different argument, it’s another party that’s less well known that you have to trust. The more parties you trust, the less secure things become. Whether that additional risk is something you want to take on is a personal decision. MITM SSL traffic would make me uncomfortable.
If you really wanted/NEEDED this, you could definitely go through all the code. It would take a bit, but it's doable with determination (lol). Also, you don't have to necessarily review all of the code every update. All you have to do is view the changes/new commits every time you want to update.
The hardest part is determining that you want to go through all of this hassle to replicate something browser extensions already do (for the most part).
If you believe you can find even just all unintentional bugs, let alone deliberate security vulnerabilities, you've never looked at the underhanded C contest [1].
> All you have to do is view the changes/new commits every time you want to update.
These can be thousands of lines of code per day in busy projects.
I'm as paranoid about this as you, but this type of verification seems easier today with AI tools. I'm not aware of any that do this, but if LLMs can give insight about what a piece of code is doing, they can surely be trained to detect possible suspicious behavior. Perhaps even by inspecting a binary, but certainly by processing code.
Maybe for well-intended code (and even there I have my doubts – the halting problem says hi!), but most definitely not for malicious backdoors at this point.
The build steps are provided as a GitHub action in the repo. You can audit the build pretty easily, or if you're super paranoid you can build it yourself by following the build steps.
Even if the app is trustworthy, it still adds an attack vector to your system. It could have a bug, or the certificate could be exploited by another program.
It's in no way worse than running a single browser extension with overly broad privileges. If this method of adblocking gains more traction (quite possible, as Google keeps moving to damage in-browser ad blockers), I expect the implementation to receive a lot more scrutiny.
I think we have to face the reality that web browsers might no longer be considered "user" agents.
I think it is a mistake for programs that have SSL traffic to not have an option for a user-defined non-secure proxy (usually this would be for a proxy running on the local computer, rather than a remote proxy). A non-secure proxy would save energy (since then it doesn't need to decrypt and encrypt it twice) as well as allowing use of newer (or older) cipher methods in programs that do not support them.
How do you know that the downloaded binaries are built by the GitHub action? If I must audit the code and build it myself every release, then how is this a usable product?
Not a product. It's literally free, free as in free speech, and free as in you're free not to use it.
Building the code yourself for every update is also a solved problem on every system with a feature complete package manager, including Windows. Trust is not so easily solvable, but if you trust nobody, you can choose to look at ads.
Same as everything you use on your computer... If it's not open source it's already game over. If it is, congratulations feel free to inspect all the code yourself and build from source OR trust the project maintainers and use pre built binaries.
Applies to this program no different than your Linux distro.
Of course there could be other tools that can help verify things such as checksums on reproducible builds.
If none of that is "usable" enough for you, feel free to set up your own tooling and automation
In fact, that's what I'm trying to say. The line we draw at "hey we can at least audit open source" is a fully imaginary one. It's a false comfort we create. It's the Kool-Aid we drink.
I don't have any trust in any of those components you mentioned, but I came to terms with the risks associated with using them as part of my threat model. However, I find the notion that open source is somewhat safer because "we can audit it" exaggerating if not misleading. It's not a valid argument, and it should never be used because there's no way to do it in an either practical or consistent way for the users of the said product.
There's a difference between "you/I can audit it" and "we (collectively) can audit it".
You're not living in a vacuum. The more users (and perhaps more importantly, contributors) an open source product has, the less likely it has intentional backdoors built into it.
Yes that's fair, however that's how our complex world works. E.g. we rely on journalism (the real kind) to uncover all kind of scummy behavior. Similar in the OSS world.
There is no way to easily verify that unless some trusted bodies do this for us and publish their work specifically for what you're using.
Now you just have been stating a problem and no solution.
I do agree with you though that "hey it's OSS and easy to verify because we have the code" is indeed lying to ourselves and especially tools with privileges like this (MITM your encrypted traffic) should not be taken that lightly and have the proper warnings, disclaimer and attention (to watch for bad behavior)
Being able to MITM any HTTPS request on my system is a privilege I'd not grant lightly. It's up there with browsers, browser extensions (with "all content on all sites" access), and password managers in terms of blast radius in case anything goes wrong.