Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #14284 > unrolled thread

Parental guardian - internet (WEB) filtering

Back to article view | Back to comp.os.linux.misc

Contents

  Parental guardian - internet (WEB) filtering Tim Watts <tw_usenet@dionic.net> - 2015-03-31 18:36 +0100
    Re: Parental guardian - internet (WEB) filtering Andy Cap <snruwfpgbizo@trashmail.net> - 2015-03-31 18:44 +0100
    Re: Parental guardian - internet (WEB) filtering "Dave Liquorice" <allsortsnotthisbit@howhill.com> - 2015-03-31 19:25 +0000
      Re: Parental guardian - internet (WEB) filtering Tim Watts <tw_usenet@dionic.net> - 2015-03-31 22:13 +0100
        Re: Parental guardian - internet (WEB) filtering "Dave Liquorice" <allsortsnotthisbit@howhill.com> - 2015-04-02 00:03 +0000
          Re: Parental guardian - internet (WEB) filtering Tim Watts <tw_usenet@dionic.net> - 2015-04-02 01:14 +0100
    Re: Parental guardian - internet (WEB) filtering Bill <Billaboard@gmail.com> - 2015-03-31 20:14 +0100
      Re: Parental guardian - internet (WEB) filtering Tim Watts <tw_usenet@dionic.net> - 2015-03-31 22:07 +0100
      Re: Parental guardian - internet (WEB) filtering Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2015-03-31 15:18 -0700
        Re: Parental guardian - internet (WEB) filtering The Real Doctor <ian.groups@btinternet.com> - 2015-04-01 23:10 +0100
          Re: Parental guardian - internet (WEB) filtering Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2015-04-01 17:01 -0700
            Re: Parental guardian - internet (WEB) filtering "Rod Speed" <rod.speed.aaa@gmail.com> - 2015-04-02 11:38 +1100
    Re: Parental guardian - internet (WEB) filtering "john james" <jj9801@nospam.com> - 2015-04-01 06:59 +1100
      Re: Parental guardian - internet (WEB) filtering Tim Watts <tw_usenet@dionic.net> - 2015-03-31 22:13 +0100
        Re: Parental guardian - internet (WEB) filtering Capitol <spam@wher.eva.co.uk> - 2015-03-31 22:19 +0100
        Re: Parental guardian - internet (WEB) filtering "john james" <jj9801@nospam.com> - 2015-04-01 09:46 +1100
          Re: Parental guardian - internet (WEB) filtering Tim Watts <tw_usenet@dionic.net> - 2015-04-01 00:19 +0100
            Re: Parental guardian - internet (WEB) filtering Tim Watts <tw_usenet@dionic.net> - 2015-04-01 16:30 +0100
    Re: Parental guardian - internet (WEB) filtering John Rumm <see.my.signature@nowhere.null> - 2015-04-01 23:50 +0100
      Re: Parental guardian - internet (WEB) filtering Tim Watts <tw_usenet@dionic.net> - 2015-04-02 01:10 +0100
        Re: Parental guardian - internet (WEB) filtering Bobbie Sellers <bliss-sf4ever@dslextreme.com> - 2015-04-03 17:52 -0700
          Re: Parental guardian - internet (WEB) filtering Tim Watts <tw_usenet@dionic.net> - 2015-04-04 09:09 +0100
            Re: Parental guardian - internet (WEB) filtering Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-04 12:24 +0000
              Re: Parental guardian - internet (WEB) filtering Tim Watts <tw_usenet@dionic.net> - 2015-04-04 19:25 +0100
                Re: Parental guardian - internet (WEB) filtering Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-04 19:29 +0000
                  Re: Parental guardian - internet (WEB) filtering Tim Watts <tw_usenet@dionic.net> - 2015-04-04 20:53 +0100
                    Re: Parental guardian - internet (WEB) filtering Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-04 21:58 +0000
                      Re: Parental guardian - internet (WEB) filtering Tim Watts <tw_usenet@dionic.net> - 2015-04-04 23:18 +0100
                Re: Parental guardian - internet (WEB) filtering Richard Kettlewell <rjk@greenend.org.uk> - 2015-04-04 21:28 +0100
                  Re: Parental guardian - internet (WEB) filtering Tim Watts <tw_usenet@dionic.net> - 2015-04-04 21:37 +0100
                Re: Parental guardian - internet (WEB) filtering Andy Burns <usenet.feb2014@adslpipe.co.uk> - 2015-04-05 02:50 +0100
                  Re: Parental guardian - internet (WEB) filtering Tim Watts <tw_usenet@dionic.net> - 2015-04-05 10:58 +0100
                    Re: Parental guardian - internet (WEB) filtering Andy Burns <usenet.feb2014@adslpipe.co.uk> - 2015-04-05 11:27 +0100
        Re: Parental guardian - internet (WEB) filtering Tim Watts <tw_usenet@dionic.net> - 2015-04-04 13:57 +0100
          Re: Parental guardian - internet (WEB) filtering Tim Watts <tw_usenet@dionic.net> - 2015-04-04 19:35 +0100
            Re: Parental guardian - internet (WEB) filtering Tim Watts <tw_usenet@dionic.net> - 2015-04-04 21:39 +0100
    Re: Parental guardian - internet (WEB) filtering usenet@cucumber.me.uk (Andrew Gabriel) - 2015-04-09 09:29 +0000
      Re: Parental guardian - internet (WEB) filtering Tim Watts <tw_usenet@dionic.net> - 2015-04-09 13:35 +0100

