Adam Stiles

Just upgraded to Firefox 3.0 beta 5... do you think I have enough back/forward buttons? Revert!

One feature I've missed since abandoning NetCaptor for Firefox a few years ago was the ability to open new tabs next to the current tab instead of at the end of my tab stack. I spent an hour white-boarding this with Firefox dev Ben Goodger, and I gave up trying to do this myself after finding the Firefox tab-ordering code to be a spaghetti-mess of independent arrays.

I don't remember how I stumbled on Tabs Open Relative... but all is well in my tabbed browsing world again -- as if some annoying background music is gone. Ahhhhh.

Why is this feature so important? Context. When you open new tabs, they tend to be related to the current tab. If I'm searching Google for digital camera reviews and open the top five links as separate tabs, those tabs should be close to the "starter" tab, not lost at the end.

One thing that has annoyed me about my MacBook Pro is that, by default, "tab" skips past select elements (combo boxes) on web pages. Luckily its not that hard to fix.

Tip from Slashdot. ZDNet has a story about test builds of Thunderbird which allow tabbed email browsing. I like it - flip between several emails quickly. I wish Gmail made it easier to manage multiple emails at the same time.

Tags: thunderbird, browsers

I have a prediction to make - the Phishing Filter, as currently implemented in IE7 beta 1, will be radically re-engineered (or even removed) from the final release of IE7. Keep reading and I'll tell you why.

I haven't installed IE7 beta, but I have read a blog post (and comments) on the IEBlog from the IE team that gives details about the IE7 Phishing Filter (PF).

A little background. The browser is the last line of defense against phishing attacks, and therefore the most important. Spam filters can be bypassed (and bayesian filters actually help phishers get through to likely targets), and network filters are only as effective as their most recent blocklist update. Most network filters don't understand javascript and are easily fooled.

Browsers can use two complimentary methods to defend against phishing sites.

The first method requires a block list. Whenever you initiate a navigation (click a link, type a URL in the address bar, select a Favorite) the browser checks the host or url of the requested site against a block list. If found, the browser warns the user and blocks the navigation. The advantage to blocking sites pre-navigation is that you stop users from navigating to sites that could also dump malware/trojans/etc on their machine. Pre-navigation protection is only as effective as the block list it relies upon. If your block list is out-of-date, and phishing sites come and go quickly, or you are the first user to find a phishing site then you are not protected. As block lists become more widely deployed, phishers will find ways to thwart them: dynamically generating unique urls or obfuscating urls so that every combo must be added to the block list or risk misses or false positives.

The second method is post-navigation heuristics and/or content analysis. Whenever a new page is loaded, the browser analyzes that page and tries to determine whether it is a phishing site. The earliest AP products used very simple rules to warn users based on things like geolocation or funny url characteristics. These simple rules do a decent job of detecting phishing sites, but have a high false positive rate. One downside is that the toolbar approach requires constant attention and never gives the user a definitive recommendation. Second generation anti-phishing products like ScamAlarm use content analysis and extensive rule sets to identify phishing sites. ScamAlarm heuristics currently identify over 99% of phishing sites. If you have a good heuristics implementation, you don't need a block list.

So, where does the IE7 Phishing Filter fit in? It seems that the primary tech in IE7 is a real-time block list. A real-time block list gets around the my-block-list-is-out-of-date problem by requiring the browser to phone home on every navigation request. Don't miss this. Every navigation will generate a request to an MS server, ask the MS server if the URL (or a hash of the URL or host) in question is OK, and then warn the user if there is a problem. That's a ton of traffic! If the request is synchronous, it slows down your browsing experience. If its asynchronous, then the warning may not load until its too late. The IE team likes to talk about 400 million IE users. If that number is correct, we're talking tens of billions of requests daily, all
routing through an MS server. Not only does this create tons of extra traffic and a single point of failure susceptible to denial-of-service attacks, but the privacy problems are unprecendented - do you want MS knowing the URL of every site you visit? Even hashed url/host data can be recovered by a determined data miner. I can imagine every reviewer of IE7 cautioning users to turn off the Phishing Filter because Microsoft is watching their every move on the internet.

