Firefox needs to rethink its password manager

Firefox is my browser of choice.  Primarily because of the wide range of useful extensions available with make it very useful to me.  In particular, Google Browser Sync and FireBug are extremely useful to me.  Like many browsers, Firefox comes with a password manager.  I don't know the details for other browsers, but Firefox's implementation is a security risk, a privacy risk, and unhelpful.

The Password Manager isn't handy

It's unhelpful, because it when you enter a new password, it prompt you whether you wish to save that set of credentials, giving you three options: Yes, No, and Never for this Site.  I understand the first two options - you want confirmation before you store the credentials.  The last option is odd though.  I'm sure there are sites I never want to store credentials for, but usually, there are sites that I never want to store a particular username/password combo for.  Why?  Because it frequently occurs that I use another's browser (to show them this hip new web-page somebody gmailed me a link to), or vice-versa: that somebody else uses my firefox to log in temporarily.

Lately, we're seeing increased development and use web-apps, whose two prime benefits are ease of installation (namely none) and ease of access (namely anywhere).  A browser would do well to make those two benefits really easy to achieve.  In order to access one or more web-apps in a browser, you need to log in.  That's obvious: you can't just have anyone using your private email after all.  However, with ease of access being such a key benefit, it's ridiculous that using multiple accounts on one machine is so difficult.  A guest should be able to securely use his email without logging out his host's email.  By securely, I basically mean secure vs. XSS scripting.  Clearly, if someone else is using your machine, you'll have to trust that person.

The problem with firefox's dialog is that it'll constantly appear for all guests that don't wish their credentials to be saved.  Worse yet, if such a guest accidentally clicks on "Never" then even the host can no longer use the password manager.  Since you're likely to have the same guests over and over again, this is annoying.  You have two friends over, and they'll log you out (annoying) and stay logged in themselves (annoying) and potentially accidentally save their password (unwise, but I've seen this happen many times), or disable the password manager on that site (annoying).

The password manager tries to make logging in less of a hassle, but since most sites now allow long term cookies, it's really not that useful anymore, and it does bring up a distracting popup which takes thought to click away, lest you click on an option you don't want to.

The Password Manager is a privacy risk

The problem gets worse if you have a firefox profile shared between multiple machines:  I use Google browser sync to do so, but there are other methods too.  One of my co-web-dev's was busy discussing some bugs in the latest version and used his credentials to log on to the intranet app.  Accidentally, he clicked to have his password saved, and now I just read his clear-text password on my home machine.  Any guest using my machine could have looked at that password, at that should never have been possible.

Unfortunately, there are more risks like that.  In a bugzilla report more reminiscent of a soap-opera than a bug report, A woman describes how she discovered dating sites in her fiancee's profile (because of an installation issue, these dating sites were also in her own profile, making the matter worse).  She didn't find incriminating evidence in his bookmarks or history.  Nor did she find saved passwords to any of these sites.  What she did find, were sites which were set to "Never Save".

Firefox does not take the privacy of it's users seriously enough.  An option which seems to  be intended to avoid security or privacy issues should not leave that kind of trivially visible trace.  Furthermore, firefox cannot be fully uninstalled (without manually deleting deleting hidden directories in your home directory).  At the very least, firefox should be cognizant of the privacy issues surrounding these left-over profiles, especially as the application itself is so uncareful with the users secrets.

The Password Manager is a security risk

Unfortunately, the password manager doesn't just expose your private information to friends and family using your machine, it allows malicious internet content to steal your password too.  A malicious page can read a password using the DOM once it's been entered - and the password manager enters your password for you.  With a little creativity, phishers can create a login page to fool firefox into supplying the users credentials, and hide it from view while it's being harvested for that information.  And that's exactly what happened recently, when MySpace accounts were compromised by phishers.

The Password Manager needs to go

As a result of all these issues, I've disabled the password manager, after clearing of it's content (and it's while clearing it that I discovered my coworker's password).  In its current form, the tool is a security, privacy and usability issue that is in dire need of resolving.

What could Mozilla do to fix these issues?

