Re: draft-ietf-http-state-mgmt-01.txt LAST CALL

Marc writes:
> Syntax:
> 
> The augmented BNF doesn't contain a comment keyword as per HTTP 1.1.
> Translucence of the cookie is important, as the cookie speaks the server's data
> on the user for the user at the user's command.  A server's documentation of
> the contents of its cookies can both aid a user in determining whether they
> want to keep a cookie in their cookie jar, and could be used legally in certain
> jurisdictions bind a content provider's representation of cookie functionality
> to actual functionality to prevent abuses.  The absence of cookie commentary
> can be of value itself.  This can be accomplished either by commenting each
> chip in the cookie or by providing a URI as a link to a key describing this
> flavor of cookie.

Boy, am I tired of the extended metaphors on cookie, especially the
mixed metaphors.  A translucent, flavored cookie?  

Anyway, the spec states that while the cookie is to be considered opaque,
it may contain anything which the server chooses, including commentary,
patriotic songs, or whatever:

     The VALUE is opaque to the user agent and may be anything the
     origin server chooses to send, possibly in a server-selected
     printable ASCII encoding.  ``Opaque'' implies that the content is
     of interest and relevance only to the origin server.  The content
     may, in fact, be readable by anyone that examines the Set-Cookie
     header.

So you may embed a comment within the cookie if you like.  That comment
is part of the cookie, though, and cannot be hacked off.  This makes
parsing the name/value pairs much easier as you don't need a new seperator
for the Value and the comment.   

Please don't, by the way, drag into the cookies requirements for legal
explanations for any jurisdiction; we went through this with the Warnings
and it is not a good idea.  See the mailing list archives.

> 7.2  Protocol Design
> 
> |Therefore a request-host is limited as to what values it can set for Domain.
> |We consider it acceptable for hosts host1.foo.com and host2.foo.com to
> |share cookies, but not a.com and b.com.
> 
> I'm not a DNS guru, but it seems possible to use cookies, redirects and
> cooperating DNS domains to achieve the 1:n cookie functionality in accordance
> with this document:
> 
> Say that a.com and b.com conspire to create a new domain between them called
> spy.com.  In the DNS foo.a.com is also foo.spy.com and bar.b.com is also
> bar.spy.com (perhaps multi-homed).  One initiates a connection to foo.a.com,
> recieves a redirect with a Set-Cookie (cookie-1) to foo.spy.com which itself
> returns a Set-Cookie (cookie-2) for .spy.com.
> 
> a.com and  b.com et al conspire to redirect all requests with cookie-1 to the
> appropriate *.spy.com where cookie-2 is sent and the user is tracked.  If this
> is correct, then Set-Cookies in 302 responses are as dangerous to privacy as
> 1:n cookies.
> 

Note in your example that all of the actual data is coming from spy.com.  From the
user's point of view, they are connecting to spy.com, and lots of features in
User Agents will make that obvious.  If two sites (say, cnn.com and msnbc.com)
are so interested in sharing cookies that they are willing to appear as tv.com
to the user, then I think that they have done enough to make the user aware that
they may share information.  

				regards,
					Ted Hardie

Received on Thursday, 20 June 1996 13:04:47 UTC