22183 - UI spoofing can cause user to mistake content for chrome

Status: RESOLVED FIXED

(Core :: XUL, defect, P2)

Description

[joro]

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

Comment 1

[leger]

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

Comment 2

[Jim Roskind]

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

Comment 3

[Mitchell Stoltz (not reading bugmail)]

Bulk reassigning most of norris's bugs to mstoltz.

Comment 4

[Mitchell Stoltz (not reading bugmail)]

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.

Comment 5

[troy]

Changing component to XUL

Comment 6

[Peter Trudelle]

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

Comment 7

[Mitchell Stoltz (not reading bugmail)]

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?

Comment 8

[Peter Trudelle]

[nsbeta2-]

Comment 9

[Peter Trudelle]

Mass-moving all nsbeta2- bugs to M20

Comment 10

[Peter Trudelle]

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

Comment 11

[Mitchell Stoltz (not reading bugmail)]

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.

Comment 12

[Daniel Veditz [:dveditz]]

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

Comment 13

[Peter Trudelle]

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

Comment 14

[Peter Trudelle]

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

Comment 15

[Jim Roskind]

Per PDT, changing to beta3-minus

Comment 16

[Peter Trudelle]

->future

Comment 17

[Daniel Veditz [:dveditz]]

Should be groupset 2, not 1024

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 19

[Mitchell Stoltz (not reading bugmail)]

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? 

Comment 20

[jag (Peter Annema)]

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. 

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 22

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 23

[timeless]

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

Comment 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

CCing Eileen, the author of the Dartmouth reports.

Comment 25

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 26

[Stephen P. Morse]

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.

Comment 27

[Stephen P. Morse]

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.

Comment 28

[jag (Peter Annema)]

Some changes didn't seem to take. Applying.

Comment 29

[jag (Peter Annema)]

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.

Comment 30

[Stephen P. Morse]

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.

Comment 31

[jag (Peter Annema)]

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.

Comment 32

[Stephen P. Morse]

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.

Comment 33

[Stephen P. Morse]

Attachment: Blank out non-trusted areas by pressing ctl-tilde

Comment 34

[timeless]

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

Comment 35

[Stephen P. Morse]

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.

Comment 36

[Stephen P. Morse]

Attachment: zip file of test case for spoofed UI

Comment 37

[Stephen P. Morse]

Attachment: Same zipfile attachment, seeing if format comes out better this time

Comment 38

[Stephen P. Morse]

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.

Comment 39

[Stephen P. Morse]

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.

Comment 40

[Stephen P. Morse]

Attachment: Extends previous patch by blanking out sidebar and mail as well.

Comment 41

[Stephen P. Morse]

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

Comment 42

[timeless]

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

Comment 43

[Brendan Eich [:brendan]]

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

Comment 44

[Stephen P. Morse]

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.

Comment 45

[Stephen P. Morse]

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.

Comment 46

[Stephen P. Morse]

Attachment: Aborted attempt to make triggering event non-capturable. For archival purposes only

Comment 47

[Stephen P. Morse]

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.

Comment 48

[Stephen P. Morse]

Attachment: cleaned up patch, ready for reviews

Comment 49

[Stephen P. Morse]

I'll take over ownership of this.

Comment 50

[Brendan Eich [:brendan]]

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

Comment 51

[Randell Jesup [:jesup] (needinfo me)]

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

Comment 52

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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.

Comment 53

[Stephen P. Morse]

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?

Comment 54

[Stephen P. Morse]

> 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.

Comment 55

[David Hyatt]

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 56

[Brendan Eich [:brendan]]

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

Comment 57

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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.

Comment 58

[Stephen P. Morse]

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'

Comment 59

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 60

[Stephen P. Morse]

Attachment: added discoverability to title line

Comment 61

[Mitchell Stoltz (not reading bugmail)]

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 62

[Brendan Eich [:brendan]]

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

Comment 63

[Stephen P. Morse]

Attachment: address issue in comment 62

Comment 64

[Brendan Eich [:brendan]]

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 65

[Brendan Eich [:brendan]]

Comment on attachment 107990 [details] [diff] [review]
address issue in comment 62

Why add those commented-out document.getElementById calls?

/be

Comment 66

[Stephen P. Morse]

Attachment: screenshot showing discoverability on title line

Comment 67

[Stephen P. Morse]

Attachment: second try at screenshot showing discoverability

Comment 68

[Brendan Eich [:brendan]]

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

Comment 69

[Stephen P. Morse]

Attachment: comment 65: oops, forgot to remove some experimental code

Comment 70

[Stephen P. Morse]

> 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.

Comment 71

[Stephen P. Morse]

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.

Comment 72

[Stephen P. Morse]

Attachment: screenshot of spoofed image of window inside a real window

Comment 73

[Stephen P. Morse]

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.

Comment 74

[Stephen P. Morse]

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.

Comment 75

[Hixie (not reading bugmail)]

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.

Comment 76

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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

Comment 77

[Hixie (not reading bugmail)]

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.

Comment 78

[Stephen P. Morse]

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.

Comment 79

[Hixie (not reading bugmail)]

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?

Comment 80

[Heikki Toivonen (remove -bugzilla when emailing directly)]

morse is no longer working on Mozilla, reassigning to mstoltz

Comment 81

[Hixie (not reading bugmail)]

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

Comment 82

[Mitchell Stoltz (not reading bugmail)]

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.

Comment 83

[Hixie (not reading bugmail)]

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.

Comment 84

[Mitchell Stoltz (not reading bugmail)]

> 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 [e-mail].

Comment 85

[Mitchell Stoltz (not reading bugmail)]

Clearing milestone

Comment 86

[Daniel Veditz [:dveditz]]

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

Comment 87

[alanjstr]

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

Comment 88

[pegasus]

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.

Comment 89

[alanjstr]

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.

Comment 90

[Jason Lustig]

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.

Comment 91

[pegasus]

