Sunday, September 19, 2004
Browser Spoofing: Examining the Solutions
First, read Jesse Ruderman's take on the issue from last month. Then, check out my definition of the problem and the criteria for a solution.
Proposed Solution #1: always show the address bar
Ok. This does solve the problems. Now, only internal dialogs can show without an address bar. Since Mozilla added security information to the address bar, we can now always see that data. And for unsecure sites, we have the full url, though that may be somewhat hidden by adding lots of text before the domain name in the url. The downsides: we usually have our navigation buttons here, which add unnecessary clutter to the UI for web-based dialogs. Plus, Firefox lets you customize your toolbars. Personally, my navigation bar is empty, I have everyting on the menu bar. So I'm no longer really protected in terms of site spoofing. Also, this still allows sites to spoof the status bar, which is the traditional location of the security information (and still one of the sources of security information in Firefox), so user's who check that instead of the address bar will be fooled into thinking they're safe.
Proposed Solution #2: always show the status bar
Again, this solves the problems for the most part. Internal dialogs would be the only one's without a status bar. On secure sites, the certificate information is available, and the domain name is shown. If we simply added showing the domain name on the status bar for unsecure sites as well, then this would actually provide more anti-phishing protection than the address bar, as it would prevent the domain from being hidden by a long url. Also, the status bar is slightly smaller than the address bar, and data there can't have been moved to another toolbar. The downside: Mostly, now the address bar can be spoofed, and user's who look there for data, especially on un-secure sites, may be tricked if they ignore the status bar data.
Proposed Solution #3: A new UI
The idea here is to replace the status bar with something that actually wraps around the untrusted chrome. This has all the benefits of the status bar approach, but it prevents address-bar spoofing to an extent, by forcing that spoofed address bar to appear inside the yellow outline. My concerns are: these mock-ups don't take into account other current status-bar data. Does that still stay on this UI? Or are we not going to entirely replace the current status bar? How would this really look for a normal, maximized full window? Also, how can we insure that the utility of the outline and such don't disappear when using different browser themes? This is already a small problem with the current UI, but I can see that outline becoming even more of a problem.
Conclusions
The reason there is no simple solution to this problem is because we (Mozilla) have chosen to display security information two places: the address bar and the status bar. So, unless we change that, I think Benjamin Smedberg's idea (#3) is the best way to go. I wasn't convinced when it was first brought up, and obviously I still have some concerns, but going through this process has convinced me.
Labels: web
Comments:
I'm not sure I'm happy with any of these solutions.
As the web becomes more used for application development with more companies moving traditional native applications over to web-based applications, I think that additional UI elements being forced to be on the screen at all times becomes a huge hassle.
For instance, imagine if you have a pop up window where you want to emulate the typical wizard interface. If the navigation buttons appear on this window, then the user can (and probably will) use them instead of the integrated navigation methods on the page. This could cause problems with the web application, and confusion on the user side.
I don't think Mozilla putting the security information in more that one place is a bad idea. More places with the information hopefully mean more places people can/will look for this information. It also makes spoofing harder because you have to make sure you get all your bases covered to pull it off.
Perhaps a better solution would be to insert some sort of visible margin around the inside of the browser frame that can't be removed. Then, there would be an obvious padding of everything that was being spoofed inside the browser window, clearly seperating it from the chrome that makes up the browser. Of course, web developers have for years enjoyed the ability to make the outside border of the page disappear.
However, if this extra space was just used as a margin along the top and bottom of the browser content render section, this would probably not harm web development efforts any, and should still serve the same purpose. It wouldn't have to be much space, filled with a color or pattern or other decoration that would be clear. Then, if a window was opened without any browser chrome, but instead rendered chrome inside the browser content section, it would be obvious that menus and other aspects of the typical interface would be appearing below this margin. I believe this would easily pass all your tests, and should even be somewhat obvious to a regular user of the brwoser as well as a high tech one.
I think the ultimate solution to this problem though might be to not rely on any single method, but to use several different solutions. I like the idea of having the hostname displayed on the status bar, like we see in firefox 1.0PR for SSL sites. That's a good step, but teaching people to use the information they have is another step that is perhaps the hardest of them all.
Well, now that I wrote all that out, it seems that's what the idea in #3 was. That'll teach me to not read through the links you provide as well!
Anyways, I think that's a potentially good idea, although I'm not sure if I like how it's replacing the status bar. I think perhaps it should be added along with the status bar. The browser status bar could still be used to show additional information that wouldn't fit in the top bar, or wasn't as important to the user. Also, the status bar gives a larger place to grab the corner of the window for resizing purposes, and I'm always a big fan of larger UI targets.
Hehehe.
Yeah, when I first saw that solution, I wasn't convinced at all that it was necessary.
But after slowly walking through the problem, it becomes pretty obvious that Smedberg is right, and that we need something like that. So obvious that I ended up agreeing with something I started off intending to disprove, and so obvious that your brought it up almost exactly in a comment just before reading the solution. Almost eerie. :)
Also: I should have a warning posted on my Blog:
"Please read all links before commenting. I'm way too lazy to write a good summary for you."
