Downloadable XUL allows window spoofing thru window.content.location.href #3 I am not sure whether this is a feature or bug, but if it is possible I think this is worth fixing. There is a security vulnerability which allows window spoofing by using downloadable XUL. The problem is modifying the location bar in a downloaded XUL file. The input control for the location bar is changed and the original one is made hidden. So when the user enters a URL in the "location bar" it in fact is entered in another input control which calls window.content.location.href = 'http://www.mozilla.org/'. This allow may allow spoofing the web by sending requests to services like Anonymizer. The code is: ----------------------------------------------------------------- In downloaded navigator2.xul (copy of navigator.xul): The following was added: <html:input id="urlbar" type="hidden" ></html:input>; The following was modified: <html:input id="urlbar" type="text" chromeclass="location" onkeyup="if (event.which == 13) { window.content.location.href = 'http://www.mozilla.org/' ; }" flex = "100%"/>; ----------------------------------------------------------------------------- In chrome4.html: ----------------------------------------------------------------------------- <SCRIPT language="JavaScript1.4"> function BrowserOpenWindow(url) { window.open(url,"_new","chrome,menubar,toolbar,location,status,resizable"); } </SCRIPT> <A HREF=# onclick="BrowserOpenWindow('navigator2.xul')">Click here to test </A> ------------------------------------------------------------------------------- ----------------------------------------------------------------------

Bulk moving all Browser Security bugs to new Security: General component. The previous Security component for Browser will be deleted.

With Norris out this week, I'm moving this to M16. This is not a stability stopper for M15.

Bulk reassigning most of norris's bugs to mstoltz.

This has more to do with layout, I think. Reassigning to layout module. Retargeting to M17 as this is a spoofing attack, and more serious attacks take precedence.

Changing component to XUL

reassigning to danm. How urgent is this, considering it is the first skinnable release, and we should have PR3 out soon thereafter?

I would say this is not very important. We tend to put spoofing attacks like this one lower on the priority list for security bugs. Should we make it post-Beta2?

[nsbeta2-]

Mass-moving all nsbeta2- bugs to M20

need info: mstoltz: do we really need to fix this for nsbeta3?

We need this for RTM. If it can get into nsbeta3, all the better, as it's a security exploit and (until just now) visible to the public.

Adding nsbeta2 keyword to bugs with nsbeta2 triage value in status field so the queries don't get screwed up

nsbeta3+, assuming that all that is required is an addition to the titlebar text. This is also a problem with any HTML window. I doubt that the titlebar change is really enough, but it at least it gives the user a chance to notice a spoof. P4

Mitch - new priority scheme means that this bug may not make the cut. We are committing to fix P1-P3, but not P4/P5.

Per PDT, changing to beta3-minus

->future

Should be groupset 2, not 1024

There's nothing to stop someone from creating a chromeless popup window containing a styled edit box on top of a GIF that looks like our chrome area, so this can be done without any XUL support, in any browser. I recommend that we make this bug public. This is clearly not going to be fixed anytime soon and it probably affects other major browsers.

We need to start thinking about how to make our UI, particularly the URL bar and lock icon, unspoofable. Can the Phoenix folks be thinking about this too?

It's hard to make things unspoofable when we allow them to be hidden from content. Though XUL makes it a little easier to emulate the hidden chrome, the same can be accomplished with purely HTML. Btw, I think IE has the same problem. Putting some text up in the titlebar might help a little, but it's hard to convey to the user that "this is a window whose chrome may be emulated by content and should therefore not be trusted" in a short and understandable way. The only solution I see is to not allow windows to have their chrome hidden.

There is a group at Dartmouth who've been doing research on chrome spoofing, and they're actually using Mozilla for their experiments. http://www.cs.dartmouth.edu/~sws/papers/usenix02.pdf http://www.cgisecurity.com/lib/tr418.pdf http://www.cs.dartmouth.edu/~pkilab/demos/countermeasures/ I don't know if I like their solution much but their survey of the issues and their ideas are excellent.

I'm going to try to get the Dartmouth author onto this bug. It would be helpful if we could make these UI spoofing bugs public to make it easier for people like her to contact us.

not that it'd be a great solution, but we could probably set the window icon (windows, macos) to indicate its origin (remote, chrome). We could also force the first few letters of a window title to be something special ("Web App"?). Perhaps any window which has chrome hidden by a web app should get that title text? jag's right, it's hard to convey the problem to users. One thing we could do is provide a keystroke which allows users to find out what is trusted chrome. WindowsNT does that with ctrl-alt-delete. Only the os can respond to it, and only the os will paint things after you press it (it kicks VNC off among other things). we could probably use ctrl-break(sysrequest) to mean that. The behavior could be: disable all behaviors (css, js, timers, xbl, animations, plugins, java) for all content and draw all content as some test pattern. This could actually be relatively easy to explain to an end user. We should probably pop up a window with some buttons like NT does (one would let the user return to normal behavior. one could let the user manage security settings, one might allow the user to quit, there should probably be a limit to the number of buttons. They shouldn't change as mozilla develops, so we'd need to get them right the first time).

CCing Eileen, the author of the Dartmouth reports.

How about a two-pronged approach: -- chromeless windows get some chrome tagged onto them, like a bar saying "Web Page Popup Window". This would be a handy place to put popup blacklisting too. -- We hack the chrome with some unpredictable dynamic effect like in the Usenix paper, for example, a background image that cycles smoothly and *randomly* through some color and texture variations. What this means is that even if a Web page pops up a DHTML box that looks like a password prompt or some other dialog, it won't have the right cycling chrome. Even if they try to spoof the cycling chrome, their cycling won't be in sync with the app's cycling. Everyone should read the Usenix paper BTW.

This report has morphed. If I'm understanding it correctly, the original report had to do with xul that the user downloaded and which in turn can be used to spoof the web (not the user) by sending requests not the the URL that appears in the URL bar but rather to a sevice such an anonymizer.com. It's not a spoof on the user because the user would have had to cooperate by willingly downloading the xul. Then comments 11, 13 and 18 onward all talk about UI that spoofs the user so these are not relevant to the original report. Rather than opening a new report on the UI spoof, I'm going to change the title of this report to go along with the morph. I'm usually against doing such things, but in this case the original spoof of downloadable xul is less of a threat than the UI spoof that it morphed into. Changing title from: Downloadable XUL allows window spoofing thru window.content.location.href #3 to UI spoofing can cause user to mistake content for chrome and removing the following from the URL line http://www.nat.bg/~joro/mozilla/chrome4/chrome4.html My apologies to the original reporter (joro) for this morph. If you still feel your original report is significant, then please open a new report on it.

Now some comments on the ui-spoofing issue The only thing that would be non-spoofable (because the site can always send an image of the chrome) would be for something randomly changing as along the ideas suggested by the Dartmouth team. However there several things that I don't like about their solution: 1. The flipping between so-called inset and outset border styles as demonstrated on their website is very annoying. It's the reason the html blink tag was killed. A better solution would be for some continuous color changing along the lines suggested in comment 25. 2. Their solution involves putting these changing borders around all UI elements that are to be trusted. That makes for a very cluttered display. Couldn't you accomplish the same notion of trust by using only one such border per window and putting it around the content? 3. You'd need some trusted reference as to what the true color of the moment should be. The Dartmouth report solves that by having a reference window that is permantly displayed. A better solution, on windows at least, would be to have a color bar placed in the system tray. Orthogonal to the Dartmouth solution is the idea of a non-capturable key sequence as described in comment 23 to determine what is trusted chrome. But rather than turning off all the items mentioned in that comment, it would be simpler and more intuitive to the user if that keystroke simply toggled between turning on and off the content while leaving the chrome always displayed. That way the user could test to see what is content and what is chrome. Of course it requires some sophistication on the part of the user to know about this keystroke, as well as requiring him to take a more active roll. But it would be a useful feature to have, and could co-exist along with the Dartmouth solution.

Some changes didn't seem to take. Applying.

An alternative is to mark the sandbox, e.g. always surround content by some distinct mark that wouldn't appear in chrome. "Always show chrome" is one such way to mark the content, but something like a thick black border could perhaps do the trick. None of these make the browser more appealing to use though.

Marking the content with somthing unique is what I was saying in comment 27 item 3. But you need more than just a static thick black border around it because that could always be spoofed by putting up an image of a window within the content area of another window.

Which the user could see as two separate browsers overlapping, instead of an image of a browser displayed inside a browser. Ceci n'est pas une pipe, or something like that.

Attaching a patch that implements the idea in the last paragraph of comment 27. Namely having a key sequence that would turn off the non-trusted area so the user can determine what is trusted and what is not. The current patch uses the key combination ctl-tilde, but that could be changed of course. When that key-combination is pressed, all the non-trusted areas become blanked out, and they reappear when the keys are released. The blanking applies to the content area of a browser window and also the entire area of a confirm/prompt/alert box put up by the content. Since content is not permitted to issue an OpenDialog command, I believe this covers all cases of windows that the content can produce. I did not implement the keystroke as non-capturable. I don't believe there is any way the attacker can prevent the blanking if he captured the sequence, but I could be wrong. If I'm wrong, please give an example showing me the error of my ways.

for lack of a useful testcase, the reason i suggested cancelling plugins is among various things the url i've just filled in. plugins have tend to bleed through tabs and other hidden states. the reason for holding off timeouts is that a timeout might trigger a window move or new window call, those things shouldn't happen while the user is trying to figure out what content is trustworthy. also, your patch doesn't seem to cover the sidebar, or mailnews. i'd at least want those two covered (inspector would be a nice bonus). i'm thinking that it should be a broadcaster or something with all <browser>'s observing it. also if a <browser> has a chrome: url, it shouldn't be collapsed :)

