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

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.

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]

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 :)

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.