Bug 145579 (future_referer)

Website can see url of page visited after it (document referer used when loading images with javascript is incorrect while loading a new page)

VERIFIED FIXED in mozilla1.0.2



17 years ago
14 years ago


(Reporter: bugzilla, Assigned: rpotts)


({privacy, topembed+})

privacy, topembed+
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [adt1] [ETA 09/19])


(2 attachments)



17 years ago
If a new url is entered into the address bar (and enter or go is pressed) the
browser starts to look up this address.
When a javascript script loads a new image by a setTimeout-triggered event on
the current page while the browser is looking up the new address, the image has
a document referer of http://new page/ instead of http://current page/

Reproducable: always, easier on slow connections or when the server on the other
end is down.
Platform/OS/build: tested on PC/win98/1.0rc2
Refers to: bug 61660

code example:

    <script type="text/javascript">
      function load_image
  <body onload="setTimeout('load_image()',10000)">
    <img name="bla" src="bla.jpg">

For bla2.jpg I used a php-generated image that shows the document referer as the

How to reproduce using the above code and by replacing bla2 with an image that
shows the document referer:
- load the html page
- within the 10 second timeout enter a new url (preferably an unreachable server
that would cause a timeout) in your address bar and press enter
- while Mozilla tries to load the new url the javascript is triggered
- the javascript loads bla2.jpg using 'new url' as a document referer.
- Mozilla gives an error: 'new url' not reachable (or if you used a server that
does work it continues loading 'new url'

Comment 1

17 years ago
-> docshell
Assignee: darin → adamlock
Component: Networking: HTTP → Embedding: Docshell
QA Contact: tever → adamlock

Comment 2

17 years ago
-> Rick
Assignee: adamlock → rpotts

Comment 3

17 years ago
It is also (reliably!) triggered on pages that load images using the
window.onunload handler. This bug lets a webmaster find out what page you
visited next (including pages who's URLs were entered manually).

I.e.: Add a window.onunload handler to the page. Your handler loads an image.
The referer for the image in your access_log will be the NEW page that gets
loaded over the current one!!

example for handler that loads an image on unload:
function good_bye() {
        var x = new Image();
window.onunload = good_bye;
When you visit this page, then go to another URL your HTTP server log will show
the request for "pixel.gif" with the referer of the other URL you visited after
this page.

I noticed this bug when I looked in my http server logfile. The user visiting
was using mozilla 1.0
I reproduced the bug with galeon 1.2.3 (mozilla 1.0rc3) on Linux - I don't have
mozilla 1.0 installed yet because of galeon issues.

FWIW, MS IE 6.0 doesn't seem to have this bug.

Please get this bug fixed before 1.0.1 ships.

Comment 4

17 years ago
This bug seems to be platform independent.
OS: Windows 98 → All
Hardware: PC → All


17 years ago
Severity: normal → critical
Raising radar indicators for this bug ; yes we have a privacy issue here.
Keywords: nsbranch, privacy
Priority: -- → P1
Target Milestone: --- → mozilla1.0.1


17 years ago
Blocks: 61660
Yup, serious. There might be other fun ways to exploit this, e.g. in mail.
Blocks: 54184
Summary: document referer used when loading images with javascript is incorrect while loading a new page → Website can see url of page visited after it (document referer used when loading images with javascript is incorrect while loading a new page)
Adding nsbeta1 - let's get this fixed before our (Netscape's) next release.
Adding security-sensitive flag.
Group: security?
Keywords: nsbeta1
This has been reported open and was open for 2 months, please keep it that way.

Comment 9

17 years ago
See also:
bug 79840  document.referrer is incorrect in a situation that involves frames
bug 84749  [FIXED] onUnload JavaScript gets wrong value for location.href
bug 141274 If I navigate away from my webpage before it loads, the page I'm
going to comes up in the referrer list in my site stats.

Comment 10

17 years ago
This bug is still present in the Mozilla 1.1 release :-(
I think I will make this bug public by the end of the week. hopefully that will
get it fixed. It's been 3 months...
Keywords: nsbeta1 → nsbeta1+


17 years ago
Keywords: topembed
Whiteboard: [adt1] [ETA Needed]

Comment 12

17 years ago
Publicly known (http://mozillazine.org/talkback.html?article=2467), removing 
security-sensitive flag.
Group: security?

Comment 13

17 years ago
1.0.1 is out the door. moving to 1.0.2
Target Milestone: mozilla1.0.1 → mozilla1.0.2


17 years ago
Target Milestone: mozilla1.0.2 → mozilla1.0.1

Comment 14

17 years ago
I found a good workaround in a comment at Mozillazine:

Add the line

  user_pref("capability.policy.default.Window.onunload", "noAccess");

to your user.js file.

For information about the user.js file, read the documentation at

Other workaround: use a proxy that filters the http referer header.
Alias: future_referer
Target Milestone: mozilla1.0.1 → mozilla1.0.2
Bug does not exist in Beonex Communicator's default config, removing dep.
No longer blocks: 54184
It seems the problem is that imgLoader::LoadImage uses the load group as the
source for the Referer, but nsDocShell recycles the same load group for all the
documents loaded in a given docshell.

(Is the document URL really the correct thing to send as the referrer if the
image is loaded from script that lives in a separate file?  Shouldn't we send
the URL of the script?  The HTTP spec (RFC 2616) says the referer should be "the
address (URI) of the resource from which the Request-URI was obtained".  We
probably have the same bug with stylesheets (and probably others, for imported

Comment 17

17 years ago
> Is the document URL really the correct thing to send as the referrer if the
> image is loaded from script that lives in a separate file?

I think the document URL is the correct referrer for images loaded by scripts. 
It's often possible for a page to trick an external script into doing something
it wasn't intended to do, so the page should take responsibility for whatever
the script does.  Someone looking at the page can figure out why it loaded a
given image, while someone looking at just the script can't.  If script urls
were sent as referrers, site A could mask its referrer to site B by loading a
script from site C and messing with the script (getters/setters, etc).
user_pref("network.http.sendRefererHeader", 0); 
seems to be a valid workaround.

Comment 19

17 years ago
As a commercial web site owner, I urge you to stress that the workaround listed
in comment #14 is the preferred workaround.

Where visitors go after they leave us is none of our business.  Knowing who
referred them to us helps us focus our advertising budget on people who are
actually interested in our products, and bug the other folks less. :)


Comment 20

17 years ago
As a follow-up to comment #19, is it possible to put the line in user.js as
defined in Comment #14 as a temporary measure until a proper fix is implemented?

By temp measure, I mean, put the patch in for tomorrows nightlies, and then fix
it properly for 1.2b. I say this because it is a privacy issue, and even a temp
fix would hold off any negative press.

Comment 21

17 years ago
I'm very surprised that this bug has been open for this long to be thwarted. Our
last publicly announced bug < bug 141061 and
http://www.mozillazine.org/talkback.html?article=2201 > only took 2 days to
patch. What gives here?

Comment 25

17 years ago
The workaround from commant 14 does not work (checked with the testcase) as the
pref is not registered (checked with the about:config). Probably adding it to
all.js would work.

However, the workaround from comment 19 does work when applied to user.js
(testcase proven).

Comment 26

17 years ago
Comment on attachment 99468 [details] [diff] [review]
patch to explicitly provide a referring URI when loading images...


this looks great.  everything else that sets a referrer (e.g., CSS, JS,
xmlHttpRequest) seem to likewise get the referrer from the document, but this
should of course be double checked ;)
Attachment #99468 - Flags: superreview+
Comment on attachment 99468 [details] [diff] [review]
patch to explicitly provide a referring URI when loading images...

Attachment #99468 - Flags: review+


17 years ago
Blocks: 163993

Comment 28

17 years ago
patch is checked into the trunk...

branch patch to follow :-)

-- rick

Comment 30

17 years ago
Comment on attachment 99565 [details] [diff] [review]
same patch for the MOZILLA_1_0 branch...

Attachment #99565 - Flags: review+
Nominating as adt1.0.2 and mozilla1.0.2 for inclusion on the 1.0 branch.
Keywords: nsbranch, topembed → adt1.0.2, approval, mozilla1.0.2, topembed+
Whiteboard: [adt1] [ETA Needed] → [adt1] [ETA 09/19]

Comment 32

17 years ago
 please checkin to the MOZILLA_1_0_BRANCH branch. once there, remove the
"mozilla1.0.2+" keyword and add the "fixed1.0.2" keyword. 
Keywords: mozilla1.0.2 → mozilla1.0.2+
Attachment #99565 - Flags: superreview+
Comment on attachment 99565 [details] [diff] [review]
same patch for the MOZILLA_1_0 branch...


Comment 34

17 years ago
checked into the MOZILLA_1_0 branch.

adding the fixed1.0.2 keyword ;-)
Keywords: fixed1.0.2

Comment 35

17 years ago
removing mozilla1.0.2+ and marking fixed...

-- rick
Keywords: mozilla1.0.2+

Comment 36

17 years ago
Doing what rpotts intended. My pleasure :-)
Last Resolved: 17 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.0.2 → ---
adamlock: can you pls verify this as fixed on the 1.0 branch, then replace
"fixed1.0.2" with "verified1.0.2". thanks!

is adam the right person for the QA Contact, and to be verifying this as fixed?
Target Milestone: --- → mozilla1.0.2

Comment 38

17 years ago
Verifying fixed in 1.0.2.
Keywords: fixed1.0.2 → verified1.0.2
posthumus adt1.0.2+.
Keywords: adt1.0.2 → adt1.0.2+

Comment 40

17 years ago
I did some more testing as requested in Darin's commment 26 with a nightly build
("Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20020922").


 * CSS loaded by setting the href property of a HTMLLinkElement yields the
correct referer. Yay!

 * A XMLHTTPRequest gets no referer at all (this is a bug, isn't it?)

 * Setting the src property of a HTMLScriptElement does not trigger a HTTP
Request - what's the correct way to do this?
Sven, you need to create the whole script tag dynamically and attach it to the
document (this was changed some time back to avoid multiple loads).

Comment 42

17 years ago
OK. Did that and it triggers a request. 
It seems the referer for the <script> was already ok in 1.1 (without the fix).

Code used for testing:

<HEAD ID="dh1">
 function good_bye () {
                var sc = document.createElement("script");
 window.onunload = good_bye;

Is it worth it testing frames loading also perhaps?


14 years ago
No longer blocks: 163993
You need to log in before you can comment on or make changes to this bug.