Attaching a demo of spoofed UI so that the patch presented here can be tested. To run the demo, unzip the attachment into a directory and then bring up spoofdemo.html in the browser.

re: timeless' comment 34 > also, your patch doesn't seem to cover the sidebar, or mailnews. i'd at > least want those two covered (inspector would be a nice bonus). It does cover sidebar. Try it out and you'll see that it works. I'll look into mailnews next. > also if a <browser> has a chrome: url, it shouldn't be collapsed :) The chrome is not collapsed but the content area is. Could you be more explicit regarding your first, second, and fourth paragraphs. I'm not exactly sure I know what you are saying there.

timeless: >> also, your patch doesn't seem to cover the sidebar, or mailnews. i'd at >> least want those two covered (inspector would be a nice bonus). morse: > It does cover sidebar. Try it out and you'll see that it works. Correction -- it does not cover sidebar, you are correct. Namely the sidebar contents are untrusted and should be collapsed along with the content window. I'll look into that as well. Thanks.

Previously I posted a demo of this attack in a zip file. I have since figured out how to make a server return a mime-type of xul, so now I have a demo on the web. To try it out, go to http://home.pacbell.net/spmorse/spoof.html

*** Bug 180744 has been marked as a duplicate of this bug. ***

I'm cc'ing roc, who suggested that we open this bug up. I doubt many users will know, or ever learn, about an uncapturable key chord that helps show what is chrome and what is content. Why not use the title bar, as we have done for JS alerts, etc., for ages? Cc'ing heikki too. Is this really priority work? It's interesting and good for academic research, and it might help someone avoid being spoofed, some day (if the victim knows the secret chord), but it seems like small potatoes compared to other bugs still open. /be

If you use the title bar, how much of the chrome would need to be spoofed before you tell the user that it's not real chrome? The attack could open up some real chrome and then add some spoofed chrome to it. It could even open up the full chrome but add another line below it that also looks like chrome. Or it could open up all the real chrome but then put up a spoofed sidebar? Is the title bar solution cross platform? Granted this will require an education process on the part of the users. But that's better than not offering any way for the user to determine true from spoofed chrome.

Tried to extend the preceding patch by having the triggering event be non-capturable -- i.e., gets sent to chrome only and not to content. Tried doing it both by testing for the element being in chrome as well as testing for the calling script being in chrome. Was not successful in making it non-capturable in general. Did succeed in making it impossible for elements within the spoofed chrome to capture the event, but the body of that spoofed chrome will still capture it. Decided to abandon this effort because the non-capturable feature is not necessary. The original patch in which the blanking out of the content is triggered by a capturable event will be a safe solution. Unless there is another security hole that the attacker exploits, there is no way that the spoofed chrome can unblank the content area that the chrome code has blanked. So for archival purposes only, I am posting my attempt at making it non-capturable. Note that this patch uses the simultaneous pressing of left and right mouse buttons as the triggering event. This was done for testing purposes only. Note also the use of the ifdefs in the patch. This allows the same patch to be used for either element testing or calling-script testing by simply undefining the one we don't want.

Attaching a cleaned-up version of original patch so that it can be reviewed. Significant changes from original patch are better handling of mail windows (a third mail window has identified as needing collapsing). Also the special key sequence has been changed to control-shift-b per discussion with the UE folks -- Aaron asked that it be control-shift-<letter> and I arbitrarily chose b for blanking.

I'll take over ownership of this.

Sorry, mstoltz can't r= xpfe and mailnews code. Cc'ing sspitzer for mailnews, jag is already on the cc: list for xpfe. Responding to comment #44: >If you use the title bar, how much of the chrome would need to be spoofed >before you tell the user that it's not real chrome? Any change initiated by the remote content to the default chrome of a window could be flagged in the titlebar. >The attack could open up some real chrome and then add some spoofed chrome to >it. Real chrome with fewer than the default number of toolbars would be flagged in the titlebar. >It could even open up the full chrome but add another line below it that >also looks like chrome. So? It can do this with DHTML. What problem are you solving? >Or it could open up all the real chrome but then put up a spoofed sidebar? Yes, lots of spoofs are possible even with the real chrome. The patch you're proposing doesn't help users who don't know the magic key-chord, which is to say, almost all users. >Is the title bar solution cross platform? Yes, we put [JavaScript Application] in DOM-generated alert/confirm/prompt dialog titlebars. If we want something fancier than text (a warning icon), we may have more work to do. >Granted this will require an education process on the part of the users. But >that's better than not offering any way for the user to determine true from >spoofed chrome. Why is it better? If no one except a handful of users know the key-chord, it's no better, due to the opportunity costs. I think we should try for something that doesn't count on users learning a new key-chord that doesn't work in IE or any other app, and then (to boot) knowing when to use it. Why would a user suspect a spoofing attack? If they seem some knew sidebar or non-default chrome, why can't we detect those changes with code and better alert them via a titlebar change? /be

I must agree with brendan here. This solution misses some of the point of the Dartmouth paper - In order to know you're being spoofed, there must be a visual indication _without the user having to act_. Unless the user hits CTRL-whatever after every page (or popup) appears, how does that help them? (even if they did, there are evil ways to beat that too). The window title (and border) is one of the very few things that cannot be messed with directly and spoofed on most OS's. Window border sometimes doesn't exist, and is very much normally owned by the window manager, so title is your best bet. This assumes, of course, that this security flaw is worth dealing with (at this time).