Page 2 of 2 — ← Prev page 1 [2]

#14318

On 04/01/2015 05:10 PM, Tim Watts wrote:
> On 01/04/15 23:50, John Rumm wrote:
>> On 31/03/2015 18:36, Tim Watts wrote:
>>
>>> Please, no debates about the merits of this -
>>>
>>> I'm having trouble trying to find anything that might work.
>>>
>>>
>>> DNS based:
>>> ==========
>>> OpenDNS https://www.opendns.com/home-internet-security/
>>> is going to be tricky trying to make that work alongside Unblock-US
>>> which is also DNS based. I might be able to track down the relevant
>>> Netflix zones and declared them in my local DNS server and refer those
>>> to UnblockUS whilst the default is to OpenDNS. In many ways though this
>>> is the easiest solution, except that it has to work along side
>>> UnblockUS.
>>>
>>> No worries about the kids setting their own DNS servers, I'll deal with
>>> that in the firewall :)
>>
>> Sticking cache: in front of the google search usually does for many DNS
>> blocks ;-)
>
> Indeed - I just discovered a nasty in that google image search embed the
> porn^H^H^H^Hresults as data URIs in the HTML.
>
> So OpenDNS cannot block them.
>
> But there's a little known feature in Google in that if you set your DNS
> to resolve www.google.* to the CNAME forcesafesearch.google.com
> then that does what it says - clever...
>
> As for cache - good point.
>
> I think you cannot get everything - but reducing the volume and ease is
> OK - mostly at this stage I want to remove the "by accident" factor...
>
>>> Proxy
>>> =====
>>> eg Squidguard - It will not work with SSL traffic. Well, it might, but
>>> then all my browsers will throw up man-in-the-middle warnings. Seems
>>> like a non starter.
>>>
>>> Bloody big blacklist of IPs
>>> ===========================
>>> Assuming I can load several million into iptables without blowing up the
>>> router (see below), this could work.
>>>
>>>
>>> Any approaches I've missed? Does not need to be perfect - just good
>>> enough to mostly keep them off rotten.com, jihadist beheading vids and
>>> hard core porn. And if they hack their way around it, good for them - at
>>> least they are working for it - no illusions that they will be defeated
>>> for ever.
>>
>> If you still have the Draytek 2830, you can install (paid for extra) a
>> filter in the router itself - that cuts off most of the available
>> circumventions.
>
> I did try that - and it looked interesting, but I've now dropped the
> Vigor in favour of a linux router as it was too buggy and alien to work
> with.
>

	This Linux Journal article might be of help.
