Having just posted the app to a couple of small subreddits before sleep and then waking up to being on the front page over here is quite an experience :) I was hoping to make a Show HN post after giving Zen a bit more polish, but I guess here we are.
Thanks for all the constructive feedback. I totally share your concerns about its security and likewise wouldn't use some unverified application trying to install a root CA on my system. For those wanting to audit the certificate generation and installation code, feel free to take a look at certmanager/get.go and certmanager/install_{platformname}.go. It is mostly self-contained and, I hope, easy to understand. The lack of any instructions on how to delete the certificate is an oversight on my part, and I'll be working on this. Regarding the binaries: all of them are built on GitHub's CI. I wish there was a way for users to verify this fact, but to my knowledge, there is no way to do that currently. You can run and build the app yourself using Wails (https://wails.io/docs/gettingstarted/installation). I'll be sure to add more instructions to the repo in the coming days.
As always, any feedback, help, and suggestions are much welcome.
Thank you for starting this project. There is a bit of overall negativity in this thread from users who don't fully understand what is going on here, but please don't get discouraged. This is ultimately the correct approach to addressing browsers that have a financial interest in serving ads.
Thank you for your work. I appreciate it very much. Please don’t be down motivation by the negative comments.
About your comment of security, I think it’s better to make a FAQ file and write it there to clearly explain.
And one suggestion is I hope zen will have function to choose upstream DNS server (can be DoH or DoT server). It will be the best block ads with combo DNS and HTTPS.
I'm comfortable with a DNS based blocker (pi-hole) and it seems to work quite well. Bonus: It works across all devices on the network, rather than installing something onto the OS.
I seem to end up regretting anything I do at the network level to block traffic. It always seems to pop up that one weird time I actually do need something from a blocked domain to load, and it takes me way too long to remember that's what I did to block it.
I have a network configuration with 2 dnsmasqs, 1 with pi-hole-style hosts block, and 1 without, and most of my devices get the ad-blocking DNS, 1 gets the "unfiltered" DNS.
I'm not refuting what youre saying in any way; this is just a related suggestion for anyone using PiHole who occasionally runs into what you've described.
There's an Android app called flutterhole which can connect to and activate your pihole's 'pause blocking' feature. I have found this to be the easiest way around the scenario the poster above has mentioned. Doesn't help with figuring out PiHole is responsible obviously. HTH.
I personally setup an instance of Homebridge on the device running Pi-Hole, then use HomeKit on my Apple products to turn Pi-Hole on/off as if it were a light bulb.
ISP’s router has unrestricted Wi-Fi access. I run a router behind it with restricted (via pi-hole) access.
All devices connect to the restricted Wi-Fi. Any time I need unrestricted access, I connect to the ISP router Wi-Fi for some time and back to the restricted when done.
I had that same issue until I started using mine over tailscale. One of my computers acts as the DNS server for the whole network with pihole on it, and then anytime I need to get around something I temporarily disconnect from my tailnet. Super nice cause then I get no ads on my phone too.
Good point. Its fine if I'm the only one using the network, but I'll admit it can take a bit before I connect the dots between pi-hole and "this link I'm clicking off google won't load".
I find it also a bit frustrating because browsers may even ignore your network's DNS settings so you can easily get unexpected behavior (yes, I know it's expected if you are a domain expert but I'm not and it shouldn't be surprising when users are shocked that they implement a pihole and see their machine is using a different DNS than expected. I'd actually expect novice users to be surprised in this case)
FF enables this and they aren't not ignoring the ISPs. Settings > Privacy and Security > DNS over HTTPS
There is a reason to do this btw. The name should say it all. It'll default to cloudflare but they let you specify what you want. The utility? Let's say I'm not an advanced user, what's my DNS look like? Is it DoH? We both know the answer. So defaulting so users' traffic is default DoH sounds like a security improvement. There's also an additional utility. If I take my laptop and move from my home network to another one, I actually don't end up using a different DNS.
You can also use Mullvad's DNS[0], or switch to 1.1.1.2/1.0.0.2 if you want malware protection on Cloudflare's DNS.
Stop making up conspiracies that don't exist. There's enough BS in the world already that we don't need to make ones up to be upset.
I recommend adding a tray icon that disables it for 60 seconds (super helpful for the odd site that serves something critical from an ads domain… like my bank).
Only downside is apps don’t have to use system DNS and a few mobile ones are wise enough to bypass.
I don't mind PiHole, but it doesn't do nearly as good a job of ad blocking as a "real" browser plugin does.
The amount of crap that still comes through when I turn off uBlock -- but am still using PiHole DNS, which is always active on my home network -- is a lot.
Honestly I don't think DNS-based adblocking is really viable, long-term. It's just too easy for advertisers and dirtbag website operators to get around it. There's just no substitute for controlling the retrieval of content elements and their presentation from the application where the user is doing the interaction.
This is why keeping browsers out of the hands of adtech corporations is pretty important; once they control that presentation layer it's largely game over. They can just tunnel all the traffic through a single connection to a relay server, if they want to, and there won't be shit a user can do about it once they've decided that's the only browser they can use.
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.
The post I was replying to said that despite being open source, nobody reads the code for Chromium and Firefox. This isn't true because people are paid to read that code. Nonetheless, anyone can still read it if they want to. This means that it's at least marginally higher risk for a state actor trying to get code into these codebases than a proprietary codebase.
As I said, I think it's still pretty unlikely that Microsoft products are compromised by a state actor. It's certainly not part of my threat model. I'm not sure what point you're trying to make though. I certainly wouldn't install a system-wide HTTP proxy from a developer I didn't trust. And I don't have much of a choice but to trust Microsoft, their products are so ubiquitous I often have little choice.
The point I am making is that both Google (insofar as their open source software) and Microsoft both pay programmers to write and examine their code. That was the original criteria, and working off that you shouldn't have a problem with Microsoft.
Of course, you do have a problem as you've already made clear. However, that problem stems from how Microsoft's code is closed source compared to Google's open source code. That's religious FOSS dogma which I referred to earlier, and has nothing to do with whether programmers are paid to write and examine your code.
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 we have to face the reality that web browsers might no longer be considered "user" agents.
I think too many techies are, much like yourself, contributing to the problem by refusing to move away from Chrome for "reasons"[1], and then compounding it by refusing to acknowledge that "web browsers" != "Google Chrome".
[1] The "reasons" are of dubious quality. Myself and many others are able to do all normal web-browsing from firefox or firefox forks with no functional or performance degradation.
> I think too many techies are, much like yourself, contributing to the problem by refusing to move away from Chrome [...]
Contrary to your assumptions, I've been quite vocal against the Chrome/Blink monoculture for a while. Unfortunately there is a legit case for it; several generations of "low-end" devices (anything older than 10 years basically), that are still quite capable and in common use, where the difference in performance between Firefox and Chromium becomes quite noticeable, especially as you try to watch video.
I don't think the problem is "techies", we have zero influence outside our own circles - see the historical rates of Linux adoption. The problem is we need the good ol' hammer of antitrust to start swinging again. We also need the regulators to be smart; if we get really unlucky, they will target iOS Safari instead. (This would be good in a healthy ecosystem, but would only serve to further entrench Google's position in the current situation.)
By the way, using a filtering/rewriting proxy has other merits, especially on said older hardware; you can rewrite the entire web page to make it more lightweight and accessible. Check out miniwebproxy[1] and medium-rare[2]. It's also quite simple to write one; you need maybe a hundred lines of Go to start getting results. I've been experimenting with integrating Readability[3][4]; and I think there's more potential to this approach.
> I think we have to face the reality that web browsers might no longer be considered "user" agents.
If by "web browsers" you mean specifically Chrome, yes. Firefox, Brave, and others are all committed to supporting MV2, and will continue to serve my interests as a user for the foreseeable future.
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
Thank you. That's my point. There is no point in stating that some open source code is somewhat safer because "it can be audited". No. As you said, it's the same as everything I use on my computer. Unless we can establish a consistent safety level for certain type of projects, we can't claim an arbitrary category of software is somehow better.
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)
That's true, but if it is trying to exfiltrate data you will probably see more packets coming out than going in. If the concern is that the SSL cert they add allows them to decrypt your data, and you see it sending your requests anywhere it shouldn't, you'll get a window into what they are trying to do. It's not perfect, but it is possible to gain information in such a way.
Unfortunately many people do like that, but I hate it and I don't do stuff like that (and it seems many other people hate it too; fortunately you can just download the file without immediately executing it, if you want to view (and possibly modify) it).
The way Charles does this is by generating a root certificate dynamically and makes it really easy to remove by giving you instructions for how to install and remove it just for Chrome for example:
Tangentially related, I found many built-in Windows applications and services use certificate pinning and will either fail outright or modify behavior (easily identified by the number and size of packets with and without MITM).
It made me very curious to find out what data they're downloading / exfiltrating that they feel the need to go to such extremes to hide it from the user.
FWIW, even some of the packages that do pass through MITM are further encrypted binary blobs, not clear text.
I don't know how it actually works, but won't website like youtube simply deny you access if it detects that the ad related request timed out?
I imagine that browser extensions actually tap into the site's code and somehow go around such detection.
But if this is a simple firewall, how will this work against any website that doesn't just default to most trivial "import ad service", but rather actually takes steps to block the ad blockers (Like youtube)?
I've wondered what-if scenarios like this for a long time. I see them being implemented smaller websites, but never at scale like amazon.com or YouTube where they serve petabytes per second. My conclusion is: it gets so expensive to track and block users at session level that they just let go.
That's only true if only a small percentage of users actually use that particular ad-blocking strategy. If a significant number of users did, then it would be a real concern.
Although I think YouTube et al see an increasing amount of revenue and viewership coming from apps... and if they could, I suspect they would kill their web sites in favor of apps where they have much more control.
I haven’t had time to look at the code. Is this generating a unique root certificate per install? If not this could become an attack vector to decrypt TLS traffic.
> During the first run, Zen will prompt you to install a root certificate. This is required for Zen to be able to intercept and modify HTTPS requests. This certificate is generated locally and never leaves your device.
Even if it does create unique root certificates it is a massive attack vector. How good is the tool at protecting the corresponding private key from other software on the device, for example?
It's interesting to see the paranoia FUD in the comments here around MITM, when this is happening on your own machine under your control, and it's open-source too. It should be painfully obvious by now that Big Tech is using "security" as an excuse to effectively force-feed you whatever they want, and depriving you of the right to refuse should be illegal.
Fuck the corporate-authoritarians who are taking away the freedom to do what we want to content that enters our machines. They've been fighting that war for a long time, and we can see through the tactics they've been using.
I've been using Proxomitron as a filtering proxy for over 2 decades after its author's death, and it is even more powerful than this (but requires more setup and tuning.)
Is that even a common problem? I can't think of any apps on my computer that are showing me ads, other than my browser.
It's a very different story on mobile, but there, certificate pinning can also trivially bypass this kind of blocking, and for good reason too: Imagine a system-wide tool like this getting access to online banking credentials, for example...
This won't affect fingerprinting (except maybe it'll block the fingerprinting scripts if they're in lists). It does work better than add-ons in that it'll work on regular applications, not just your browser
I meant - but was not very clear: if one used this software instead of a browser add-on to block ads, would this be a big improvement in escaping browser fingerprinting ?
Probably not. Use a dedicated tool like a custom browser (Mullvad Browser comes to mind - it beats fingerprint.com/demo which Firefox even WITH protections enabled, does not.
It isn't the best way to do it as far as effectiveness goes but it it is pretty good, especially for web browsing. It is the easiest way to do it on my iOS devices (as a fake VPN profile) and can be switched off in a corner case where I need to access something it is filtering out.
It isn't as flexible or powerful as other methods, but it is very simple. Tools are all about how you use them. Ignoring them isn't any better than suggesting them.
I know the YouTube ads is getting more complicated now, but it's just simple example. Another is hosts file/DNS blocking will remain the blank space on web page, but this one will not.
I don't see the problem here. They're adding value to their OS this way, value that will result in greater profits and therefore shareholder value. My MS stock is doing great thanks to moves like this!
If you don't like it, you don't have to use MS products.
Why do you doubt that? Even Microsoft, with all their money and NIH syndrome, are unlikely to invent a brand new application protocol just to serve ads.
ChromeOS puts Chrome in a nice safe sandbox (in addition to the sandboxing of Chrome tabs that happens on all OSes) that used selinux and other technologies. This requires modifications to Chrome. Replicating that for another browser might be harder than modifying ChromeOS to add something like this.
If you have to use it for work “whether you like it or not” then you’re extremely unlikely to have the permissions to install your own root certificate, which is a lot more sensitive operation than running Firefox.
Well then they’re able to install and run Firefox.
My point is the only situations where you have no control over browser installs are when the machine is locked down in such a way that you also cannot install root certificates.
Not necessarily. And there’s plenty of browser based software/services that do not work with Firefox or have a limited functionality with Firefox that are required for work.
I know back when I did more freelancing with podcast clients this was a constant problem. The OS folks were using could reek havoc if it wasn’t safari, edge, or chrome 90% of the time.
But again, you’d then just use Chrome for work and Firefox for personal browsing.
As it happens I lived through this in the early 00s with IE but back then I used Opera for personal browsing and IE for work.
Even in the very remote possibility that you can somehow make changes to root certificates but cannot install a second browser (and I’m being charitable here because there are literally zero reasons that would ever happen), it would still make more sense to update your local hosts files with a pihole-list block list rather than installing your own root cert and using a 3rd party tool to MITM all your web traffic.
I do get the appeal of this tool. I honestly do. But there are so many safer ways to solve this same problem.
Why not? Lots of services are now desktop apps and since you cannot run browser adblockers on Electron apps, this is the next best thing. I also run something similar on Android so I don't see ads in apps either, not just in the browser.
If other apps run into obscure errors due to ad blocking, then it's time to find alternative apps (pending overly-aggressive blocking causing the obscure error - which I have come across, although rarely).
Not to mention, that doesn't even work for ads which are delivered from dynamically generated hostnames, or from hosts which deliver other content as well.
Having just posted the app to a couple of small subreddits before sleep and then waking up to being on the front page over here is quite an experience :) I was hoping to make a Show HN post after giving Zen a bit more polish, but I guess here we are.
Thanks for all the constructive feedback. I totally share your concerns about its security and likewise wouldn't use some unverified application trying to install a root CA on my system. For those wanting to audit the certificate generation and installation code, feel free to take a look at certmanager/get.go and certmanager/install_{platformname}.go. It is mostly self-contained and, I hope, easy to understand. The lack of any instructions on how to delete the certificate is an oversight on my part, and I'll be working on this. Regarding the binaries: all of them are built on GitHub's CI. I wish there was a way for users to verify this fact, but to my knowledge, there is no way to do that currently. You can run and build the app yourself using Wails (https://wails.io/docs/gettingstarted/installation). I'll be sure to add more instructions to the repo in the coming days.
As always, any feedback, help, and suggestions are much welcome.