Re: Unverifiable Transactions / Cookie draft

[I believe my earlier comments make clear that I disagree with some of
Brian's positions.  I will try to limit these comments to new or
particularly murky points.]

On Tue, 18 Mar 1997, Brian Behlendorf wrote:
> Looking to technology for a solution to the privacy problems is
> as misguided as blaming technology for causing them.  

Brian, I would (in all seriousness) like to have a long discussion with you
on this assertion sometime in the future, but I don't believe it is
relevant to the draft we are discussing.  I don't think anyone is trying to
solve the Web's privacy problems with this draft; and if we were, I would
agree with Yaron that such a goal would be way out of the scope of this WG.
Instead, I believe we are trying to avoid _creating_ privacy problems in
the HTTP spec. 

> The fact that my opinion can be different today suggests it may be too
> early to try and coerce the protocols into implementing policy...

What's "policy"?  I don't consider this "policy" discussion to be all that
different in _scope_ from the discussions we had last year, in which many
WG members asserted that creating a scalable caching mechanism was the most
important work before us.  Is the HTTP spec implementable between one
browser and one server without a solid caching mechanism?  Sure -- but to
leave it at that would ignore the realities of bandwidth depletion and
network congestion that HTTP's implementation has, in part, caused.  So the
group let a "policy" question -- in this case, resource depletion -- guide
its work. 

My point is not that caching (bandwidth conservation) and cookies (privacy)
are indistinguishable -- obviously, there are many dinstinctions.  Instead,
I am arguing that it is specious to dismiss privacy protections as
"implementing policy."  We should not retreat from a privacy issue simply
because it seems a broader concern than the specification of working code.  

[proposal:] 
> 1) By default, user agents are configured to prompt for confirmation on 
>      receipt of all cookies - unlike today's defaults which is to accept
>      all cookies.
> 2) Upon receipt of a cookie, UI must have the options:
>      Accept this cookie
>      Do not accept this cookie
>      Accept all cookies from this domain
>      Never accept cookies from this domain
> 3) UI allows for some indication of pages with content inlined from other
>      servers.  Perhaps specially flag cookie requests for inlined content too.

I think in the above you are doing what Yaron is asking that we avoid:
specifying a UI in a wire protocol.  I would agree with him that the above
is too restrictive. 

> 4) Remove the restriction on unverified transactions.
> 
> Show me this leads to /less/ privacy, particularly in combination with all the
> other existing provisions of the current spec.

Less privacy than what?  The current implementations from the Netscape
cookie proposal?  Perhaps not. The implementations that would arise from
compliance with the draft RFC?  I would argue that (4) above would
substantially reduce privacy protection for the user if compared to the
current draft.  You are arguing for an "after-the-fact" notification (3),
which I don't think is sufficient.

> I really wish this was a more clear-cut situation - that cookies really did
> make the difference between being "database-able" or not.  It doesn't. 

I agree that it doesn't _solve_ the problem of "databasability."  I
disagree that anyone is trying to do that. 

M. Hedlund <hedlund@best.com>

Received on Tuesday, 18 March 1997 11:11:51 UTC