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

The most disturbing thing about this...

[Corvaith]

...is that the bug has apparently been a known one for months, and still hasn't been repaired.

I love Mozilla. I use Mozilla. This just troubles me greatly. Even now that it's known, I haven't heard anything about a fix. Hopefully it'll be arriving shortly, because I like my privacy.

Re:The most disturbing thing about this...

[jmcnamera]

If this bug has really been known for months, are we hypocritical to bash others (always MS) for late fixes?

Bugs should be publicized immediately so fixes will happen sooner. It's good to first inform those who are responsible for the code so they can have a heads up, but months (if true here) is too long to wait.

Re:The most disturbing thing about this...

[Anonymous Coward]

> This just troubles me greatly.

Fine, this is not how you'd expect it to work.

But, GIVE ME A BREAK. Privacy issues on the Web are legend. Cookies, refer, hidden fields, the entire body of software we know as "IE", the list goes on and on and on.

So, by some new "stupid browser trick" you can now see where people are going -- not just where they've come from (as has always, forever, been the case).

Oh my.

If you are worried about "privacy" then you have been using an appropriate "junk busting" proxy from day one.

If you are not using such a proxy, then you are not now, and never have been, seriously worried about privacy. And, this "horror of horrors" is no more an issue to anyone than the Referrer field.

This sounds more like Microsoft Marketing pouring though a Bug Base and using the media to turn a mole hill into a mountain.

Should it be fixed? Yea. So should Referrer be removed from existence. So should alot of much more pressing privacy issues be outright abolished.

So go back to sleep. If you weren't worried about this yesterday, then there is no reason for you to be worried about it today.

Re:The most disturbing thing about this...

[cpeterso]

Mozilla is open source. Why haven't YOU fixed this bug yet?

Dear Slashdot morons

[rebrane]

Do not link to BugZilla from the front page. Not only is it extremely impolite to overload their system with a bunch of hits from people who have no actual interest in the page, but they have disabled links with a slashdot referrer anyway. I'm sure some clued person will go to the bug report and relay any pertinent information in the comments anyway.

Re:Dear Slashdot morons

[Neon Spiral Injector]

Have they also disabled people leaving Bugzilla to go to Slashdot? Okay, I know that was bad.

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

[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

HTTP_REFERER

[nick_davison]

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.

It always bemuses me that people seem to think these things are new. Tracking exits is relatively simple and as for how people access your site, just check HTTP_REFERER. Typed URLs and bookmarks show no referer, links show you who sent them to your site. Granted, it's not 100% infalible, but it works on any browser. I'd rather trade 80% accuracy 100% of the time than 100% accuracy on 5-10% of hits.

From time to time, it still amuses me to be watching the logs while I'm chatting to a visitor via Messenger and tell them what system they're running, what their screen res is, color depth, what enabled/disable features they have and the path they've taken through the site. If you're really that bothered, JavaScript even lets you track their mouse's movement around and how they scroll up/down the page and then play it back on your own PC, telling you things like how fast they read and what they paid attention to.

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.

The problem with this bug

[Chuck Chunder]

Is that as breeches go it is a fairly minor one with a trivial work around, yet it remained confidential in bugzilla.
If it isn't a big enough security hole to warrant instant attention then it should not be hidden in bugzilla, so anyone can have a whack at fixing it.

Re:The problem with this bug

[jesser]

If it isn't a big enough security hole to warrant instant attention then it should not be hidden in bugzilla, so anyone can have a whack at fixing it.

The bug was public for two months before it was marked as security-sensitive. There isn't an army of coders who spend all of their time fixing known minor privacy bugs. The bug had the "privacy" keyword for almost two months before it was marked as security-sensitive, so it would not have been invisible to such an army.

I'm not saying it was a good idea to make it security-sensitive after it was open for a while. It wasn't a good idea in this case, because someone who had seen the bug while it was public decided to make it public again. I'm just saying that leaving it open probably would not have led someone to fix it immediately.

Re:The problem with this bug

[foobar104]

Perhaps my lack of knowledge of JavaScript, but what exactly constitutes a legitimate use of onUnLoad?

I'll give you one example. My company sells software with web front-end interfaces. One of the techniques we use is implementing a close-to-log-out feature. In other words, when you close the main app window, a handler fires that closes all daughter windows of the main app window and ends the user's session. That depends on onunload().

We also use onunload() to make sure the application doesn't get confused if a user closes a window on which the application depends. When the users closes a window-- an alert dialog, say-- the onunload() handler checks to make sure that everything is as it should be. If it isn't, an error condition is established. Without onunload(), our application would be much less reliable in those kinds of situations.

Re:The problem with this bug

[foobar104]

Myself, I prefer to rely on the user closing their session(s) properly....

I mean no offense, but that's a terrible idea. I say that only because we had a pretty serious debate-- okay, shouting match-- about this in a team meeting about a year ago. On the one hand, there were us-- the managers-- saying that the software had to be resilient in the face of inconsistent or wrong user input. On the other, we had the engineers who said things like, "Browsers just don't work that way," and "Of course it's going to break if you do something stupid," and "We have to rely on the user closing their session properly." The bottom line is this: users don't do what you tell them. If you tell them not to close the window, they'll close it anyway. Your app has to be able to deal with things like that, just as it has to deal with "no such file or directory" or "out of memory." Without onunload(), it'd be impossible to write a non-trivial, resilient web application.

Okay, end of rant. ;-)

Re:The problem with this bug

[Idaho]

The workaround is to disable the onunload handler. This is the kind of workaround that breaks legitimate applications.

Are you going to tell me there actually are legitimate uses for unonload!?

I use the internet since 1996 and have yet to come across the first site that uses this 'feature' *cough* in a usefull, non-irritating manner (i.e. something else then opening a bazillion new popups as soon as you close the previous one)

I can not imagine why onunload exists in the first place - 2nd, I can not imagine why people would ever leave it on if they can turn it off.

But maybe that's just because my imagination is so limited :)

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.

I hate to defend Microsoft...

[coene]

But why is it when its an IE bug, its a "Severe Security Exploit", and when its a Mozilla bug, its a "Privacy Leak"...

George Carlin said it best, that we think in language. Changing the rhetoric that is used to describe the problem doesent change the problem. You can be Anti-Microsoft all you want, but that is worth NOTHING if the software that you choose to use exhibits the same problems, and you are not honest about them.

Again, I'm not taking Microsoft's side -- there aren't sides to take. Open Source software needs to be just as accountable as commercial software if it's to be taken seriously.

bug?

[bilbobuggins]

I don't understand how this is a 'bug'.

First of all, this does not allow someone to track where you're going but rather where you went. I know that sounds like nitpicking, but really it's the difference between a bug and a correct protocol implementation.

The method described is to check the referrer on requests sent to a particular server after the user has left a page on that server. Surprise! the referrer is now their current location i.e. where they went after your site.
Would you expect any different?
It's matter of micro-seconds and request timing.
Ok, maybe they could make sure all requests generated by an 'onunload' event are handled before the request to the following page, but personally I would consider that a judgement call and not 'bug'.

Also, I've noticed people here don't seem to give a hoot that your entire history of where you came from can be far more easily tracked!