[WEB4LIB] Betr.: Cookie-pusher for DOI resolution

Richard L. Goerwitz III richard at goerwitz.com
Tue Nov 6 07:58:32 EST 2001


Theo van Veen wrote, regarding an OpenURL resolving mechanism
that:

> 1) offers the user the ability to fill in his base-url when presenting OpenUrls,
> 2) sets the base-url in a cookie by means of  javascript and
> 3) compute the OpenUrl's on the fly also by means of javascript.

This system has several unfortunate elements, which you yourself
note.  First off, it uses cookies.  Some users turn cookies off.
Others (who use privacy enhancing software) block them.  See
Thomas Dowling's original list of objections to cookie-based
schemes.  Yes, he was speaking more about cookie pushing mechanisms
than you were (you're really talking more about a personal link
page or thin portal).  But most of his remarks apply to the sys-
tem you're proposing.

Secondly, it requires user intervention.  This intervention has to
to come in the form of either clicking on an image or link (which
sets a third-party cookie, and which is therefore going to be dis-
allowed, by default, by recent browsers).  Otherwise, the inter-
vention must come in the form of a menu presented by the resolver,
which is simply too obtrusive.  How many patrons know or care what
their base URL is?  Note also that the intervention is necessary
for every machine the user uses.  Undoing or changing settings is
an equally nasty affair.

Thirdly, your solution utilizes JavaScript, which has been a re-
peated source of security problems, and which again some users
simply turn off.

JavaScript and cookies will also make things difficult for auto-
mated systems.  There are a lot of reasons to want to automate
the retrieval of certain URLs.

My contention is that people who are suggesting cookie-pusher
schemes and/or personal link pages aren't really thinking of what
the average patron is interested in and/or capable of.  Nor are
they thinking of automated systems.  We need an OpenURL mechanism
that's transparent (requiring intervention only if the user cares
to override a default), that requires no cookies, and requires no
JavaScript - although it may offer fallbacks or other secondary
interfaces that do so.

If there is to be a central OpenURL site redirection mechanism it
can't be a heavyweight affair from the client's perspective.  Most
systems I've seen confuse behaviors proper to personal link pages
or thin portals with functions properly reserved for a resolver.
The resolver should be lean and built to fall back to cookies only
if there's no other choice (or if the user really feels compelled
to tweak the behavior of the system).

(I realize some people will claim that the DOI "proxy" [as they
call it] fits my specifications perfectly - and that might to some
extent be true.  Unfortunately, the DOI resolution mechanism is
controlled by publishers, and currently affords little opportunity
for local tailoring.  The point of OpenURLs is that they don't
hardcode in identifiers that essentially "source route" the reso-
lution process; they, rather, allow libraries to handle resolution
in terms that suit local resources and collections.  There seems to
be a subtle push-and-shove going on between libraries and publishers
right now to determine who will really control the process of re-
solving reference links.  Some publishers, at the very least, want
a way to opt out of local resolution, and to force specific resolu-
tion pathways they control.  Some libraries want total local con-
trol, even if that means bearing an immense maintenance burden.
Library automation vendors, realizing that the libraries' desire
for control exceeds their capacity to manage the resources needed
to do so, want to sell them packages and services that help them
get the job done.  I don't think that libraries in particular know
what they're getting into.)

Anyway, if you haven't already, take a look at my draft paper,
which has gotten me some heated mail, both pro and con:

  http://www.goerwitz.com:31265/papers/ucla/

Please feel free to post responses or write me scathing letters,
as many already have ;-).

-- 

Richard Goerwitz                               richard at Goerwitz.COM
tel: 401 438 8978


More information about the Web4lib mailing list