Papers in PDF format

etween subsequent requests, and an understanding of server structure to recognise which items a user is likely
to access based on his current position in the server. It may be possible to do this analysis in real-time as each
request was served, but it would pose a large overhead to already over-loaded servers.
Authentication is often used by sites needing a fail-safe and universal way to track users through their servers.
The advantages of this method are that it provides a method of user tracking which works with most browsers
and it identifies individual users on subsequent visits even if they are connecting from a different computer.
However, it is extremely inconvenient as it requires users to first register with the site and then remember a
username and password that they should use on all subsequent visits to the site. Many users find that it
generally isn't possible to use the same username and password at all such sites as many won't allow users their
primary choice of username/password. Furthermore, based on our own experiences, we expect that many users
who would otherwise look through the site may be dissuaded because of the inconvenience of registering or
remembering their username. Thus, in general, we would not recommend this technique for sites hoping to get
a high volume of traffic and who wouldn't otherwise use authentication for controlling access to their site.
HTTP/1.0 Extensions
The Cookie mechanism for client-side stateful transactions in HTTP is an extension to the HTTP protocol
proposed by Netscape Corporation and implemented by the Netscape browser and several servers [Cookies
1995]. When a browser requests a resource from a server for the first time, the server responds with a cookie,
which the browser stores and sends as part of each subsequent request. This allows the server to link up
requests from a particular browser into a click-trail. Cookies can be persistent, linking requests from one
browsing session with requests from the previous one.
The Keep-Alive extension to HTTP/1.0 allows several resources to be requested over a single connection. This
is implemented by the Netscape browser and several servers. In principle it allows several requests to be
matched up together as coming from one browser. However, in practice browsers use it only for single pages,
requesting the page itself and all its embedded objects in one request. This limits the usefulness of the
extension to follow a browser between distinct pages.
In HTTP/1.1
The HTTP/1.1 proposal introduces a new persistent connection architecture as the default connection type
[Fielding et al. 1996]. This supersedes the Keep-Alive extension header described in 2.1.2. Any number of
requests can be made on a single connection, until either the server or browser closes the connection. The
specification does not make clear the circumstances under which connections should be closed or maintained
and as, at the time of writing, there are no widespread implementations of the protocol, it is difficult to
comment on whether this new architecture will improve user tracking. It is likely, however, that for matching
of click-trails where the requests are punctuated by hours or days, that this architecture will not help.
Tracking at the Browser
The chief difficulty with server-side click-trail tracking using any of the mechanisms described in section 2.1 is
that you can only track requests to the server. Frequently, browsers cache pages, and provide history
mechanisms to allow navigation `Back' to the previous and `Forward' to the next page in the history. The
browsers quite correctly do not generate new requests for this navigation. A consequence of this is, however,
that it is not possible to maintain an accurate position of a user within a site if the user has navigated using the
history mechanism. This is a major problem as a study at Georgia Institute of Technology analysed browsing
strategies and determined that a total of 42.7% of navigation was through the history mechanism [Catledge et
al. 1995].
An alternative to user-tracking at the server side is to extend users' browsers to send usage information to
interested parties whenever a new page is accessed. This can be implemented very easily with Mosaic's
Common Client Interface (CCI) and a small helper application which connects to the CCI port of the browser,
and relays WWW movement information via TCP or multicast to interested parties. Both WebCast [Burns
1995] and FollowWWW [Brown et al. 1996] are applications which make use of this technique. An alternative
would be a Netscape plug-in which monitors the actions of the user and sends movement information.