RE: comments on jaye-trust-state-01

"Jaye, Dan" <DJaye@engagetech.com> wrote on Fri, 12 Sep 1997 00:26:13 -0400:

DMK>
  > Although a server may emit PICS-Label immediately after Set-Cookie2, 
  > it
  > may not be in that position at the client, due to proxy header
  > shuffling.  The only guarantee is that the relative order of
  > Set-Cookie2 headers will be preserved, as will the relative order of
  > PICS-Label headers.  But they well may get separated (particularly 
  > with
  > header folding).
  > 
DJaye>
  > The goal here is to work within the constraints of the current 
  > PICS-Label header syntax and the cookie syntax.   I will propose that 
  > we make a trust-label apply to all cookies that match the "for" 
  > attribute of the PICS-Label as opposed to specifically enumerating all 
  > cookies for which the PICS-Label applies.  In the end...the trust 
  > label is issued for a URL-space... not a specific cookie.

That's okay, I guess, and it makes it resemble the rules for Path= in
RFC 2109.  In that case, you probably need rules that describe how a
more specific "for" takes precedence over a less specific one.  For
example, if you have

	[label1] for "http://foo.com/a/" ratings { noshare 1 }
and	[label2] for "http://foo.com/a/b/ ratings { noexchange 1 }

then label1 applies to cookies for http://foo.com/a/xyz, and label2
applies to cookies for http://foo.com/a/b/qrs.

  > 
DMK>
  > There would appear to be a possible danger with using "PICS-Label".
  > Suppose the origin server wants to emit one PICS-Label to label the
  > content, and another to label the cookie.  Header folding would group
  > all PICS-Label headers together, making it harder to pick out which
  > ones apply to cookies, and which to content.
  > 
DJaye>
  > The key issue is how does the user agent determine which PIC-Label 
  > headers it needs to interprete to process the cookies.  At this point 
  > they will look for ServiceID's that correspond to trust-labels.  I 
  > propose that the browser will have a list of these ServiceID's 
  > available.  ServiceID's are modified so they now point to a URL that 
  > describes the rating system rather than a specific Trust Authority.

I'm certainly no authority on the PICS label mechanism, but it seems to
me that it would be desirable to have some kind of more robust way to
identify labels that are intended for cookies.  Otherwise a browser
that has an incomplete list of Trust Authority rating systems would
interpret the serviceID of an unrecognized (cookie) TA as a PICS
content rater, which might interfere with correct treatment of that
content.

Is there a place to add an attribute that describes the
function/purpose of a PICS-Label?  Such an extensible mechanism would
make it possible to expand the role of the PICS-Label to other, similar
purposes.  A label with no such attribute would by default be for
content.  Then you might have { function cookie-rating } to identify
labels that rate cookie privacy policies, for example.
  > 
  > ....
  > 
  > 
DMK>
  > There seems to be the implication that the privacy-practice values
  > form a partial ordering, and that a more-stringent privacy-practice
  > in a trust label should be acceptable to a user agent that is set to
  > accept less-stringent ones, but that ordering and treatment isn't
  > spelled out explicitly and should be.
  > 
DJaye:
  > There is no sensitivity to ordering.  The ratings are independent. 
  >  The numeric values are merely an artifact of the PICS rating spec 
  > that requires a "string number" format.  The fact that there are 
  > different rating strings rather than one string with four levels is 
  > intended to convey that they are independent.  The examples at the end 
  > also convey this by describing privacy preferences that enumerate all 
  > acceptable ratings.

Okay.  I think I failed to read the examples carefully enough.  I see
now how they're independent.

This design does raise an implementation, user interface, and
deployment observation, however.  A user agent has to have a ([an]
extensible) way to decide what ratings services are acceptable.  It
then has to be able to grab a list of the ratings strings for a
service, and it has to be able to present them all to the user as a set
of independent checkboxes that the user can select.  And the UA has to
be able to do this for *each* rating service.  Sounds like "fun"!

  > 
  > 
  > [...]
  > 
DMK>
  > One of the contentious issues with RFC 2109 has been the concept of
  > "related servers" (although it isn't called that) to which a user 
  > agent
  > can send a cookie.  That's the business with the domain-matching, the
  > "two-dot rule", etc.  The trust-label mechanism is even *more*
  > restrictive, since the label applies to a single host.  Won't that
  > restriction be even more objectionable?
  > 
DJaye>
  > The assumption is that each host obtains a separate trust-label.  This 
  > does not prevent cookie-sharing (where acceptable to the user-agent).

Okay.  I wonder if sites that use a large number of hosts will be pleased,
though.
  > 
  > [...]
  > 
DMK>
  > > The User Agent should have a default preference to reject 
  > "third-party-
  > > exchange" cookies from unverifiable transactions.
  > 
  > Need a definition of "third-party-exchange"; or omit this statement, 
  > since
  > it appears in RFC 2109.
  > 
DJaye>
  > Should be "thirdpartyexchange", i.e., the well known rating value 
  > described in 3.1.

I think there are two different concepts here, I think.
"Third-party-exchange cookies" (actually, they're "third-party
cookies") are the mechanism by which a cookie arrives or gets sent in
an unverifiable transaction.  Such cookies are exchanged with a server
other than the one with which the origin transaction was made.

Thirdpartyexchange, as defined in 3.1, deals with the information
actually gathered by using a cookie.  The holder of the information
asserts they plan to share the information with others.

So, xyz.com might use cookies, gather information, and plan to sell
it to others, and their rating would be "thirdpartyexchange 1", but
the cookies themselves would only go between a user an xyz.com.
Meanwhile, an advertising site, ads.com, might use cookies in
unverifiable transactions, but its rating might be "noexchange 1",
because they use the cookies only to rotate ads, and they do not
distribute the gathered information to anyone else.
  > 
  > >
DMK>
  > > For example, a user may wish to accept cookies rated 
  > anonymousexchange by
  > > a recognized trust authority, rather than relying on an unsigned 
  > trust
  > > label or a trust label signed by an unrecognized entity.
  > 
  > I don't understand the point this statement is trying to make.
  > 
DJaye>
  > The intent was not to require the site to pay for a signed trust 
  > label... so unsigned labels are allowed.  In some jurisdictions, 
  > consumer protection laws about "truth in advertising" may be 
  > sufficient for enforcement.  Also, many parties point out that 
  > REQUIRING small web sites to pay for auditing and verification is too 
  > onerous.  Allowing the implementors / market to decide whether 
  > third-party verification is necessary seemed to be a fair compromise 
  > as long as the user can override the default.

Okay.  I think the "For example" and "rather than" wording is a bit
confusing.  Let me propose alternative wording:

User agents should allow users to select the level of certification
with which they're comfortable.  For example, a user may wish to accept
cookies rated anonymousexchange by a recognized Trust Authority, but
not accept cookies that have an unsigned trust label or that have a
trust label signed by an unrecognized entity.

Dave Kristol

Received on Thursday, 18 September 1997 08:47:06 UTC