December 2010 Archives

Firefox 4 is getting really close. Help us finished it faster by using the latest betas and giving feedback.

Get the Firefox 4 beta for desktop here and for mobile by searching the Android Marketplace for "firefox web browser".

In a previous post I raised the issue of browser integration and called out specific vendors for "evil" approaches to integrating their software with Firefox. That resulted in quite a bit of discussion and some consensus that there is no one right way for software vendors to integrate with Web browsers. The discussion also made it clear to me that a problem for users and vendors alike is that we don't have clear standards or even a good handle on what are the best practices for how software vendors approach browser integration.

If there exists some agreement on best practices that just hasn't been codified, or if we can get there through continued debate, I think then maybe we have a shot at actually convincing many vendors to improve the experience for everyone. This post is me trying to give that discussion a better starting point than what I'd offered in my earlier rant.

I've started off by writing up a set of high-level guidelines that might be able to stand on their own, or could serve as a foundation for a more tightly defined prescription. I'd like to hear from you all if you think these are reasonable or not, and if you have changes or additions you'd make.

1. Software vendors should take more care and be more conservative in what they do to alter or integrate with other programs than what they do inside of their own programs. Within their own apps, a vendor should feel free to experiment and innovate, to change up how features work and to occasionally even baffle users with radically new and potentially better ways of getting things done. But when making changes to how other programs work, how the larger computer system works, or when introducing novel forms of integration with other programs or the system as a whole, software vendors should tread much more carefully and should take care to avoid user surprise and bafflement.