<http://www.linuxjournal.com/content/flexible-access-control-squid-proxy>

	bliss

[toc] | [prev] | [next] | [standalone]

#14321

On 04/04/15 01:52, Bobbie Sellers wrote:
>      This Linux Journal article might be of help.
> <http://www.linuxjournal.com/content/flexible-access-control-squid-proxy>
>
>      bliss

That's very interesting - but he seems to have glossed over the SSL 
problem...

[toc] | [prev] | [next] | [standalone]

#14327

On Sat, 04 Apr 2015 09:09:44 +0100, Tim Watts wrote:

> On 04/04/15 01:52, Bobbie Sellers wrote:
>>      This Linux Journal article might be of help.
>> <http://www.linuxjournal.com/content/flexible-access-control-squid-
proxy>
>>
>>      bliss
> 
> That's very interesting - but he seems to have glossed over the SSL
> problem...

I think its been dealt with by the Squid developers. See:
http://wiki.squid-cache.org/Features/HTTPS

but working out exactly how an SSL connection is handled would need more 
than the quick scan I gave it. Squid documentation seems to be a bit 
fragmented and its website's internal search seems to be borked, but 
hopefully that link will give you enough clues to find the relevant 
entries.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#14330

On 04/04/15 13:24, Martin Gregorie wrote:
> On Sat, 04 Apr 2015 09:09:44 +0100, Tim Watts wrote:
>
>> On 04/04/15 01:52, Bobbie Sellers wrote:
>>>       This Linux Journal article might be of help.
>>> <http://www.linuxjournal.com/content/flexible-access-control-squid-
> proxy>
>>>
>>>       bliss
>>
>> That's very interesting - but he seems to have glossed over the SSL
>> problem...
>
> I think its been dealt with by the Squid developers. See:
> http://wiki.squid-cache.org/Features/HTTPS
>
> but working out exactly how an SSL connection is handled would need more
> than the quick scan I gave it. Squid documentation seems to be a bit
> fragmented and its website's internal search seems to be borked, but
> hopefully that link will give you enough clues to find the relevant
> entries.
>
>

I can skip the read - because it is fundamentally impossible to proxy an 
SSL connection at anything above the TCP datastream as you'd need copies 
of the target SSL certs to be able to fake a session that was valid to 
the client.

No amount of squid clever-trickery can help with that.

[toc] | [prev] | [next] | [standalone]

#14332

On Sat, 04 Apr 2015 19:25:23 +0100, Tim Watts wrote:

> On 04/04/15 13:24, Martin Gregorie wrote:
>> On Sat, 04 Apr 2015 09:09:44 +0100, Tim Watts wrote:
>>
>>> On 04/04/15 01:52, Bobbie Sellers wrote:
>>>>       This Linux Journal article might be of help.
>>>> <http://www.linuxjournal.com/content/flexible-access-control-squid-
>> proxy>
>>>>
>>>>       bliss
>>>
>>> That's very interesting - but he seems to have glossed over the SSL
>>> problem...
>>
>> I think its been dealt with by the Squid developers. See:
>> http://wiki.squid-cache.org/Features/HTTPS
>>
>> but working out exactly how an SSL connection is handled would need
>> more than the quick scan I gave it. Squid documentation seems to be a
>> bit fragmented and its website's internal search seems to be borked,
>> but hopefully that link will give you enough clues to find the relevant
>> entries.
>>
>>
>>
> I can skip the read - because it is fundamentally impossible to proxy an
> SSL connection at anything above the TCP datastream as you'd need copies
> of the target SSL certs to be able to fake a session that was valid to
> the client.
> 
> No amount of squid clever-trickery can help with that.

The manual page I referenced *seems* to say either that squid acts as the 
SSL endpoint or that squid uses something it calls a CONNECT tunnel to 
pass the session through to the browser without itself acting as an end-
point. Apparently RFC 2817 gives the gory details of CONNECT tunnels, so 
maybe you should look at this since you appear to know more than I do 
about SSL internals.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#14334

On 04/04/15 20:29, Martin Gregorie wrote:

> The manual page I referenced *seems* to say either that squid acts as the
> SSL endpoint or that squid uses something it calls a CONNECT tunnel to
> pass the session through to the browser without itself acting as an end-
> point. Apparently RFC 2817 gives the gory details of CONNECT tunnels, so
> maybe you should look at this since you appear to know more than I do
> about SSL internals.

OK - I see, I think... It's hard to follow, but if we define terms more 
rigorously:

SSL can never be supported through an HTTP proxy cleanly (without having 
the target certs - note this is basically what a load balancer HTTP 
proxy does, but those would be handling incoming connections to your own 
servers, so you *could* ensure all relevant certs were copied to the 
right places).

I think your RFC is working the problem with TLS - it reminded me of SNI 
(Server Name Indication) which is how a server can virtual-host loads of 
SSL enabled websites with different names/domains on a single IP.

SNI basically lets the client connect with HTTP, then drop a header its 
way saying "I will be addressing you as hostname BLAH". The client them 
(and is only allowed by the server if TLS is being required) to issue a 
STARTTLS which upgrades the connection to SSL in place. The clever bit 
is the server now knows what host the client wants and can select the 
appropriate SSL cert and use that.

I've enabled that on some of my work servers (that cover several 
domains) and it works a treat with any modern-ish browser. However wget 
still throws a strop.



So I am wondering if this is a variation - the HTTP proxy can introspect 
the conversation and see the target name and make a decision about how 
to route it, or not.

What would then happen is the client could issue a STARTTLS to the 
server through the proxy and upgrade the end to end connection so no 
certificate problems. The proxy agrees to simply relay the raw 
connection now.


I'm not saying that is what the RFC is detailing, and I'd sure like to 
know if I'm on the right track...


The fly here is *all* SSL enabled servers would have to support this 
otherwise parts of the Internet will be inaccessible via your proxy. 
It's slightly different to SNI, where:

1) You can say "upgrade your browser"

2) And if not (1), then it fails gracefully in that the server offers 
the first, or default SSL cert if it does not get SNI, so you still get 
a connection, albeit your browser will now shout about an incorrect cert 
- though all browsers generally allow the user to override this.

[toc] | [prev] | [next] | [standalone]

#14338

On Sat, 04 Apr 2015 20:53:02 +0100, Tim Watts wrote:

> OK - I see, I think... It's hard to follow, but if we define terms more
> rigorously:
>
Quite - and the rest of the squid documentation isn't any easier.
 
> I think your RFC is working the problem with TLS - it reminded me of SNI
> (Server Name Indication) which is how a server can virtual-host loads of
> SSL enabled websites with different names/domains on a single IP.
>
Sounds likely. I had a very quick ferret through the squid wiki and IIRC 
it uses one mechanism for HTTP and different mechanisms for other 
protocols, eg FTP.

I should add that I haven't attempted to install squid but I did give it 
a fairly close look a while back to see if did anything I need before 
deciding that I don't need any facilities it offers. I have no axes to 
grind over this subject.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#14339

On 04/04/15 22:58, Martin Gregorie wrote:
> I should add that I haven't attempted to install squid but I did give it
> a fairly close look a while back to see if did anything I need before
> deciding that I don't need any facilities it offers. I have no axes to
> grind over this subject.

I should add too - if anyone wants to use OpenDNS, it is NOT as obtuse 
as I made it sound.

if you just want whole net protection, it's a piece of piss - just pop 
it in your router as the DNS server and fix the route to NAT or block 
any other outgoing port 53 connections.

It's only weird because I wanted multiple personality networks whilst 
trying to blend in another DNS based doohicky.

[toc] | [prev] | [next] | [standalone]

#14335

Tim Watts <tw_usenet@dionic.net> writes:
> On 04/04/15 13:24, Martin Gregorie wrote:
>> I think its been dealt with by the Squid developers. See:
>> http://wiki.squid-cache.org/Features/HTTPS
>>
>> but working out exactly how an SSL connection is handled would need more
>> than the quick scan I gave it. Squid documentation seems to be a bit
>> fragmented and its website's internal search seems to be borked, but
>> hopefully that link will give you enough clues to find the relevant
>> entries.
>
> I can skip the read - because it is fundamentally impossible to proxy
> an SSL connection at anything above the TCP datastream as you'd need
> copies of the target SSL certs to be able to fake a session that was
> valid to the client.

I think you’re confused about what a certificate is; they are public
data, and don’t in isolation let you fake anything.

TLS MITM systems do exist; they require each client to trust a key held
by the MITM box.  This is common on corporate networks and Lenovo
laptops.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#14336

On 04/04/15 21:28, Richard Kettlewell wrote:
> Tim Watts <tw_usenet@dionic.net> writes:
>> On 04/04/15 13:24, Martin Gregorie wrote:
>>> I think its been dealt with by the Squid developers. See:
>>> http://wiki.squid-cache.org/Features/HTTPS
>>>
>>> but working out exactly how an SSL connection is handled would need more
>>> than the quick scan I gave it. Squid documentation seems to be a bit
>>> fragmented and its website's internal search seems to be borked, but
>>> hopefully that link will give you enough clues to find the relevant
>>> entries.
>>
>> I can skip the read - because it is fundamentally impossible to proxy
>> an SSL connection at anything above the TCP datastream as you'd need
>> copies of the target SSL certs to be able to fake a session that was
>> valid to the client.
>
> I think you’re confused about what a certificate is; they are public
> data, and don’t in isolation let you fake anything.

OK - bad terminology because I was being fast and loose - "key", then to 
be specific.

> TLS MITM systems do exist; they require each client to trust a key held
> by the MITM box.  This is common on corporate networks and Lenovo
> laptops.

[toc] | [prev] | [next] | [standalone]

#14341

Tim Watts wrote:

> it is fundamentally impossible to proxy an
> SSL connection at anything above the TCP datastream as you'd need copies
> of the target SSL certs to be able to fake a session that was valid to
> the client.
>
> No amount of squid clever-trickery can help with that.

Create your own CA, tell all the household machines to trust its 
certificate as a CA, intercept all SSL, create a certificate on the fly 
for the domain being accessed signed by the CA ... it's what Microsoft 
TMG does (and no doubt others) would be surprised if it's not do-able 
with squid.

[toc] | [prev] | [next] | [standalone]

#14342

On 05/04/15 02:50, Andy Burns wrote:
> Tim Watts wrote:
>
>> it is fundamentally impossible to proxy an
>> SSL connection at anything above the TCP datastream as you'd need copies
>> of the target SSL certs to be able to fake a session that was valid to
>> the client.
>>
>> No amount of squid clever-trickery can help with that.
>
> Create your own CA, tell all the household machines to trust its
> certificate as a CA, intercept all SSL, create a certificate on the fly
> for the domain being accessed signed by the CA ...

oooo...

That could work - by by *** that's devious!

> it's what Microsoft
> TMG does (and no doubt others) would be surprised if it's not do-able
> with squid.
>
>
>

[toc] | [prev] | [next] | [standalone]

#14343

Tim Watts wrote:

> Andy Burns wrote:
>
>> Create your own CA, tell all the household machines to trust its
>> certificate as a CA, intercept all SSL, create a certificate on the fly
>> for the domain being accessed signed by the CA ...
>
> oooo...
> That could work - by by *** that's devious!

For squid, some relevant search phrases seem to be peek, splice, bump 
and mimic.

I don't like workplaces that do it, but it's pretty necessary in schools ...

[toc] | [prev] | [next] | [standalone]

#14328

