User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040722 Firefox/0.9.1+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040722 Firefox/0.9.1+ With all the talk of url spoofing and phishing we should not allow hiding of the statusbar by default. IE6 will change to this with service pack 2. It should only be a change to the pref in firefox.js for us to do it as well. This would also help with Gerv's Bug 245406. Reproducible: Always Steps to Reproduce:

This may or may not be a dupe of bug 252198, depending on what happens in that bug.

IMO this bug should block the XUL security bug. Also (IMO) there shouldn't even be UI in Tools > Options... to enable hiding on the status bar.

I'd prefer it if people couldn't turn off the status bar manually either, but that might be too controversial. I'd be happy with a patch which just stopped sites turning it off. (Thanks for filing this bug, BTW.) Gerv

This patch turns off by default the preferences which allow web pages to hide the status bar and modify its text. IMO both are probably needed if we want to say that the status bar is a reliable way of identifying the source of the window; modifying the main status text may not be enough to fool the user, but why take the chance? I'm open to persuasion on this point, however :-) Gerv

So you avoid doing something because it might be controversial, and then throw in another (quite possibly more) controversial change. Could we not just make this bug about (as the summary says) hiding the status bar? Widening it out to cover other stuff just reduces the chance of anything actually happening in time for 1.0.

Michael: I've left it up to ben to decide what to do about this, which I'm sure he will. If you can come up with any vital reason why websites should be allowed to continue modifying the contents of the status bar, let's hear them :-) Gerv

Disabling js to change the statusbar text is not making things safer, imho. It would still be easy to trick a user, for example see this: <a href="http://google.com" onclick="this.href='http://www.microsoft.com'">Google</a> I see the disabling of js to change the statusbar text more as a way to get rid of annoying status bar tickers.

Disabling the ability for JS to change the status bar is not designed to stop the user being fooled when clicking a link, it's designed to stop someone trying to spoof the site name by changing the status bar. Combined with the fact that it's an irritating feature which is mostly used for evil ;-) As I said, this may be overkill - I'll let ben decide. Gerv

Ok, sorry, I misunderstood. But someone could still change the statusbartext - even when the dom.disable_window_status_change pref is set to false - by using dom level 2 events. See example: http://home.hccnet.nl/m.wargers/test/mozilla/spoofstatusbar.htm

> But someone could still change the statusbartext - even when the > dom.disable_window_status_change pref is set to false - by using dom level 2 > events. A separate bugzilla entry for this would make sense, I think.

Comment on attachment 154296 [details] [diff] [review] Patch v.1 r/a=ben@mozilla.org

See bug 22183. I don't understand why this helps ... does Firefox usually display the page URL in the status bar? (Seamonkey doesn't.) Do users look there? What will users think if there's a spoofed location bar that disagrees with the status bar? I think I'd trust the location bar myself...

(In reply to comment #12) > See bug 22183. > > I don't understand why this helps ... does Firefox usually display the page URL > in the status bar? (Seamonkey doesn't.) Firefox displays the domain in the status bar next to the lock on secure pages

roc: Firefox does now display the hostname in the status bar next to the lock (on the grounds that the location bar can be misleading as the actual host/domain may not be clear from a URL), and one would hope that users look down there for the lock (as that is where it has been in the past and in other browsers). This bug was to finish up that work. The not-hiding-location-bar idea was an alternative that didn't originally get moved forward for Firefox. The status bar hostname stuff and this bug were filed and Gerv's patches approved by Ben before it happened that bug 22183 was covering Firefox as well as Seamonkey (with blake's dupe and dveditz's patch). I think either solution is fine, but doing both things seems rather redundant.

OK. That makes sense. I'll comment in bug 22183.

Martjin, can you file that bug?

(In reply to comment #16) > Martjin, can you file that bug? Sure Robret ;), I filed bug 254187 on that. However, I'm not sure if that's a bug. It seems logical to me when I create a mouseover event on a link, that the statusbar changes to contain the href attribute of that link.

Checked in on branch. Checking in browser/app/profile/firefox.js; /cvsroot/mozilla/browser/app/profile/firefox.js,v <-- firefox.js new revision: 1.7.4.20; previous revision: 1.7.4.19 done Gerv

As this is fixed on branch, i'm clearing the blocking-flag (and adding "fixed-aviary1.0" keyword)

Aviary is regressing this fix by landing the approach at bug 22183, so we will need a solution to the bug 122445 problem(s) before 1.0.

This has been relanded on the aviary branch in Bug 259192

If the purpose of this bug is to prevent spoofing urls in the status bar, then we should first make sure the correct text is in the status bar for a particular tab. Making bug 104532 dependant.

This has been fixed by the aviary landing: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/browser/app/profile/firefox.js&rev=1.35&root=/cvsroot&mark=218-225#215

Excuse me for bringing this bug back from the dead, but I really don't see how disabling "allow scripts to change the status bar text" has anything to do with security (which was the motive behind this bug). From comment 8, comment 12, comment 13, and comment 14, I understand that this was justified in order to prevent sites from spoofing the site name next to the lock on the status bar on HTTPS pages. However, this seems impossible to do anyway - as window.status() only sets the text on the left side of the statusbar, leaving alone the lock and domain name on the right side (I'm on Mac/Pinstripe - perhaps other themes do this differently?). Try this for yourself on https://bugzilla.mozilla.org/attachment.cgi?id=156545 (after enabling the pref, of course). So it seems the only real justification for defaulting the pref to "off" is that scripting the status bar text "is an irritating feature which is mostly used for evil". But that could be said about animated gifs and Flash as well. We should give the user options to disable these things - but disabling them by default is, IMO, wrong. Notice that there are bugs filed on this (bug 256204, bug 294147). People are expecting window.status() to work by default, and I think they are right. I'm bringing this up here to grab the atention of people involved in the original decision, and because this is where the original discussion took place. I hope this is not considered spamming. I'll be happy to continue the discussion somewhere else.

(In reply to comment #24) > Excuse me for bringing this bug back from the dead, but I really don't see how > disabling "allow scripts to change the status bar text" has anything to do with > security (which was the motive behind this bug). Because "the status bar is trusted" is much, much easier to explain to a user than "Well, you can trust the right-hand part, but you can't trust the left-hand part. You see that little divider there? The one that's two pixels wide? No, not that one, the one further to the left. Yes. That's the trust boundary." Gerv

> > Because "the status bar is trusted" is much, much easier to explain to a user > than "Well, you can trust the right-hand part, but you can't trust the left-hand > part. You see that little divider there? The one that's two pixels wide? No, not > that one, the one further to the left. Yes. That's the trust boundary." > > Gerv > No need for sarcasm, Gerv. I can see your point, although "you can trust the domain name next to the little lock icon" seems simple enough to me. If it isn't, I would suggest somehow graphically associating the domain name with the lock (e.g. putting them together on a yellow background). Using a bold font for the domain name might also help. Anyway, the silent majority here seems to agree with you, so I think I'll drop the issue now and stop spamming the bug.

I apologise if that sounded sarcastic - it wasn't meant to be. It was just a demonstration of a usability point. Gerv