No subject

  inherent
       adj 1: existing as an essential constituent or characteristic; "the
              Ptolemaic system with its built-in concept of
              periodicity"; "a constitutional inability to tell the
              truth" [syn: {built-in}, {constitutional}, {inbuilt},
              {integral}]
       2: present at birth but not necessarily hereditary; acquired
          during fetal development [syn: {congenital}, {inborn}, {innate}]
       3: in the nature of something though not readily apparent;
          "shortcomings inherent in our approach"; "an underlying
          meaning" [syn: {implicit in(p)}, {underlying}]


Now, if there is an exception.  If the protocol does allow for
non-anonymous use, then anonymity is not "inseparably attached or
connected".  It is not "an essential constituent".

> The http protocals were designed to allow for anonymous access to
> libraries of documents.  The authentication exemption in no way affects
> the initial premise or fact.

It does however, greatly alter what the protocol is capable of.  If
you had said "was originally designed to allow", I would agree,
however, your original premise or fact was that it is "inherently
annonymous".  HTTP has, however, grown beyond it's original intent,
much as Linux has grown beyond Unix's original intent of providing a
timesharing OS for the PDP 11.  Or even Linux has grown beyond only
running on the x86, and it is no longer *inherently* tied to the x86
architecture, even if it was *originally* tied to that architecture,
or most use cases are still on that architecture.  Unix was certainly
not originally designed to use a GUI, that does not mean X is still
inherently tied to the command line, and not a real GUI.

>> 
>> What's not right?  The Authorization header WAS around in HTTP/1.0
>> (feel free and go read the spec yourself). It wasn't in HTTP/0.9, but
>> that doesn't invalidate my statement.
>> 
>> > Prior to gophernet access to documents require that sysadmins give
>> > usernae and password access to machines, something they rightfully
>> > balked at.  This was the problem that was needed to solved and which
>> > gophernet, and later the wwww protocals resolved.  Security of the
>> > cryptography isn't computer security, but message security. 
>> 
>> But if the Authentication messages are being transmitted securely,
>> then HTTP Auth is a perfectly good method for authenticating.  Probaly
>> better than MIT-MAGIC-COOKIE.
>> 
>> > Prior to these services it was near impossilbe to prevent an
>
> The http proocals allow access to computers without allowing executables
> to be run.  I don't know how to state this more simply and the security
> benifits are obvious.

they allow the transfer of files, and are neutral on what to do with
those files.  However, the notion of using HTTP requests to modify
remote machines in arbitrary ways is the whole reason for the POST
command.  It was always clearly intended to do more than just upload
files.

>> > anonyous user from remove half your hard drive or worse if you gave
>> > them document accces.
>> 
>> Umm....  I remember anonymous read-only FTP well prior to gopher. 
>> 
>
> Yeah, and it being used for exploits and its strange ability to
> cd all over the hard drive and execute random code.

As HTTP has been.  As SMTP has been.  As DNS has been.  

I mean the morris worm propagated through *finger*, which is hardly
designed for running random bits of code on remote machines.  

A 1995 httpd bug allowing arbitrary shell commands by the user running
httpd:

http://www.cert.org/advisories/CA-1995-04.html

the "executing arbitrary code" failures of FTP were all failures in
implementation, rather than fundamental flaws in the protocol.  HTTP
is no more, or no less vulnerable to these sorts of flaws.  Either
protocol, when implemented correctly, allows anonymous (or
authenticated) access to files on a server.  Which files can contain
safe, or unsafe content it is, or is not, safe to execute, and which
decision about whether to execute it is outside the bounds of the
protocol.

-- 
Eric