Re: firefox > Preferences > When Firefox starts.
On Thu 25 Apr 2019 at 12:28:37 (-0400), Lee wrote:
> On 4/25/19, David Wright <deblis@lionunicorn.co.uk> wrote:
> > On Wed 24 Apr 2019 at 14:29:00 (-0400), Lee wrote:
> >> On 4/24/19, David Wright <deblis@lionunicorn.co.uk> wrote:
> >> > On Tue 23 Apr 2019 at 10:38:41 (-0400), Lee wrote:
> >> >> On 4/22/19, David Wright <deblis@lionunicorn.co.uk> wrote:
> >> >> > On Sun 21 Apr 2019 at 20:30:53 (-0700), peter@easthope.ca wrote:
> >> >> >> From: David Wright <deblis@lionunicorn.co.uk>
> >> >> >> Date: Sun, 21 Apr 2019 16:13:11 -0500
> >> >> >> > Does the behaviour reported in your OP cause you *great* concern?
> >> >> >>
> >> >> >> No. Just wastes time. Opening a simple local HTML home page
> >> >> >> requires
> >> >> >> roughly a minute rather than roughly a second.
> >> >> >
> >> >> > I tend to forget that, because my /etc/hosts file has ~14000 lines,
> >> >> > pages appear a lot faster here.
> >> >>
> >> >> Have you looked at bind's dns rpz?
> >> >
> >> > Just now.
> >> >
> >> >> http://zytrax.com/books/dns/ch7/rpz.html
> >> >> It lets you do things like
> >> >> *.2o7.net CNAME .
> >> >> *.doubleclick.net CNAME .
> >> >>
> >> >> to block entire domains instead of having to list each and every
> >> >> hostname in the domain.
> >> >>
> >> >> And you can log what is blocked/allowed to make troubleshooting easier
> >> >
> >> > It might be a good *mechanism* for the diversion itself, but AFAICT
> >> > it's aimed at the *policy* implementers rather than the end-user.
> >>
> >> Just out of curiosity - do you think pi-hole is aimed at policy
> >> implementers or end users?
> >
> > I don't know about their policies, or whether they have any. I've not
> > found any description of how you would configure it, only how you
> > install it. Do they provide blacklists?
>
> It looks like they give you a default list of lists that you can modify:
> https://github.com/pi-hole/pi-hole/blob/master/automated%20install/basic-install.sh#L1181
Yes, and taking one of the sites mentioned, I see they explain their
policy at https://hosts-file.net/?s=policy
and that's what I want done for me.
> > It's also not clear to me where I should install it to. My router
> > uses the Google nameservers, and all my machines have the router
> > as their nameserver. The router is the only part of the network
> > that's always up and running.
>
> I have a server that I leave running all the time;
… and I don't.
> reconfigure your
> router to use your dns server
… which doesn't exist …
> instead of google, add a firewall rule
> to block all outgoing tcp/udp traffic to port 53 except from the
> server & you're done.
>
> > But let me explain what I mean by those terms I used earlier:
> >
> > Mechanism: Any method of modifying the result of trying to resolve
> > foo.bar to an IP address, irrespective of the specific domainnames
> > which somebody has to give to it. My mechanism is resolving to
> > localhost.
> >
> > Policy implementers: The people who make the decisions about which
> > domainnames should have their resolution modified. If you look
> > through the reference I gave for the source of my /etc/hosts, you
> > can see their policies listed as comments bracketing the sections,
> > and they are:
> >
[snipped]
> >
> > End-users: The people whose browsing experience are improved by
> > the policies selected, and implemented using the chosen mechanism.
> >
> >> > The value I get from Dan Pollock is the list of sites rather than the
> >> > most elegant mechanism for handling that list. Looking at the comments
> >> > in the list, and by comparing evolving versions, it does appear that
> >> > Dan actively "opens holes" where people report interference or
> >> > difficulties using certain legitimate sites.
>
> But the holes get opened only after someone reports a problem. If
> you're using a host file, how do you figure out which host name(s)
> being blocked are causing the problem?
I guess the people who report the problem figure that out. Looking at
the comments, they're not services that I use.
> I never figured out an easy way to troubleshoot hostfiles & switched
> to something that logged what all was blocked and allowed.
That would be easy to check. I build /etc/hosts with a commandline:
# cat /root/hosts-[0-9]-*[^~] | sed -e "/^[[:space:]]*192.168.1.[0-9]\+[[:sp
ace:]]\+$HOSTNAME.corp[[:space:]]\+$HOSTNAME\$/s/[[:space:]]*\([0-9.]\+\)[[:sp
ace:]]\+\(.*\)\$/127.0.1.1\t\2\t# \1/" > /etc/hosts
so I would hide Dan's file (whose final destination is a file that
matches /root/hosts-[0-9]-*[^~]) before rerunning that command.
> >> > Finally, I wouldn't know where to start to compile a list of sites
> >> > like that.
> >>
> >> https://dnsrpz.info/
> >> If you're a business, you can buy access to an rpz feed.
> >
> > I'm not, but I take it that different feeds have different policies on
> > which sites to include, and come at different prices.
> >
> >> If you're a [home?] network admin it's simple enough to enable logging
> >> & see what all is allowed that you'd rather have blocked. And/or grab
> >> things like Dan Pollock's list and turn them into an rpz file.
> >
> > Frankly, I don't want to be bothered with processing the list.
>
> That makes it easy then, stay with what you've got :)
Sure. I like to publicise it when I'm reminded that its use might help
someone else fix any sort of problem.
Cheers,
David.
Reply to: