Food for Thought

[Marvin GodfatherofSoul Bellamy]

I need to make a distinction between what I think is a good idea for 
filtering and what exists today.  If there's a law that states that 
pornographic sites and content have to be marked (headers, domain name, 
etc.), then your filtering is absolutely inclusive.  It's not the bogus 
filtering schemes that these commercial products rely on.  Also, it 
makes it easier to prosecute and monitor sites.  Is the site adhering to 
the law by indicating the nature of its content? No? Then penalize.  My 
guess is librarians don't want patrons whacking off in the stacks, but 
are most concerned with the objective nature of filtering by current 
commercial products.

The law should only be enforced in cases where a web site has spammed or 
broadcast links to its content without the indicators.  No need for a 
Porn Patrol snooping around any old porn site (but I'd volunteer).

The filtering can also work in reverse.  If a client sends a certain 
header, then porn sites will block access to that client (allowing 
parental control or proxy control).  Either node has the option to stop 
the porn flow, like killing a persistent connection with HTTP.

-- 
 |/ ____ |/ | Marvin Keith Bellamy
  @~/ Oo ~@  | AKA GodfatherofSoul
 /_( __/ )_ | website:  http://godfatherofsoul.tripod.com
    __U_/    | E-mail:   mbellamy at kc.rr.com

Jason Clinton wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Marvin GodfatherofSoul Bellamy wrote:
> | Whoa, you've just make a flood of posts implying that this is a 
> nebulous
> | issue.  No one is saying take away your rights to download pr0n, God
> | forbid they take mine :)  We're talking about methods for filtering.
>
> We're actually discussing the COPA which is a law that mandates 
> filtering. And
> whether or not filtering is ethical. I'm arguing that not only is 
> mandating
> filtering a Bad Thing, but also the philosophy on which the arguments 
> used to
> support COPA were based.
>
> The technical capacity of a filtering agent is generally regarded as 
> _always_
> permeable (i.e. not fool-proof).
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQE9yDRjtSqjk42zvwkRAl3BAKCPg4X+LS+fZDmFP+yPCEJiz7tmcwCeK0b7
> WY4tEkrqmREFQJrJtsXynL8=
> =xpn1
> -----END PGP SIGNATURE-----
>
>
>
>