On 02/04/15 01:10, Tim Watts wrote:
>
> But there's a little known feature in Google in that if you set your DNS
> to resolve www.google.* to the CNAME forcesafesearch.google.com
> then that does what it says - clever...
>

OMG that was unexpectedly difficult to do in bind9 (easier in dnsmasq 
apparently):

https://productforums.google.com/d/msg/websearch/srXRvrF1ERg/qtvZfsaWsIQJ

But it does work - even in a "view"

So onwards and upwards - now to blend netflix.* and OpenDNS...

[toc] | [prev] | [next] | [standalone]

#14331

On 04/04/15 13:57, Tim Watts wrote:
> On 02/04/15 01:10, Tim Watts wrote:
>>
>> But there's a little known feature in Google in that if you set your DNS
>> to resolve www.google.* to the CNAME forcesafesearch.google.com
>> then that does what it says - clever...
>>
>
> OMG that was unexpectedly difficult to do in bind9 (easier in dnsmasq
> apparently):
>
> https://productforums.google.com/d/msg/websearch/srXRvrF1ERg/qtvZfsaWsIQJ
>
> But it does work - even in a "view"
>
> So onwards and upwards - now to blend netflix.* and OpenDNS...

Right - it works!

This is going to get a blog write up - but essentially my logic is:

4 WiFi ESSIDs each mapping to 4 VLANs/netblocks.

2 are protected and Unblock-US enabled for Netflix enjoyment.

Basically the magic is thus:

named.conf:
view "filtered" {
         match-clients { filter; };
         forward only;
#
#   Default forward to OpenDNS
#
         forwarders {
         208.67.222.222;
         208.67.220.220;
         };
         include "/etc/bind/named.conf.default-zones";
         include "/etc/bind/common/inc-internal-tentacleacres.conf";
         include "/etc/bind/common/inc-forcegoogle-safesearch.conf";
         include "/etc/bind/common/inc-sites-to-unblockus.conf";
};

## So by default queries from "filter" clients (an ACL that includes the 
2 protected netblocks) are forwarded to OpenDNS servers where we have an 
account.

inc-forcegoogle-safesearch.conf looks like:

#
# Catch google queries and force to safesearch
#
response-policy { zone "google"; };
#
zone "google" IN {
     type master;
     file "/etc/bind/master/db.google";
     allow-query { none; };
};


No credit to me - I nicked Terry's work in a previously referenced link.
Works a treat though - and the zone file looks like:

$TTL 1D
;
; overrides for www.google.* to force safesearch
;
@ IN    SOA         localhost. hostmaster.dionic.net. (
         2015040436  ; Serial (YYYYMMDD##)
         1H          ; Refresh
         1H          ; Retry
         1H          ; Expire
         1H )        ; Default_ttl

@       IN  NS      localhost.
;
; Google forced Safe Search zone and data
;
google.com           IN CNAME forcesafesearch.google.com.
www.google.com       IN CNAME forcesafesearch.google.com.
google.ad            IN CNAME forcesafesearch.google.com.
www.google.ad        IN CNAME forcesafesearch.google.com.
google.ae            IN CNAME forcesafesearch.google.com.
www.google.ae        IN CNAME forcesafesearch.google.com.
... etc



Then the merge in of Unblock-US - this is a bit of a kludge but does work:

### inc-sites-to-unblockus.conf

# Declare netflix zones to forward to unblock-us DNS servers
#
# We need this!
zone "unblock-us.com" IN {
     type forward;
     forwarders {
         208.122.23.22;
         208.122.23.23;
     };
};
#
# Netflix domains
#
zone "netflix.com" IN {
     type forward;
     forwarders {
         208.122.23.22;
         208.122.23.23;
     };
};
zone "netflix.net" IN {
     type forward;
     forwarders {
         208.122.23.22;
         208.122.23.23;
     };
};

zone "nflximg.com" IN {
     type forward;
     forwarders {
         208.122.23.22;
         208.122.23.23;
     };
};
zone "nflximg.net" IN {
     type forward;
     forwarders {
         208.122.23.22;
         208.122.23.23;
     };
};
# Yes, we do need this.
zone "elb.amazonaws.com" IN {
     type forward;
     forwarders {
         208.122.23.22;
         208.122.23.23;
     };
};
#
# End of Netflix
#


The worst bit there is having to grab elb.amazonaws.com and throw it 
towards UnblockUS's DNS servers - without it the stream simply will not 
load.


We have some netfilter rules too for force all relevant DNS queries to 
go to our server and to make sure that queries to OpenDNS consistently 
originate from one particular IP (because they only let to regsiter 
(easily) one IP on the free account).


However, it works - and it works really well. +100 vote for OpenDNS - 
they have some lovely category filters that you can tick on/off as 
required and you can add white and blacklisted domains in.


No way is it bompproof - nothing is. But to circumvent it, the kids will 
either need a VPN or a proxy (eg ssh server or raw SOCKS5 proxy) outside 
my networks. If they figure that out I will be proud of them. Then I'll 
fix that too :)