• Firefox should store usernames and passwords not under the name of the website for which they work, but under a secure hash of that website's name.  This means it's impossible to see for which websites you have a password stored.
• Firefox should not just use the website's name to identify a login field, but include a select bit of context of the login page to make phishing attempts more difficult.  That bit of context could include some of the headers of the webserver, any certificate it is using, and some bits of html surrounding the submit form.  It's better that the user need to log in again when a website is redesigned than that a phisher gets easy access to your private details.
• Firefox should not make passwords accessible via the DOM, and certainly not passwords which are auto-completed.   This also means that if a script changes the target of the form, any auto-completed passwords need to be re-evaluated.
• Firefox should not store usernames and passwords in clear text, but encrypted with a key: that key should be derived from a different secure hash than that under which it is stored.  In this way, an attacker can not determine a standard password which the user frequently uses easily.  A master password should be also be an option.
• Firefox might consider a means of obscuring or removing sites from a users history if they have stored passwords for that site.  This would make attacks more difficult, but the history (which I rarely see used anyway) less useful.
• Firefox should take a good look at user interaction with the password manager and rethink it's UI, its available choices, and the default settings to support real-world usage.  A good starting point would be other browsers, and specifically opera, which I occasionally use and has an obviously better design.  Firefox should also consider web-apps and the future goals of firefox as a platform, which might lead to changes about the way windows and tabs share cookies (i.e. sessions) so that multiple users can use firefox.

I'm not sure users can do much of anything beyond disabling the password manager (not a bad choice in my opinion) and being aware of the risks.

Webmasters can use the attribute autocomplete="off" on the form tag or the input tag to suppress the password manager for an entire form or just that field.  However, users can force firefox to disregard the autocomplete="off" tag, and some do because of the perceived annoyance.  This attribute isn't part of the HTML spec, but is supported by Mozilla- and IE-based browsers.

Firefox really needs to rethink it's password manager.

Automatic Properties in C# 3.0 - sweet!

In programming languages size matters - and smaller is better.  Automatic properties will certainly reduce boilerplate code, and I wish they were even shorter; but it's better than nothing.  An example:

string Name {get; set;}

If you follow common practice and don't declare instance fields public, the only way to achieve such functionality is by writing out a field declaration and a property with explicit getter and setter which return that field and set it, respectively.  There are boilerplate code generating plugins for Visual Studio which reduce the tedium somewhat and even visual studio has some functionality for making a property based on a field.  Code-generation approaches like that don't appeal to me however, as they only solve the writing part of the problem - and since you and others are liable to need to read that code, it's nice to have a concise, clear syntax.

Of course, in many projects you can just ignore common practice and declare instance fields public and get the same effect, but you might run into issues with reflection based API's, to which fields and properties are fundamentally different.

Why Maximum Path Lengths are a Bad Idea

All file systems have a maximum path length which is limited - that's not particularly surprising, as computers are quite finite.  However, the problem is that path lengths have an arbitrary length limit which in no way scales with the computer involved.  In windows' case, it's an especially short one - 260 characters - at that.  Coding Horror doesn't seem to think that's a problem.  His argues that humans dealing with a hierarchy that deep can't really deal with it at all, and you can't remove those human limitations, so why bother removing the technical ones?  And anyway's, it's not such a big deal, you should just choose shorter paths!

That argument just doesn't hold water, unfortunately.  People can deal with huge hierarchies without great difficulty, and the technical issues are more nasty that they look at first sight.

Why can people deal with huge hierarchies?  Because you only tend to only ever look at a very small part of it at the same time.  Explaining the concept of a galaxy will faze people initially, while they try - and fail - to relate that concept to themselves.  But eventually, you stop doing that and it's just this big swirling mass of stars.  No problem there.  Oh yeah, stars, well, they're often the center of a solar system with some planets swirling around them.  And planets are just lumps of rock (or other stuff).  Some planets contain landmasses and water, and on those land masses you might find mountain ranges, rivers, cities, people - and yourself.

Hierarchies aren't the problem, but situations in which you need to deal with the whole thing simultaneously are.  displaying a large part of the hierarchy in the way a file system does is difficult.  And strict tree structures are unnecessarily limiting.  There's definitely room for improvement - but reducing the depth of hierarchy in a file system doesn't solve the problem, it makes it worse, because all of the sudden you actually need to be aware of the root of the file system while dealing with a leaf.

When I take a look at somebody's project, I want to be able to do so without needing to think about how long the path might be.  A common scenario for me is to dump things related in some sub-directory - some place I won't see it unless I'm actually viewing the project itself.  Of course, that sub-directory can contain sub-directories etc etc, and it's not a problem since I never stop to think about it, and hard-drives are huge anyway.  It's common for back-ups of file systems of old computers to end up somewhere in there  (Think, "Documents" > "Work related" > "old job" > "backup of old work PC").  I like to keep these things just in case, as long as it doesn't cost much effort.  Backups of PC's however can easily exceed maximum path lengths and that means, I need to start bothering again.  It's a hassle.

The problem with maximum path lengths doesn't occur when you're able to plan everything out in advance.  It occurs when you combine two existing hierarchies into one.  Maximum path lengths turn the file system into a leaky abstraction.

