234736 - javascript:window.location reassignment creates bogus referrer

Status: RESOLVED DUPLICATE of bug 122668

(Firefox :: General, defect)

Description

[Ben Henick]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

When reassigning window.location via the Location bar or a bookmarklet, the page
in the browser window at the time the reassignment occurred is shown in the
access log as the referrer.

Discovery of the issue was as follows:

I have a bookmarklet that allows me to provide a timestamp for a single archived
entry in my blog to the end of requesting that single entry.  I used it while a
friend's site was loaded into that tab, and the friend's site was shown as the
referrer.  I was then able to reproduce the problem simply by putting JavaScript
in the Location bar as described in the Actual Results.

Reproducible: Always
Steps to Reproduce:
1.  Create a bookmarklet that reassigns window.location, or reassign it manually
from the Location bar.
2.  Look up the visit in your serverlogs.

Actual Results:  
In one instance, when typing "javascript:window.location =
'http://www.io.com/persist1/log.php'" into the Location bar while
http://badpoetry.net/katie/ was already loaded into the browser window:

4.13.31.137 - - [17/Feb/2004:23:25:27 -0600] "GET /persist1/log.php HTTP/1.1"
200 5182 "http://badpoetry.net/katie/" "Mozilla/5.0 (Windows; U; Win98; en-US;
rv:1.6) Gecko/20040206 Firefox/0.8"

I run TabBrowser Extensions, and closed all of my tabs before reproducing the
problem again.

Expected Results:  
...Left empty the referrer field of the access log entry.

AFAIK, page requests generated via JavaScript window.location reassignment or
window object method invocation never create referrers; at least this has been
the S.O.P. since 1996 without regard to who publishes the software...

While I can see the benefit to providing a referrer in the event that INLINE
CODE generated the page request (thus preventing anonymous referrals), doing the
same in the event that the code was stored locally outside of the cache (e.g. in
chrome or a bookmarklet) could be understood to be an egregious (if inadvertent)
violation of user privacy.

Comment 1

[Jesse Ruderman]

*** This bug has been marked as a duplicate of 122668 ***