2. Software vendors should thoughtfully consider the range of options for altering or integrating with other apps and the computer system as a whole and choose the least surprising method. This includes both the integration technology choices (whether it's traditional browser plug-ins, Web content and browser UI extensions, protocol handlers, etc.) as well as the user consent mechanisms (from the currently over-used "just do it automatically" to "opt-out" to "opt-in" models.) When in doubt vendors should bias towards the more familiar and more conservative approaches of integration.

3. The further the third-party integration is from accomplishing the advertised purpose of the product doing the install, the more conservative should be the mechanism for adding that integration, if it's added at all. Products and services that have little or no connection to the application that delivered them into the browser should require a higher level of user engagement and agreement than products and services which are well understood parts of the app that delivered them.

As I said, those are kind of high-level but I hope they're a good start.

Are there other guidelines you'd add here? Are the ones I've provided clearly wrong on some accounts or for some common cases already in the wild? Would adopting these principles or variations of them lead to a world that's worse than what we have today for vendors or users? Would love your thoughts.

The incomparable David Eaves has a pretty amazing blog post that uses Test Pilot data from about 25K users to build visualizations on plug-in memory usage. I love his suggestion of showing users this data at the Plugin Check page. I think we should also see about just adding this to Firefox itself, maybe in about:plugins.

It's pretty amazing to me that just running a few plug-ins, say Google Updater, Adobe Reader, and DivX Player can chew up half a gigabyte of RAM or more. What's especially lame is that a plug-in like Google Update doesn't even enhance the Firefox experience in any meaningful way. It's simply wasting 100+ MB of RAM every time you run Firefox. At least plug-ins like Flash and Adobe Reader let you access to useful content.

This is another reason why sneaking plug-ins into a user's browser isn't cool.

The tech press doesn't (often) get the kinds of lurid violence and gore to cover that the evening news does, so they usually chase the next best thing, controversy. And when they can't find controversy, they'll sometimes just make it up.

Such was the case of the mostly bullshit Wall Street Journal article Hiding Online Footprints:
Makers of Firefox Browser Explore Do-Not-Track Tool After Scrapping Earlier Effort which purports to reveal to the reader how Mozilla abandoned an important user privacy feature after secret meetings with the advertising industry.

That article is wrong. The WSJ got it about as wrong as it was possible to get. And weeks later, they published a little note at the end of the article saying they made a small mistake.

Here's what seems to have happened.

The author of this WSJ article, Julie Angwin, Wall Street Journal published a fabricated timeline where Mozilla designs and builds a "do not track" feature, the advertising industry learns about this, Mozilla meets with representatives from the advertising industry, and immediately after that meeting Mozilla scraps the feature.

That's the foundation for the entire article. Mozilla caves to advertising industry pressure and sells out its users.

There's only one problem here. The timeline is bullshit -- a complete fabrication designed to smear Mozilla and generate controversy and pageviews.

The real timeline was this: Mozilla engineers prototyped the feature and put it into testing. Mozilla engineers discussed what kind of impact it might have on the Web and concluded that not only would it not be very effective and have some undesirable side effects, but that it could drive advertisers to build worse experiences where users had even less privacy and control. So Mozilla scrapped the feature and started work on designing a better feature. Later, some advertising reps met with Mozilla to let Mozilla know what they were up to on the privacy front and to talk with Mozilla about what it was up to.

That's the story -- or non-story.

The Wall Street Journal knew knew or should have known this and still they published an entire article that was based on a lie. That article got picked up and the lie propagated around the Web. Two weeks later, the WSJ publishes a small note at the end of the article saying they made a minor mistake in the timeline.

That's not a minor mistake, Julie Angwin! That's the basis for your whole story!

How about a complete retraction? How about an apology for smearing Mozilla's good name?

WTF?

The real shame here is this is an important topic that absolutely needs to be elevated above this kind of muckraking and the WSJ is just the kind of organization that could, if they wanted to, do that. Unfortunately, the "journalists" writing this story opted for sensationalism and controversy over education and public service.

Had they taken the time to learn what Mozilla's really about, instead of manufacturing a controversy, they would have known that Mozilla is a public benefit organization that never has and never will put advertisers above the needs of the global Web using public. But that story's already been written and probably wouldn't generate many ad-dollars for the Wall Street Journal.

update: After re-reading this a few times, I've decided that it was wrong to personally call out Julia Angwin like that. (and to get her name wrong while doing it). I'm not going to delete those parts of the post but I am sorry that I didn't use more restraint. This isn't about any one reporter and I shouldn't have made it so personal.

Over the weekend, Gawker Media, home of sites like Engadget Gizmodo and LifeHacker, had its entire user credential database stolen and published to the Web. I had an account with LifeHacker for commenting there and while I didn't use that password at any other sites, I did use that login name, my email address, for quite a few other accounts. This isn't a post about how Gawker handled the situation (poorly, IMO) but rather a post about how LinkedIn handled the Gawker problem.

Because lots of people, myself included, share the same login name -- often an email address, across websites, and some people re-use passwords, LinkedIn took the precaution to temporarily disable the accounts of all LinkedIn users that had used the same login name from the disclosed Gawker list. They notified all of those users, myself included, that their accounts had been disabled and that they would need to take steps to re-enable them.

And here's where it gets awesome. LinkedIn is surely the target of myriad phishing scams, emails sent to their users claiming to be from LinkedIn but actually from bad guys trying to steal user credentials. So how did LinkedIn alert me without appearing to be a phishing scam. Here's how.

Dear Asa Dotzler,

In order to ensure that you continue to have the best experience using LinkedIn, we are constantly monitoring our site to make sure your account information is safe.

We have recently disabled your account for security reasons. To reset your password, follow these quick steps:

Go to the LinkedIn website
Click on "Sign In"
Click on "Forgot Password?" and follow the directions on the website

Thank you,
The LinkedIn Team

See what they did there? Or rather, what they didn't? They didn't provide any links. They didn't solicit any visits to special sites. They didn't ask me to put any trust into this email.

Email is just not trustworthy and so telling users to find their own way to LinkedIn and to go through a normal LinkedIn login process is absolutely the best way to handle this kind of request.

Kudos, LinkedIn. Thanks for making this safe and easy.

After reading and responding to many comments over here and elsewhere, I've been persuaded that my plug-in rant oversimplified some, that it was too "black and white" and didn't account for several legitimate approaches to browser integration.

(Note: I'm not going to discuss what Firefox should or shouldn't be doing about unrequested or unwanted integrations. My concern here is not how users defend themselves against those software installs. My concern is what is and isn't appropriate behavior on the part of the software making those installs. For the record, I support Firefox taking measures to alert users to changes made to Firefox by third party software. We do some of that today and we'll do more of that soon. If you want to talk about what Firefox should be doing with third-party installs, please take that to one of the other posts. Thanks.)

In my previous posts, I harped on "ask first" as the correct way for third parties to integrate features into Firefox. I was overly-focused on a few specific examples where I really do believe that "ask first" is the right answer, but "ask first" probably isn't the only legitimate approach and may even be the wrong approach in some cases. For example, when I downloaded and installed a software package called Adobe Flash Player, I clearly wanted the feature added to my Web browser. That's only way that the Flash Player works and that's the specific reason I installed it. Asking permission to integrate with the browser in a case like that is at best unnecessary and at worst potentially confusing to users.

If it isn't black-and-white-always-ask-first, if there is no one-size-fits-all approach to browser integration, then the question becomes: what are the range of acceptable practices and when to use which approach.

I've scoured the Web for a couple of weeks looking for any existing guidelines or best practice documents on this subject and while there are plenty of technical howtos for integrating third party software with Web browsers, I don't see anything covering the actual user experience of integration or offering guidelines to software vendors around what's appropriate and what's not.

Since that seems to be missing from the Web, I thought I'd take a stab at it. Stay tuned for follow-up posts where I offer my take on how vendors ought to behave when it comes to integrating their software with Web browsers.