The IEBlog also hints at a strategy to use some post-navigation rules:

[E]ven if a site hasn’t been reported yet, Internet Explorer will warn you about sites that might look a “little bit phishy” because they use some features commonly used on phishing sites.

How this works out will remain to be seen, but the tone of the description leads me to think IE will rely on first generation rules (is the site hosted on an IP address, does it use a non-standard port, is it hosted in an axis-of-evil nation?). MS doesn't sound confident that IE7 will be able to definitively identify phishing sites, just that it can recognize sites that look a "little bit phishy". This doesn't sound like a trainable system that can detect specific sites and targets as much as something that recognizes generic characteristics - the characteristics that phishers are getting more and more adept at avoiding.

The fact that MS has been working on a solution demonstrates that they think phishing is a huge problem. Its too bad that their privacy-busting implementation (and ineffective rules?) may lead users to turn it off.

Bruce Morgan, dev manager for the IE tabbed browsing team, commented on my original post on IE7 tabs - thanks Bruce! His comment provides more depth into why MS chose the each-tab-gets-its-own-toolbars route. In short - appcompat weight heaviest in making the decision, and 3rd party toolbars will indeed require extra UI space. Just so no one misses it (buried at the bottom of the comments of the previous post), here's the comment:

Adam, I want to explain more about why we chose the thread-per-tab, toolbar instance-per-tab approach we did for IE7.

Adam and I know each other a little bit. For other readers - I'm the dev manager for the IE feature team that owns tabbed browsing in IE7.

We researched several other approaches, and we ultimately preferred the multiple thread, toolbar-per-tab as the right balance of appcompat and stability vs. memory use. Remember that we're retrofitting multiple tabs into a browser that wasn't designed that way, and we want it to work out-of-the-box with 3rd party toolbars that weren't designed to work with tabs.

Our testing showed that if we went with a single thread for all tabs in a window, we would encounter many more UI stalls and jerkiness – too many things both in our code and common 3rd party code block on various things like network activity. So the foreground tab scrolling would stall for a moment, or the whole frame would hang for several seconds while a background tab loaded some docobject, and the like. Not good.

We looked at other approaches for implementing toolbars that weren't instance-per-tab, but they all had much bigger appcompat issues. Ultimately we felt we needed this approach for the best possible appcompat. Even so, some toolbars won't work with IE7 and will need to be fixed. But we hope the fixes will be minor.

We certainly didn't do it this way to save time. Back when we were deciding the implementation, the thread-per-tab approach was estimated to be significantly more expensive than any other approach we considered.

Obviously third party toolbars that handle many top level windows well will work well with IE7's tabs, and ones that don't handle lots of windows won't handle lots of tabs any better.

As for UI space, yes, third party toolbars are currently located below the tabs and can't be moved above them. Another tradeoff.

Microsoft's Tony Schreiner is in charge of the IE7's tabbed browsing features. He posted today about the complications of adding tabs to IE. I still maintain that MS should have hired me to help in this process (quals: 7+ years of IE tabbed browser development) but they weren't interested. Anyway...

Perhaps the trickiest decision MS was whether to break compatibility with 3rd-party IE toolbars. Currently, IE toolbars are "tied" one toolbar to one IE window. But when done right, tabbed browsers save memory compared to single-window browsers because tabs share toolbars. Use the RoboForm toolbar for example. In NetCaptor, you can have 20 tabs open and one RoboForm toolbar - but 20 IE windows would require 20 RoboForm toolbars.