Basically, any time you move or copy a directory you're potentially in trouble.  And that's simply not acceptable.

The technical nastiness this causes isn't funny either.  For example, using only the normal Win32 API its trivial to make paths that are longer than 260 characters, and probably longer than 32k as well.  You just need to move a directory containing a long path somewhere into a deeper spot of the directory hierarchy.  Moving on the same file system is almost instantaneous because you're just updating a few references.  You don't need to actually touch all the contents of the moved directory.  But that means there's no way to even know that a file path exceeded the maximum!  And so windows will happily let any user create a directory structure which is impossible to delete - even by an administrator or a virus scanner - without first moving all the directories out of their nested structure.

And that's a big security leak.

Windows should evolve a new API without an overt maximum path length, because the current situation causes many many nasty corner cases which rarely occur, but currently have no satisfactory solution.

GWC: The Missing LINQ

I'm going to give a talk about LINQ this Friday.  I'm quite hyped on LINQ:  I know it shouldn't feel like it's the next best thing since sliced bread... but... well...  I haven't prepared the talk yet, but I want to give a strait, to-the-point example of a program which leverages linq successfully, and not talk too much about difficult concepts like the abstract ideas behind LINQ.  Know of any simple samples?

LINQ looks rather revolutionary from java-esque perspective.  Queries with all kinds of nested phrases, lazy evaluation, query translation for real DBMS's, query execution over in memory data, and more!  What's revolutionary isn't the features themselves though, but their embedding in a mainstream language - and by the looks of it, this will be an embedding eminently useable without intimate knowledge of its inner workings.  LINQ, first and foremost, is practical.

The roots of LINQ can clearly be found in functional languages such as LISP and Haskell.  Interpreting a syntactic expression - such as a LINQ query - as data which can be used to generate useful behavior in for instance a database, but might equally be interpreted as code to execute is something LISP macros are well known for.

LINQ does not transform C# into a functional language however:  Key functional language abstractions are missing or broken, and you'll find frustrating roadblocks, or unhandy syntax if you try to implement an entire program in functional style.  The missing expressive power isn't merely a disadvantage though as it makes difficult concepts such as monads unnecessary.  That kind of functionality is more easily implemented in C# as-is anyhow.

So what is LINQ?

LINQ takes an extremely important area - query - in which functional and declarative languages used to provide clearly better programming experience, and aims to simplify it by co-opting a bare minimum of functional features, wrapping those in delicious syntax sugar, and serving it warm :-).

At least, that's my view.

The Eternal Sunshine of the Spotful Sun?

Global Warming is a highly politicized issue, fleshed out with appropriately terrifying horror-stories. Save the world! Think of the children! Right... Anyway's, it's almost impossible to form an informed decision based on the cacophony of voices around. And what is there really to decide?
It's clear that:

• Temperatures seem to have risen over the past few decades (image taken from wikipedia)
• Looking back a little farther, things get cloudy. It's not clear exactly how much variability there has been.  It previously looked like the last centuries temperatures had been skyrocketing, but not everyone agrees, however. The oft-shown (just because it's so easy to understand) "hockey-stick" temperature record of the last millennium appears to be flawed - so where are we at then?
• CO2 isn't the whole story, not by a long shot. The current focus on CO2 makes sense from a policy perspective (it's a factor we can effect, as it's easy to measure), but there are many other factors involved.   For example, Solar activity, related to sunspots, might be involved.

As "The Power of Nightmares" points out however, many politicians have a motivation to portray impending doom which, it so happens, their vision can save us from. The media's coverage is biased too, since horror stories also sell so well: a healthy dose of skepticism is clearly recommended.

The British government's Stern Review is one such fear-mongering article. Bjorn Lomborg doesn't buy it, and neither does Christopher Monckton, the author of Climate Chaos? Don't Believe It,  in which he disputes the review's findings.  Then again RealClimate thinks Mr. Monckton doesn't have a clue. Lindzen is a frequently cited respectable skeptic, and here is one of his (older) articles, an op-ed in the WSJ, which also is skeptical of the need to fear global warming.

So what can we actually say? A point many people focus on is that this warming is man-made. In my opinion that simply isn't relevant. Nobody is disputing (right?) that the earth is warmer now than a century ago. Whether or not the next ice-age, or next green-house episode is caused by man or not, will not in any way make a difference to the problems it will cause. The real question shouldn't be whether we are causing global warming, but whether we can cost-effectively, and thus usefully prevent it. 

