Privacy Leak in Mozilla and Mozilla-Based Browsers

Mike S. writes "Mozillazine has pointed users to this story at ZDNet UK which breaks the news about a privacy bug discovered in in all Mozilla builds up to and including 1.2a as well as browsers based on Mozilla such as Netscape 6/7, Chimera and Galeon. The bug allows a web site to track where you're going when leaving the site whether you use a link, a bookmark or type a URL into the address field. This page has a demonstration of the bug and instructions on patching it via a user.js file."

Comments

Easy work-around for now

[RPoet]

People will tell you to disable Javascript alltogether for protection, but it's better to just disable the onunload event. Just put the following line into your user.js file:

user_pref("capability.policy.default.Window.onun lo ad", "noAccess");

You won't miss those ununload events anyway :)

Re:Easy work-around for now

[bcrowell]

Where is your user.js file supposed to be (on Linux)? Slocate tells me I don't have one. Should I create one somewhere with only this line in it?

Re:Easy work-around for now

[maw]

You should have a file called prefs.js somewhere within your $HOME/.mozilla directory. You can set user_prefs there.

Re:Easy work-around for now

[teslatug]

better not to set them in prefs.js ,but in user.js (create new file if not there) as the settings in the prefs.js file might get overwritten

Re:Easy work-around for now

[superpeach]

Yes, create one
If you just use mozilla as it is then you create your user.js in ~/.mozilla/[your_username]/[some random directory name]/user.js - the path up to user.js should exist already if you have used mozilla, and hopefully only 1 with a wierd random name :)
If you use galeon, then it goes in ~/.galeon/mozilla/galeon/user.js

Muwahahaha

[evilviper]

Well, this just proves my point. Javascript should be disabled. (check my older posts, it's there somewhere).

Anyhow, I think everyone should look into Privoxy [privoxy.org]. In my setup, I have all on(un)load tags removed, and the refer forged to report the it as root of the current server.

It's quite nice. You simply setup a regex to replace/remove any HTML, you can configure that feature on a site-by-site basis, and do so using a simple web-editor.

So, check it out, and take back full control of your browser.

Re:HTTP_REFERER

[singularity]

As with a lot of browser-based things that show up on Slashdot, I feel the need to chime in with a different perspective, from a browser that does a lot of these things correctly.

iCab, on the Mac, has a setting (and has had it almost since its very first versions) to only allow the Referrer: to be sent only when in the same domain (or even never sent). So Sony.com can trace how I look through their site, but cannot see that I came to Sony's site from a link on slashdot.org

I could even set it to never send it, as well.

Re:I can't get the demo to work...

[superpeach]

The bug has nothing to do with cookies, the cookie is just so that the demo site can tell you where you went after visiting there. The problem is with the window.onunload javascript function - so either that needs to be disables, or all of javascript (the instructions are on the demo page for how to only disable onunload). All that stopping javascript playing with cookies will do is stop the demo from being able to tell you where you went, the server operators can still find out if they wanted.

Re:cookie, cookie, cookie

[lamp77]

Dude, the first line reads

For this demonstration, you need to enable cookies. The bug itself does not require cookies to be enabled, however.

I think that explains the situration pretty clearly.