After MS announced IE7 would have tabs, I expected to hear about changes to the add-on APIs to allow IE7 tabs so share toolbar instances. I never considered the possibility that each IE7 tab would have its own copy of 3rd party toolbars. But that's the direction Microsoft has taken. What's the problem with that approach? Every time you open a new browser tab (which tabbed browser users do much more frequently than single-window browser users), you have to create new instances of any 3rd-party bars. Ouch. Opening a folder of 25 Favorites in tabs? You get 25 RoboForm toolbars, and use much more memory and resources than necessary.

Beyond wasting memory and resources, it sounds like IE7 tabs will also waste user interface space. Tony wrote that 3rd party toolbars will now be a part of the tab instead of the IE frame. If I'm reading him right, IE7 could waste valuable vertical UI space, as shown in this doctored screenshot:

A couple of weeks ago I wrote Tabbed Browsing Turns 7, about NetCaptor's 7th birthday, and claimed that "Firefox, Mozilla, Opera, Safari and others can all trace their tabbed browsing DNA back to NetCaptor at some level".

In a comment, an anonymous poster wrote:

AOL bought Booklink in late 1994, and Booklink's Internetworks had tabs as we know them today.   Though largely unheard of today, Booklink was well-known at the time, and has the only legitimate claim on the DNA of tabbed browsing.

I must disagree for two reasons. First, Booklink/GNN/NetShark, in its various incarnations, was not a "tabbed browser" as we now know them. In GNN (and I have several copies floating around), tabs represented the navigation stack of a user's browsing session. To go back or forward, you switched to the different tabs which represented other locations in your session history. Tabs were not in any way independent, you could not right-click "open in new window/tab". In all modern tabbed browsers, each tab can be independent of the others. You can have one tab open at CNN, one at Slashdot, one at Del.icio.us. GNN's tabs just gave a picture of your navigation stack, that's all, like an expanded menu in your back and forward button. NetCaptor was the first to offer dynamic browser tabs where each one had its own navigation stack and could function independently of others. Anyone who has used both will understand the difference.

