- From: Ted Hardie <hardie@thornhill.arc.nasa.gov>
- Date: Fri, 14 Mar 1997 16:46:08 -0800
- To: "Jaye, Dan" <DJaye@engagetech.com>, 'Yaron Goland' <yarong@microsoft.com>, "'hedlund@best.com\ '" <hedlund@best.com>, "'http-wg@cuckoo.hpl.hp.com\ '" <http-wg@cuckoo.hpl.hp.com>
- Cc: "'dmerriman@doubleclick.net'" <dmerriman@doubleclick.net>
On Mar 14, 7:34pm, Jaye, Dan wrote: > Examples of: non-privacy invading uses: > Content and service aggregators using redirection to allow a visitor > to use many different services under one umbrella where cookies are used > for maintaining state. Although it is sometimes possible for all of > these to be under one domain, it sometimes is not possible or is > impractical. > By any chance do you have a URL pointer to such a service? I have an idea of what you mean, but the examples I can list off the top of my head are under attack for other reasons. > The key point is that the user must be informed. I believe that is why > DoubleClick has suggested that the user be notified that a cookie is > being set and given the opportunity to reject, accept, or specify to > accept all from this domain in the future. This is actually more > informative than transparently rejecting all cookies without notifying > the user at all. Once again, I think more information needs to be made > available to the user than just a domain name of the issuer, like a > third party rating system, certificate, etc. > > BTW, we are not an advertising network or a user of one. I think we agree that more information is key. Where we seem to disagree is in how to get that information to the user and how to behave when it is not being presented. Having used systems which reset cookies on a per-page basis, I can easily see the arguments of those who say that constant display is not the answer. Bad design forces users to turn the display off. An unscrupulous site might well use such a design simply to increase the likelihood that users would turn off cookie notification. > Doesn't the current spec ignore current and legacy browsers as well? Not intentionally. The problem being addressed by the working group now is that one major implementation, based on the early Netscape spec, is not interoperable with the RFC. regards, Ted Hardie NASA NIC NB: I am not in this message speaking for NASA --
Received on Friday, 14 March 1997 16:49:28 UTC