Papers in PDF format

The major disadvantage of these schemes is that they need to be explicitly configured by the users. The
Netscape plug-in needs to be downloaded and installed; the Mosaic CCI application needs to be downloaded,
installed, and then Mosaic needs to be configured and the helper started at the start of each session. It is likely
that due to this inconvenience few users will download and install the tracking software, unless some form of
incentive is given (free access to a subscription service, etc.). Furthermore, there are then the problems shared
by any public software developer: supporting multiple architectures, user support, fixing bugs and notifying
users of updates.
Commentary
The loss of real-time server-side tracking accuracy due to history mechanisms described in Section 2.1 might
suggest that a browser-oriented tracking mechanism would be more desirable. However, whilst browser-side
tracking is certainly more accurate, it suffers from scalability problems, and potentially low uptake due to the
explicit configuration required. It may be possible to increase the accuracy of server-side tracking with certain
browsers through several techniques. One such technique is the use of an anchor to an unavailable background
image, embedded in the page. Netscape and Mosaic's history mechanism causes all unloaded images to be rerequested
whenever the page is revisited, so careful analysis of requests for this unavailable image, including
the Referer header, will indicate when a particular page has been revisited through the history mechanism.
A hybrid approach which combines server-side and browser-side tracking would be for the server to include a
reference to a small Java tracking applet with each page. The applet would have the sole responsibility of
contacting the server each time the user departs a page or navigated back to a page through the history
mechanism. The applet would be stored in the browsers cache, and so wouldn't be loaded across the network
for each page. The Java applets may even be able to track the browsing activity levels on the workstation to
determine if a user is actively viewing a page. Doing so, however, might be regarded as a breach of privacy.
Both of these approaches could be handled within the WWW server which issues the resources, or they could
be served by `tracking servers', in a similar way to the current proliferation of `page counting servers'.
Tracking servers could handle page tracking for a number of different sites. They could act standalone for their
benefit only, or make the tracking information available to applications such as HyperVisVR through TCP,
UDP or multicast communication.
Cache/Firewall problems
The need to accurately track the movement of browsers clashes horribly with the application of proxy cache
servers and firewalls to drastically reduce the amount of network bandwidth consumed with redundant
requests. The crux of the problem is based on the load-based algorithm proxy caches use to determine how
long a particular object should be cached for. This results in the original WWW server `seeing' extremely few
requests from proxy servers for its most popular resources (as the caches store these popular objects), and an
disproportionately high volume of requests for its least popular resources. As the popularity of proxy caches
increases, this could completely invalidate the use of visualization such as HyperVisVR, which relies heavily
on usage and popularity information. Possible solutions to the proxy cache problem can be broadly categorised
into `ignoring the cache', `beating the cache', and `working with the cache'. We now discuss each of these in
turn.
It is possible to completely ignore the WWW population which accesses the server from behind a proxy cache
by disregarding all requests which contain a `Via' header or the word `via' in the User-Agent header from the
cache. Ignoring these misleading requests would seem like a good, straightforward approach to the problem.
However, it is not possible to assume that the `direct access population' will be a representative sample of the
entire requests. Many WWW users access through a cache because of organisation rules or country-based
bandwidth problems, so by eliminating these users from the statistics you could unwittingly be excluding whole
classes of users from the tracking statistics.
Many content providers have resorted to `beating the cache' when attempting to obtain full access statistics and
tracking information. HTTP/1.0 specifies a `Pragma: no-cache' header, which is an instruction to the cache