As an example - app stores for android. Each manufacturer makes it's own and for years they are unable to cooperate.

It is funny, on the paper I should love this idea but as an app developer the last thing I want is more code coming through the OEMs.

Sadly Google is essential in keeping their shitty hacks at bay.

I suppose an extension is easier but as browsers can be told to go through proxies, an extension isn't necessary for adblocking. A 2nd process on the machine, a change to the browser (set localhost and a port) and you're done. Someone did something similar and called it Dan's Guardian IIRC, but that's all it was.

That's how I run mine, a local (and very ancient) version of squid blocks everything. It won't be as flexible but it works.

Popular ad blockers have features like dynamic heuristic based blocking, right-click to block element, one click whitelist, etc.

That doesn't work as well for https connections where you can only block on domain name, for which any DNS/VPN-based blocking works just as well.

Usually proxying can work for https connections - by letting the proxy terminate ssl. But then you really need to trust the proxy's ssl implementation, and it probably also breaks standard security ui like viewing the cert.

Definitely it has its problems.

The SSL implementation is the least of your problems. You’d need to have a private CA on your system that creates certificates on the fly. How do you secure that proper. You’d also have problems when reporting SSL errors between the site and the proxy to the browser because from the browsers PoV, the connection looks good.

I don't think so, AIUI. The page is decrypted by squid to serve it, so security is irrelevant.

Also it can match on regular expressions <http://www.squidguard.org/Doc/expressionlist.html>

If I'm wrong about the first point, please clarify. Web/HTTP is really not my area so maybe squid receives and passes stuff through entirely as a blob, if https is used.

Edit. What dgoldstein0 wrote suggests I do misunderstand.