> I have not seen any arguments in this list which counter the various
>scenarios where a server owner has a right and a necessity to store state
>info in a client. Ignorance of cookies and what they ameliorate (server
>states, huge hidden URLs, vast hackery) drives the paranoia that impedes a
>useful state mechanism. UA helpfiles and configuration UIs that allow
>defeating Cookies (and the Net apps that rely on them) are more than proof
>against this ignorance. The remedies to Cookie incompatibility in the new
>draft are valuable, but rendered worthless if Cookies are unused due to
>their unreliable presence in an application architecture.
If you haven't seen any such arguments, then you haven't looked at the
archives.
<SOAPBOX>
Cookies will never be reliable. Never. They were a poorly conceived
extension to a stateless protocol that should have been accomplished
via anonymous authentication and true client-side state. No server
has the "right" to store any information on the client, let alone
opaque information that gets attached to later requests like a virus.
Any state mechanism that involves preferences can be more efficiently
implemented using judicious use of context URLs rather than cookies
(judicious means one URL per state, not an unbounded number of URLs
due to embedding of a user-id); it is only ignorance on the part of server
application designers and the continued lack of browser support for
external links that justifies their legitimate use at all.
As for illegitimate uses, including silent tracking of users between
sites, a little bit of paranoia can be quite healthy. Until the law
provides adequate protection against the sharing of personal information
between sites, users should disable cookies. If you want that to change,
then promote laws that offer user protection, rather than badger the
users into reducing their own right to privacy.
</SOAPBOX>
.....Roy