Closed Bug 675446 Opened 14 years ago Closed 3 years ago

Cached JS files can effectively be used as a per-URI cookie

Categories

(Core :: Networking: Cache, defect, P5)

Product:
Core
Component:
Networking: Cache
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: usenet, Unassigned)

Details

(Whiteboard: [necko-would-take])

In particular, the cookie is basically stored in the ETag. It's not clear how to deal with this offhand without making ETags completely useless at least for third-party requests. Note that the second link there indicates that kissmetrics has stopped using ETags this way.
Component: Security → Networking: Cache
QA Contact: toolkit → networking.cache
Summary: Javascript caching may be used to store persistent state → ETag values can effectively be used as a per-URI cookie
No, this bug wasn't about the ETag issue -- it was about the case of keeping the unique ID in the cached _javascript_ file, and using that to send the value back to base.
That's not at all obvious from the links in comment 0, but ok. Again, I'm not certain what can be done about that short of disabling the cache for cross-site requests.
Summary: ETag values can effectively be used as a per-URI cookie → Cached JS files can effectively be used as a per-URI cookie
Ah. The Kissmetrics link, which, at the time I filed this bug, pointed to a page which explained in some considerable detail how this was done, has now changed to point to something else entirely.
A possible mitigation -- if perhaps the cache lifetime of cached script files could be limited to something like 1 to 5 minutes, this would make this sort of tracking considerably harder by allowing cached files to regularly age out during normal browing behaviour, without causing much too extra data to be sent for the common case where a user is rapidly visiting multiple pages during a single browsing session?
That would seriously penalize sites using jQuery and the like, since it would be forced to be downloaded over and over again, no? The common case is not for users to "rapidly" visit multiple pages. Users typically load a page, read, then load another one, etc...
Perhaps for each new session (after a browser restart), for each request which has an etag, we issue a HEAD request instead and compare the response's etag against the cached etag to determine if the content has changed. This way the server won't be able to retrieve the old etag and will be forced to issue a new etag or a real etag.
HEAD requests on the web are basically broken (e.g. it's common for CGIs to rerun and return response bodies and the like on a HEAD, some servers always return a 404 for HEAD, etc, etc). You shouldn't really rely on HEAD for anything useful.
This blog post, from the Center for Internet and Society at Stanford Law School, describes something similar to the "JS cookie" technique described in the initial bug report: http://cyberlaw.stanford.edu/node/6715
Whiteboard: [necko-would-take]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P5
QA Whiteboard: qa-not-actionable

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: major → --

Since we now partition the cache by top level origin, I think we can close this as WORKSFORME.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.