Cookie-pusher for DOI resolution

[Thomas Dowling]

I have received a couple of messages about my comments on the cookie-pusher
solution to appropriate copy resolution of DOIs.  Here's a fuller
articulation of my points.

I believe that the cookie pusher will prove inadequate for many users.
However, the consensus of a group of organizations who worked on this
problem over the last year was that no better solution will be available in
the foreseeable future.

The cookie pusher is a CGI script that lives at www.doi.org.  Its function
is to set a cookie within the doi.org domain and issue an HTTP Location
header sending the browser to a URL specified in its query string.  HTTP
requests received by the global DOI resolver at dx.doi.org will note the
presence of this cookie; if it's present, the resolver will redirect users
to a local DOI resolver determined from the value of the cookie.

The expected implementation is that a page on, say, www.ohiolink.edu, would
include an <img> element whose src attribute was actually the cookie pusher
script called, so as to redirect the browser to an image back on
www.ohiolink.edu.

The expected benefit of doing this is that a database vendor can create
DOI-based outbound links to citations without having to worry about where
any user's resolver might live.  Those links all go to dx.doi.org, which
determines whether to give users the global resolution service to or
redirect them to a local service.


My issues with this are:

Any user whose path to the database avoids the page(s) with the cookie
pusher image will not get the cookie set under any circumstances.  This
includes anyone following a bookmark to the database.  They will therefore
get the global resolution service rather than your carefully tailored local
service.

Sites have to choose carefully on how many pages to put the cookie pusher
image.  Too few, and you increase the number of users who won't get the
cookie set.  Too many, and the effect of continually re-running the script
might be a perception that your site is slow.

This "page from one site, image and cookie from another" trick (third-party
cookies) has been widely used by commercial traffic monitoring companies.
Because of the privacy issues involved with this, most cookie management
software--including what's built into Netscape 6.1 and IE6--disables this by
default.  This could be avoided by actually linking to the cookie pusher
rather than insinuating it into an img, but IMO this exacerbates the problem
of deciding where users should see that link.

The image-based cookie will not be set under any circumstances if:

  The browser is not set to show images.
  The browser is set to disallow all cookies.
  The browser is set to allow cookies only from a set of servers that
    does not include www.doi.org.
  The browser, or cookie management software, or firewall is set to
    disallow third party cookies.
  OR the browser does not go to a cookie-pushing page before
    going to services with DOI-based links to dx.doi.org.


But again, there's no better solution right now to identify your users to
the global DOI resolver.  That's why we will increasingly tell vendors that
straight DOI links are a very minimal level of service (just one step better
than hard-wired links to publisher sites).  The preferred solution for
licensed services will be to include an OpenURL resolver's base URL in the
customer profile information.

Thomas Dowling
Ohio Library and Information Network
tdowling at ohiolink.edu