Re: cache cookies?

[Clover Andrew <aclover () 1VALUE COM>]

> http://www.princeton.edu/pr/news/00/q4/1205-browser.htm

> or is it snakeoil?

Well it *can* work. But I don't think the release's claims of
being 'very reliable', 'very dangerous [to privacy]' and
'countermeasure-proof' are justified.

AFAICS what they're talking about is using JavaScript onload
events to time how long it takes to load a URL, which can be
an image, a frameset, an object (with DOM level 2 events) or
a frame or iframe (in IE5.5). onload can also be set on popups,
but this would not be so easy to hide from the user.
IE4+ images also have a 'complete' attribute which reflects the
same information as onload.

This can easily be foiled by turning off JavaScript on
untrusted sites or setting cache policy to check for newer
versions of documents on every access. It is already likely
to be confused by shared proxy caches and setups where there
is no local cache.

Calling it a 'cache cookie' is overselling it a bit IMHO
- it can't contain a value, only a yes/no response for each
possible key (URL), and an unreliable one at that. Trawling
many URLs at once would be slow, and the user would be more
likely to notice it.

Since the act of running the cache-bug will itself cache the
target URL, it's also likely to get confused by reporting
false cache hits caused by itself and possibly other cache
bugs.

I find the proposed solution, disabling the cache on objects
that are non-local (and how is this determined? insert usual
images.site.com/www.geocities.com type argument) to be over-
harsh. How about an option for paranoiacs to add a
random pause (1-4 seconds?) between something being loaded
and its onload handler being called (and complete being
updated on IE)?

I wouldn't be too worried though. JavaScript implementation
bugs and client-side-trojan problems are currently far
worse in my opinion.

--
Andrew Clover
Technical Support
1VALUE.com AG