NODE ee45bf81NYET--attempted formal specs (again)
Nathan Zook <nzook@bga.com>Wed, 2 Aug 95 06:53:05 PDT
I hope I'm not becoming Detweileresqe about this, but I've had some
requests for these. Since not even I was satisfied with my original
notation, I thought I'ld try again...
(donning gear)
-----BEGIN PGP SIGNED MESSAGE-----
Copyright 1995, Nathan Zook. All rights reserved.
NYET-- Non-Youths Exhibit Temperance.
This is a rising, legitamate concern among parents that their children
have all-to-easy access to porn on the internet. Last year, there
were numerous proposals for various voluntary self-rating systems.
AOL and Prodigy heavily censor their systems in various ways. This
year, Senator Exon advanced his own proposal. Of course, this occured
just about the time that SurfWatch came out.
But none of these proposals can ultimately succeed. Here I restate my
NYET proposal from last year for your consideration. The system is of
necessity ISP-based. Home-based systems are subject to attacks at
home. Since many (most?) children are better with computers than
their parents, these attacks can be expected to succeed.
Any ISP-based system requires that the ISP determine which customers
are not of majority age and who is legally responsible for them.
There are technical solutions to this problem which are part of the
basis to the proposal.
The elements of NYET are as follows: the ISP, monitoring software, the
parent/guardian of the minor, and one or more ratings services.
A NYET-ISP does not grant access priveleges to minors without prior
contact with the (generically) parent of the minor. This contact
includes explaining and helping configure the NYET software in
accordance with the parent's wishes.
The NYET-software runs as superuser on the ISP's machine. All minor
accounts have a corresponding configuration file sitting in their
account owner's parent's directory, which is locked with read/write by
owner only flags. The correspondence between minor and parent
accounts sits in a file owned by root and similiarly locked.
The parent sets the configuration file to permit and deny access to
various parts of the net. Since it is unreasonable for the parent to
personally "rate" the net, it is expected that various organizations
will form ratings services. The parent could then select various
combinations of ratings criteria from these agencies as default. It
is expected that the services would charge for their information. It
is likely that these charges could be added to the monthly bill that
the parent receives from the ISP.
And the role of government? Right now--none other than to encourage
parental involvement. Any attempt to force this, or almost any other,
type of restriction by legislative "I say so" (fiat in Latin) will
meet with fatal opposition. Until the legislature understands the
net, the combined efforts of the millions who use the net will swamp
any efforts to control it.
Speaking of government, school internet access is the bane of any
attempt by parents to control the access that their kids have to the
net. Anyone seeking to limit children's access should look carefully
at this experimentation.
I post this proposal because I believe it to be one of the few stable
attractors in this problem. I believe that Prodigy and SurfWatch
amount to first iterations, and that the market will push them towards
NYET. When it does so move, and a majority of ISPs provide or nearly
provide NYET service, and ONLY then, the government might mandate the
NYET standard. As a somewhat earlier measure, the government could
offer to hold harmless ISPs that adhere to these standards--but only
when the market has already handled the technical hurdles.
I feel it necessary to reiterate the importance of the government
waiting for a market solution to this problem. By its design, the net
appeals to libertarians and anarchists. For many years, it has been
accessible almost exclusively by people demographically predisposed to
a libertarian or anarchist world view. The net.gods, when angered,
can produce no end of michief. And since they designed the system,
they won't be stoppable.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMB73X34gWvtXVTwZAQFKsAP9E/NOfKrt7WwcvNdMlWzg8jneyVa19hL+
9Ot7Ir4SigZJDDQ7hjxS2elJourCZpFWpBXFdKMbTGqTXMtmELZJu5qYidXDmV1i
BAWHYI0RW2E6MszGSgAh1MDfUpY7/RO89CjsuP8M3aGVF44FOWpIoTRZnNhXRO9q
xnA2tErpz+A=
=NpaG
-----END PGP SIGNATURE-----
NODE e18e7410Re: NYET--attempted formal specs (again)
futplex@pseudonym.com (Futplex)Thu, 3 Aug 95 02:06:05 PDT
Nathan Zook writes:
> The NYET-software runs as superuser on the ISP's machine. All minor
> accounts have a corresponding configuration file sitting in their
> account owner's parent's directory, which is locked with read/write by
> owner only flags. The correspondence between minor and parent
> accounts sits in a file owned by root and similiarly locked.
Just a minor technical comment:
Based on my rather limited experience lurking on the firewalls list, I
believe the preferred security-conscious method of running such daemons
involves _not_ giving them su/root privileges. Dr. FBC's thttp, for example,
runs as a user named, e.g., "www" with pretty ordinary privileges. They are
also often run in a chroot()ed "jail", so that the process can't see any
directories outside the tree artifically rooted in its home directory. You'd
then need some mechanism for the `rents to submit configuration updates to
the imprisoned daemon, I suppose. Perhaps digitally-signed email....
-Futplex <futplex@pseudonym.com>
"Before you started tokin' you used to have a brain, but now you don't get
even the simplest of things...." -Offspring
NODE b6f6850fRe: NYET--attempted formal specs (again)
Nathan Zook <nzook@bga.com>Thu, 3 Aug 95 11:33:59 PDT
On Thu, 3 Aug 1995, Futplex wrote:
> Nathan Zook writes:
> > The NYET-software runs as superuser on the ISP's machine. All minor
> > accounts have a corresponding configuration file sitting in their
> > account owner's parent's directory, which is locked with read/write by
> > owner only flags. The correspondence between minor and parent
> > accounts sits in a file owned by root and similiarly locked.
>
> Just a minor technical comment:
> Based on my rather limited experience lurking on the firewalls list, I
> believe the preferred security-conscious method of running such daemons
> involves _not_ giving them su/root privileges. Dr. FBC's thttp, for example,
> runs as a user named, e.g., "www" with pretty ordinary privileges. They are
> also often run in a chroot()ed "jail", so that the process can't see any
> directories outside the tree artifically rooted in its home directory. You'd
> then need some mechanism for the `rents to submit configuration updates to
> the imprisoned daemon, I suppose. Perhaps digitally-signed email....
>
> -Futplex <futplex@pseudonym.com>
> "Before you started tokin' you used to have a brain, but now you don't get
> even the simplest of things...." -Offspring
>
I bow before superior wisdom, such as this....
Nathan
NODE 2918009cNYET--attempted formal specs (again)
pjm@ionia.engr.sgi.com (Patrick May)Wed, 2 Aug 95 11:53:49 PDT
-----BEGIN PGP SIGNED MESSAGE-----
Nathan Zook writes:
[ . . . ]
> NYET-- Non-Youths Exhibit Temperance.
>
> This is a rising, legitamate concern among parents that their children
> have all-to-easy access to porn on the internet. Last year, there
[ . . . ]
>
> But none of these proposals can ultimately succeed. Here I restate my
> NYET proposal from last year for your consideration. The system is of
> necessity ISP-based. Home-based systems are subject to attacks at
> home. Since many (most?) children are better with computers than
> their parents, these attacks can be expected to succeed.
[ . . . ]
>
> The NYET-software runs as superuser on the ISP's machine. All minor
> accounts have a corresponding configuration file sitting in their
> account owner's parent's directory, which is locked with read/write by
> owner only flags. The correspondence between minor and parent
> accounts sits in a file owned by root and similiarly locked.
>
> The parent sets the configuration file to permit and deny access to
> various parts of the net. Since it is unreasonable for the parent to
[ . . . ]
Your solution fails against your specified threat. Children who
are more software-proficient than their parents will, in many cases,
be able to access their parents' accounts and modify the configuration
file (or simply use the account to access the blocked areas).
Ultimately, all such systems are "home-based" if any accounts used by
members of the household have or can be granted access to the naughty
bits (tip o' the hat to M. Python).
While your proposal is obviously marketable, given the success of
Prodigy and the prospects for SurfWatch, it does not appear to be
inherently more secure than schemes that utilize subscriber software.
Regards,
Patrick May
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMB/Jqe5Yg08fDKehAQH16gQAp78uOJX02xNz7/5XYPBcaRZRC8pCWx6K
oUdOxbGta/l1rKrRGWhJ7WLJy9iaopBcbr4YXNOMPL4Va91DEXkJ5rfJKXC+o7Mz
jA0wBujVu0DK+S0C49Ah3OoXxX6H0SorbuscvDF2IIw9aGLSezD49H4/GgWvhklo
Y1Gu5Tfok+Y=
=FsYi
-----END PGP SIGNATURE-----
NODE b7b37aaaRe: NYET--attempted formal specs (again)
Nathan Zook <nzook@bga.com>Wed, 2 Aug 95 16:43:14 PDT
On Wed, 2 Aug 1995, Patrick May wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Nathan Zook writes:
> [ . . . ]
> > NYET-- Non-Youths Exhibit Temperance.
> >
> > This is a rising, legitamate concern among parents that their children
> > have all-to-easy access to porn on the internet. Last year, there
> [ . . . ]
> >
> > But none of these proposals can ultimately succeed. Here I restate my
> > NYET proposal from last year for your consideration. The system is of
> > necessity ISP-based. Home-based systems are subject to attacks at
> > home. Since many (most?) children are better with computers than
> > their parents, these attacks can be expected to succeed.
> [ . . . ]
> >
> > The NYET-software runs as superuser on the ISP's machine. All minor
> > accounts have a corresponding configuration file sitting in their
> > account owner's parent's directory, which is locked with read/write by
> > owner only flags. The correspondence between minor and parent
> > accounts sits in a file owned by root and similiarly locked.
> >
> > The parent sets the configuration file to permit and deny access to
> > various parts of the net. Since it is unreasonable for the parent to
> [ . . . ]
>
> Your solution fails against your specified threat. Children who
> are more software-proficient than their parents will, in many cases,
> be able to access their parents' accounts and modify the configuration
> file (or simply use the account to access the blocked areas).
> Ultimately, all such systems are "home-based" if any accounts used by
> members of the household have or can be granted access to the naughty
> bits (tip o' the hat to M. Python).
Unquestionably, it is not possible to block this hole entirely. However,
that does not mean that this proposal is not still superior, at least on
two points.
First, by moving the monitoring software to the ISP, the instalation &
configuration becomes much easier and more secure for the parent. The
monitoring software itself becomes at least as difficult to hack as the
rest of unix, and the "Hot Babes Watch" hacks at least are prevented.
Secondly, as we move to challenge-response systems, the ability of Jr. to
forge parental access drops considerably. The "Last access on"
information could clue a parent in. (Jr. could reset the clock before
modifying programs at home.)
No one on this list is going to claim that a 17-year old who has been
hacking since he was ten can be stopped. That doesn't make these efforts
doomed from the outset, however. In particular, I want to avoid
non-custom "solutions" for minors attempting access.
Nathan
> While your proposal is obviously marketable, given the success of
> Prodigy and the prospects for SurfWatch, it does not appear to be
> inherently more secure than schemes that utilize subscriber software.
>
> Regards,
>
> Patrick May
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.2
>
> iQCVAwUBMB/Jqe5Yg08fDKehAQH16gQAp78uOJX02xNz7/5XYPBcaRZRC8pCWx6K
> oUdOxbGta/l1rKrRGWhJ7WLJy9iaopBcbr4YXNOMPL4Va91DEXkJ5rfJKXC+o7Mz
> jA0wBujVu0DK+S0C49Ah3OoXxX6H0SorbuscvDF2IIw9aGLSezD49H4/GgWvhklo
> Y1Gu5Tfok+Y=
> =FsYi
> -----END PGP SIGNATURE-----
>