That's a distinction that's not made clearly enough.  The Stern Review speaks of 5-20% of GDP lost to global warming if we fail to act (and those numbers are probably exaggerated), and claims "Costs of mitigation of around 1% of GDP are small relative to the costs and risks of climate change that will be avoided." and merrily progresses with more analysis about CO2 levels (which again, aren't the whole picture) and sustainability.  Do they expect global warming to simply cease when CO2 levels are capped at a level higher than todays?  There are numerous other factors at play here, so this simple trade-off doesn't seem realistic to me.  We may not be able to avoid climate change no matter what we do; accounting as if the risks can be completely avoided by our actions isn't realistic.

The world has certainly been through a lot more extreme climate situations - maybe even much more extreme - so it might be be useful to consider artificical means of climate modification.  Even crazy ideas like space sunshades deserve a little attention.  We should be focussing not on CO2 as a reason in and of itself, but only in the greater context of manipulating the global climate.

Fear! Cheap Fear for Sale...!

This post by Madduck reminded me again of the BBC Documentary "The Power of Nightmares" which I immensely enjoyed. "The Power of Nightmares", by Adam Curtis, portrays the world as the now-familiar place in which the battle for belief is waged using terror. However, in an insightful (and ironic) twist, Adam contends that it is western politicians fanning the flames of this fear in their struggle to remain ideologically relevant. The whatever generation doesn't buy into the upbeat idealism of the past, but fear of a great external evil is an ideology which sells. Conversely, the islamic fundamentalists aren't trying to frighten the west, but rather other muslims to save them from the moral perversions of the west.

As with any political documentary, take it with a grain of salt... but it's really well done. It must be, imdb says so :-). Seriously though, this is an absolutely brilliant, must-see documentary for anyone remotely interested in politics. There's an interview with Adam Curtis on the BBC site, which states that they're trying to clear various copyright issues to be able to release it as a normal non-broadcast only movie. In the meantime, google video is your friend...

Educational software lock-in

I'm a student at an institution which uses educational software provided by Blackboard. Blackboard is very successful eLearning system which is widely used. Of course, it's also a web-app, and it suffers from many of the typical web-app failures: it's slow, insecure, integrates badly into the operating system and provides a generally poor user interface. One of my pet peeves is the unbelievable number of clicks I require to achieve simple things like getting a course overview, or managing assignments which need to be handed in or retrieved. Web applications can be frustrating.

It's very hard to judge how heavily Blackboard is to blame these failures, and how heavily other factors (it's a web-app, and a university is administering it...) weigh. From the point of view of a computer science student, it's frustrating that such a seemingly simple purpose - I use it as a glorified message board - is bogged down by so many features with so many resultant bugs, and so many resultant performance issues. It doesn't make things any simpler either.

I also work for the university writing webapps, so I often get the inside story from fellow developers, specifically two roommates which try to implement work-arounds and generally improve blackboard's embedding into the RuG. That's pretty much required because of the many problems blackboard suffers. I sometimes wish we could just dump blackboard and choose something else:

There's got to be something else out there that's better than this, right?

Of course, it's not so easy - by now, so much work has been done customizing blackboard to our situation, and so many teachers and students have finally begun to understand this particular piece of software, that we really can't make the switch easily at all. It's as Coding Horror says: "Once you've performed extensive software customizations, extracting yourself from that software becomes nearly impossible." As if this weren't bad enough, blackboard has confusing patents, and is willing to (ab?)use them to stifle competition. There have been many sites which try to illustrate how meaningless blackboard's patent is, but the award goes to Blackboard itself: FAQ on Understanding the Blackboard Patent. It's completely meaningless! I have my doubts "How do you read a patent?" qualifies as a frequently asked question, but fortunately, blackboard also includes such helpful sections as:

Is Blackboard suggesting that all course management systems are covered by the Blackboard patent?
Absolutely not. Blackboard is not claiming to have invented or to have received a patent on all e-Learning or on all course management systems ever created. Blackboard didn't invent just any course management system, but the system claimed in the patent, which has achieved great commercial success. Another common misperception is that Blackboard is claiming to have invented or has claims over a broad range of standard e-learning tools standing alone, like discussion boards and chat rooms, which is also not the case.

Oh, OK, that's fine then, the patent only covers the specific systems which it claims to cover. Gee, happy we cleared that up. If you're so inclined, you can read the patent application itself. Claim 1 is short and easy to understand - once you've worked your way through the convoluted grammar anyways. It's simply taking a well-known authorization scheme (users with roles) and applying that to a specific case (courses, students, instructors, administrators etc).

The whole patent issue is bad, their software is not of high quality (though it does have many features), but neither would pose a problem if you could switch.

Lock-in is evil.