Apparently, the referer is only stripped when linking from an SSL site to a non-SSL site. You're referencing a SSL site, so the referer is passed along. I had not tested this issue on an SSL server. Very interesting. I updated the script to take care of this issue while still allowing bookmarkable URLs. The best workaround I could find (using <code>href="javascript:location.href='https://...'"</code>) required its own workaround so that the link is colored when you've visited it, and <i>that</i> was very hard to come by. This might be the first time it has been used like this (yay me!), so I feel obliged to mention that it exposes an interesting way to invade users' privacy. With this method, the javascript essentially gains access to whether or not you have visited a link. A malicious coder could then submit this data to a third party. (The more obvious methods of gaining this data are protected, but this one is not.) Another method of gaining this knowledge comes in the form of CSS, using a unique background image for each <code>a:visited</code> link (which is tedious) and logging the http requests for those background images on a server. This is a known "exploit" and I believe it is being worked on specifically, whereas I believe mine is both more elegant and (more importantly) not yet known. <b>Update:</b> Of course it's known. Far too simple. This is <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=147777#c11" title=":visited support allows queries into global history">Mozilla Bug 14777</a>. The patch blocking it landed <i>yesterday</i>(!), so I'll have to get another workaround[1] when that gets propagated into a release (which won't be for a while). I'll put my code in a try/catch test so that this part can die silently if denied access to that attribute (though I expect it will merely grab the un-visited color instead, which is effectively the same result). [1]: Probably these four steps: duplicate the link, alter the duplication's href, place it exactly on top of the original, and set its opacity to 1.00. Very messy. Maybe there will be an "official" way to do it, or maybe I'll figure out how to do it with onclick instead (my initial attempts there failed). <p>Apparently, the referer is only stripped when linking from an SSL site to a non-SSL site. You're referencing a SSL site, so the referer is passed along. I had not tested this issue on an SSL server. Very interesting. I updated the script to take care of this issue while still allowing bookmarkable URLs.</p> <p>The best workaround I could find (using <code>href="javascript:location.href='https://...'"</code>) required its own workaround so that the link is colored when you've visited it, and <i>that</i> was very hard to come by. This might be the first time it has been used like this (yay me!), so I feel obliged to mention that it exposes an interesting way to invade users' privacy. With this method, the javascript essentially gains access to whether or not you have visited a link. A malicious coder could then submit this data to a third party. (The more obvious methods of gaining this data are protected, but this one is not.)</p> <p>Another method of gaining this knowledge comes in the form of CSS, using a unique background image for each <code>a:visited</code> link (which is tedious) and logging the http requests for those background images on a server. This is a known "exploit" and I believe it is being worked on specifically, whereas I believe mine is both more elegant and (more importantly) not yet known.</p> <p><b>Update:</b> Of course it's known. Far too simple. This is <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=147777#c11" title=":visited support allows queries into global history">Mozilla Bug 14777</a>. The patch blocking it landed <i>yesterday</i>(!), so I'll have to get another workaround[1] when that gets propagated into a release (which won't be for a while). I'll put my code in a try/catch test so that this part can die silently if denied access to that attribute (though I expect it will merely grab the un-visited color instead, which is effectively the same result).</p> <p>[1]: Probably these four steps: duplicate the link, alter the duplication's href, place it exactly on top of the original, and set its opacity to 1.00. Very messy. Maybe there will be an "official" way to do it, or maybe I'll figure out how to do it with onclick instead (my initial attempts there failed).</p> 2008-10-22T19:07:03Z 23529 Script 49394 14225 2008-11-16T23:55:42Z 41779