With the demise of the always-on location bar we once again have no anti-spoofing/anti-phishing story. Possible solution: expand the SSL hostname thing to show the host name all the time. If it's important to distinguish between secure "we know this for a fact" hostnames vs "if you trust DNS" host names we could bold the secure hosts and/or add a background field.
I have a patch for the statusbar idea. I just have one question... Do you want the host name shown on non-secure sites: (1) all of the time (2) only if the location bar is not present (3) only in pop-up windows (4) only in pop-up windows if the location bar is not present If there is a agreement on which approach is best, I can post the patch.
if we can get this one we can get to zero open secunia issues.
Flags: blocking-aviary1.0? → blocking-aviary1.0+
Created attachment 160706 [details] [diff] [review] possible fix This patch follows the approach number 3. Whenever a user sees a chromeless popup window, the domain of the current site will be visible in the statusbar. To differentiate between secure sites, normal sites show the broken lock icon.
Comment on attachment 160706 [details] [diff] [review] possible fix Asking review from Ben. Also, please ignore the errant space in front of the ending else bracket. I don't how that got there.
Created attachment 160710 [details] [diff] [review] possible fix Its been one of those days, sorry for bugspam.
Attachment #160706 - Attachment is obsolete: true
Created attachment 160715 [details] [diff] [review] possible fix Also, fix pinstripe while I am at it.
Attachment #160710 - Attachment is obsolete: true
> With the demise of the always-on location bar we once again have no > anti-spoofing/anti-phishing story. I'm not sure that's true. For sites where important or confidential information is involved (and which therefore use SSL) we do. For other sites, we can't guarantee we are connecting to the right site anyway (e.g. because of DNS spoofing). I therefore suggest that putting the hostname in the status bar even when we are _not_ sure we are connected to the correct site reduces, rather than improves, security. If ebay wants anti-phishing, they should use SSL and tell Firefox users to look for ebay.com in the status bar. Having said that, if people disagree with me and decide to do this, then we should have it all the time, not just when it's a popup window. This is not a "replacement URL bar", it's a piece of security UI with a different function. Showing the broken lock icon on normal sites is also a departure from previous practice, and changes the meaning of that icon. I don't think that's a good idea. Gerv
FWIW, I agree that 1) would be better than 3), but I think either is better than doing nothing on non-SSL sites. I'm not sure that DNS spoofing is a huge issue - it's relatively difficult to do, and I think that spoofers would go for simpler tricks long before they get to that. There are (not that there should be) plenty of sites where important information is involved but SSL isn't used. You can say "if ebay wants anti-phishing...." - but it's users (and secunia) that need/want anti-phishing, and they'll take it from either the sites or the browser - millions of sites and half a dozen browsers means it's easier to get the browsers to change. Like Gerv, I don't like the idea of having the existing broken lock icon though - that has a specific meaning that has been used across browsers for years, and this would be a change. It should either be a substantially different icon (maybe a greyed-out open lock?), or no lock at all, IMHO.
Ok, I agree that showing the broken icon goes against previous practice. My reasoning for using the broken icon is that its a pretty clear indicator that the site is not secure and I am not sure that the average user is going to see a difference between broken/no security. My original patch did not use an icon, but when I tested it, the domain in the statusbar wasn’t very noticeable to me. With that said, it is probably better to create a new icon ie. a grayed out open lock called Security-none.png. I still think that (3) is the best approach. DNS spoofing is fairly involved and not showing the domain isn't that much safer (the spoofed site still looks spoofed). (1) is also viable, but it makes the toolbar look cluttered and is redundant considering that ~90% of users are not going to hide the location bar. But, its trivial to switch this behavior.
"(1) ... is redundant considering that ~90% of users are not going to hide the location bar." Not sure what you mean here - the concern isn't about users hiding the location bar, but about spoof sites hiding it (and possibly replacing it with a fake location bar).
Created attachment 160768 [details] [diff] [review] always show domain I think this is what everyone wants. This patch will cause Firefox to always show the domain in the statusbar (number 1). Non-secure sites use the (currently) non-existent icon Security-none.png. I also added a check to make sure about: sites don't appear in the statusbar. I have tested the patch a bit more and everything looks good. Chrome sites (chrome://) are a little funky, but I don't think that is a big deal.
(In reply to comment #10) > "(1) ... is redundant considering that ~90% of users are not going to hide the > location bar." > > Not sure what you mean here - the concern isn't about users hiding the location > bar, but about spoof sites hiding it (and possibly replacing it with a fake > location bar). Please bear with me, I learning here. Even though I obsoleted that patch I still have a question about this. To hide the location bar, wouldn't the site have to launch a window with the chromehidden attribute? If so, the patch whould make sure that the domain always appeared in this situation, protecting the user. When the user is browsing normally, the location bar (by default) is present and is probably a better indicator of spoofing than just showing the domain.
argh... sorry Jim, you're right and I was commenting based on a misremembering/misunderstanding of the previous comments. Please ignore me...
14 years ago
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
> I think this is what everyone wants. Ben Goodger gets the final word in Firefox UI decisions, and he's marked this bug as "blocking-aviary1.0 -" so I suspect he doesn't want it. :-) Gerv
"Not blocking" is not the same as "Wouldn't take if a reviewed patch was available". If he meant the latter he would have WONTFIXed the bug.
Does anyone else want to review this patch if Ben is busy?
It is definitely something i would love to see in firefox.
I think this would be good, as long as their is an uption to turn it off. Currently I have over 5 or 6 extensions all taking up space in my status bar, and I don't think I would have room for much else!
> I therefore suggest that putting the hostname in the status bar even when we are > _not_ sure we are connected to the correct site reduces, rather than improves, > security. If ebay wants anti-phishing, they should use SSL and tell Firefox > users to look for ebay.com in the status bar. I agree with this. The point of putting the additional information on the status bar is to indicate what is reliably known, and by always putting the domain name in that spot in the status bar, this becomes just another little detail for the user to glaze over. Almost all phishing is non-SSL because users haven't accepted the "padlock" security model. Only by enlarging the padlock notion into a more complete security display can this be made obvious to users, and only by forcing SSL to be important can the identity information be used to protect users against bogus identities. Not only is more SSL information needed (other than the padlock) but it needs to be made more obvious, so that users can get accustomed to its presence on their favourite banking site. It is the *difference* that matters more than the content, as phishers create as perfect a copy as they can. This means that a non-SSL site should not have an additional information shown. (Apologies for being late to this conversation; I had been led to believe that nobody in Mozilla accepted / worked on phishing as a serious problem!)
see also bug 252142
Comment on attachment 160768 [details] [diff] [review] always show domain I have had some time to think about everything discussed here and I still think that always showing the domain name is still a good idea. Adding this feature will be especially beneficial in alerting users to spoofing in pop-up windows or for users who like to hide the address bar. It will also lessen (although it is not the proper fix) the impact of bugs like Bug 273699. The arguments against doing this are definitely valid and must be considered. It is important to note that showing the domain does not degrade the meaning of the padlock or secure sites. DNS Spoofing is quite rare and still affects the url bar, however, to further emphasize that the domain cannot be trusted, a tooltip can be added to state “website identity not verified” – or something similar. In addition, Firefox does not currently allow an easy, obvious way to access site security information (which is still important for non-secure sites simply to tell the user the site is not secure and not to be trusted). By allowing access on the statusbar, Firefox makes an additional step towards making site security information to the user more apparent with the resulting benefit of reducing the effectiveness of several common spoofing techniques. If there is a consensus that this is the right path, I am more than willing to update the patch for the trunk.
> Adding this feature > will be especially beneficial in alerting users to spoofing in pop-up windows Actually, I think the current arrangement is the best for alerting users to spoofing in popup windows - because the difference between wrong and right is so much greater. Now, if it's a valid popup on an important site (which therefore uses HTTPS), you'll get the domain. If it's a spoofed popup, you'll get *nothing at all*, unless the attacker has exposed themselves by buying a cert (which does give at least some audit trail). If you changed it, on a valid popup you'd get a domain, and on a spoofed popup you'd get a different (but perhaps very similar) domain. This is much harder to spot. So the right thing to do to help most users is keep things the way they are. Gerv
I apologize for the delay in response, but I have been unbelievably busy. Gerv, I have been following your blog and I agree with several of your suggestions to prevent phishing in Firefox, but I still have issues with always showing the domain address. (In reply to comment #23) > Now, if it's a valid popup on an important site (which therefore uses HTTPS), Although that is becoming increasingly true, it is still a very dangerous assumption. Many websites still do not use HTTPS for important data, especially forums, webmail, and software registration sites. Consider hotmail – although a user losing their password is not a major concern (you can easily create a new account), the concern is that the phisher can then access secure information within the user’s email. > If ebay wants anti-phishing, they should use SSL and tell Firefox > users to look for ebay.com in the status bar. In many cases the website could care less whether they have anti- phishing policies (thus, they have no motivation to change the site) - it is the users that want the protection. If always showing the domain address is implemented, then ebay would simply tell the users to look for the lock icon AND to check the domain address. This makes more sense considering many new Firefox users are migrating over from IE and are familiar with the concept of "checking the lock." > If you changed it, on a valid popup you'd get a domain, and on a spoofed popup > you'd get a different (but perhaps very similar) domain. This is much harder to > spot. And if you show nothing, the difference is impossible to spot ;) I view the similar domain name problem as an issue of accountability. Once again, consider the hotmail example I stated before. Right now, if I opened hotmail or a spoofed hotmail site in a popup window, you cannot tell the difference between the spoofed and real versions. Additionally, since the domain name is not shown on the real site, the user has no real reason to doubt its validity when the domain name is not shown on the spoofed site as well (this is true in non-popup windows even with the url bar present – think of http login phishing). Thus, the user has a valid complaint that Firefox has not reasonably alerted him/her to the possibility that the website is spoofed. By showing the domain address, we allow the decision to be in the hands of the user. If the user is confused by similar domain names, Firefox has at least helped the user make an informed decision, rather than simply saying the website is not using SSL and withholding information (heuristics could also help a lot in this situation). And on a related note, yes I know about Page Info and dom.disable_window_open_feature.*, but most users do not. Also, I am aware that showing the domain name is useless against DNS tampering, however, there isn’t much a browser can do about this in the first place. > Actually, I think the current arrangement is the best for alerting users to > spoofing in popup windows - because the difference between wrong and right is so > much greater. That is why this is only a partial fix. To truly tackle the problems of phishing, we will need to consider heuristics, white/blacklists, etc. I do agree that more could be done to differentiate between secure and insecure sites – but these issues are issues for other bugs.
Currently I view the additional domain name in the status bar as an important proof that this is a checked domain name, as per the cert. If the domain name is also shown in situations where the cert is not checked, then the cert check is now meaningless. If the domain were to be shown in the same fashion as the non-checked domain, then there is no point in using TLS for security. What this says is that you must provide phishing protection in unprotected HTTP. That's very problematical. Without cryptographic keys it is imposible to make statements that can be tied down and reliable. So however good you get the techniques, there is always a possibility that a bug slips through, and there is a growing expectation that phishers will start to attack DNS in the future (there are documented examples of DNS attacks already, but on a very small scale. These are consistent with other leading indicators.) This is why we view the phishing fight to *assume* the presence of the certs. Yes, this is to draw a line in the sand. And yes, those sites out there - hotmail or whoever - may miss out. And their users. The presence of hotmail and the risk the users face there does not mean that it is possible or desirable to attempt to protect them. Not all the users are protected all the time. And, especially, if it breaks the protection that was designed in the first place, this is likely to do long term harm. In browsing, TLS and certs are the security layer, they are the layer that promises to stop spoofing, and phishing is a spoof. They are the only thing that allows the browser to say anything for certain. That statement is essentially this: a) the domain in the cert is X b) CA signed that cert c) you are on a crypto-secure channel to X/cert/CA d) you recorded your relationship to X/cert/CA as Y. It's very simple stuff (all three things need to be on the chrome). Armed with that information, the user can apply some security metrics. (Note, even this is not ideal. She is still vulnerable to a data re-writing attack on the node, so a more complete solution would be to make sure the Firefox DB is encrypted and protected as best as possible... which still leaves keylogging. But, let's be practical here, and not lose sight of what *can* be achieved.)
I should add that the security model calls for cert-checked information to be shown differently. That doesn't say that you can't show the domain on the status bar. What it says is that if must look different. So, if you were to duplicate the mighty impressive yellow bar effect for cert statements and leave the boring grey or white for unchecked statements, that would also align with the security model. (But, please consider adding the CA's name next to the domain. Simply putting the domain name there as checked by a cert is not sufficient security, as it is too easy to acquire a cert from another CA in the same name.)
(In reply to comment #26) > I should add that the security model calls for cert-checked information to be > shown differently. That doesn't say that you can't show the domain on the > status bar. What it says is that if must look different. So, if you were to > duplicate the mighty impressive yellow bar effect for cert statements and leave > the boring grey or white for unchecked statements, that would also align with > the security model. Absolutely, I agree that we should make secure sites and insecure sites that much different in the statusbar – and it probably can be done by simply changing the background of the text (say to bright yellow for secure sites, red for broken security, none for insecure, etc.). That way we don’t degrade the secure model and help improve its prominence. I wanted to add that the risk of confusing the user is largely negated considering we already show the full url in the url bar. Therefore, based on some of the arguments against showing the domain in the statusbar, shouldn’t we also hide the address in the address bar, since we cannot verify it really is the correct address? No, of course not. If anything, showing the domain in the statusbar adds additional protection by alerting to http login phishing and by shortening long urls that may be constructed to confuse the user. Additionally, if a hacker corrupts the users DNS, then the url bar will also show the bad address as well, thus, we are not placing the user at an additional risk. I also wish to reiterate that a secure website is always going to be the best protection against phishing. Firefox does a great job with alerting the user of this additional protection by changing the address bar and adding the lock in the statusbar. Hopefully, we can continue this by improving protection on the sites further – with a clear UI alert system, heuristics, white/blacklists, etc. For insecure sites, showing the domain is just a bandaid fix at best, but considering we loose nothing by showing it, it is better than doing nothing.
The precise mix of those decisions and presentations is not really something that can be determined in advance of some testing. As you suggest above is a good start - yellow / red / boring. But you might want to keep an eye on adding more colours later. Bear in mind that in terms of the original security model, the URL bar was what the user typed in. There should be a second bar that shows what the browser then connected to. In security terms, they should show the difference, and the statement made by the browser should be as 'proven' as possible. So arguments for/against the status bar do not apply necessarily to the URL bar.
"I agree that we should make secure sites and insecure sites that much different in the statusbar – and it probably can be done by simply changing the background of the text (say to bright yellow for secure sites, red for broken security, none for insecure, etc.). That way we don’t degrade the secure model and help improve its prominence." It sounds to me like that would degrade the secure model - anything that increases the complexity of the UI reduces security. Currently, the user has to look for one thing - it is either there or it isn't. Now you'll be asking the user to look for several different things and understand the difference between them. Also, in Firefox 1.1 no background means "secure" - you're planning that in a future version no background will mean "insecure". So if the user switches between versions, they will need to be aware of which version they have in order to understand the meaning of the UI...
> It sounds to me like that would degrade the secure model > - anything that increases the complexity of the UI reduces > security. Currently, the user has to look for one thing - > it is either there or it isn't. Now you'll be asking the > user to look for several different things and understand > the difference between them. The converse of that would be to simplify the complexity until there is no security. Obviously, the security optimum exists somewhere between a null system and a too-complex system. Right now, the security standard is a padlock that is not looked at by users; one that creates a binary signal that hides whether the identity of the site is as expected, whether the CA is as before, and whether either have ever been seen before. As the padlock is widely ignored, adding complexity can't really hurt security! > Also, in Firefox 1.1 no background means "secure" - you're > planning that in a future version no background will mean > "insecure". So if the user switches between versions, they > will need to be aware of which version they have in order > to understand the meaning of the UI... Security is generally signalled by a positive signal, such as a green light at a traffic stop. Also, security is not an absolute signal, there are degrees of security.
I'm in favor of this approach. I think it makes sense to put the hostname in a reliable place. Encourage people to look there instead of at the URL bar. It frees people from having to parse URLs in their mind, and that's a good thing even for insecure pages. Perhaps if we do this then we should have the notion of an unlocked icon or some other icon that indicates no security. (Doesn't seamonkey do this?) Maybe if users hover over it or double-click it we can explain what it means to be insecure, etc.
Having discussed it with dveditz, I've come round to (a modified form of) this idea. If we can maintain a clear and visible difference between "site identity verified", and "site identity not verified", and not confuse people upgrading from 1.0, and get rid of the URL in the title bar, then I'd go with this. It has the additional advantage of branding all windows with a clear indication that they are browser windows, which reduces UI spoofing. We will always be balancing the needs of web applications with the need for security. I would like to suggest that we draw a line and say "the status bar is ours - it's all about security, you can't get rid of it. Everything else can be controlled by the site within the normal security models, to provide a rich user experience." I think we need some way of saying "site identity verified as correct" without implying "connection encrypted". If phishers start to attack the DNS, and we implement DNSSec or other counter-measures, we can than flag "site identity verified", without flagging "connection encrypted". This suggests to me that the way we indicate that the site identity is verified should be _different_ to the way we indicate that a site is secure - i.e. we shouldn't just duplicate the yellow background stuff. I'm not sure what the correct solution is yet, though. Gerv
14 years ago
Flags: blocking-aviary1.1? → blocking-aviary1.1+
I have ported over a modified version of the previous patch to the trunk and I have been running a build with it for a while. Right now it will: 1) Always show the domain, except for about links (chrome links are shown, but this should not be a big deal) 2) Not show an icon in the statusbar when at an insecure site (to reduce user confusion) 3) Not change colors - although I feel this might be beneficial, not changing colors allows for better flexibility when implementing additional anti-phishing or security UI in the future (as Gerv said in comment 32). One problem I have run into deals with tooltips. Right now the default tooltip for insecure sites is "Displays security information about the current page" (http://lxr.mozilla.org/seamonkey/source/security/manager/ssl/resources/locale/en-US/security.properties#51). This statement is not very meaningful and I am inclined to change it to something like "Web site identity not verified". This change, however, probably impacts Seamonkey as well, so I am not sure of the correct course of action.
Depends on: 264064
Would anyone oppose splitting the ssl and host name indicators into separate statusbar panels? This might make the transition easier for previous users and has the added benefit of allowing for better flexibility when implementing additional spoofing protection in the future.
We're currently trying to work out a more general strategy for this bit of UI, taking into account some other concerns which are SSL-related, over in n.p.m.security. Gerv
Gerv, I'm minusing this for now in the absence of anything concrete with consensus in the last 3-4 months since your comment. Please renominate and provide details if we have a plan that we can execute on in the next two weeks.
Flags: blocking-aviary1.1+ → blocking-aviary1.1-
I could put together a patch, but I was hoping to get a response from comment 34.
Jim: the host-name indicator is closely associated with the SSL lock icon, so having them in different panels would be a backwards step IMO. We currently are not planning to fix this bug as it's currently titled, but I have some different ideas on how to solve the problem. Minusing it is the correct thing to do for now. Gerv
What is the status of this bug? Should it be Wontfixed? I know that there has been considerable effort to institute mechanisms to protect users from phishing/spoofing for version 2.0 and I think this bug is still beneficial. I will create a new patch if there is interest.
I don't think there are any plans to fix this bug as it stands. IMO, we only want to present verified information to the user; the hostname of a non-SSL site is not verified. However, given that it was originally filed by our security lead, I'm not going to WONTFIX it myself :-) Gerv
A year has passed, and I've got bolder than I was in comment #40 :-) Gerv
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.