Re: Protocols at the Point of a Gun

[Scott Brickner <sjb@universe.digex.net>]

Bill Stewart writes:
>There are serious technical problems with the suggestion that labelling packets
>as "Adult" or "Child" using IP options and filtering at ISPs for censorship.

Few of the following are really *technical* problems.

>IP works on a per-machine basis (technically, a per-network-interface basis,
>though for most client machines that's the same thing.)  That means that a 
>web or nntp server including some "Adult" material and some "Child" material
>either needs
>a way for an application process to communicate this to the network drivers,
>or needs to label all packets as "Adult" to avoid the politically incorrect risk
>of mislabelling a packet as "Child" when it's not.  The standard TCP/IP API 
>programming interface software on Windows, Mac, and Unix machines doesn't
>provide 
>for applications to _tell_ the network drivers about IP options, so even if
>IPng had censorship features added, the applications couldn't use it.
>(There are a few military multi-level security versions of Unix that give
>you more flexibility for this sort of thing, but they tend to provide
>mandatory security so you _can't_ send a packet marked "UNCLASSIFIED" from a
>"TOP SECRET" session.)  

This is more of an economic problem than a technical one.  By the
"standard API" we usually mean "BSD sockets", which already has a
"getsockopt()" and "setsockopt()" interface for the application to
communicate this sort of thing.  Adding a SO_SECCLASS to change the
setting from the system default would be pretty straightforward,
technically.

>Another problem is that it only addresses single-user client machines,
>rather than multi-user operating systems such as Linux, which has a million
>or so
>users out there.  The model works fine when you treat a PC as a fancy version of
>a dumb terminal, but a machine shared by multiple users (whether many at one
>time,
>or one at a time) uses a single connection to support all of them - that
>means you
>can't have censored material available to the child and uncensored material
>available to the parent unless the networking software can pass the censorship
>labels on to the application program - but again, the standard operating system
>interfaces (developed over many years by thousands of The Free World's finest
>developers :-) don't have a way to implement it, because it was never a
>design goal.

Actually, this is a bit of an "ivory tower" picture of the Internet.
Conceptually, the protocols are purely peer-to-peer, but in the real
world, those end-user Linux boxes go through an ISP.  The User to ISP
link is governed by a contrac, which may specify filtering done at the
ISP.  If you want to access "adult" material, but don't want your kid
to be able to, you should get a separate filtered PPP account for the
kid.

>Trying to implement censored sessions at a transport level instead has its
>own problems.
>First of all, TCP provides reliable sessions; censoring packets based on IP
>labels
>in the middle of a transaction means that TCP will retransmit until the
>packet gets
>through or it gives up and drops the connection, so any "Adult" packets would

Not so.  If one end of the connection is discarding "adult" packets,
the SYN packet attempting to establish the session will *also* be
dropped, probably resulting in a "connection refused" (from a RST by
the other side) or "destination unreachable" (from the IP module that
discarded it).

>dump a Registered Child out of the browser, even if they were unintentional

Dropped connections don't dump you out of the browser.  You just get
a popup.  (If it *does* dump you out, get a new browser.)

>(e.g. from an Adult who labels all packets "Adult" to avoid being liable for
>mistakes,
>or packets from Europe that were default-labelled by a service provider to avoid
>having to read them all, or from the Library of Congress Online Edition if
>the Librarian
>labels each packet correctly.)

Again, these aren't technical issues, they're social.  A European
company who sends a dirty magazine to a sixteen year old American is
violating existing non-CDA decency laws.

>On the other hand, UDP packet exchange,
>which doesn't
>use sessions, would require validating the user's ID and authorization on
>each packet.

True, but this isn't a problem.  The "validation" is simply a matter of
checking the "information level" in the packet with the "authorization
level" of the user.  If the ISP is filtering adult packets, the "authorization
level" is a constant per PPP connection.  If the ISP is inserting "information
levels", it's still constant per PPP connection, but now the content provider
needs to check if the request is permitted to be fulfilled.  In either case
the test is trivial.  It's not like there has to be a key exchange and
RSA exponentiation for each packet.

>Furthermore, if the censorship information is carried at the transport level,
>or at a higher level (i.e. headers in the message itself), the only way the
>ISP's routers, which work at the IP level, can censor packets is to perform the
>equivalent of the Post Office steaming open envelopes before delivering them
>to your house, and refusing to deliver them if there's a child living in the
>house
>and the letter either contains a bad word or is written in a language the
>Post Office doesn't understand, such as Finnish or Japanese or PGP.

Agreed.  But the current discussion is about adding features to the network
layer.

>If you create outgoing packets that are labelled "Minor", and contain
>"Restricted to Government-Certified Adults Only, and No Felons or
>Foreigners Allowed" material, you can get busted for it.
>So you have to either restrict all your outgoing packets to be labelled 
>"RtG-C Adults O,aNFoFA", or else make sure all the material you transmit
>passes the "Government-Approved-for-Minors, Foreigners, and Victorian
>ladies" filter.
>
>On the other hand, if you don't log in to your ISP with a
>"government-certified adult,
>non-felon, non-foreigner, politically stable, not-a-Commie-or-Jew" id,
>it'll block any packets not approved for you.  Any news or web server will also
>have refuse to send any "Adult"-labelled material to you if the requests
>arrived on a "Kid"-labelled connection - this means that either the server
>machine
>will have to only carry Kid-approved traffic, or only talk to Adults,
>or add an "Adult" label to all outgoing packets whether marked "Kid" or not,
>or else it will have to break protocol boundaries by passing IP-layer
>information
>up to the application.

Regardless of whether information is added at the network layer to
communicate the "adult/minor" information, knowingly sending web pages
with adult material to a minor is illegal.  With current implementations,
providers have the excuse that they have no way of knowing that the requester
is a minor.  If the information is added to the protocols, they lose the
excuse.  Again, this is a social matter, not a technical one.

The point about breaking protocol boundaries is an interesting one, and
as far as I am concerned, the *only* technical issue you raise.  I note
that the IP layer's "Security Compartment" option, which is one I've
suggested might be used to implement the censorship, already provides
exactly this "violation".  The "Stream ID" option and "Type of Service"
field are similar "violations".  The TCP layer gives the application
layer the "Urgent" and "Push" flags, which are arguably similar
"violations".

Again, I'd like to emphasize that I think implementing this suggestion
would be censorship, and do more harm than good.  I really hope someone
can come up with a solid technical reason why doing this won't work,
but the more I think about it, the more I think it *will* work.  I
maintain that the CDA is bad socially, but that support for it at the
network layer is technically possible.