[toc] | [prev] | [next] | [standalone]

#14337

On 04/04/15 19:35, Tim Watts wrote:
> On 04/04/15 13:57, Tim Watts wrote:
>> On 02/04/15 01:10, Tim Watts wrote:
>>>
>>> But there's a little known feature in Google in that if you set your DNS
>>> to resolve www.google.* to the CNAME forcesafesearch.google.com
>>> then that does what it says - clever...
>>>
>>
>> OMG that was unexpectedly difficult to do in bind9 (easier in dnsmasq
>> apparently):
>>
>> https://productforums.google.com/d/msg/websearch/srXRvrF1ERg/qtvZfsaWsIQJ
>>
>> But it does work - even in a "view"
>>
>> So onwards and upwards - now to blend netflix.* and OpenDNS...
>
> Right - it works!

It works better now I have told OpenDNS to blacklist archive.org and 
webcitation.org (both quite comprehensive archives...

I expect there are a few more - but not that I can trivially find.

[toc] | [prev] | [next] | [standalone]

#14423

In article <vh2rub-54e.ln1@squidward.dionic.net>,
	Tim Watts <tw_usenet@dionic.net> writes:
> Please, no debates about the merits of this -
> 
> I'm having trouble trying to find anything that might work.

Don't have kids myself, but we used to get asked this a lot by
colleagues because I've always worked on networking, so we had
many discussions about it over the years, between the techies
and and non-technical parents (usefully spread across many
countries, so could also contrast approaches).

Bottom line - forget filtering. It just gives you a false sense
that you have protected your children, when in fact you haven't.
The best it gets you is protection from mistyping a URL and
ending up somewhere less pleasent than you actually intended.
It's all quite easily got around, and easy to deploy solutions
to do this pass amongst the teenage community all the time. As
many parents know all too well, the blocking in the UK by some
ISPs is effective only for the parents, as almost every teenager
quickly learns how to circumvent it.

You need to handle this with supervised internet use until the
children are old enough to understand there are dangers out on
the internet (and they can understand that principle long before
they can or need to understand more precisely what the dangers
are). Depends on the maturity of the child and quality of guidance
by the parents, but by age 8, you can teach them enough to use
the internet safely without you sitting next to them, but you
should be in the same room and keeping an eye on them, e.g. using
a PC, tablet, or whatever in a family room in the home, not at
that stage in private.

In early teens, you must expect that a child is going to be using
the internet increasingly unsupervised, and over the period from,
say, 8 to 13, you need to be preparing them for that point. That
means age appropriate education on more precisely what the
dangers are out in the real world, such as porn, social website
bullying and personal safety, terrorism, eating disorders, body
image, etc. If you do this right, when they eventually stumble on
these issues (as they surely will), it won't be such a surprise
or something they don't understand, because they will be able to
put it into context. The internet means you can't pretend things
you may find unsavory don't exist, and you need to educate your
children about at a yonger age than you perhaps became aware.

Finally (and particularly revelant in UK at the moment due to the
current goverment's hangups) - don't fly off the handle if you
find your teenager watching porn. Hormones are a powerful drive
for anything sexual at that age, and you should probably be more
worried if your teenager is not showing any such interest. My
European colleagues find this UK attidude bemusing, and yet they
manage to bring up teenagers with significantly fewer sexual
problems than we do without worrying about them being exposed to
porn. If you have talked about porn as one of the internet's
contents beforehand so they understand the difference between
porn and relationships, it's not normally anything to worry about.
Making a fuss about it will just stop your kids feeling they can
talk to you about such issues, which is potentially much more
damaging.

-- 
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]

[toc] | [prev] | [next] | [standalone]

#14424

On 09/04/15 10:29, Andrew Gabriel wrote:
> In article <vh2rub-54e.ln1@squidward.dionic.net>,
> 	Tim Watts <tw_usenet@dionic.net> writes:
>> Please, no debates about the merits of this -
>>
>> I'm having trouble trying to find anything that might work.
>
> Don't have kids myself, but we used to get asked this a lot by
> colleagues because I've always worked on networking, so we had
> many discussions about it over the years, between the techies
> and and non-technical parents (usefully spread across many
> countries, so could also contrast approaches).
>
> Bottom line - forget filtering. It just gives you a false sense
> that you have protected your children, when in fact you haven't.

I'm afraid I disagree - quite strongly.

There's way to much bad stuff like rotten.com and other sick crap.

The art here is not to eliminate it but to seriously reduce the risk of 
accidental and mildly curious exposure.

I'm managed that as detailed above in a  previous post.

> The best it gets you is protection from mistyping a URL and
> ending up somewhere less pleasent than you actually intended.

That's actually extremely important.

> It's all quite easily got around, and easy to deploy solutions
> to do this pass amongst the teenage community all the time. As
> many parents know all too well, the blocking in the UK by some
> ISPs is effective only for the parents, as almost every teenager
> quickly learns how to circumvent it.

They'll have to work on it here - I've sewn it up pretty tight. And if 
they get some porn out of some seriously hacking, fair play to them.

> You need to handle this with supervised internet use until the
> children are old enough to understand there are dangers out on
> the internet (and they can understand that principle long before
> they can or need to understand more precisely what the dangers
> are). Depends on the maturity of the child and quality of guidance
> by the parents, but by age 8, you can teach them enough to use
> the internet safely without you sitting next to them, but you
> should be in the same room and keeping an eye on them, e.g. using
> a PC, tablet, or whatever in a family room in the home, not at
> that stage in private.
>
> In early teens, you must expect that a child is going to be using
> the internet increasingly unsupervised, and over the period from,
> say, 8 to 13, you need to be preparing them for that point. That
> means age appropriate education on more precisely what the
> dangers are out in the real world, such as porn, social website
> bullying and personal safety, terrorism, eating disorders, body
> image, etc. If you do this right, when they eventually stumble on
> these issues (as they surely will), it won't be such a surprise
> or something they don't understand, because they will be able to
> put it into context. The internet means you can't pretend things
> you may find unsavory don't exist, and you need to educate your
> children about at a yonger age than you perhaps became aware.
>
> Finally (and particularly revelant in UK at the moment due to the
> current goverment's hangups) - don't fly off the handle if you
> find your teenager watching porn. Hormones are a powerful drive
> for anything sexual at that age, and you should probably be more
> worried if your teenager is not showing any such interest. My
> European colleagues find this UK attidude bemusing, and yet they
> manage to bring up teenagers with significantly fewer sexual
> problems than we do without worrying about them being exposed to
> porn. If you have talked about porn as one of the internet's
> contents beforehand so they understand the difference between
> porn and relationships, it's not normally anything to worry about.
> Making a fuss about it will just stop your kids feeling they can
> talk to you about such issues, which is potentially much more
> damaging.
>

I agree with all that, but as I've solved about 99% of the problem I 
only have the 1% to worry about...

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.os.linux.misc

csiph-web