Cookies, privacy, mIm

[Richard L. Goerwitz III]

In typical cases, cookies are used

  1) to help sites pick out individual users by giving them unique IDs
  2) to provide a persistent record of user preferences (e.g., no frames)
  3) to provide a temporary "shopping cart"

You can actually accomplish (3) with hidden fields in HTML forms, so
cookies aren't really needed here.  Cookies are convenient, though,
if you want to allow users to customize how they view your site, or
maintain some record of preferences and actions across multiple ses-
sions (2).

The vast majority of sites using cookies, however, do it for reason
(1) - namely, that they are obsessed with how users move through their
site.  To get this kind of information out of web logs, they need to
have some persistent identifier that allows them to pick out individ-
ual users.  That persistent identifier is a cookie.

What is the concern here?

Cookies allow extra information to be passed around about me that I
can't normally see (or, if I can see it, can't normally interpret in
any meaningful way).  Cookies also add overhead and complexity to the
HTT protocol, which makes it hard to use with tools like the UVa's
mIm (they are a pain also for the pass-through proxy system being used
here at Brown University - but only if domain restricted; see below).

What I fear is that library IS vendors will find cookies to be a use-
ful means of passing around session or authentication/authorization
information.  Right now, most vendors use systems of temporary URLs or
session keys encapsulated within URLs.  I'd guess that in the next
year, vendors will start rolling out systems that use cookies to serve
those functions.  Probably they will support "legacy" systems that
don't use cookies for a while.  But I'd expect a push for cookies.

Really, there's no reason that session information can't be encoded
in hidden form fields.  If need be, it can be encrypted.  Hidden fields
add no overhead to the HTT protocol, and they don't screw up systems
like mIm.

If vendors start going to cookies, my hope is that they'll at least
use path-restricted cookies, and not domain-restricted ones.  At least
with path-restricted cookies, we know what machine is getting the in-
formation, and for what URLs.  And if need be, pass-through proxy sys-
tems can do what translations are necessary on them.

Libraries need to be aware of these issues, and to talk to each other.
Vendors, after all, are in business to make money, and if their custom-
ers are upset, they'll make what changes are needed to make them happy
again.  But if libraries don't talk to each other (and communicate well
with their own IS staffs, who understand these issues), we'll all just
fall prey to the vendors' own IS staffs - who will be thinking primarily
of the specs that have been handed to them, and not about matters like
how their systems will work with mIm or Brown's pass-through proxy
server (systems that are necessitated because of the way in which these
same vendors have decided to license their resources and the way in which
they authenticate our use of them).

Richard Goerwitz
Brown University Scholarly Technology Group