Blanking content on key combo is not the perfect solution, but it is better than nothing (works great if you get suspicuous) and does no harm. It works just as good on black and white screen as a color screen, there are no questions about color blind people, it should even work for blind people. Discoverability is a UE problem, and we need to file a new bug on that which is blocked by this bug (some ways to advertise this would be hint pages at startup, help pages etc. although I can't think of a really good one). I don't see title bar as a good solution either. For example, I didn't know parts of the title bar cannot be changed by scripts/pages. I rarely look at it anyway. Besides, even if I did know, I can't remember what the non-spoofable part is supposed to say (not sure if that matters, but still...) I don't think anyone has a good solution for this problem. Otherwise this would have been fixed a long time ago. We now have something, so let's get it reviewed and checked in and think of new and better ways that can help us.

Why must these two things (blanking of content, warning on title line) be mutually exclusive? If we detect incomplete chrome, we could put a notification on the title line. But that won't tell the user what part of the chrome is not to be trusted. The keypress would tell the rest of the story. The text on the title bar could even mention the keypress. But these two features can be done independently. I have posted the patch for the keypress. Another patch could be posted and separately reviewed for the title-line change. The Dartmouth approach has a lot to be commended for. My only objection to it is that it decreases the beauty that was designed into the screen display. Flashing borders, smoothly changing borders, or any other variation do not enhance the webpage (if it did, the web designer would have implemented it). If we suddenly start displaying pages that are esthetically less pleasing than the way they are displayed on IE, which browser do you think the users are going to migrate to?

> Discoverability is a UE problem, and we need to file a new bug on that > which is blocked by this bug Bug 182078 has been filed for that.

This patch should not be checked in to the xpfe code. Relying on a hidden keybinding that no one knows helps nobody, adds confusion to the xpfe code, and doesn't adequately solve the UI spoofing problem. I will veto any solution that is based off a non-discoverable key binding. Please consider some of the other suggested approaches.

Comment on attachment 107484 [details] [diff] [review] cleaned up patch, ready for reviews >+ if (window.title.slice(0,gLeftContext.length) == gLeftContext && >+ window.title.slice(gRightContext.length,-0) == gRightContext) { FYI, -0 does not mean what you want here. It's converted to an unsigned integer 0, which makes that slice always return the empty string. I get the impression from comments in this bug that 'any code is better than no code, so we should check this in" (my paraphrase). That's clearly wrong; just as a matter of historical fact, Mozilla has had "too much code" in too many areas where it would have been better to do less, well. We're still digging out from under the combined weight in human and footprint/performance terms of such code. I don't see why spoofing attacks are more than an academic concern, but let's say that we can't foresee a firedrill in the near term, and want some kind of solution. It's obvious to me that the only solution that prevents or palliates a fire (avoiding the drill to quiet the bad press, if not to reduce liability and preserve users' security and privacy) is one that doesn't require each user to learn or "discover" something new. Otherwise, there will be users who learn the hard way, and pointing people to some document, or online help widget, or discoverability tooltip/icon, will not save us from the fire. We need much more automatic spoofing defenses, if we need any. But aren't there other security bugs that come first? Spoofing is even less of a real world problem right now than denial of service through browser-level content is. /be

First some review comments, pardon my JS/XUL ignorance: * Can you change the magic 66 to 'b' or something more descriptive? * Do we load the properties file for every dialog open? If so, it should be changed so that we only load it when the key combo is pressed. * Can you perhaps change e.which to e.keyCode (or something like that) which is more descriptive and should someday become a DOM Rec. * Can content generate this key event and fool you into blanking (DoS attack)? If so, you need to check the event to see if it is a "real" event and act only then. jst at least will know how to check this. * I have an uneasy feeling about checking the window title to see if stuff is chrome or not. Is there any other way to achieve what you want? I don't approve of checking unfinished code in the tree. That is why there is the review step before anyone can check in. New functionality generally means more code. Content swirling with rainbow colors, or making it so that content can't use chrome colors, or any other fix that I can think of, will almost certainly be more code than what is in this patch and have even less of a chance of being accepted. The patch here solves part of the problem. It can fix it now. If someone later comes up with another patch that makes it obsolete, great, it can be removed then. But until that happens, this would provide a little bit of protection. We have a handful of different UI spoofing bugs, and this would provide a little bit of protection against all of them at once. We have several hidden, obscure or generally unknown and unused features, and we will have more of them as time goes by. Nobody knows all the features in the product, and what you don't know you don't use. Nobody uses all the features they know of. We have a bug open to discuss the discoverability problem (if anyone wants to be added to the Cc of that bug please let me know privately). Even if we are fighting against feature creep, I think security should override that if it does not degrade performance etc. and in some cases even if it does (for example all the same origin checks). In my opinion the code would add insignificant amount of confusion to xpfe: 5 elements would have two extra attributes, and there would be one new function in three files. This code could be moved to the event system (C++) but I believe that would be more complicated. I also find it a weak argument to say this does not solve the whole problem because most checkins fail in that; we work by fixing the problems small piece at a time. I am hoping that those that are against this would still reconsider.

Heikki asked: * Can you change the magic 66 to 'b' or something more descriptive? * Can you perhaps change e.which to e.keyCode (or something like that) which is more descriptive and should someday become a DOM Rec. Yes. It's simply a matter of changing: var blankKey = (e.which == 66); to var blankKey = (e.keyCode == e.DOM_VK_B); // the letter 'b'

Title line warning isn't all that helpful because a spoofing page can display an image that looks like a popup window with any desired title. The problem with this patch is that the number of people it could help is approximately zero. I don't think saying "we'll add discoverability later" changes that. Passive solutions --- such as chrome cycling --- if they can be shown to work --- help approximately everyone. That's why a significant amount of code to implement the latter might be acceptable but even a small amount of code to implement the former is highly questionable.

Just wanted to mention one spoofing scenario that I have not seen mentioned. Suppose a malicious page draws a DHTML facsimile of a password prompt, OS-specific chrome and all, within its content area. This fake dialog could be made nearly indistinguishable from a real window. It could even be moved around. There's one limitation: it can't be moved outside of the window's content area, but most users don't try to move dialogs before typing in them. Protecting the titlebar or any other window chrome can't prevent this. If you think spoofing of password dialogs is not a serious problem, just ask any AOL user. UI spoofing is quite common on AOL - and it works.

Comment on attachment 107919 [details] [diff] [review] added discoverability to title line You don't need titleLength at all -- just call slice with the first argument only. /be

Mitch: re: comment #61 -- roc raised that point in comment #59 paragraph 1. Why don't we chrome-cycle the titlebar, then? Some platforms let you put any image there, IIRC. /be

Comment on attachment 107990 [details] [diff] [review] address issue in comment 62 Why add those commented-out document.getElementById calls? /be

When I see "to verify", the question "verify what?" leaps into my head. I'm not sure of the right noun, and it's even stranger to see extra " -- ..." words in the title, but it might help someone (maybe) if you said what ctrl-shift-b verifies. "to verify chrome"? Hrm. /be

> When I see "to verify", the question "verify what?" leaps into my head. I'm not > sure of the right noun, and it's even stranger to see extra " -- ..." words in > the title, but it might help someone (maybe) if you said what ctrl-shift-b > verifies. "to verify chrome"? Hrm. I was trying to be terse for the first cut. I anticipated that UE would come up with the desired wording. Adding "chrome" after "verify" is certainly a good idea.

Let me try to clarify the point about a spoofed window being a picture of an entire window. I'm attaching a screenshot in which a real content window contains an image of a spoofed window with a false title line. That title line gives a different verification keypress in attempt to foil the user. But note that the enclosing window is still there and it gives the real kepress. The fact that these two title lines are contradictary should arouse the suspicion of the user.

Let me continue explaining the attack of this spoofed window inside a window. The inner spoofed window gives a false keysequence. And when the user presses that false sequence, the attacker captures it and replaces the image of the inner window with another image that shows the content area of that window image being blanked. So this fools the user into thinking that the chrome portion of that inner window image is real. This would work except for the fact that the user is being presented with two different title lines and they differ in the keysequence. That's the cue that tells the user that something is not kosher.

Of course the screenshot of the spoofed image of a window is contrived. The way I have it is not possible -- the inner window has to be in the content area of the outer window but I have it overlapping the chrome area of the outer window. That's my error, so please excuse that oversight.

This is a joke, right? I just saw a user (who used to be a VMS system administrator) see a GIF picture of a Windows dialog box with flashing icons saying "Your computer is broadcasting an IP address!" and even after selecting the image, thus making it go blue, even after finding the "window" could not be dragged, even after noting that clicking anywhere on this "dialog box" brought him to a page advertising a firewall product, even after I explained that this was a sensaionalist advert, even after noting that the dialog did not use the same system colours and fonts as other windows on his PC, he STILL thought it was a native windows dialog box. Do you really think that adding some lame-ass text to the window title bar is going to make even the slightest bit of difference, other than making us look like freaky geek morons? Please, leave the uber-paranoia to Beonex, and let's get on with the REAL problems with out browser.

Well, some people could be protected, some won't ever know when they've been scammed (the particular example you stated, I've fallen for clicking the bogus close button once when I was extremely tired, and then I immediately noticed what happened after it opened a new site). We'd need a bunch of test users to see when they realize something is fishy to draw any real numbers. Regardless, I object to opening this bug as long as we don't have any fix for this problem (if nothing else, this bug gives just way too many good ideas, some with ready implementations, for bad guys).

Dude, the "bad guys" aren't stupid, they've already had all these ideas. Anyway, we already put a dark inset border around untrusted chrome, we already say [Javascript Application] on alerts, we already allow the user to disable the disabling of the status bar, and so forth. Without making ourselves the laughing stock of the Web browser implementer community, there is little more we can do.

That "dark inset border around untrusted chrome" is really ineffective. Take a look at my demo at http://home.pacbell.net/spmorse/spoof.html and you'll see what I mean. Yes, that inset is there, but it's hardly noticable.

Actually I thought it was totally noticable -- I wasn't expecting it and it made me think something was wrong with the demo because it wasn't spoofing the chrome well enough. The fact of the matter is that even if we coloured all the content blue or something silly like that, it still wouldn't solve the problem for the users that are affected by this. The case I mentioned in comment 75 is real, and as I said, the user in question used to be a VMS administrator, so he's no stranger to computers. (He's also a part time programmer, and webmaster of several medium-sized sites.) If a simple GIF that doesn't even match the system look and feel can spoof a seasoned user, what chance do we have of unobtrusively conveying the concept of untrusted content being able to spoof UI to a novice user?

morse is no longer working on Mozilla, reassigning to mstoltz

This should IMHO be WONFIXed and made public. See comment 75 and comment 79.

I don't want this bug made public yet, for the reason Heikki mentioned in comment 76. I don't want to WONTFIX it either, because this is a real problem, and we have not exhausted every possible solution. We just haven't found a really good one yet.

I fail to see how we can _ever_ fix this problem. My anecdote in comment 75 is not a joke -- it really happened. This proves that even if we make the entire content area _blue_, users, even users that are very computer literate, can still be fooled. As for leaving the bug closed, see comment 77 -- the "bad guys" have already thought of, and used, everything discussed in this bug.

> I fail to see how we can _ever_ fix this problem You are correct, we can't prevent all users in all situations from falling for a spoofed site. But there's lots we can do to minimize the chances of this happening. Just because a 100% solution is impossible is no reason not to seek 80%. The purpose of the security group is to keep script kiddies from using Bugzilla as a manual for mischief, which is why this bug needs to remain confidential for now. Expert "bad guys" know all of this and more - those who don't already know will not learn about it here. Please continue the confidential/non-confidential discussion on security-group@mozilla.org.

Clearing milestone

Unhiding bug: as Hixie points out some of these spoofs are already used in the wild, and there's published research on chrome spoofing.

This appeared on today's Slashdot and scares the hell out of me. I am definitely glad I customize my browser.

My suggestion: Note: this doesn't fix the fake window/browser within browser issue. However, it does mainly resolve the single window spoof problem. Applying this solution would mean the title of this bug could be changed to "Spoofing window(s) within a browser". As such, I believe it's useful. The only real solutions that were advanced were either border around content, that can be viewed as ugly and diminishes screen realestate (but can be a more complete solution); or to not honor the certain hiding directives. This suggestion uses the second solution in a way that should be acceptable to all. Consider this: When asked to hide most (or all) chrome, don't honor the URL bar and status bar hiding. However, modify the URL bar to have two extra icons on the extreme right (where the kicker is). These two icons should do the following: close window, and hide URL and status bar (not necessarily in that order). This immediately solves the URL bar and status bar spoof problems, furthermore the menubar can't be spoofed as it would be located under. But we can already (mostly) do this with an about:config change. Why these two buttons and why there? It's to diminish intrusiveness. This is summed up in four points: - I can't say this applies to everyone, but usually, when I look at a page, I'll first look in the top right to see if it's finished loading. The addition of two buttons (not just one: fluke) would attract my attention: immediate discoverability to resolve the change in handling. - The close buttons are usually some attractive color, further bringing attention. The same thing could be done with the 'hide bars' button. - Usually when you have a popup, it will either be legit: you'll want to hide the bars; or it isn't, you'll want to close the window/tab. This provides a convenient interface to do so. - Furthermore, the hide bars button could be extended with a secondary function to interface with a whitelist dialog. This would make it possible for intranet applications to be excluded from this behavior after first use (thus appeasing web developers). What this means is people will immediately know that this window is different and that there is an easily discoverable way to make the window have no chrome. Other notes: - Why not allow the status bar to be hidden: if this is allowed in such a way that the "two icons" would not be triggered, the status bar could be spoofed without the user knowing. (cf. SSL spoofing, link URL spoofing, etc...) - A suggestion for the icon of the hide toolbar button: an eject button, but with the triangle replaced by a fat upwards arrow. (bottom bar: toolbar; arrow: lift, remove; association with eject: remove) - The addition of a close button may add some redundancy in certain scenarios, however - Most likely the best triggers for the two buttons is if the client requests that either the URL bar or the status bar be hidden, this only thing this leaves as open is spoofing the personal toolbar and sidebar. I don't think that's a problem but some people may have different opinions (are there any password prompts in the sidebar?) - There would have to be a bit of code that would compensate the window size request to account for the extra toolbars such that this wouldn't break current popups (unless the window size already refers to the usable space) - In my opinion randomness may not be optimal since the user will not know what to expect. It may even be worse: stuff changes all the time so, if an attacker creates a dialog that only loosely looks or acts correctly (eg. if there's no 'color security border'), the user may chalk it up to randomness and believe the window is legit. - Does this fix the problem for blind people? (Does it mater? Honestly, I don't know if it's a consideration.) I haven't done any web development since the HTML4.0 days otherwise, I'd try to fix this my-self.

How about a whitelist of domains that can do chromeless? While this can't protect against the DHTML spoof, it certainly would cover pop up windows. DHTML within the context of browser.xul (comment 60) should probably be a separate bug from XUL chrome spoofing.

While Comment 89 does present some interesting ideas on how to solve this issue, I think a much simpler and easier-on-the end-user solution should not have 10000 preferences; rather it should be three things: simple, easy to see, and easy to understand. I think that what we should do, and that qualifies for all three of the above, is simple: if a website contains XUL (no matter how much), have the "yellow information bar" (that is currently used to inform people if the page is trying to open a popup window or something) show up that says something along the lines of "This web page contains [Some non-developer name for XUL that normal people can understand] and may be spoofing the interface. Just to let you know." with a button to white-list that site/domain, so that the bar won't show up. This way, people don't have to deal with a popup dialogue (just as bad as a pop-up ad, imho - people will just click "OK" anyway), and also if they are turning off the address bar and stuff, the "yellow information bar" will look really weird - it will be ABOVE the UI, when normally if it was just a regular page using XUL, it would be BELOW the UI. In addition, this gets us around messing with all sorts of crazy preferences and logic - for example saying "pop up a message if it uses XUL *and* also turns off the address bar and status bar" - it is just simple, if it uses XUL, show the bar and allow the user to turn it off for that website/domain.

(In reply to comment #90) > I think that what we should do, [...] is simple: if a website contains XUL [...], have > the "yellow information bar" [...] show up that says something[.] Agreed, the yellow box may be a more in the lines of current responses. However I don't believe it should be triggered solely for when a window uses XUL. It should be triggered any time someone decides to hide the url or status bar: most people don't customize the browser appearance, the UI could be spoofed with DHTML, and therefor without warning. Other than that, the only thing to worry about is that the user might start believing the “yellow information bar” is too apocalyptic and start ignoring it. Also, if it was unclear, my original comment 88 was to trigger the the URL bar changes independently of the presence of XUL, just in response to the hide URL or status bar. The implementation of comment 90 (with the above modifications) would probably be significantly easier, while achieving the same results as what I proposed.

Without reiterating my comments from comment 75 and comment 77, which I believe still apply, the only things I think we could do to fix this bug would be to simply disallow the untrusted-content-driven hiding of the menubar and location bar, and disallow their sizing and positioning windows such that they overlap other chrome (only allow them to be popped up above their originating content area). Microsoft have said they'll be doing some of these things in Windows XP SP2's IE update. Every time we try to do this, some Web Apps people whine that we are breaking their apps, but frankly I think "tough". Note that in WHATWG's Web Apps 1.0 we'll be introducing much better ways of doing untrusted-content-driven-popups that don't suffer from spoofing problems (basically, fancy support for positioned DIVs). Personally, I would be fine with just blocking _all_ popups once and for all (disable window.open), but I doubt that would fly.

(The idea of having the info bar on any pop-up saying "This window was openned by example.org. Click here for pop-up options..." with the popup having "Don't show this message for example.org", "Disallow all pop-ups from example.org", etc would be pretty cool too, actually.)

*** Bug 252198 has been marked as a duplicate of this bug. ***

WT (a lightweight XUL clone in Java) solved this problem by adding an indelible "scar" to otherwise chromeless windows. See the red stripe/lock icon in the lower left corner of the attached screenshot for an example. Mozilla could use a similar idea on untrusted windows opened without appropriate chrome.

fyi, java applets when opened in a window are showing a status bar with a text "Warning". you cannot remove it.

What about something like this? Web apps have a legitimate desire to minimize browser chrome. Here's a mini replacement read-only location-bar when the real location bar is turned off. Also shows the security status and allows easy access to page info. Or we could just force the location bar to be on using the existing pref, but obviously there must be some reluctance to that or it'd be done already.

What does it look like?

screen shot of a typical popup with the patch implemented (suite). Might as well take the bug, Mitch isn't around.

This is what the same thing would look like without any code changes, just forcing the location bar to be on all the time. They're pretty similar, especially if you're turned off extra buttons as I have).

I think it's important for this UI to be consistent with the normal UI. So actually I think you should make the location bar be the standard location bar. In fact I'd go one more daring step and say we should put the lock in the location bar *always*. Hey, the whole point of the lock is to say that the URL is a trustworthy indication of identity, so it should have been next to the URL all along.

Despite having created the patch above, I tend to agree with roc that the standard UI would be preferable and that the URL bar should include the SSL lock -- easier to train people to look in one place rather than two. Here's the Firefox version of forcing location on. More obtrusive than in the Suite because of the buttons, and on a small window like this the buttons squeeze the actual location and would make a user:pass phishing URL that much easier to sell. Firefox currently does include the lock icon in the location bar for https pages, but it's way over on the right side and not even present for non-SSL pages: I fear people won't learn to look for it since it's a sometimes thing. It also isn't active, doesn't show a tooltip with the CA or bring up the page info dialog when clicked (meaning a page could block access to page info by hiding the menus and trapping Ctrl+J).

(In reply to comment #102) > Firefox currently does include the lock icon in the location bar for https > pages, but it's way over on the right side and not even present for non-SSL > pages: I fear people won't learn to look for it since it's a sometimes thing. > It also isn't active, doesn't show a tooltip with the CA or bring up the page > info dialog when clicked (meaning a page could block access to page info by > hiding the menus and trapping Ctrl+J). A patch for Bug 252811 has been granted approval-aviary1.0, and should help mitigate this problem by disabling hiding of the statusbar by default.

The lock isn't important for spoofing like this. What's important is to make it impossible for the site to be able to create a window that _looks_ authentic but is actually not. I think disabling location=no is a fine idea.

> The lock isn't important for spoofing like this. Yes it is. The only point of forcing location=no is to show the current URL. If there is no lock, or the lock can be spoofed, then the URL is meaningless in the face of an attacker who can monitor and inject packets into the network. Example: -- User browses to www.bank.com (or gets redirected there) -- Attacker intercepts the HTTP load and replaces it with chrome that spoofs the lock, plus a username+password entry form -- User sees spoofed lock plus the www.bank.com URL, trusts the page, game over We can't fix these issues piecemeal, with different people fixing UI elements in different bugs. Someone needs to make a coherent decision and I believe that someone is Ben, at least for Firefox.

Yeah, that makes sense.

IMHO Dan's Firefox patch is close to optimal. Just make it always show an unlocked lock for non-secure pages.

(In reply to comment #101) > I think it's important for this UI to be consistent with the normal UI. The only problem I can think of is that a user:pass would have to appear in the standard address bar and would therefore be more vulnerable to phishing scams. However, a read-only address bar could be stripped of the user:pass part.

The phishing scam solution is to escape the username:password part so it doesn't look like a domain name.

That could still allow for an extremely long URL... Would people know to scroll in the location bar to investigate further? How would the read-only location bar show extremely long URLs, only the first chunk of it?

The user:password and similar phishing attacks are a different problem. It has to be solved for normal windows as well as popups, and any solution for normal windows will no doubt affect popups that pull in the location bar. Let's keep it to a different bug.

Okay, Firefox displays the target hostname next to the lock in the status bar. So bug 252811 really takes care of this issue for Firefox. We should make Seamonkey work the same way.

(In reply to comment #112) > Okay, Firefox displays the target hostname next to the lock in the status bar. > So bug 252811 really takes care of this issue for Firefox. Firefox only displays the hostname on SSL pages. Normal unencrypted sites will not have the hostname or the lock displayed. It seems like that would leave the spoof possible by just using a non-SSL site. Maybe the hostname should be displayed for all sites.

I actually prefer forcing the location bar than forcing the status bar, because being at the top of the window it is far more obvious to most users than a duplicate status bar will be. It also preserves navigation functionality. The only reservation in the past has been impact on web site compatibility with regard to popup window sizing - has this been resolved? Do sites size by the outer height of the window, or the client height area?

Even if forcing location bar, it has to be read-only, otherwise it will create one more tabstop, messing up the tab sequence.

I agree with several of the posts proposing ways to distinguish different kinds of chrome windows, including a thin border, status bar &/or address bar by default, etc. I think, however, that along with these warnings, a confirmation window should appear before a chrome window is opened by a website asking the user wether or not to trust it. I think, further, that, similar to the cookie confirmation dialog, a diolog should appear when a website tries to load images, etc from chrome: with options such as always/never for this site/session, etc. This should be enabled by default and able to be disabled in the options dialog (under security, not privacy). I am weary of allowing websites to display XUL at all, except maybe in a jailed environment as it seems a likely avenue for a security exploit similar to the ones which pop up in ie's fancier features every day.

*** Bug 254657 has been marked as a duplicate of this bug. ***

Robert said: "Maybe the hostname should be displayed for all sites." We specifically didn't do this because if your connection is not secure, you have far less guarantee that the site you think you are on is the one the content is coming from (think DNS spoofing.) If this is a security mechanism, we should only show the domain when we are (within the limits of SSL) certain that it's correct. Ben said: "I actually prefer forcing the location bar than forcing the status bar," Just for those following along, a quick summary of the points in favour of forcing the status bar rather than the location bar (in case people missed them over in bug 245406): - IE compatibility (status bar will be compulsory in XP SP 2) - smaller vertical height (usually) - The vast majority of people currently look to the SB for security info - nicer for web-app authors and people who want to make navigation-less windows (for which there are many genuine uses) - There are a bunch of good usability and security arguments for domain-in-SB (over in bug 245406); but it isn't any use (and can be spoofed easily) unless the SB is compulsory. Gerv

*** Bug 254582 has been marked as a duplicate of this bug. ***

The status bar is insufficient as an anti-spoofing measure. In fact, it might even assist a spoofer if they put up a faked toolbar and got the real status bar to "prove" it was legit (better on a non-ssl, no status bar host site, of course) Drivers plus Ben agree it should be the location bar to do any good (brendan, shaver, roc, dbaron, asa, myself). Gerv makes good points in comment 118. We should look into whether we can adjust the window height to compensate for the stolen space. We could also consider making the urlbar read-only. In the Firefox case we need to hide more of the buttons when the opening page is attempting to hide the toolbars.

(In reply to comment #118) > Robert said: "Maybe the hostname should be displayed for all sites." > > We specifically didn't do this because if your connection is not secure, you > have far less guarantee that the site you think you are on is the one the > content is coming from (think DNS spoofing.) If this is a security mechanism, > we should only show the domain when we are (within the limits of SSL) certain > that it's correct. That's pretty subtle though. IMHO, in the absence of the hostname in the status bar, most users are going to simply look elsewhere for the hostname and believe whatever they find (e.g., a spoofed location bar). Which is actually more dangerous since it makes them vulnerable to passive Web page design attacks, whereas DNS or HTTP hijacking requires some sort of active packet injection attack. > Just for those following along, a quick summary of the points in favour of > forcing the status bar rather than the location bar (in case people missed > them over in bug 245406): > > - IE compatibility (status bar will be compulsory in XP SP 2) Aye. > - smaller vertical height (usually) I think we can work around the sizing issues. > - The vast majority of people currently look to the SB for security info Actually they currently have to look at both the status bar and the location bar to get any meaningful security info. And anecdotally (and logically) they look at the location bar first because it's at the top of the page. > - nicer for web-app authors and people who want to make navigation-less > windows (for which there are many genuine uses) I suggest that when the Web-app author requests "location=no", we give them a location bar with the same look and buttons but with everything disabled (except for the click-on-lock behaviour). > - There are a bunch of good usability and security arguments for domain-in-SB > (over in bug 245406); but it isn't any use (and can be spoofed easily) > unless the SB is compulsory. We need a better story on identifying the domain in the location bar as a general defense against phishing attacks. Not much point in worrying about chrome spoofing if the user will be tricked by MICR0SOFT.COM (or some user:password thing) in a regular browser window.

Adjusting for the window size could work like this: -- Figure out what client size the app really wants, by subtracting the sizes of the chrome it requested (probably the sizes of the IE chrome parts, in fact) from the specified size -- Compute the actual window size by adding the sizes of the chrome parts we're going to show

> IMHO, in the absence of the hostname in the status bar, most users are going > to simply look elsewhere for the hostname and believe whatever they find > (e.g., a spoofed location bar). Perhaps. How about normal font for non-secure sites, and bold for secure sites? Either that, or just display it for everything - I don't feel too strongly about this. > Which is actually more > dangerous since it makes them vulnerable to passive Web page design attacks, > whereas DNS or HTTP hijacking requires some sort of active packet injection > attack. Well, it depends. Would you rather your security UI was 100% right when it said something, or it was 99.9% right but said something more often? > Actually they currently have to look at both the status bar and the location > bar to get any meaningful security info. All they need is in the status bar - whether it's secure and, if so, what site they are on. > I suggest that when the Web-app author requests "location=no", we give them a > location bar with the same look and buttons but with everything disabled > (except for the click-on-lock behaviour). I can see that confusing a user ("How come this web page doesn't let me navigate?"). I also think that people who remove the location bar often do it for aesthetic reasons on certain types of window - web app URLs are ugly these days. So is there a happy compromise here? How about something like the current status bar domain display and lock, but in a narrow bar at the top of the screen? So it makes it clear which site you are on, but without being ugly or presenting confusing UI. So this is like the UI of dveditz's patch, but less complex. A bit like that SpoofStick thing (http://www.corestreet.com/spoofstick/) except a lot less ugly ;-) and taking up less space. These ideas for window size guessing algorithms really scare me; I can see this becoming a nightmare for web developers who ask for a 200x200 window and wonder why what they get isn't what they expect, or what other browsers give them. And how does it work when you ask for and expect a window of the maximum size of the screen? Note that the IE chrome will be different sizes on different OSes (bigger on XP, IIRC) and depending on theme chosen. Gerv

Brendan and I, and dveditz and I on separate occasions talked about this. Here's what I'm in favor of: making the Location bar trustworthy. We may not be able to get to that in one pass, but I think that should be the goal. So, the best possible pre-1.0 fix for this bug could be (Brendan and I agree, at least, and I don't think dveditz differs based on our conversation Friday): - all windows open with the location bar showing - if other chrome is not specified, other chrome is not shown - the location bar is read only if it was not specified, so as not to break web app functionality. So, a popup window opened with no features might look like this: http://www.bengoodger.com/software/mb/forcedlocation.png The sizing isn't dramatically different from the status bar.

In reply to comment #124: Would you do this for all popups or just the ones that use Downlaodable XUL? Here are some other thoughts: Would you also have an alert message box, similar to the new xp sp2 active x warning, or Mozilla's XPI (or jar or whatever) install box, that explains that an XUL "program" is going to run? Could someone spoof the UI without even using Downloadable XUL (maybe a seporate issue)? You could place some text in the Window Title bar (or an icon) that explains that a user is not on a secure site (for javascript enabled popups - or any windows that have status bar/location bar turned off). This would allow sites that use Chromeless Popups for legitimate reasons to continue using them with minimul interuption (like for flash popups on marchofdimes.com and the like). You could require location and status bars for windows that host secure sites (turn them on if a user is directed or navigates to a secure site while in a chromeless window).

Ben: would it be good to have this "read-only location bar" do one or more of the following: - not show username/pass info at all - show a lock - only show the domain (like the current status bar indicator) My thought is that we want this to provide as little and as simple information as possible while still being secure. I think there's power and security in banks being able to say "In Firefox, all our web app windows have exactly this <screenshot> at the top", where <screenshot> is a lock and then http://www.company.com. In other words, if _anything_ is different, don't trust the window. If we always provide the whole URL, we need to teach users the difference between the following: http://www.mybank.com/someDLL.jsp?sessionID=654FADE4532&foo=bar and http://www.mybank.com.someDLL.js?sessionID=654FADE4532&foo=bar If we just provide the domain, not only does it look neater, but the difference between: http://www.mybank.com and http://www.mybank.com.someDLL.js is much more visible. Gerv

I would say clipping the username/password information from the display (I've heard arguments that have been made as to why it should kept... but none of them trump being able to trust the location bar) is a good first step... other embellishments can be treated separately. Since in my mind the location bar is the same piece of UI used elsewhere, just readonly, all the same functions are available - yellow bg, lock icon, etc. I implemented a rough patch quickly, here's a screenshot of it in action: http://www.bengoodger.com/software/mb/forcedlocation2.png

I haven't exhaustively tested this, but am interested in feedback.

I don't mind what happens to the popup trusted location bar, but please don't remove the username/password part from the normal location bar. (I don't mind if you heavily escape the username/password to make spoofing sites impossible, so long as the URIs keep working when I copy and paste them.)

Secure pop-ups should get the status bar as well so they can benefit from 245406. (on a reduced size location bar, its needed even more IMHO. Consistency as well, if we are going to tell users how to spot a phishing attempt). I can't really see a need for the status bar on non-secure pop-ups however.

I forgot about 252811 disabling hiding of status bar by default in my last comment - so all pop-ups are getting the status bar already and then the read-only location bar from this patch. I can't really say that I'm against having both, as long as the extra chrome size is added on to whatever the site requested.

If the location bar becomes always-on, and we take steps to make it readable and trusted, then we should back out the status bar domain-name and always-on patches. There's no point in having both - it would just confuse users. Simplicity is key. (It's the same simplicity argument that leads me to assert that the read-only location bar should only display the domain of the site. See comment 126). Hmm. It's just occurred to me that swapping status-bar-always-on for location-bar-always-on removes guaranteed access to the cookie and popup icons, and the stylesheet switcher. <sigh> Gerv

I like the status-bar domain name - it's a simple & effective idea, and is also something that helps distinguish Firefox from the competition. If it gets removed then we should do something similar for the address bar (eg make the domain bold or a different colour). If you are going to scrap the *implementation*, please don't scrap the *idea* (and this is from someone who was initially doubtful about the whole thing)

plussing. I think we need to get a solution in for the preview release so we give a chance for wide spread use of this and assoicated feedback. dbaron, deveditz, ben and others: this will be in the agenda for the aviary meeting tomorrow. come with recommendations and lets get this wrapped up.

I accidentally commented this in another bug: To achieve the effect in the screenshot the following prefs also need to be set this way: dom.disable_window_open_feature.location true dom.disable_window_open_feature.status false

(In reply to comment #133) > If it gets > removed then we should do something similar for the address bar (eg make the > domain bold or a different colour). I can't find it right now, but I think there's a bugzilla bug about color coding the url in the address bar -- this would be effective at helping fix this bug, as well as the one listed here: http://www.mozilla.org/releases/mozilla1.8a3/known-issues.html#browser-general which is about long usernames. the protocol would be one color (black?), and the username, password, domain (maybe bold this section for secure sites), and path would each get their own color

Be careful about color-coding so that you don't make it unusable for people who are color blind. The most common form of color blindness involves confusing red with green. Other forms of color blindness involve other pairs of colors. A rare form causes everything to be gray. Thus, don't use one color for "good" and another for "bad" since a color blind person might confuse them when they both appear gray. Instead, there might be only one "alert" color with all else being black.

Suggestion: For all chromeless windows, pull a Java-style thing. End each window name with [Popup Window]. This would help users differentiate between real browser windows (which would not end with [Popup Window]) and chromeless browser windows with fake chrome (which would end with [Popup Window]). That might get somewhat annoying, and it wouldn't exactly work if the name stretches off, but it's an idea :/ Possibly also an always-on statusbar with "Warning: Popup Window" in it would get the point across (obviously not required for popups with chrome).

no. it's way too easy to push something offscreen if it's appended.

> it's way too easy to push something offscreen if it's appended. then prepend it.

Wouldn't prepended content be susceptible to hiding as well as it could be off the top of the screen? As several of the given edges of a window could be offscreen at any given time, it would seem that the ultimate solution should take into consideration that the warnings around the content might not be seen if they are placed on an edge. As such, it would not provide the user with a useful warning.

I thought it was the case that web content was not permitted to position windows offscreen, even partially offscreen. Am I mistaken?

From my testing, the top and left side can not be explicitly placed off screen, thou the bottom and right definitely can as the window can be sized to be larger than the screen. Additionally, the start menu or other tool bars that bind to the side of the window can be on top of any given side of a browser window.

Comment on attachment 155874 [details] [diff] [review] patch against aviary branch to implement my screenshot for firefox need to get reviews and get this in mas rapido.... dveditz plans to check in just pref changes for 1.7

Comment on attachment 155874 [details] [diff] [review] patch against aviary branch to implement my screenshot for firefox r=dveditz (including the pref change not in this diff)

Comment on attachment 155874 [details] [diff] [review] patch against aviary branch to implement my screenshot for firefox a=asa for branch checkin.

Complete patch with pref setting, and code to trim username/pass from location when links are clicked.

Fix a problem with the last patch where the trim user pass pref didn't work because of a js error.

Comment on attachment 157917 [details] [diff] [review] patch seeking review for the new sections - the user-pass trimming (to prevent spoofing) which is controllable via a hidden pref.

Attachment 146447 [details] [diff] in bug 157354 takes care of the user:pass if we want it -- there was some controversy about doing it at the time which scared me off checking it in (note: applies to your approach here as well, mainly Darin's concern about non-anonymous ftp). If we're going to do it it makes more sense to do in docshell where we're already spending time running URIFixup code (and would fix Seamonkey too). >+pref("dom.disable_window_open_feature.location", true); >+pref("dom.disable_window_status_change", true); These could go in all.js, Seamonkey wants these too.

OK, in that case my first patch will work. Since it has all the appropriate bits set, I'll check it in now ;-) Are you sure the dom_disable prefs should go into all.js and just not additionally into browser-prefs.js? By putting them into all.js (correct me if I'm wrong) we're making a call for all potential embedding clients, not just firefox and seamonkey...

My patch is checked in on the trunk and aviary br for firefox - some work needs to be done still for seamonkey to decide what of its UI to hide if the same approach is to be taken there.

I downloaded the latest branch build and I see this new url bar in popup windows. However, when I go to customize I could remove the url bar. If I add it back it looks like a regular url bar, not the read only url bar. It even lets me visit other sites.

Simple patch to remove the context menu from the nav-bar when in chromeless mode. If you can think of a better way, by all means use one, but this works and prevents: 1) Disabling of the nav-bar 2) Customization that lets you drag the address bar off and back on (messes up the nav-bar in the normal chrome state too) 3) Enabling the bookmarks toolbar (even though it's not visible)

Apologies for bugspam, but found another problem... when the nav-bar is hidden in a regular window, it remains hidden in chromeless popups (i.e. the current code is ineffective). My proposed solution is to strip the "collapsed" property. I also switched to removeAttribute for the "context" property too.

I've noticed using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.3) Gecko/20040907 Firefox/1.0 PR (NOT FINAL) that buttons and spacers on the Navigation toolbar (other than ones there by default) also appear in pop-up windows. There should always be only the location bar.

Another bug: If the location bar has been removed in Firefox's default view, then it is not present on the navigation toolbar in the chromeless popup. A blank toolbar is shown.

It sounds like we need a special toolbar for this situation, just like fullscreen which is independent from user customization.

Is there a reason the whole toolbar cannot just be made insensitive? Although that might interfere with url selection (which I'd like to have). Interaction with the throbber and the site icon seems kindof weird to me. Previously a popup without the navigation bar would not have this anyway, is it intentional? Maybe Asa is right... Rather than having to disable many features of the existing urlbar and plan for (future) changes, it's better to make something specific for this?

I agree with Asa that we need something specific here. IMO it's another security problem when every dump user now sees the complete URL in the top of the window. Popup windows are often used as logins etc. Also, why do we need the google textbox in a popup??? I guess we're going too far here. The "fixing" of the spoofing issues is getting a real problem for our company because the initial idea for mozilla as a web platform is going to be neglected.

> Popup windows are often used as logins etc. That's a good reason to prevent pop-ups from being spoofed. > Also, why do we need the google textbox in a popup??? It's a bug. > I guess we're going too far here. The "fixing" of the spoofing issues is > getting a real problem for our company because the initial idea for mozilla > as a web platform is going to be neglected. Can admins set hidden prefs to turn off this spoof protection for certain (internet) sites?

> Can admins set hidden prefs to turn off this spoof protection for certain > (internet) sites? Why not simply putting "Mozilla Firefox: <title>" in the titlebar instead of using the toolbar? Or when showing the toolbar why not simply show the domain instead of the whole path and search string?

This addresses Asa's comment, I think. Instead of adding more XUL, I have cloned the toolbar node (using cloneNode(false)) and appended gURLBar as a child. Two notes: 1) I've added in a variable which someone could (and should) expand to allow this to be disabled by preferences on a per-site basis. 2) This still breaks if the toolbar is not visible in default view, but so does the rest of the browser too - see Bug 247603.

> This addresses Asa's comment, I think. Instead of adding more XUL, I have > cloned the toolbar node (using cloneNode(false)) and appended gURLBar as a > child. As far as I understand it will also prevent custom extensions' buttons from appearing there, won't it?

Correct. I tested it with my Foobar Controls extension, but it excludes any elements other than the URL bar.

Comment on attachment 158192 [details] [diff] [review] Make only gURLBar be present Moving review request to Ben as he wrote the patch and Asa normally doesn't do code reviews.

if you disable the "hide tab bar when only one tab is opened" option, a tab bar will be visible under the special location bar in popup window without toolbar. expected result: no tab bar ... using Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040908 Firefox/0.10

(In reply to comment #167) > expected result: no tab bar ... If the tab-bar isn't to be visible, middle-clicking should either (1) open a new pop-up window, or (2) open a new tab in the window from which the current pop-up window popped up. Opening a new, hidden tab in the pop-up window should not be possible.

maybe simply disable middle clicking if the popup is set to toolbar=0 whatever the decision is for the middle click stuff, the tab-bar must be hidden from toolbar=0 windows (regardless of the settings for ordinary browser windows)

I'm afraid I'm alone with my concerns regarding this approach here. Anyway, I'll try it again: Did anybody realize that spoofing can't be hindered by such methods? I mean I can easily create a layer which looks exactly like any window I want. Even a popup block wouldn't have a chance to prevent this (Look at netscape.com). What I want to say is that you can't prevent someone from creating things on the screen as he likes. On the other hand it's getting more and more difficult for enterprise developers to create good looking and good working web-apps. After 1.5 the problems started with the chrome flag in windows.open and now continues with these toolbars. I doubt that after all I get heard but thanks for reading this. Hish

> Did anybody realize that spoofing can't be hindered by such methods? I mean I > can easily create a layer which looks exactly like any window I want. Even a > popup block wouldn't have a chance to prevent this (Look at netscape.com). Yup, you are correct... sort of (*). I raised this same issue while discussing this problem in-person with Jesse, Doron, and others a few weeks ago. I know it is more work to create a DIV that looks and acts like a window, but it is totally do-able. So, are we really adding value by forcing the addition of some chrome (urlbar, or whatever) to untrusted windows? Can we really solve this sort of spoofing problem? Maybe we can hinder it, but there doesn't seem to be a way to completely protect against it. Afterall, you can put XUL inside that DIV :-/ (*) I said "sort of" because you'd probably have to limit your attack to a particular version of the default theme on some version of Windows in order to match the window border, but I'm sure that's not a huge limitation ;-)

> (*) I said "sort of" because you'd probably have to limit your attack to a > particular version of the default theme on some version of Windows in order to > match the window border, but I'm sure that's not a huge limitation ;-) mpt pointed out the obvious in Doron's blaahg that this is easy to around by simply inspecting the UA string!

RE DHTML "window": we've now cycled around to comment 25 from two years ago (and comment 30, comment 61, etc) and the Dartmouth research. See especially Hixie's anecdote in comment 75.

Yes, that was my point. A spoofer can very easily do his job, but all these security "enhancements" hinders web-app developers from doing their job. Because maybe 80% now use win-xp with blue rounded windows, I now consider spoofing myself by replacing my popups with layers in order to maintain our clients the look and feel. Another alternative is to recommend Seamonkey 1.5. But both approaches aren't really satisfying. :-(

This feature does protect some users: many power users will find a fake "browser window" contained in the content area too small and try to make it larger. Some, like me, always maximize browser windows.

(In reply to comment #175) > This feature does protect some users: many power users will find a fake "browser > window" contained in the content area too small and try to make it larger. > Some, like me, always maximize browser windows. Some like you recognize spoofing by other methods already. When I would have the criminal energy to spoof users, I'll do a bit of js and even would allow them to zoom and move the layer. Now you can say that I can't move it outside the main window. But hey, when talking about spoofing, we're talking about trying to catch <1% of users who surf to a specific page. So, this "feature" doesn't help at all. It (and some other enhancements like the discussion of removing view-source or the removal of the chrome flag and a dozen other issues) simply risks mozilla's unique position as a web-app/web-development platform. Maybe it would be a compromise to let the user choose under preferences "use firefox as web-client" with a hint that in this case some security issue my occur. In that case I could happily live with security=high by default and tell our clients to disable it.

I agree with many of the statements that adding chrome will do little to prevent spoofing, and will do much to hinder legitamate developers. My current favorate quote: If encryption is outlawed then only outlaws will have encryption. I believe that the same principle applies here. That's why I suggested an alternative, less intrusive way to allert people that they are connected to a secure site - putting an icon on the title bar. This way, even if the spoofer makes chrome that looks like the connection is secure, they can't fake the icon on the title bar (at least not with a real window - they could still do it in JS). this idea could be expanded, and we could add another type of icon for the type of content - so that if an XUL app is running, they will see an XUL icon, or something else that they would see and think is not "the normal way it works" - which is something casual users of computers are actually quite keen to pick up on, and aks about.

Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040909 Firefox/0.10 The locationbar of the opened window has background-color missing (making it use the body color).

if you still go on with this idea of "sticky location bar", you need to fix two things a) you can right click, customize the bar; although you dont see the change on this bar, the changes will be apparent when you will reload the main window. and b) the tab bar is present

I fixed problem A with my patch, and while I haven't tested, I think it might fix B also.

Toolbar separators should be removed also.

The patch in Bug 258405 combines the patch from comment #163 with a patch to remove all toolbars except the location bar.

A couple more UI glitches: 1) If the location bar is focused and Shift+Down is pressed, the auto-complete drop-down is shown. 2) If the throbber is present on the navigation toolbar, it doesn't get hidden. Personally, I think that's fine. The problem is that is can be clicked or middle-clicked, opening up the Firefox product page.

Gravest apologies, but I object in the strongest sense to the 'solution' (forcing up the address bar) to this bug, because IMO the source of the bug should be fixed instead of penalizing site and web-application designs -- and fighting spoofing is an almost completely futile attempt that only harms the good users. a) The url bar and domains is meaningless to the average user - they will NOT track whether a link *should have* changed domains (agree/diagree)? b) As someone stated earlier, all browsers.. (in fact not just browsers, mail clients, etc).. are "vulnerable to" window content spoofing (ie. the site serving look-alike content).. what we are calling "spoofing" is THE FAULT OR MALICE of the site author that is simply unpreventable without putting a label over EVERY element, and is in other cases also serving some legitmate or inadvertent purpose (eg screenshots). c) The XUL/chrome specific part - if the site can serve (Mozilla specific no less) XUL and Mozilla does not have a more elegant way of sandboxing it then *this* is the fundamantal flaw, which needs to be treated at its root. If that means changing the entire implementation to only exec signed code, then lets scrap the existing stuff. What other choice is there? And if visible content is vulnerable to this, what about linked or nested content (.js), frames, iframes, images, form actions... place an address bar over all those too? Shimmer. d) this "bug" and its current solution set a MASSIVE precedent for making similar GUI compromises in a whole slew of security-vs-layout topics (spoofing or otherwise) not yet discussed in this bug (topics which are probably better left unmentioned for now given this apparent destabilizing effect on even a very matured function like window.open's default behavior). Suffice to say that just about _everything_ in a content window can be spoofed even without XUL, including bookmarks, nav buttons, menubar, status bar.. are we to compromise on these to and force-display them?

force status bar instead, documenting firefox.js so that people know how to make things more obvious if they want to

The current behavior with the bar thing at the top, to me, seems as if it's not so much the right way to fix this. I'm thinking a multi-pronged approach would help. Earlier, I suggested appending [Popup Window], but it was pointed out that that wouldn't help the situation any. So, here are my ideas: 1) For all popup windows, use a *different* icon. MSN Explorer 7.0 does this for popups. It uses a "document" style icon. And a *slightly* different toolbar (back, next, URL bar), but let's go into #2 for that: 2) For standard popups (not XUL/Web Application), do what you currently do, but fix the obvious bugs (tab bar shows up, web developer shows up, etc.), but also add a button after the URL bar that's a question mark that would explain what the hell the URL bar is (possibly link it to a topic in Help), and possibly provide a way to disable it for power users (even if it's just a pref, but I would really like to see Advanced > Browsing > [X] Hide URL Bar in Popup Windows). 3) For XUL/Web Application popups, throw up an info bar, and make it say something like "This is a web application and it may mimic the interface of Firefox. Click here for more information and options." At that point, the user could click on it and get something like the popup-blocked does: More Information... ------------------- Hide this message when web applications run I believe that solves both tiers of bad popups (bad XUL, bad images), and gets the point across: this is a popup, not your browser! This also will make users of web applications happy, because they won't have that URL bar at the top if they choose to kill the information bar message. You know, it just feels better to not have the URL bar on web apps, but this bug was to fix that in the first place. That's why I'm saying to just use an information bar on web apps. Sorry if I'm suggesting this in the wrong place, the bug looked as good a place as any.

Summary to self for future doco: user optical problem, forced statusbar solution. Sorry for the spam but 186 comments I'd otherwise have to read 3-5 times!

Can I hide the toolbar when using signed scripts?

(In reply to comment #168) > (In reply to comment #167) > > expected result: no tab bar ... > > If the tab-bar isn't to be visible, middle-clicking should either (1) open a new > pop-up window, or (2) open a new tab in the window from which the current pop-up > window popped up. Opening a new, hidden tab in the pop-up window should not be > possible. Either way, the current implementation does exactly what it shouldn't do: display the tabbar. Why not? I use (and lots of developers with me) popups for displaying information in a small window, like the popups Firefox generates when opening Options or any other pref-setting-window. The last thing I need is a whole lot of extra chrome added to the window when I just want to display a list (I use it for buddylists and visitor lists on a community). I've set all options to false for a reason: Not showing all those toolbars. The new locationbar and the tabbar together are almost as high as half the windows was a few days ago, so my popups have increased in size for 30% or so, I really don't like this...

Comment on attachment 158816 [details] [diff] [review] patch, force status instead of location [checked into aviary branch] Ben has checked in this patch, see bug 259192. Now the status bar is forced instead of the location bar again. Get 1.0PR (out now) to test it.

> Ben has checked in this patch, see bug 259192. Now the status bar is forced > instead of the location bar again. Glad to hear that!

(In reply to comment #185) > Created an attachment (id=158816) > patch, force status instead of location > > force status bar instead, documenting firefox.js so that people know how to > make things more obvious if they want to How about adding a button to the statusbar (in the case that all chrome is missing) offering the option "restore window functionality" meaning: -allow resize -restore all toolbars -override rightclick contextmenu This would offer anyone who cares the option to check the window in great detail if they don't trust it.

In the tonights build I see the location bar is removed and the status bar takes its place. *Much* more pleasing... but still futile, sorry to say.. tell me of I'm wrong here but: a) users wont keep track of, let alone understand, the domain that they should be using, let alone redirections as in the case of server farms, etc (www1.moz.com, www2, mail. login., etc) (true/false) b) One can spoof the status bar (or location bar) using mere framesets or iframes or DIVs (true/false). c) Nethier method deals well with multi-frame content anyway; one frame could load after the spoofed content, and report the intended domain (true/false). To dela with this the browser would have to diplay status/location bars for each frame/iframe/div. IMO the only viable add-on solution to this concern is to display an intial pop-up alert similar to the "Your are about to send form data over the internet...", but instead saying something like "You are about to connect to a different server than the one you are currently using" and allow the user to permantly dismass the alert. Like the Form Data Submission warning, there is simply no other answer than to make the user initially aware that there is some risk invloved here, becasue there are too many attack vectors. The 'form data submission' and 'you are about to leave a secured site' warnings address what is a HUGE risk potential, but no user tracks they actual occurance, nor would they this bugs solution (dispalying the domain). And legitimate site operators already have a solution - SSL - its years-old deisgn already protects against this (except where there is malice by the server operator), since interframe communication is sandboxed (or is there a flaw in XUL there?). Provided a site has a trusted cert, there cant be any inter-domain data transfer... nor content spoofing, without an certificate alert.

For clarity I humbly propose that this bug be declared fixed (or not) soley on its original topic of a reported vulnerability in XUL itself, in this case that a user could download XUL that is actually able to take control of chrome (hiding and/or replacing the location bar, window dressing, etc), and create a new bug about spoofing so that the devil's advocates among us have plenty of room to submit example loophole scenarios. :-) I actually didnt notice in all the responses an indication as to where/if the 'downloadable/sandboxing-of XUL' has been fixed.. if it hasn't I have alarms about a Visual-Basic-Script-severity vulnerability, because that opens up new attack vectors, like buffer overflows(?) inside of XUL itself, maybe XPI installers (from what little I know about them), or spoofing entire applications to be looking like completely different apps (mail, money management, etc) since even the native window-dressing can be changed via XUL(?)..

Possibly related to Mozilla bug#257036.

> I actually didnt notice in all the responses an indication as to where/if the > 'downloadable/sandboxing-of XUL' has been fixed.. if it hasn't I have alarms > about a Visual-Basic-Script-severity vulnerability, because that opens up new > attack vectors, like buffer overflows(?) XUL is rendered just about the same as HTML or SVG... Buffer overruns in the rendering of XUL would mean there's a buffer overrun in Gecko somewhere (*). > inside of XUL itself, maybe XPI installers (from what little I know about > them), or spoofing entire applications to be looking like completely different > apps (mail, money management, etc) since even the native > window-dressing can be changed via XUL(?).. No. If XUL could change the "window dressing" on all platforms, it would surprise the hell out of me. Windows' method for custom windows is 100% different from the X method, which also is about 9 billion percent different from the OS X method. In a word: no. That would never be possible. However, the "make it look like other applications" element is possible in any browser. I've personally made a proof-of-concept "login" dialog that mimics the XP login dialog (and if I had a screenshot of the 9x one, I could copy that too). And, it's nothing more than some CSS and some <input>'s. The point is, the problem needs to be fixed by making sure the user understands that the content they're viewing isn't really an application on their computer, or their web browser. Or the URL they're currently on. The IE team did what Ben did: forced the statusbar. IMO, there does need to be a bit more protection than that (perhaps an info bar that appears until you disable it that says something like "Warning: This is a popup window, click here for options and more information."). Yeah, I keep changing my mind on this, but I really wouldn't have thought that this would have been a bug in the first place, so it's somewhat difficult to think of a method that wouldn't be obtrusive but would get the point across. Sorry for the bugspam >_<.

(In reply to comment #192) > How about adding a button to the statusbar (in the case that all chrome is > missing) offering the option > "restore window functionality" > meaning: > -allow resize > -restore all toolbars > -override rightclick contextmenu > > This would offer anyone who cares the option to check the window in > great detail if they don't trust it. This suggestion should be seriously considered. It would add a way to check a page (enhance security), and gives the added benefit that it makes popups in general less annoying because they could quickly be converted to normal windows if the user wants.

As I vaguely recall all windowed-OSs allow the application to add custom menu-elements to the current window's topmost window-control menu (on Mac and Gnome, the bar at the top of the screen, on Windows and KDE the top-left-most corner icon). So perhaps the page-info screen (ala CTRL-I) could be placed there - it would always be available to mouse and keyboard navigation, and would also remind people of the shortcut-key CTRL-I. But like any unobtrusive method people in a hurry are going to ignore the idea of tracking what host their connected to, just like when users choose to not see the alert for "Warn me when I am about to leave a site that is secure" --- let alone keep track of mixed-domain content within frames, JS files, forms...

Is there some way of denying fake chrome the right to change the mouse icon? If so, you can just make the mouse change when it's hovering over legitimate chrome.

Even though you now force the status bar, it still seems that there are ways to get around this for spoofers. For example, they could just create a frameset, top and bottom, and in the bottom frame add some text that "explains" that the site in the above section is secure, then load the chrome or spoofed html in there. There are many ways to fool inexperienced users on the internet. It may not be possible to adaquitly protect against these types of spoofing or phishing techniques, without severly limiting the flexibility of the browser. Why not take some of the more unspoofable suggestions that I or others have made (the icon or other indicator in the title bar, or the altered mouse curser for various situations - like a lock next to the cursor when viewing a secure site) instead of just copying what MS has done in IE? Also, can't the new look of the location bar (with the lock and yellow bg) be duplicated with XUL? Even if the spoofer leaves out the status bar, they would still have a pretty convincing browser window, that looks like it is on a secure server (and points to the correct domain according to the location bar). To be even more bold, you could apply a new set of rules for "untrusted" XUL apps, where they have to have a parent window with security details open at all times (this would help with XUL spoofing at least, but not html spoofing - which is more of a problem with ads - and poorly designed ones, that still work pretty well to fool users on both Mozilla and IE, status bar or no). I think it should also be said that there may not be any way to protect users from phishing and spoofing, without severly restricting the flexibility of a web browser. Let's be realisitic for a second, the truth of the matter is that most users, don't care about the status bar, because they don't use it - and aren't even aware that they should look down there when they are ordering $5000 furniture with their bank cards. It's good to try to address these issues, but I wonder if it's going to be possible to solve this without radically changing the way that the web works for users. Consider the rise of "rich applications". They have no chrome and be spoofed even easier than anything in Mozilla. Sorry for the bugspam, it just seems like there are some issues and suggestions that still merit discusion and that haven't been addressed in this thread.

(In reply to comment #200) > Why not take some of the more unspoofable suggestions that I or others have made > (the icon or other indicator in the title bar, or the altered mouse curser for > various situations - like a lock next to the cursor when viewing a secure site) > instead of just copying what MS has done in IE? Part of the problem with doing things in the title bar is that Mozilla isn't always in control of what's in the title bar. It may be on Windows, but it's limited in what it can do on Linux (since there's who knows how many different window managers out there and they're all different), I don't know about the Mac. We know what we've got so far isn't 100%, but it's a start and I'm sure there's more to come... I like the idea about a special cursor for chrome UI...

How about ONLY showing the ststaus bar when *any* content within the window (images, iframes, scripts) comes from mixed domains - and then in the status bar show a red, perhaps flashing SSL-unlockd-type icon, which when clicked opens the page-info window to a new tab that shows a summary of all hosts that are providing the content, or perhaps instead to the existing 'Privacy' tab and expanding its 'Extenally Loaded Documents' tree? When only one host has content in the window, such as is almost always the case in a web-application, there's no value IMO to forcing the status bar to be on. Does anyone disagree? I'd be happy with this compromise.

This bug has covered many issues, but fundamentally it has nothing to do with content coming from a mixture of sites. There's the original chrome spoofing subject and the later anti-phishing push, and all of it could be hosted by a single site.

> I like the idea about a special cursor for chrome UI... I'm concerned that it will damage usability (as app authors can't manipulate the cursor in the usual ways to give feedback, as happens with normal apps) and that users won't know what the special cursor means anyway. Gerv

Instead of forcing the status bar (which is largely acknowledged as being inadequate, I think), we could do what I described in bug 244965 comment 46. That should also satisfy the Corporate Customers (does it?).

As another example of comment 75, auditmypc.com puts up DHTML "dialog" windows http://www.auditmypc.com/freescan/securityscan.asp?S=T12067 Legit in this case (not accessible though), but could easily fool many windows users into thinking it's real window.

I develop for a corporate customer, and have a number of internal html/js apps that are opened without a chrome. They have their own menubar, toolbar and company branded colour scheme. But now - these apps are hit with the ugly stick, big time (ie when the address bar isn't supressed) This will be enough for many users to go back to using IE to access these apps, rather than stick with Firefox after all the hard work I've done to introduce Firefox into the organisation. I'd like someway to turn off the address bar. If its the user clicking a trust dialogue, so be it. If its by using signed scripts (which btw, nobody has answered comment #188 from Hish), then even better. But damn, that address bar is ugly. This isn't one of my apps, but is similar in GUI richness. Go to http://www.bindows.net and click the forum link. The ugly factor here is somewhat reduced, as the forum is using default system colours. Change the forum colours to a custom scheme, and then the address bar will really stick out. Introduce larger spacing between UI elements (eg like OS X has) and the address bar will stick out even more. As I said, I don't want to turn my customers away from Firefox.

Simon, see comment 190. Try Firefox 1.0PR. If you already have that version, enter about:config in the location bar, search for dom.disable_window_open_feature.location, right-click that and choose Reset. It should now be "false", which means "do not disable the window.open-feature to hide the location bar".

(In reply to comment #208) > Simon, see comment 190. Try Firefox 1.0PR. If you already have that version, > enter about:config in the location bar, search for > dom.disable_window_open_feature.location, right-click that and choose Reset. It > should now be "false", which means "do not disable the window.open-feature to > hide the location bar". Thanks Steffen, I was testing on the 0930 nightly, assuming that to be the current behaviour (it forces the location bar). But, I've gone back to 1.0PR 0.1, and yes I see the location bar is no longer being forced. Phew! Thanks for setting me straight ..

> Thanks Steffen, I was testing on the 0930 nightly, assuming that to be the > current behaviour (it forces the location bar). You have to test aviary branch nightlies: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-0.9/ Firefox 0.9 and 1.0PR were built from that branch, and 1.0 will be.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=AviaryBranchTinderbox&branch=AVIARY_1_0_20040515_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-09-06+08%3A00%3A00&maxdate=2004-09-07+08%3A00%3A00&cvsroot=%2Fcvsroot That should be a list of the changes between those two builds...

Duh, wrong bug...

Comment on attachment 157917 [details] [diff] [review] patch removing stale review request. please re-request review if i'm mistaken.

Comment on attachment 155874 [details] [diff] [review] patch against aviary branch to implement my screenshot for firefox Removing review request from obsolete patch.

*** Bug 268567 has been marked as a duplicate of this bug. ***

Comment on attachment 157917 [details] [diff] [review] patch Removing what I think is a stale review request (at least part of this is already checked in). Please re-request review with an up-to-date patch if I'm wrong.