A second reason I disagree is that modern tabbed browsers like Firefox, Mozilla, Safari, and Opera based their tabbed browsing systems either directly or indirectly on NetCaptor. I chose the term DNA very carefully. Evolution says that mutations occur, and when those mutations are advantageous, they are adopted widely. Even if GNN did tabs first (which I maintain they didn't) the "tabbed browser" mutation came through NetCaptor.

Multizilla was the first tabbed browser extension for Mozilla, and it copied NetCaptor's menu items  and many features word-for-word. David Hyatt, who implemented tabs in Mozilla, Chimera, and Phoenix and I assume Safari, wrote a little about where the tabs in Mozilla came from back in September 2002:

Here's how the whole tabbed browsing thing happened. One night I finally downloaded an extension called MultiZilla (go check it out on mozdev.org. I was particularly impressed with a feature contained in MultiZilla called tabbed browsing. I started doing research and discovered NetCaptor, a tabbed browser that embedded WinIE.

MultiZilla was cool but at the time suffered from two fundamental flaws that prevented the code from being incorporated into the Mozilla tree. The first was a UI flaw, namely that at the time it had ripped off NetCaptor down to the last context menu item. The GUI was similar enough that there would have been definite concerns about so obviously copying some of NetCaptor's more obscure capabilities (like sticky names and tab locking). The second concern was that the tab behavior wasn't encapsulated cleanly into a widget.

I produced a simplified version of tabbed browsing on my own time (did it in a weekend) that removed some of the geekier NetCaptor features and that encapsulated the tab behavior so that the changes to other Navigator files would be minimal. Once I established that it didn't degrade performance in the single tab case, I checked it in as an experiment.

More from David in 2003:

Mozilla had tabs before Opera had tabs. Opera's MDI interface is not the same thing as tabbed browsing. Opera only added tabs in its newest version after Mozilla had them already in its trunk builds. Also, neither browser can take any kind of credit for inventing tabbed browsing. NetCaptor had tabs when Opera was still limited to vanilla MDI, and Mozilla had nothing at all.

Opera's tabbed browser history is a little harder to trace. They had an MDI interface for a long time, but added tabs in their version 7 release in late 2002. I do remember seeing tons of posts in the Opera newsgroups asking for "tabs like NetCaptor".

Alright - gotta get back to work. Just wanted to set the record straight.

Alternative browsers like Firefox and to a lesser extent Opera, Safari and NetCaptor exploded in popularity in 2004. Better security was a major focus, but almost universally, "tabbed browsing", the ability to open multiple web sites in the same browser window by placing each site on its own tab, was listed as a top reason to switch from Internet Explorer. I like what Walt Mossberg said in one of columns in The Wall Street Journal:

Tabbed browsing is the biggest fundamental improvement in the Web browser in years.

I agree

From reading various journalists, you'd think that tabbed browsing was a relatively new feature. Actually, tabbed browsing is over 7 years old - Firefox, Mozilla, Opera, Safari and others can all trace their tabbed browsing DNA back to NetCaptor at some level. I started developing NetCaptor in the summer of 1997 and released the first public version on January 3rd, 1998.

Happy 7th birthday NetCaptor!

Scott Berkun, former Internet Explorer program manager, has written an interesting article: How to build a better web browser. A few friends have asked for my comments, so here goes.

For readers unfamiliar with my background, I'm the developer of the NetCaptor web browser. NetCaptor introduced "tabbed browsing" to the world back in 1998, long before Opera or Firefox.

Scott is right on in his opinion on intelligent bookmarks. A system that automatically builds a list of your most frequently visited sites, whether from the address bar, Links, Favorites, Aliases, or other means has been on my TODO list for years - I just need to pull the trigger one of these days.

Scott thinks Favorites should be searchable, and notes that Firefox has that feature. NetCaptor has had it also... for longer than most of my children have been alive. It would be slick to allow searching by other site metadata as well. NetCaptor just searches the actual Favorites files themselves (essentially little .ini files), and it wouldn't be too hard to add the site metadata to that file when its created.

About sidebars. I think one of the reasons that IE's sidebars never really caught on is that they are so hard to switch between. They are totally independent of one another. Want to switch from your Favorites to your History bar? If you click the History button, the Favorites bar goes away. Where'd it go? I think NetCaptor's tabbed sidebar is a much better implementation.

The part of Scott's article that really got me going was his discussion of Security and Stability.

Something is wrong if competition in any product line continually focuses on security and stability. These design attributes are basic requirements, not advanced features. You won't see advertisements for toaster ovens that say "Now, it explodes less often!"

He's right... there is something wrong - what's wrong is that the market leader IE has made security features and usability an afterthought. How many clicks does it take to add a web site to your Trust Sites zone in Internet Explorer? About 9. Tools > Internet Options > Security Tab > Trust sites icon, sites button, type the site, hit OK twice, and then you're done. And you have to type the site address correctly. In NetCaptor, its a two clicker with no typing: Security menu, Add to Trusted Sites zone. How many clicks does it take to disable javascript in IE? About 5. In NetCaptor, its 2 again. Does IE let you look at the cookies that a current site has stored on your system? Nope. Someday alternative browsers will move beyond the focus on security, but only when IE is so secure that improvements aren't necessary.

One last gripe. Scott thinks browsers should store credit card numbers so users never have to type them twice.

[P]rovide a standard secure way for me to pay for things on the web, and don’t ever require me to type in that 16 digit # again.

No, no, no. Please don't store credit card numbers locally. Why? There is no secure way to store them locally so that a spyware or trojan app can't steal them. Even if you encrypt them on your local machine, you need to decrypt them on the local machine. Anything you do on your machine is crackable, so it would be fairly trivial to write a trojan to steal that data. IE puts its autocomplete data in "protected storage", but its trivial to get it out again. I've got an app I never released that goes through and shows you exactly what's stored by autocomplete - sometimes its not pretty.