public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: "Peter Müller" <peter.mueller@ipfire.org>
To: development@lists.ipfire.org
Subject: Thoughts regarding IP-based ad blockers (was: Re: IP Address Blacklists)
Date: Wed, 19 Feb 2020 19:48:00 +0000	[thread overview]
Message-ID: <a61b5896-0582-8450-7b80-7ea1bb92a787@ipfire.org> (raw)
In-Reply-To: <74f000b75d7f9c8ad9df5ce357bcef854343d134.camel@ipfire.org>

[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]

Hello *,

as a footnote on including blacklist feeds covering not inherently
malicious networks, I do not think it is wise to overdo things here.

In my point of view, the main intention of Tim's effort was to drop
connections from criminal or heavily abused IP addresses/networks
efficiently. Compared to what we have today, this is a huge improvement
of which nobody I think is in denial.

However, we must keep in mind dropping packets from and to certain
destinations can cause massive confusion and endless troubleshooting
if somebody sits behind such a firewall without being informed about
this.

>From my own experience, convincing (network) administration staff and/or
management folks to do take step can be quite challenging - it is hard
to imagine they will like a transparent advertisement blocker at IP level
better.

Further, this reminds me of projects like PiHole - which is basically
doing the same thing at DNS level - which I never liked at all. If
anyone intends to block or filter traffic to certain destinations, non-
transparent proxies are the way to do it: Everybody is aware of something
between client and server and does not take unlimited connectivity for
granted. Everybody can easily tell the difference between connection
failures due to network issues and policy reasons.

PiHole et al. exists because we unfortunately have to deal with devices
(a) lacking support for HTTP(S) proxies
(b) connecting to advertisement, tracking or even worse destinations.

Personally, I made good experience in strictly enforcing proxy support:
If a device lacks it, it will not get any internet connectivity. Period.

Thereof, I suggest not to include non-malicious blacklists in this feature
and attempt to ship a first operational version of it rather than arguing
for a long time about possible improvements or disadvantages. I certainly
have to swipe my own hallway first on this... :-)

Thanks, and best regards,
Peter Müller

  reply	other threads:[~2020-02-19 19:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-15 15:40 IP Address Blacklists Tim FitzGeorge
2020-02-18 14:58 ` Michael Tremer
2020-02-18 16:49 ` ummeegge
2020-02-19 11:52   ` Michael Tremer
2020-02-19 17:13     ` ummeegge
2020-02-19 17:21       ` Michael Tremer
2020-02-19 18:43         ` ummeegge
2020-02-19 19:48           ` Peter Müller [this message]
2020-02-19 22:47           ` Tim FitzGeorge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a61b5896-0582-8450-7b80-7ea1bb92a787@ipfire.org \
    --to=peter.mueller@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox