1. 6
  1.  

  2. 5

    Privoxy is neat but the same can be achieved with Squid and an appropriate block list (the setup I use). One of the better free blocklists is available from pgl.yoyo.org - lists are available for all the popular proxies, in hosts format, DNS zone format, etc.

    One downside of the move to https is that it’s getting more difficult to block ads via a proxy. Moving to DNS-based blocking is an alternative, but it can be a bit heavy-handed if both ads and non-ad content are saved from the same DNS hostname.

    1. [Comment removed by author]

      1. 1

        Nowadays, with ad blockers commonly available across both desktop and mobile, there isn’t a huge difference. I have a feeling in-browser blockers have some limitations though (eg, I don’t think they can prevent the HTTP referer header from being sent).

        I starting doing this with Squid years ago, long before mobile ad blockers were available and I’ve just continued. For complete coverage I do use multiple approaches though - ad blocking proxy as well as ad blockers on mobile and in-browser. Nothing like a shotgun approach, I say!

      2. 1

        One downside of the move to https is that it’s getting more difficult to block ads via a proxy.

        If you run the proxy it’s not that much harder to issue certs on-the-fly (e.g. mitmproxy can do this)

        1. 1

          True (and Squid can do it without any addons - see SSLBump). I’m not at all comfortable with MITMing SSL though.

          1. 1

            I wouldn’t do it on a vps, and I’d want a browser grade tls stack for revocation etc, but the benefits are solid. Definitely tempted.

      3. 4

        What’s the difference between this and a browser extension like ublock origin?

        1. 6

          Privoxy can block ads outside the browser, e.g. when you curl things, but it can’t block ads on pages that are served over https (which makes it pretty useless IMO).

          1. 5

            Ublock doesn’t parse html with a regex…

            1. 1

              Who parses html with regex? Or is that your point?

              1. 3

                privoxy filters do. there’s even a section of the faq devoted to the problem of a filter accidentally mangling a perl script you’re trying to download.

          2. 4

            I think the success of Safari’s content blocking system shows the way forward for this type of thing.

            A proxy based solution has some major shortcomings compares to content blockers:

            • can’t securely & easily work on https pages
            • doesn’t work when mobile OR requires all your traffic to go to a remote server
            • isn’t easily toggle-able for one-time page loads where you need/want all traffic to load (i.e. pages broken without a blocked resource)
            1. 6

              I partially came to the opposite conclusion. For many sites, I don’t just want to block some banner ad or whatever, I want to strip out a lot of the crap that’s in the html. Or the 3MB CSS file. I want to do that upstream, as close to the source as I can.

              I’m slowly chipping away at a web based headless “browser”…

              1. 3

                I’m slowly chipping away at a web based headless “browser”…

                I’m getting to this point too, though not chipping away at it. But, RMS’s once considered absurd method of browsing the web, namely, send an email, get the, effective, output of curl $url doesn’t seem so bad these days.

            2. 3

              “Note that the Privoxy project currently has no trusted build infrastructure” pretty much kills this for me. If they had a git repo or did signed source releases, maybe, but as is there’s nearly no chance I would take some random person’s binary build, stick a trusted cert on it, and lob all my traffic through it.