Hacker News Reader

Comment by derefr | Hacker News Reader

There's really no way to disable all ad-blocking in a browser, even if the browser-vendor wanted desperately to do so, because—whether ad-stripping browser extensions exist or not—ad-stripping HTTP proxies (e.g. Privoxy) will always exist.

And if you think users couldn't handle using one of those, there's nothing stopping someone from making an e.g. "Privoxy configurator + blocklist updater" browser extension that just serves as a client GUI to your ad-stripping proxy's control channel. (Or giving the daemon a system-tray icon that launches an Electron GUI or something.)

The development of ad-blockers outside of the browser kind of stalled ~5 years ago, but only because everyone has been pretty satisfied with the browser extension solution to the problem. Take it away, and other solutions will just come back into play, with all the modern lessons learned from building the browser-extensions brought in.

View on HN

The only issue with that is HTTPS, which Privoxy currently can't handle ( https://www.privoxy.org/faq/misc.html ) and will become even more of a problem with the current "encrypt everything" trend. Certificate pinning and all the other stuff aimed at making TLS harder to MITM also gets in the way of effective adblocking proxies. The only one I know of which can MITM SSL on Windows is Proxomitron, and you still have to patch the browser(s).

HTTPS proxying is perfectly possible, though. IMHO it's one of those bizarre cases where the code to implement it isn't even that hard necessarily. The challenge is all in the fact that A: more people think they understand the HTTPS security model than actually understand the HTTPS security model and B: it's really easy to write code that "works" in the sense that it allows you to proxy pages, but allows you to proxy too many pages too easily. Programmers generally acquire a deep and generally-mostly-justified belief that getting code to do the thing they want it to do is the hard part, so code that appears to work is likely more correct than broken, but this is one case where it's quite shockingly easy to write code that works far too "well" and all the challenge is actually in writing all the test cases for when it is supposed to fail to proxy the page.

That's a lot of headwinds on a bit of code, but they are possible to overcome, if the motivation, and perhaps even more importantly, the humility is there.

It'd be nice to lift out Chromium's own network stack into a library (as a continuously-rebased-from-upstream derivative fork), and then build a proxy that made requests using said network stack. Then you'd get all the HSTS/cert-pinning logic, the CORS and only-N-requests-per-host-at-a-time policies, and a very good LRU cache implementation, "for free", for your proxy daemon.

Heck, if you don't mind an extra 100MB of memory consumption, you could probably throw a "correct" proxy-daemon together in Javascript by relying on the browser network stack of a [headless] Electron instance.

Lucky for us (in this case) certificate pinning is considered to risky to actually deploy in production, it is to easy to make the page completely unacceptable with single mistake.

Also it looks like Chrome actually ignores pinning for proxies as a feature: http://www.chromium.org/Home/chromium-security/security-faq#...

Of course there is. They can make it so annoying that the ads doesn't look that bad. They own the browser. They can make it so bad that even flash ads will look like a good alternative to all the work required.

All what work required? Proxying is an OS-level concern, not a browser-level concern. You set it up in your OS's control panel. The browser doesn't get to be a part of that workflow, so it can't make it annoying.

You are ignoring having a proxy in the first place.

Compare adblocking today: step 1, search for extension. Step 2, install extension. Step 3, there is no step 3.

Now convince your parents to install a proxy, then proceed to explain they can have it on each machine (don't forget phones and tablets!) or centrally on the network (now don't forget to explain about local network while at home versus 4g when they are away)... yada yada yada.

You're trying to make it sound more complicated by bringing up complex setups that novice users wouldn't need anyway.

The simple workflow:

Step 1. search for "ad-blocker" on your OS's app store/package manager;

Step 2. choose one [that happens to be a proxy daemon]; hit install.

Step 3. Enter your password when the app asks for admin permission to finish installing (i.e. to install the proxy daemon as a background service, and autoconfigure your OS proxy settings. But you don't need to be aware of that.)

Reply on news.ycombinator.com