(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.

Comment 92

[Hixie (not reading bugmail)]

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.

Comment 93

[Hixie (not reading bugmail)]

(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.)

Comment 94

[Blake Ross]

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

Comment 95

[Tim Fries]

Attachment: Screenshot of XWT showing untrusted "scar" in lower left.

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.

Comment 96

[Marius Strumyla]

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

Comment 97

[Daniel Veditz [:dveditz]]

Attachment: alternate location indicator when location turned off

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.

Comment 98

[Hixie (not reading bugmail)]

What does it look like?

Comment 99

[Daniel Veditz [:dveditz]]

Attachment: What the above patch looks like

screen shot of a typical popup with the patch implemented (suite).

Might as well take the bug, Mitch isn't around.

Comment 100

[Daniel Veditz [:dveditz]]

Attachment: what preventing "location=no" looks like currently

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

Comment 101

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 102

[Daniel Veditz [:dveditz]]

Attachment: Same thing for firefox

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

Comment 103

[Robert Parenton]

(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.

Comment 104

[Hixie (not reading bugmail)]

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.

Comment 105

[Robert O'Callahan (:roc) (email my personal email if necessary)]

> 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.

Comment 106

[Hixie (not reading bugmail)]

Yeah, that makes sense.

Comment 107

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 108

[Peter Ryan]

(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.

Comment 109

[Hixie (not reading bugmail)]

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

Comment 110

[logan]

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?

Comment 111

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 112

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 113

[Robert Parenton]

(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.

Comment 114

[Ben Goodger (use ben at mozilla dot org for email)]

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?

Comment 115

[Alan Tam]

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

Comment 116

[Kris Maglione [:kmag]]

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.

Comment 117

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 118

[Gervase Markham [:gerv]]

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

Comment 119

[Jesse Ruderman]

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

Comment 120

[Daniel Veditz [:dveditz]]

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.

Comment 121

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(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.

Comment 122

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 123

[Gervase Markham [:gerv]]

> 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

Comment 124

[Ben Goodger (use ben at mozilla dot org for email)]

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. 

Comment 125

[Kevin Newman]

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

Comment 126

[Gervase Markham [:gerv]]

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

Comment 127

[Ben Goodger (use ben at mozilla dot org for email)]

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

Comment 128

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: patch against aviary branch to implement my screenshot for firefox

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

Comment 129

[Hixie (not reading bugmail)]

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

Comment 130

[Doug Wright]

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.

Comment 131

[Doug Wright]

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.

Comment 132

[Gervase Markham [:gerv]]

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

Comment 133

[Doug Wright]

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)

Comment 134

[chris hofmann]

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.

Comment 135

[Ben Goodger (use ben at mozilla dot org for email)]

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

Comment 136

[Zachariah]

(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

Comment 137

[David E. Ross]

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.  

Comment 138

[Keith Gable]

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

Comment 139

[timeless]

no.

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

Comment 140

[Darin Fisher]

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

then prepend it.

Comment 141

[Steve Wardell]

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.

Comment 142

[Darin Fisher]

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

Comment 143

[Steve Wardell]

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 144

[chris hofmann]

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 145

[Daniel Veditz [:dveditz]]

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 146

[Asa Dotzler [:asa]]

Comment on attachment 155874 [details] [diff] [review]
patch against aviary branch to implement my screenshot for firefox

a=asa for branch checkin.

Comment 147

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: patch

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

Comment 148

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: patch

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

Comment 149

[Ben Goodger (use ben at mozilla dot org for email)]

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.

Comment 150

[Daniel Veditz [:dveditz]]

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.

Comment 151

[Ben Goodger (use ben at mozilla dot org for email)]

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...

Comment 152

[Ben Goodger (use ben at mozilla dot org for email)]

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. 

Comment 153

[Mike Kowalski]

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.

Comment 154

[Ben Basson]

Attachment: Remove nav-bar's context menu property

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)

Comment 155

[Ben Basson]

Attachment: Remove nav-bar "context" and "collapsed" properties

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.

Comment 156

[Grey Nicholson (they/them)]

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.

Comment 157

[Ben Basson]

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.

Comment 158

[Asa Dotzler [:asa]]

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

Comment 159

[logan]

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?

Comment 160

[Hish]

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.

Comment 161

[Jesse Ruderman]

> 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?

Comment 162

[Hish]

> 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?

Comment 163

[Ben Basson]

Attachment: Make only gURLBar be present

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.

Comment 164

[Ivan Sagalaev]

> 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?

Comment 165

[Ben Basson]

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

Comment 166

[Robert Parenton]

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.

Comment 167

[Mathieu Pellerin]

Attachment: tab bar present under the location bar

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

Comment 168

[Grey Nicholson (they/them)]

(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.

Comment 169

[Mathieu Pellerin]

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)

Comment 170

[Hish]

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

Comment 171

[Darin Fisher]

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

Comment 172

[Darin Fisher]

> (*) 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!

Comment 173

[Daniel Veditz [:dveditz]]

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.

Comment 174

[Hish]

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. :-(

Comment 175

[Jesse Ruderman]

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.

Comment 176

[Hish]

(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.

Comment 177

[Kevin Newman]

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.

Comment 178

[Peter van der Woude [:Peter6]]

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

Comment 179

[Mathieu Pellerin]

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

Comment 180

[Ben Basson]

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

Comment 181

[Greg Campbell]

Attachment: toolbar separators visible

Toolbar separators should be removed also.

Comment 182

[Robert Parenton]

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

Comment 183

[Andrew Smith]

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.

Comment 184

[Ken Johanson]

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?

Comment 185

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: patch, force status instead of location [checked into aviary branch]

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

Comment 186

[Keith Gable]

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.

Comment 187

[Nigel McFarlane]

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!

Comment 188

[Hish]

Can I hide the toolbar when using signed scripts?

Comment 189

[Arjen Anker]

(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 190

[Steffen Wilberg]

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.

Comment 191

[Hish]

> 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!

Comment 192

[Peter van der Woude [:Peter6]]

(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.

Comment 193

[Ken Johanson]

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.

Comment 194

[Ken Johanson]

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(?)..

Comment 195

[Ken Johanson]

Possibly related to Mozilla bug#257036.

Comment 196

[Keith Gable]

> 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 >_<.

Comment 197

[Zachariah]

(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.

Comment 198

[Ken Johanson]

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...

Comment 199

[nsdn]

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.

Comment 200

[Kevin Newman]

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.

Comment 201

[Johnny Stenback (:jst)]

(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...

Comment 202

[Ken Johanson]

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.

Comment 203

[Daniel Veditz [:dveditz]]

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.

Comment 204

[Gervase Markham [:gerv]]

> 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

Comment 205

[Hixie (not reading bugmail)]

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?).

Comment 206

[Daniel Veditz [:dveditz]]

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.

Comment 207

[Simon Gilligan]

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. 

Comment 208

[Steffen Wilberg]

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".

Comment 209

[Simon Gilligan]

(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 ..

Comment 210

[Steffen Wilberg]

> 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.

Comment 211

[Johnny Stenback (:jst)]

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...

Comment 212

[Johnny Stenback (:jst)]

Duh, wrong bug...

Comment 213

[Darin Fisher]

Comment on attachment 157917 [details] [diff] [review]
patch

removing stale review request.	please re-request review if i'm mistaken.

Comment 214

[Steffen Wilberg]

Comment on attachment 155874 [details] [diff] [review]
patch against aviary branch to implement my screenshot for firefox

Removing review request from obsolete patch.

Comment 215

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

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

Comment 216

[Brian Ryner (not reading)]

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.

Comment 217

[Daniel Veditz [:dveditz]]

Since the forced location bar didn't fly, we're going to try to put the site in
the title bar for location=no windows. The most recent IE has been doing this
and it seems like it would help somewhat with phishing sites.

Comment 218

[Gervase Markham [:gerv]]

In IE, you can use ActiveX to manipulate the window title, so I'm not sure that
Microsoft are on to a winner there.

Anyway, surely we addressed this problem with the new UI in the (ever-present)
status bar? 

We need to be careful about providing multiple access points/reading points for
the site information. Doing so can actually make things _less_ usable and
secure, because users have to worry about which to check, or they check both,
which slows them down, or check neither, because they can't be bothered any more.

Gerv

Comment 219

[Peter van der Woude [:Peter6]]

It would be very usefull if the actual URL could be copied if someone wishes to
report a spoof.
Maybe override "rightclick disabled" if all chrome is removed ?

Comment 220

[Zachariah]

(Since the status bar is always on now...)
In windows where all the chrome is off, there should be a button to "restore all
chrome", except it would need a more user-friendly name.

(this is similar to the one showing that a popup window has been blocked, and
maybe even the first time a yellow bar at the top, like when pop-ups are first
blocked)

This would enhance security, and usability.

Also (since mozilla+firefox seem to keep track of the size+location of it's
windows) clicking the button should restore not only the chrome, but should also
make the window as big as the other windows the user is using (using whatever
rules firefox decides in setting the size when the new-window button is clicked)


(not so important, but still worth noting...)
I'd also still like to see the URL bar have a color-coded URL in it with the
'protocol' in one color, ('username' and ':' and 'password' each their own - if
mozilla still even allows this), the 'subdomain' in a color similar to the
'domain', and then differing colors for names of 'directories' and the 'slashes'
separating them, and then those same colors for 'separators' and 'arguments' for
GET forms.

Comment 221

[Asa Dotzler [:asa]]

So last I remember, we wanted to do a couple of things here. First, we wanted to
put "JavaScript Application" in some title bars and second, we wanted to do what
IE SP2 does and put the URL in the title bar.  If these are the two blocking
issues for 1.0.1, who is owning them? Dan, is this you?

Comment 222

[Hish]

I'm writing lots of XUL remote apps, so I'm interested what the user will see
finally. I'm getting to a point where I can't follow anymore. So I would
appreciate if someone could give me a status:

- Is the window title still editable or will there only be a fixed url? I
suggest somehting like "<my title> - domain" in the window.
- When using XUL menus, does something appear above the menu? (Very bad)
- Will something prevent me from positioning/resizing my window.open() window?
(killer for all remote apps!!!)

Currently everyone is cutting more and more functions to get enhanced security
but soon it doesn't make sense at all using FF as a developer platform. I guess
as long as there is no alternative like a zone modell, everyone here should be
cautious when implementing these "features". 

Keep in mind: FF is not only a browser, it's still a platform for remote apps.
If this isn't wanted anymore, please let us all know, so we can save a lot of time.

Comment 223

[Daniel Veditz [:dveditz]]

Attachment: Add host to title when no locationbar

This patch adds the host name to locationbar-less windows.

SetTitle(EmptyString()) added to nsHTMLDocument::OpenCommon() because otherwise
it would be possible to spoof the location simply by writing a new document and
never calling document.close(). With a location bar the old title isn't a
killer (though still not great) because the location updates right away. But if
people are going to trust the host in the title then we have to make sure it
gets cleared

The tabbrowser changes probably won't come into play much, you'd have to have
multiple tabs on a locationbar-less window. But if somehow you did, this part
keeps the scheme and host from disappearing.

Comment 224

[Gervase Markham [:gerv]]

> This patch adds the host name to locationbar-less windows.

For SSL domains, the hostname is already available in all windows in the status
bar, which is always-on and gives a lot of information about the site concerned.
What advantage is there in adding it to the window title also?

While I am against having the domain in the status bar for all sites (because
it's a more effective against phishing if it's only there for SSL), I also don't
think we should display it in two different places, or in one place for HTTP and
another for HTTPS...

Gerv

Comment 225

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 174291 [details] [diff] [review]
Add host to title when no locationbar

>Index: xpfe/appshell/src/nsContentTreeOwner.cpp

> + mXULWindow->GetWindowDOMElement(getter_AddRefs(docShellElement));

Are we guaranteed that the ordering of SetTitle and the "window DOM element"
changing is such that the latter will change before the SetTitle is called
(esp. on tab switches)?

>+    docShellElement->GetAttribute(NS_LITERAL_STRING("chromehidden"), chromeString);
>+    if (chromeString.Find(NS_LITERAL_STRING("location")) != kNotFound) {

Are we guaranteed that this is the only way that there will be no location bar?

>+      if (dsitem) {
>+        nsCOMPtr<nsIDocShell> shell(do_QueryInterface(dsitem));

Why bother?  We never need "shell", do we?  Why not just:

nsCOMPtr<nsIDOMDocument> domDoc = do_GetInterface(dsitem);
nsCOMPtr<nsIDocument> doc = do_QueryInteface(doc);

Note that these are both null-safe, so need to even null-check dsitem here.

Why are we not using CreateExposableURI here?  We really should be, imo.

>Index: toolkit/content/widgets/tabbrowser.xml

>+            // if location bar is hidden and the URL type supports a host
>+            // then add the scheme and host to the title to prevent spoofing

Hmm... I guess this doesn't go through the content treeowner because we're
calling this outside of content code, eh?  But then any other window.title
setter in chrome will undo all our good work.  Maybe the chrome tree owner
needs to be somehow involved in this too, instead of changing the binding?

In any case, the binding change needs review from a toolkit peer, and the xpfe
binding needs a similar change (we're trying to keep the bindings in sync
nowadays so we can merge bugfixes back and forth till we can drop the xpfe
bindings altogether).

Comment 226

[Daniel Veditz [:dveditz]]

(In reply to comment #224)
> For SSL domains, the hostname is already available in all windows in the
> status bar, which is always-on and gives a lot of information about the
> site concerned. What advantage is there in adding it to the window title

Because phishers are using non-ssl sites and opening locationbar-less windows to
disguise their true destination. Some have gone so far as to paste in their own
semi functional fake toolbars displaying the spoofed site's URL.

Users are more likely (not guaranteed) to notice the presence of the wrong
domain in the upper left than the absence of the lock in the lower right. If
they don't notice they take the blame; if the browser provides no clue at all
then *we* do.

Comment 227

[Gervase Markham [:gerv]]

So the question is: are we really attempting to solve the phishing problem for
non-SSL sites? 

Does it really shift more blame to the user? We can currently say "you didn't
check the site was secure - that domain name and lock which is always present on
paypal the last 40 times you logged into it wasn't there". With your change, we
can additionally say "...and the title bar said 'www.paypal-secure.com'". I'm
not convinced this is a much stronger argument.

The title bar has up to now been completely under the control of the page (apart
from the standard app name). Users have no expectation of what might appear
there; we should not be asking them to trust something which is normally
untrustable. This is the same problem as you would have displaying security
information in the left hand part of the status bar.

Gerv

Comment 228

[Ken Johanson]

How about instead of degrading the original fnctionality of the browser and
valid applications (by covering up the page's title/title bar with som long url
or hostname) the browser has a new 'exerience level' perference.. a simple one
with 2 or 3 user-levels-of-experience: 'new to the the internet' (default
shipping with FFM/Moz), medium, and advanced user.

So the default ship mode would raise a built in javascript confirmation *each
time* a user clicks on a link with user@pass encoding, and say, or ssl name
dicrepancy, and describe to the user the format of this trick link that had
appeared in their _top window's status bar just before they clicked it. The
confirm dialog could be JUST LIKE the ssl certificate name/date mismatch dialog
that exists now, but instead not be checkbox remember-able.

But permanately mangling the title, url, or status bar, SIMPLY BREAKS intentded
behavior of webapps.. and new internet USERS WILL STILL BE OBLIVIOUS to those.
This says it all, really. I've tested this with newbie users, and they STILL
dont even grasp the SSL/lock icon, let alone watching the url or status bar to
see if hostnames match.. they NEED training at the outset. Merely passively
displaying the URL/host in some bar just _wont_ do that.

Also, clicking on the 'I'm an advanced user' preference is practically a legal
acknowledgement / acceptance of responsibility that that the ex-newbie BELIEVES
that they now understand all this stuff, again unlike some passive display.

Comment 229

[Hish]

(In reply to comment #228)
I 100% agree. Sometimes I get the impression that we have to give unexperienced
user hints. If we would go that way to the end, then changing window titles and
status bars simply hurts web apps but the dumb user still ignores it. For this
user you need an alert like "Hi, you loaded domain XY. Are you sure you wanted
this?" prior to display EVERY page. 
The sad thing is that simply removing features without offering an alternative,
simply hurts the wrong people, namely web app developers.
A zone modell or Ken's idea would help here.

Comment 230

[Ken Johanson]

There are in fact several *other* new forms of phishing, related to SSL sites,
and so now to un-spoof those too (and other methods that come along), we'd now
have to put all of the cert's CN and alt-subject names into the *same*
URL/status/title bar, making it fully un-readable (esp for small windows, say
50x50 -an issue even now, and more reason for confirm-pop ups) - or, leave those
warnings in the ssl lock icon, so we'd then have two disparate places (from a
newbie perspective) to look for warning signs or phishing.. Definately get ignored.

Bug #267515 suggests some proactive alert methods for hostname and other
discepancies, like what this bug was intended for.

Comment 231

[Hish]

(In reply to comment #228)
I 100% agree. Sometimes I get the impression that we have to give unexperienced
user hints. If we would go that way to the end, then changing window titles and
status bars simply hurts web apps but the dumb user still ignores it. For this
user you need an alert like "Hi, you loaded domain XY. Are you sure you wanted
this?" prior to display EVERY page. 
The sad thing is that simply removing features without offering an alternative,
simply hurts the wrong people, namely web app developers.
A zone modell or Ken's idea would help here.

Comment 232

[Hish]

Btw: Is it possible to block links comming from email apps or selected apps at
all? That would prevent most phishing attacks.

Comment 233

[Zachariah]

Having the browser not open links from any external app would have to be a pref
a user could set, but I don't think I'd have it set by default.


------------

Comment #136, Comment #197, Comment #220 (apparently I already said in the first
two what I also said in the third -- now here's my arguments for it, and
compared to other solutions)

These two solutions:
1) 'Restore Window Functionality' Button
2) Color-coded URL
would be far more effective than adding the domain to the title bar of the
window.  As has been argued, the title bar is under control of the page in every
previous version of Mozilla/Firefox and in every other browser.  If you want a
place to always put a domain, do it where the secure domains go (but that's only
if you really want to protect non SSL domains, which I don't see the advantage of).

The 'Restore Window Functionality' Button makes it so that anytime any user
want's to fully check out what's going on in their browser window they can,
on-the-fly -- no pref necessary.  Again, to clarify -- this should behave like
the blocked popup behavior (gold-bar first ("This window has missing chrome and
could be an attempt to hide information from you in order to deceive you" or
something like that), then just a button in the statusbar).  

The color-coded URL would be especially useful because homographs could be in
their own color (or style -- underlined?) as well, thus solving the IDN problem,
too.

Finally, I see no drawback to implementing these two solutions.

Comment 234

[Ken Johanson]

> Finally, I see no drawback to implementing these two solutions.

I do - the user STILL has to have clearly discerned *beforehand* whether they're
on the hostname they believe. So to have a dafault window-dsiabled bahavior
doesnt help them more than it hurt them (by blocking valid links or SSL name
missmatch sites, etc). So they remain a 'newbie' without having been proavtivly
trained (by a pop-up that still gives them cancel option) to indentify the
phishing techniques (which again are not limited to the scope this bug was
reported under).

So a new users first impression of the web (or just FF/Moz) would simply that
they have a control that can disable or enable certain popup types that apps
DEMAND, without necessarily understanding why it blobked. And the user might
simply opt to leave 'normal' window behavior turned on.... I GUARANTEE that's
what my webapp users will do since they know that chrome-less popups are a
normal part of the webapp. Or to relegate this we'd then have to a
whitelist-domains preference???

Comment 235

[Kevin Newman]

I'm going to go out on a limb here and say that most of these measures feel like
hacks to try and prevent a kind of attack (phishing) that is realistically not
very preventable with current browser models. No matter how we limit the
functionality of Mozilla (for both phishers and developers) the phishers are
going to be able to come up with a way around it. For example, if I was a
phisher, I could just skip creating a new window at all, and just make a dhtml
layer that looks like a window, and put whatever I wanted in there. These "dumb
users" aren't going to know the difference in any case.

It seems like if we wanted to make a real impact on phishing, without limiting
the legitimate uses of many of these features, we ought to be discussing more
proactive options, rather than focusing on reactive ones.

Just to give an example, we could create a new feature for secure site
developers to take advantage of, like a small security window (like the download
notification) that pops up near the system tray (Windows specific). This window
would remain on top of the secure page window, and possibly be anchored by a
notification icon and could only be triggered from a secure web page coming from
a page with proper SSL credentials. This kind of measure, combined with a strong
marketing effort, would be simply unspoofable (unless there is some way to make
a notification icon from within Mozilla). This also pushes the burden of
anti-phishing measures to individual site devs (where I think it belongs), as
they would be responsible for taking anti-phishing measures and educating their
customers about the dangers of spoofing/phishing.

In order for a measure like this to work, it has to be something very simple,
and unspoofable, something that the user can glance at to make sure they are
secure, and something that technical friends or a marketing campaign can explain
very simply.

Whatever happens, I really hope we can achieve the goal of reducing the
effectiveness of phishing, without crippling Mozilla by removing/limiting one
feature after another.

Comment 236

[Ken Johanson]

> Just to give an example, we could create a new feature for secure site
> developers to take advantage of, like a small security window (like the download
> notification) that pops up near the system tray (Windows specific). 

This seems like a *really* good idea, and alternative to the pop-up confirm -
its proactive, very attention grabbing (I'm thinkng along the lines of
Thunderbird's scrolling 'you have mail', a nice boilerplate for FF/Moz suite to
use ;-), and, its location would be consistent for the platform and where it's
users expect to see advisories... It also doesnt muddle the orig appearance of
the pop-up app window that the programmer intended, and it can auto size to show
VERY large dialogs, such as whole lists of x509 subject-alt names.

Comment 237

[Zachariah]

Comment #234
> > Finally, I see no drawback to implementing these two solutions.
> 
> I do - the user STILL has to have clearly discerned 
> *beforehand* whether they're on the hostname they believe

I should have made myself clear -- I meant 'drawbacks' which break the browser.


Your argument is just pointing out the same problem with any solution using
chrome to alert users -- it only works if the user looks for it -- which I think
is clear to everyone already.  But, I don't think we should just abandon chrome
solutions -- they should be part of an overall solution.  And, we should pick
the most effective/distinctive and least damaging (to the browser) chrome
solutions people think up. 

The 'Restore Window Functionality' button would add security AND functionality
-- doubling it's effectiveness.  Same goes for the colored URLs, because it
would add security AND teach users to look at the different parts of the URL
which carry information they should be paying attention to. 

Comment 238

[Daniel Veditz [:dveditz]]

Attachment: address bz's comments

Addresses bz's comments.

Seeking mconnor r= for toolkit change. As a practical matter people will not
have multiple tabs in a window without a location bar, the tab strip is missing
making the other tabs invisible. But if it happens, the tabbrowser.xml changes
make sure the title reads correctly.

All browser title setting goes through the content tree owner, except when
changing from tab to tab. These are the only two places that need to have this
change.

The chromehidden attribute is what nsXULWindow sets and xul.css looks for to
hide the location bar. We are most definitely guaranteed this setting tells us
the state of the location bar.

Made xpfe's updateTitleBar match the one in toolkit.

Comment 239

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 174420 [details] [diff] [review]
address bz's comments

sr=bzbarsky, but it really would be nice if tabbrowser did the same thing as
everyone else... :(

I assume you also tested this with window.title being set from script in
general, btw.  If you haven't, please do.

Comment 240

[Gervase Markham [:gerv]]

> As a practical matter people will not
> have multiple tabs in a window without a location bar

FYI, this isn't too hard to achieve - just window.open() a window with no chrome
at a particular site, and press Ctrl-T.

Can we please stop and think for a minute before checking this in? I really
think it will result in user confusion, with the domain being displayed in _two_
places on secure popups. Our hitherto-clean Firefox UI is beginning to get
cluttered with various people's attempts to improve the security. There's the
status bar stuff, and there's the yellow background and lock, and now there will
be this - and we still won't have covered all the bases. What has been done
about working out a co-ordinated approach to this entire class of problems?

I've just finished a paper which attempts to do that:
http://www.gerv.net/security/a-plan-for-scams/

Do we really, really want to take on the challenge of solving the phishing
problem when we don't have SSL, and therefore even _we_ can't be sure which site
we are on?
http://www.gerv.net/security/phishing-browser-defences.html#ssl-essential

Gerv

Comment 241

[Asa Dotzler [:asa]]

Comment on attachment 174420 [details] [diff] [review]
address bz's comments

pre-approving for 1.8b on the chance that this gets reviews in time to make the
beta1.

Comment 242

[Mike Connor [:mconnor]]

Comment on attachment 174420 [details] [diff] [review]
address bz's comments

Although I don't know if its the best fix, its no worse for web apps than IE
currently is, so I can live with it.

Comment 243

[Kevin Newman]

I'm sorry if this sounds like bug spam, but I wonder if it would be worth it for
the Mozilla foundation to hire a professional interface designer to take a look
at stuff like this. It seems that programmers don't usually (rarely even) make
good designers. It would be great to get some input from a real designer on all
of these interface issues.

Just to clarify some terms, by designer I mean someone who has finished a
professional design program and has real world design experience, and is
actively working as a professional designer - this is very different from a
programmer who skins KDE or Gnome in spare time (not that I have anything
against them, but these are two different things).

Most programming books that I've read even acknowledge that there comes a time,
when the designing is best left to the designers.

Comment 244

[Daniel Veditz [:dveditz]]

Comment on attachment 174420 [details] [diff] [review]
address bz's comments

a=chofmann for branches over the phone.

Comment 245

[Daniel Veditz [:dveditz]]

Checked in to aviary1.0.1 branch

Checking in content/html/document/src/nsHTMLDocument.cpp;
/cvsroot/mozilla/content/html/document/src/nsHTMLDocument.cpp,v  <-- 
nsHTMLDocument.cpp
new revision: 3.547.2.2.2.3.2.1; previous revision: 3.547.2.2.2.3
done
Checking in xpfe/appshell/src/nsContentTreeOwner.cpp;
/cvsroot/mozilla/xpfe/appshell/src/nsContentTreeOwner.cpp,v  <-- 
nsContentTreeOwner.cpp
new revision: 1.69.24.1.2.2; previous revision: 1.69.24.1.2.1
done
Checking in xpfe/global/resources/content/bindings/tabbrowser.xml;
/cvsroot/mozilla/xpfe/global/resources/content/bindings/tabbrowser.xml,v  <-- 
tabbrowser.xml
new revision: 1.95.2.1.2.2.2.2; previous revision: 1.95.2.1.2.2.2.1
done
Checking in toolkit/content/widgets/tabbrowser.xml;
/cvsroot/mozilla/toolkit/content/widgets/tabbrowser.xml,v  <--  tabbrowser.xml
new revision: 1.36.6.29.2.4; previous revision: 1.36.6.29.2.3
done

Checked in to 1.7 branch

Checking in content/html/document/src/nsHTMLDocument.cpp;
/cvsroot/mozilla/content/html/document/src/nsHTMLDocument.cpp,v  <-- 
nsHTMLDocument.cpp
new revision: 3.547.2.6; previous revision: 3.547.2.5
done
Checking in xpfe/appshell/src/nsContentTreeOwner.cpp;
/cvsroot/mozilla/xpfe/appshell/src/nsContentTreeOwner.cpp,v  <-- 
nsContentTreeOwner.cpp
new revision: 1.69.20.3; previous revision: 1.69.20.2
done
Checking in xpfe/global/resources/content/bindings/tabbrowser.xml;
/cvsroot/mozilla/xpfe/global/resources/content/bindings/tabbrowser.xml,v  <-- 
tabbrowser.xml
new revision: 1.95.2.6; previous revision: 1.95.2.5
done
Checking in xpfe/bootstrap/browser-prefs.js;
/cvsroot/mozilla/xpfe/bootstrap/browser-prefs.js,v  <--  browser-prefs.js
new revision: 1.8.2.2; previous revision: 1.8.2.1
done
Checking in toolkit/content/widgets/tabbrowser.xml;
/cvsroot/mozilla/toolkit/content/widgets/tabbrowser.xml,v  <--  tabbrowser.xml
new revision: 1.36.2.4; previous revision: 1.36.2.3
done

Comment 246

[sairuh (rarely reading bugmail)]

tested with 2005021806-1.0.1 firefox builds on Windows XP and Mac OS 10.3.8.
when I viewed the test in the attached .zip and at
http://www.nd.edu/~jsmith30/xul/test/spoof.html, I just got another browser
window with an XML parsing error. (the one below is from the URL).

XML Parsing Error: undefined entity
Location: http://www.nd.edu/~jsmith30/xul/test/browser2.xul
Line Number 231, Column 35:    <key id="key_viewInfo"  
key="&pageInfoWinCmd.commandkey;"   command="View:PageInfo"   modifiers="accel"/>
----------------------------------^

is this now expected behavior, ie, does this result mean this bug is fixed?

Comment 247

[sairuh (rarely reading bugmail)]

dveditz walked me through how to test this. the tests result in a popup
--without a Location bar-- but should have the following in the titlebar:

a. the site from which the popup was generated (not all cases, see below)
b. the site at which the popup is located
c. tht title of the popup's page
d. (only for Windows and Linux) " - Mozilla Firefox" appended

I tested with http, ftp, file, data and javascript url's. note that only the
latter two (data and javascript) would display (a) in addition to the others
above. (I verified that it worked, too.)

also, for testing file urls properly (since web devs might need to test pages
locally), I temporarily set the pref security.checkloaduri to false.

sample test recipe:

1. in a browser window, load http://www.mozilla.org
2. in the Location field, enter:

javascript:window.open("http://google.com","","location=no")

3. hit enter key if you haven't done so, then observe how another popup appears
behind the one in step (1) --bring that to the front.

results: titlebar reads http://google.com Google - Mozilla Firefox

however, on Mac, the last " - Mozilla Firefox" part is missing --I believe this
is by design for Mac. in addition, specific to the Mac, there's no whitespace
between the site name (b) and the popup title (c). when I spoke to dveditz he
said he's looking into fixing that aspect.

4. in the popup with google loaded, do a google search: enter some term in the
search field, hit enter.

5. when the results appear, ctrl-click (cmd-click on Mac) some of the links.

results: because there is no Location or toolbar, the tabs will *not* appear.
however, you can cycle through them using ctrl-tab.

for each of these tabs, you should (and I've verified) that the titlebar
displays (b) and (c), and where applicable (d).

another observation at this point: the Mac-issue after step 3 where there's no
separating whitespace appears to correct itself when cycling through the tabs in
the popup.

tested with 200502170x-1.0.1 firefox builds on Mac 10.3.8, WinXP and Linux fc2.

Comment 248

[Jeff Smith]

(In reply to comment #246)
> tested with 2005021806-1.0.1 firefox builds on Windows XP and Mac OS 10.3.8.
> when I viewed the test in the attached .zip and at
> http://www.nd.edu/~jsmith30/xul/test/spoof.html, I just got another browser
> window with an XML parsing error. (the one below is from the URL).
> 
> XML Parsing Error: undefined entity
> Location: http://www.nd.edu/~jsmith30/xul/test/browser2.xul
> Line Number 231, Column 35:    <key id="key_viewInfo"  
> key="&pageInfoWinCmd.commandkey;"   command="View:PageInfo"   modifiers="accel"/>
> ----------------------------------^
> 
> is this now expected behavior, ie, does this result mean this bug is fixed?

No, it means nothing.  That page is ONLY for Firefox 0.9.x.  The page will give
lots of XML parsing errors in any current version because some internal names
(unrelated to browser spoofing or security) have changed.  Please do not use
that page for any current testing.

That being said, would it be useful to this bug if I made a version for FFX 1.0?

Comment 249

[Daniel Veditz [:dveditz]]

bug 282955 filed for the mac run-on title issue mentioned in comment 247 point 3

Comment 250

[[e-mail]]

Comment on attachment 174420 [details] [diff] [review]
address bz's comments

Actually the correct way to tell if the location bar is visible is to query the
XULWindow's chrome flags.

Comment 251

[Bob Niederman]

Since "downloadable XUL" is the apparent source of this problem, would disabling
downloadable XUL, or making it only downloadable from localhost, fix the
problem?  How often does one need to download and run XUL all in one step from a
remote machine?

Comment 252

[Ian Neal]

Will this be going into the trunk?

Comment 253

[Daniel Veditz [:dveditz]]

(In reply to comment #251)
> Since "downloadable XUL" is the apparent source of this problem,

Please re-read the bug. It stopped being about "XUL" around comment 18 or so.
Phishers have in fact used mocked-up IE toolbars (no XUL support in IE) in
real-life scam attempts (see antiphishing.org)

(In reply to comment #252)
> Will this be going into the trunk?

Possibly not, Gerv is softening in his opposition to bug 262366 and personally I
prefer that solution. Not only is it better to have a consistent titlebar (how
do you explain it?) it's much easier to send a single message (check the host in
the status bar) rather than two (if it's SSL..., if it's not...).

In addition, an IE spoof was recently announced involving displaying a window
small enough to truncate the hostname into something misleading. Of course the
announcement ignored the fact that without the hostname in the titlebar it would
be even easier to spoof, and the title host does help on most windows with
realistic sizes.

Comment 254

[Hish]

(In reply to comment #251)
> How often does one need to download and run XUL all in one step from a
> remote machine?
Very often. I know whole companies relying on that...

Comment 255

[Worcester12345]

If this can block 1.0.1, it should certainly go in for 1.1. Marking with a ?

Comment 256

[sairuh (rarely reading bugmail)]

reminder to self, a couple more test examples, based on comment 247:

data: test
----------
javascript:window.open("data:text/html,<title>boo</title><body>testing
123</body>","","location=no")

js test
-------
javascript:window.open("javascript:s=',<title>blah</title><body>testing
456</body>'","","location=no")

Comment 257

[sairuh (rarely reading bugmail)]

whups, the js test had a minor type. correct version:

javascript:window.open("javascript:s='<title>blah</title><body>testing
456</body>'","","location=no")

anyhow, the tests in comment 247 passed using 2005031011-1.7 mozilla bits on
linux fc3. marking verified1.7.6.

Comment 258

[sairuh (rarely reading bugmail)]

mistakenly removed fixed1.7.6 --pardon the bugspam. set your filter/quicksearch
to "ZippidityDooDahHey" to catch these for easy removal/etc/

Comment 259

[Michael]

(In reply to comment #248)
> (In reply to comment #246)
> > tested with 2005021806-1.0.1 firefox builds on Windows XP and Mac OS 10.3.8.
> > when I viewed the test in the attached .zip and at
> > http://www.nd.edu/~jsmith30/xul/test/spoof.html, I just got another browser
> > window with an XML parsing error. (the one below is from the URL).
> > 
> > XML Parsing Error: undefined entity
> > Location: http://www.nd.edu/~jsmith30/xul/test/browser2.xul
> > Line Number 231, Column 35:    <key id="key_viewInfo"  
> > key="&pageInfoWinCmd.commandkey;"   command="View:PageInfo"  
modifiers="accel"/>
> > ----------------------------------^
> > 
> > is this now expected behavior, ie, does this result mean this bug is fixed?
> 
> No, it means nothing.  That page is ONLY for Firefox 0.9.x.  The page will give
> lots of XML parsing errors in any current version because some internal names
> (unrelated to browser spoofing or security) have changed.  Please do not use
> that page for any current testing.
> 
> That being said, would it be useful to this bug if I made a version for FFX 1.0?

I guess most would really appreciate, that the problem still exists.
As long as it doesn't take many hours to modify the proof-of-concept.

Comment 260

[Jeff Smith]

(In reply to comment #259)
> 
> I guess most would really appreciate, that the problem still exists.
> As long as it doesn't take many hours to modify the proof-of-concept.

Quick-and-dirty.  New version of test case.  Works (for me) on FFx 1.0.x.

http://www.nd.edu/~jsmith30/xul/test2/

I would argue that the status bar isn't enough.

Comment 261

[Michael]

(In reply to comment #260)
> (In reply to comment #259)
> > 
> > I guess most would really appreciate, that the problem still exists.
> > As long as it doesn't take many hours to modify the proof-of-concept.
> 
> Quick-and-dirty.  New version of test case.  Works (for me) on FFx 1.0.x.
> 
> http://www.nd.edu/~jsmith30/xul/test2/
> 
> I would argue that the status bar isn't enough.



Thank you, it's working well. I see a 2nd status bar, my googlebar is gone, but
tell this a newbie...

I'm using this IDND Extention, showing my when I'm lured to a paypal site with
cyrillic "a" within. Why don't we add a note to the now unmovable statusbar in
RED, that someone tempered with crome? Right beside the keylock.

Michael
P.S. Please change the URL, I'm not empowered to do so...

Comment 262

[Daniel Veditz [:dveditz]]

With dom.disable_window_open_feature.location=true the new spoof isn't very
convincing. If you rememeber this was the solution discussed starting around
comment 92, patch check-in with comment 156, argued about, and ultimately backed
out in comment 190 (bug 259159).

The nsContentTreeOwner::SetTitle "host-in-titlebar" solution is completely
bypassed by .xul files as this spoof shows (unless you somehow manage to create
a second tab in which case the tabbrowser code takes over).

If we implemented "host always in status bar" as mentioned in comment 253 (bug
262366) then this spoof wouldn't work -- at least not for people who noticed the
status bar. The current spoof does show two status bars which is a little odd,
but with the true status bar being blank it's easy to miss.

The location bar is possibly the only one visually distinct enough to catch
people who aren't slightly suspicious to start with. Unfortunately that solution
was universally hated by web-app developers and would be hard to push through
again. Maybe if, as Hixie suggested, we implemented something like the popup
infobar's ability to go away for specific sites.

What if it was always initially displayed and then slid up out of the way,
possibly leaving a tiny grippy to reopen it?

Comment 263

[Kevin Newman]

This is my bank’s address:

http://www.jeffbank.com/

This is the address of the online banking that they offer (linked from the
previous address):

https://web3.evault.ws/pbi_pbi1961/pbi1961.asp?Rt=021909342&LogonBy=connect3&PRMACCESS=Account&enroll=true

I point this out, because I don't think that this is an uncommon occurence. It
seems like the measures you are taking to prevent phishing attacks are very
heroic, but ultimately pointless. Users will ignore the address no matter where
it is. I beleive that these measures will do very little to curb phishing
success rates, but will do much to hinder the flexability of Mozilla as a
development platform.

I suggest therefore, that functionality of the browser itself, and the
flexability of the development tools, be hindered as little as possible.

In my bank's example, I beleive it is the bank's (or the site operator's) job to
inform their users about the dangers of phishing. It is the job of the browser
makers and communities, if they have any responsibility at all, to evangelize
this idea to the operators of such sites.

Fraudsters and pranksters are always going to come up with workarounds to any
anti-spoofing/phishing features you can implement, and users, frankly, don't
know enough about this stuff for most of the measures you are taking to be
effective. Most users can’t tell you if they are on a secure site or not - or
even what that means.

It isn't worth it to continue to limit the flexibility of the web browser and
the web development community or to waste development time trying to come up
with a solution to a problem that I don't believe can be solved through
technical means. This is a cultural problem.

Just my 2 cents.

Comment 264

[Ken Johanson]

There have been some good suggestions made on how to (proactivly not passively)
advise users that more than one domain is SRC-ing content, or that a supicous
URL was used .. sadly they appear to have been ignored and these same interface
tweaks - agreedly futile - keep finding there way back and forth. This casts the
perception (right or wrong) of a 'wont acknowledge / implement it if I didnt
think it up / ignore the non-developers' attitude (which is what
idea-contributors & watcher of this bug must be thinking).... when those ideas
(not mine BTW) REALLY deserved serious discussion, or *at least* a shoot-down
reasoning. my 2 pesos.

Comment 265

[Daniel Veditz [:dveditz]]

(In reply to comment #264)
> There have been some good suggestions made [...]
> those ideas (not mine BTW) REALLY deserved serious discussion, or *at least*
> a shoot-down reasoning. my 2 pesos.

Bugzilla is not a discussion forum. Most of the debate has taken place in the
n.p.m.security newsgroup.

Comment 266

[Ken Johanson]

> Bugzilla is not a discussion forum. Most of the debate has taken place in the
> n.p.m.security newsgroup.

Buzilla appears to need another field added (or use existing?) that points to
the focal newsgroup/etc, so that watchers know where bug discussion should be
concentrated. This was the first indication that one existed. Append to subject?

Bugzilla could then be used for only inital bug reports, developer
testing/checkins.. not design suggestions or post-fix users feedback (?)

Comment 267

[Gervase Markham [:gerv]]

Dan: I agree that the blank status bar is not very noticeable, and I'm coming
round to the idea that there should be some text there, but there may be some
alternatives to it being the domain name - particularly given the other uses for
that which I mention in the paper I just sent you.

How about a system where we put "Warning: site identity not verified" (or
similar text) in that lower right corner on any non-SSL window which has no
chrome except the status bar? That means we have something there, but it doesn't
offer the false sense of security that an unchecked domain name gives.

Gerv

Comment 268

[Gervase Markham [:gerv]]

BTW, Jeff: this spoof is a great piece of work. Nice one, my son.

Gerv

Comment 269

[joro]

how can i stop receiving bugspam from this bug?

can't find a way in bugzilla to remove the reporter from this bug?

Comment 270

[Tuukka Tolvanen (sp3000)]

[e-mail], see https://bugzilla.mozilla.org/userprefs.cgi?tab=email (but no, I
don't think there's anything to disable mail /for a specific bug/ you are the
reporter of)

Comment 271

[Tuukka Tolvanen (sp3000)]

> disable mail /for a specific bug/ you are the reporter of)
...is bug 215588, fwiw.

Comment 272

[Ken Johanson]

(In reply to comment #235)
> Just to give an example, we could create a new feature for secure site
> developers to take advantage of, like a small security window (like the download
> notification) that pops up near the system tray (Windows specific). This window
> would remain on top of the secure page window, and possibly be anchored by a
> notification icon and could only be triggered from a secure web page coming from
> a page with proper SSL credentials. This kind of measure, combined with a strong
> marketing effort, would be simply unspoofable (unless there is some way to make
> a notification icon from within Mozilla). This also pushes the burden of
> anti-phishing measures to individual site devs (where I think it belongs), as
> they would be responsible for taking anti-phishing measures and educating their
> customers about the dangers of spoofing/phishing.
> 

I agree with kevin's idea - this has REAL merit and should be implemented
outright - its the ONLY solution that meets all these requirements:

-Doesn't hinder web applications by muddling the page title's appearance in
task-bars and window dress (by them pushing far right, hence making them even
less habitual to look at)
-Is dynamic - instead of being staticly diplayed (like URL/staus bar), it can
scroll-up contextually, like when a page is loaded that tries to load content
from mutiple domains (rare in a self contained webapp)
-Is proactive - the user *notices* the notice bar because it is only displayed
under warranting circumstances.
Is not overly burdensome - like an alert dialog would be (e.g. having to dismiss it)
-Is scalable - the notice can auto-size to show *all* domains, their SSL trust
stsus, etc, in the case of mixed domain pages, or pages with subject alt
certificates (no current status bar or url bar layout could even being to do all
this)
-Is unfiformly *located* to the native platform - the notice-scroller will
appear where a Mac users expects it, as with Windows, Linux, etc.
-Is unfiformly a one-stop presentaion element for *any* type of security
advisories (cookies etc), i.e. its extensible.
-Exists as biolerplate code - since thunderbird already has this scrolling 'you
have x unread meassages' type functionallity.
-Is not spoofable - since a spoofer cannot overlay a same dimenion (or larger)
pop-up window over the top of the notice-scroller, let alone easily mimick it's
position and size during scroll.


Now that another browser is reportedly about to implement this exact same idea
(likely gleaned from this discussion), now would be a good time for Moz to take
first-to-market credit... but fast.

Comment 273

[Gervase Markham [:gerv]]

I don't agree that a solution along the lines of comment #272 would help.

Its biggest disadvantage is the annoyance factor. I know I turn off (at work)
the Outlook "you have new mail" popup windows, and I get new mail less often
than when I visit a new site.

And, when you look at the non-irritating parts of the idea closely, you are
really just re-inventing the status bar. You are proposing an ever-present
indicator of security information attached to each window. That's what the
status bar is. Now if there are problems with the status bar being obscurable,
let's fix them. If there are problems with it not being noticeable enough, let's
fix them.

Gerv

Comment 274

[Ken Johanson]

(In reply to comment #273)
> I don't agree that a solution along the lines of comment #272 would help.
> 
> Its biggest disadvantage is the annoyance factor. <trim>

But that just the right balnace of annoying - the app INARGAIUBLY *has to* be
annoying to get the users attention. To cuse the status bar to grab the users
attention, your very best hope would be to make the txet scoll back and forrth
like an ad banner. I NEVER look at the status bar habitully, and I'm *not a
layman user*. In fact I only look at to see what URL a link will take me too.
I'm sure this represents 90% of the everage joe if you poll their use behavior.

On the contray, the widget ideas is FAR less annoying then the alert dialogs
which people just click the 'dont show again' option, to avoid having to ever
give another click to tha screen.

Besides, if you should opt to turn-off the widget, that's practilcally stating
that you dont want the more 'proactive' warnings, fine for your tastes, yes.
I'll keep the advisories turned on.

Last, that advisory widget represents an absent concept in the platform now
(unless you open Info->Security for each page) - a centralized placed where *any
and all* security contextual stuff can be placed.. for exmaple listing running
privileged plugins (Java, Real Player, Moz plugins), cross domain content, SSL
certs and trsusted CA.... WAY too many examples to mention. The status bar on
the other hand fills too many purposes (and cant even begin to  display enough
info *epsecially* when the window is say, 100x100) - the status bar just is not
a dedicated security tool.

> really just re-inventing the status bar. You are proposing an ever-present
> indicator of security information attached to each window. That's what the

No, it appears only as need, like the typical mail 'you have mail' widget, which
is why I call it proactive (vs the status bar as passive one). It would appear
when pligins are loaded.. when a cert is trusted against a user loaded CA...
when a link is clicked containing user:pass@host... just a few examples.

> let's fix them. If there are problems with it not being noticeable enough, let's
> fix them.
> 
Well this same 'proactive' approach to notification that mail (and other) apps
are using, is about to become a defacto in browsers too... getting the status
bar to compete with that will be a tall order.

Comment 275

[Hish]

(In reply to comment #274)
> But that just the right balnace of annoying - the app INARGAIUBLY *has to* be
> annoying to get the users attention.
Wrong. After a couple of minutes Joe Average also ignores the information within
this annoying window. It then simply keeps the feeling of what it is: annoying

Comment 276

[Kevin Newman]

This is just to clarify (and refine) the idea that I posted. The thing that I'm
talking about would be a popup that only shows up when you are in security mode
(like visiting an ssl protected site), and would be anchored to the taskbar (or
whatever equivelant in non-Windows OSs) with a coresponding icon (like a lock).
This would be none-intrusive, and would shouldn’t be annoying, though it should
be noticeable. The feeling it should evoke should actually be confort, so that
if it’s missing, bells go off.

This is essentially an extension to the status bar lock icon and colored address
bar that makes it more obvious that you are on a secure site, without crippling
what can be done with the other features of Mozilla. I will describe some things
that could be added into that window later, but the over all idea is that the
window should be very simple, contain only enough information to inform the user
about possible security risks, and should be unspoofable (unless there is a way
in XUL to create a taskbar icon and a chromeless window with accompanying
animations).

Once a feature like that has been implemented, it is up to the web development
community (and the businesses/sites they develop for) to inform their users, so
that they know to look for the little window and icon, similar to the way that
many sites now inform their users to look for Microsoft’s Active-X security
strip when you try to install an Active-X control (install flash player from
macromedia.com into IE 6.0 w/ XP SP2 to see what I mean). In order for this to
be effective it would be necessary to reeducate users about what to look for
when using a secure site, so a marketing push from Mozilla’s PR department might
be warranted too. This would help push the feature as a bonus that Mozilla
offers over it’s competitors, and would help users to see it as a benefit rather
than an annoyance.

Originally I suggested that the window only show up if the site or server calls
for it using some api (that the api gurus can come up with), however, as Ken
Johanson has suggested this could show up whenever you enter any secure site,
and contain some small amount of relevant information, such as the domain you
are currently visiting, and possibly the referring url that started the secure
session, to help with situations like I described in comment #263 – and these
could stack if the secure site sends you to another secure site, with a
different certificate. It could contain the name of the business, taken from
either the certificate, or that custom api I spoke about. Finally, just three
buttons/links – one to hide the window (but not the icon), one for more details
about the site that displays information in human readable terms, and one for
more information about the feature itself (a “what is this” button or link).

The information in that box should be human readable – the Security tab in the
Page Info dialog just doesn’t work for regular users. This dialog could be color
coded (like avast's alerts, which are normally blue, and red if something's up),
or possibly use icons similar to the ones that Netscape 8 uses for it's trusted
or untrusted sites. And different levels of security could be determined (and
displayed through the color, or icons), using a combination of the current ssl
checks, and added others like checking that the ssl site and the referring url
are the same (though I guess that wouldn’t be hard to spoof).


In response to comment #265 Is there some official channel for discussion of
this stuff? Are these kinds of ideas and suggestions appropriate in this or any
official channel? Are the design desisions and discussions not meant to be as
open as the code? If it is, what is the official channel for discussion of
design desisions? Is it newsgroups, mailing lists, irc chatrooms, mozillazine
forums, etc.? Should this conversation be moved to a new feature request?

Comment 277

[Ken Johanson]

(In reply to comment #275)
> > But that just the right balnace of annoying - the app INARGAIUBLY *has to* be
> > annoying to get the users attention.
> Wrong. After a couple of minutes Joe Average also ignores the information within
> this annoying window. It then simply keeps the feeling of what it is: annoying

Who tries to turn off their 'you have mail' Notice applet/widget? That's as
benign as it is. You seem to be stating that this is downright objectionable,
and I say it is only midly so, only becasue it's 'bold' enough to catche you
from the corner of your eye... and I argue it HAS-TO to get the average joe to
be aware of a potential problem.. or a whole list of them... again, that's what
the status bar isn't doing right now, and I cant see it doing.

The purport upcoming release of another product supposedly even has controls
inside of this new 'notice' window that allows you to change trust levels, view
lists of items to permit/deny, and remember your decision, etc. So the staus bar
is already obsolete for the fact that it cant contain entire dialogs / lists /
controls.

Comment 278

[Ken Johanson]

(In reply to comment #276)
> In response to comment #265 Is there some official channel for discussion of
> this stuff? 

Kevin, it appears you had sparked the original idea (envisioned as a
tray/taskbar type Notice/Advisory screen, e.g. Thunderbird's "you have mail")
(my apologies if someone had else described it earlier). So if I'm not mistaken
a new Buzilla entry should be created as an RFE, by you. 

(*This* thread was for a bug, with a narrower scope (that focuses on html or
chrome spoofing threats, --not mailcious plugins, ssl & installable CA certs,
cross site zcripting and injectable code on 3rd part sites... a sublist to be sure).

Comment 279

[timeless]

i disable new mail notifications. if i don't, i'd have it splashing every minute.

Comment 280

[Kevin Newman]

I created an RFE - bug #296249

Comment 281

[Asa Dotzler [:asa]]

Dan, is there anything we're going to be doing here for 1.1 that's not already
done? 

Comment 282

[Jesse Ruderman]

Hostname in titlebar for Firefox 1.5 -> bug 304388.

Comment 283

[Daniel Veditz [:dveditz]]

I'm closing this bug as "fixed" with the title bar change. It's gotten far too
unweildy. Gerv is working on proposals for anti-phishing/anti-spoofing UI
features which covers the intent of this bug and would work out better starting
from scratch.

Comment 284

[Phil Ringnalda (:philor)]

Comment on attachment 158192 [details] [diff] [review]
Make only gURLBar be present

Clearing bit-rotted review request - this seems to have migrated to bug 258405 anyway.

Comment 285

[Worcester12345]

(In reply to comment #284)
> (From update of attachment 158192 [details] [diff] [review])
> Clearing bit-rotted review request - this seems to have migrated to bug 258405
> anyway.
> 
In which case should this one be WONTFIXed?