Quote of the Week

What people don’t appreciate, when they picture Terminator-style automatons striding triumphantly across a mountain of human skulls, is how hard it is to keep your footing on something as unstable as a mountain of human skulls.

From “What if there was a robot apocalypse? How long would humanity last?“, the 5th in XKCD‘s new “What If?” series of articles answering hypothetical physics-related questions. In this case, rather loosely physics-related.

Thunderbird: The Right Process?

This is the second of my blog posts on Thunderbird; the first explained how I thought that, in the end, the right decision had been reached. This one is about whether we got there the right way.

First, let’s be clear on what is actually happening. This is a reduction of the resources the Mozilla Corporation is putting towards Thunderbird development, based on the assessment by the Mozilla project leadership of the value of Thunderbird to effectively furthering the Mozilla mission.

When analyzing this, the first thing which we need to be clear on is the nature of the relationship between MoCo and the Mozilla project. I have argued before that the right way to think about this is that MoCo is a company which was formed to support a community in achieving the goals of that community. Therefore, the actions of the company should be driven by those agreed goals.

How, then, are these goals decided? They can’t be finally decided by everyone – Mozilla is not a democracy. We do have final decision-makers. Where it gets complex, of course, is that many of the people in the company are key members of the community, and most of the leadership works there. Therefore, the people responsible for making the final decisions about community goals and direction are also some of the people who direct the activities of MoCo. So one can see how easy it might be for the process, from goal setting all the way through to resource allocation, to take place entirely inside the company.

However, even though there are people responsible for making the final decisions on goals and direction, they are community goals. So if there are significant members of a particular community outside the company, it would be wrong for discussions about the future of that community to take place entirely inside it. (It’s arguably wrong even if there aren’t; we should be transparent by default.)

At this point, we run into the problem of the difficulty with having a totally public discussion about sensitive subjects. I’ve covered this recently, twice. There’s nowhere for the Mozilla project to have this kind of conversation in peace. Were a Mozilla leader to start a public discussion with “so, what do we do about the fact that Thunderbird isn’t driving innovation?”, it would be very difficult for that discussion to proceed in a way where the loudness of a voice was approximately proportional to the person’s contribution, and there were no unhelpful “Mozilla considers axing Thunderbird” headlines – the echoes of which can create FUD about a project’s future even if it’s perfectly healthy.

So, then, given that limitation, I would say that the right process would include, at some stage, a private email conversation among core Thunderbird community members, both inside and outside MoCo. If a possible outcome is MoCo investment reduction, it impacts non-employees particularly significantly because they will need to take on extra responsibilities. So all the more reason for them to be in the loop.

So, is that what happened? It’s hard to say. I wouldn’t count myself among the people who should be consulted about MoCo’s resource investment in Thunderbird. If we were considering closing the project entirely, then that would need to be a much wider discussion across the project. But we aren’t. If this private email conversation happened, I wouldn’t expect to know about it.

At this stage, I should say that I want to be trusting by default. I have enormous respect for the top leadership at Mozilla, and I want to assume that they are doing the right thing even if I can’t see it.

However, I am aware of at least one long-time non-employed significant contributor to Thunderbird who heard about this decision when he got the email that was sent to all Mozillians. That seems wrong to me. There are lots of people complaining about not being included in the discussion who I don’t think necessarily should have been; but there are some people out there who should have been and weren’t. And that’s regrettable.

So what happens now?

We need a forum for trusted Mozillians (have I said this before?) where people can propose the controversial and we can have a sensible discussion about it. We need to continue to be vigilant to make sure that MoCo serves the needs of the whole community, not the other way around, no matter how large it gets. We need to try and make sure that future major decisions of this type do include non-employed stakeholders, even if the decision is in one sense only about employee task allocation. We need to make sure that the Mozilla project discusses and sets its goals as a community, together. And we need to do what we can to make sure that Thunderbird has a bright future as a community-driven project.

Thunderbird: The Right Decision?

I plan to write two more blog posts about the Thunderbird announcement. I would have written them earlier, but have been maxed out with other things. Perhaps leaving time for the situation to settle down is good.

This one is: was the right decision reached? The next one will be: was it reached and communicated the right way?

I think the plan is the right one for Thunderbird and for Mozilla.

There is an open question about whether Mozilla wants to have an impact on the messaging market in the same way we had an impact on the browser market and we want to have an impact on the mobile phone OS market. Arguments for: it’s an “open internet” thing, it fits the mission, and it needs doing. Arguments against: any organization, no matter what size, can execute well on only one thing at once, and that slot is taken. However, wherever you stand on that, I think it’s clear that Thunderbird is not the vehicle for any future messaging innovation.

I am a keen Thunderbird user; I’ve been using it since I switched from Netscape Communicator [Update: Neil suggests I may have gone via Mozilla Suite mail first; that’s probably true, although I did stick with Communicator Mail for a long time], and while it has its long-standing minor quirks and annoyances, it’s a solid desktop email client which deals pretty well with the 35,000 messages I receive and the 5,700 I send each year (not including spam or bugmail).

But we’ve been trying to turn Thunderbird into the “messaging Firefox” for years and, as Mitchell has pointed out, it hasn’t worked. I suggest that future innovation in the messaging space is going to be via something that’s ‘of the web’. We are doing an HTML and JS mail client for B2G. That codebase (which will not carry over much from Thunderbird, I am told) should be a much better platform for trying to, for example, free users from proprietary messaging systems.

And if that’s true, then if we have some of our smart people working full time on Thunderbird, then they aren’t working on either other messaging projects, or something else which has a higher direct impact on the success of our mission. In that light, scaling back MoCo investment in Thunderbird makes good sense.

So, then, the plan as outlined seems to me like a good way to enable those who care about Thunderbird’s future to drive it, while making sure Mozilla as an organization can stay focussed. It opens up opportunities for non-paid Mozillians to take more of a role in Thunderbird’s development, which I think is a a great thing, and may pave the way for a similar trend in other Mozilla projects. And it makes sure the current users can continue to use a great product.

Mozilla: An Ethical Career

A couple of months ago, I was asked to write a 250-word summary of my job for a booklet on Ethical Careers to accompany an Oxford University Ethical Careers Day. This is what I wrote:

An ethical career is one which enables you to love God and love your neighbour. The range of careers available which meet those criteria is very wide.

My chosen career is one example. The Internet is one of the greatest drivers of human prosperity and happiness the world has ever seen. The ability to communicate easily across long distances, for business or pleasure, has enabled unimagined trade, friendship and connection. It has empowered many people. However, the free Internet as we know it is under threat – from governments, businesses and organizations who want to control or restrict what information passes. And when control and restriction increases, for whatever reason, opportunity and innovation suffer collateral damage.

That’s why my ethical career choice is to work for Mozilla, an organization which aims to preserve and protect the open Internet as a level playing field where everyone can communicate, contribute and take full part – without having to pay gatekeepers, have a relationship with particular companies, or give up their privacy or security. We are most famous for building Firefox, a web browser which embodies these principles, but we are also moving to counter other threats to openness and consumer choice in the areas of apps, online identity and mobile operating systems. I aim to “love my neighbour” by making sure that the Internet of the present and future (when billions of people not yet online join us there) gives as much opportunity for prosperity as it has in the past.

More Evidence of the Need for a “Trusted Mozillians” Forum

The Internet storm-in-a-teacup surrounding Jono Xia’s post about his frustration with regard to the Firefox update system and UI changes (response from johnath) is another demonstration of why the Mozilla project needs a more-open-than-employees but less-open-than-public forum for people to talk, with entry gated on some form of “trusted” status.

We are a high-profile project, and everything we do is watched. This comes as an inevitable consequence of the fact that we changed the world once, and are lining up to do so again. I would much prefer this to irrelevance! However, in a situation where “public” is the only way a non-employee can communicate with the rest of the community, it has a dampening effect on our ability to converse freely.

Jono is a hard-working contributor and a great guy. He would clearly be one of those with this “trusted” status, were it to exist. And if there was a ‘trusted’ forum, he might well have chosen to express his frustration among his fellow Mozillians without the possibility of it appearing on Forbes, Reddit and HackerNews.

As a Mozillian blessed enough to be paid to work on Mozilla, I see the employees-only communications mechanisms (e.g. our Yammer instance, and the now-mostly-silent Intranet forums). They have been host to posts which are controversial like Jono’s, on other topics. For example, some people questioned our stance on H.264 (which subsequently changed), and the discussion may have included some choice words about the action or inaction of some of our partners. Can you imagine what would have happened if that had taken place in public? But a productive discussion was had, without attendant drama – but also without non-employed community members.

We need a forum for all our trusted contributors to communicate, question, and express their true feelings without their views becoming Internet famous.

Google Groups Fail

Unfortunately, for the last few months, we have not been able to hook up newly-created discussion forums to Google Groups. This means that they don’t have a method of posting over the web and they don’t have a web-based archive. (Existing groups continue to function as normal). This is bug 716007 (although note that that bug started off covering a different syncing issue). mburns writes in another bug:

Essentially, Google Groups’ codebase is at a state that new newsgroups need to manually be added by the (one?) engineer working on it. This is a low-to-not-gonna-happen level priority for them.

The underlying issue was supposed to be resolved in March, with a new rollout of the GG codebase, but wasn’t. I’ve emailed them about the ~17 other newsgroups created since than that have issues, without response.

I am working with Corey Shields, who manages Mozilla’s Systems team, to try and figure out what long-term solutions and short-term mitigations we can put in place to make this less painful. In the mean time, people may want to use or repurpose existing groups for discussions rather than starting another one. (Please don’t go off and create random free mailing lists, at Google, Yahoo or anywhere else – it just makes Mozilla project communication more fragmented and makes it harder for new people to find the group they need.)

(This post may well start a thread about the best way to technically achieve Mozilla’s goals for public discussion. If so, this document will be very relevant; I’m getting my linkage in early :-)

Help Requested: Zimbra and Google Calendar

[Update: This turned up on Planet Mozilla, even though it was only published for a few minutes before being withdrawn, so to prevent 404s, I’m putting it back. But the answer appears to be: other people can see my free/busy information, so the person who reported a problem was probably looking in the wrong place. Zimbra actually works well and how you might expect it to.]

[On the principle of “if there’s no reason for it to be private, it should be public”…]

I use Google Calendar, and I’m very happy with it. The UI is excellent, it supports events starting and ending in different timezones for flights, I can open it in a tab in Thunderbird, and I can share it with my wife and see our calendars overlaid. It’s super. The only thing it lacks is offline support.

However, that means I don’t use Zimbra, the MoCo calendar. And so when people want to schedule meetings with me, they assume I am free all the time :-|.

Can anyone, probably a MoCo employee, tell me how to get Zimbra to give other people my correct free/busy information?

I have managed to import my Google Calendar into Zimbra as an external calendar. When I go to its properties, the checkbox “Exclude this calendar when reporting free/busy times” is unchecked. When I try and arrange a meeting, the Scheduler correctly shows when I am free and when I am busy. And yet, other people who try and arrange meetings involving me tell me that I still look to them like I’m free all the time.

Importantly, I want to solve this without having to share the details of what I am doing when with everyone. I only want to share free/busy information. The “Share Calendar” option looks like it’ll share too much.

Help? :-)

MITM Boxes Reduce Network Security Even More Than They Are Designed To

It was recently discovered by the Tor project that a manufacturer of Man-In-The-Middle boxes with SSL interception capability, called Cyberoam, have been embedding the same root certificate in all of their boxes.

Background: SSL is not supposed to be interceptable. The only way to do it is for the intercepting box to be the endpoint of the SSL session and then, after inspecting the traffic, send the information over a different SSL session to the client. Now that we have explicitly banned trusted CAs from facilitating this after the Trustwave incident, the box should not be able to generate its own trusted-by-default certificate for the target site. Instead, it generates a cert which chains up to the box’s own embedded root. Therefore, any user of a network whose owners wish to use a such a box to inspect SSL traffic will have been asked to import whichever root certificate the box uses into their trusted root store, in order to avoid getting security warnings – the very warnings which would otherwise correctly tell you that your communications are being intercepted.

If each box uses a different root certificate, this is not a big problem. (Well, apart from the general issue of having to permit your employer or school to intercept your secure communications.) However, as noted above, Cyberoam uses the same root for all the boxes they manufacture. This root reuse means that sites who have tried to use Cyberoam boxes to punch a small hole in their security for ostensibly reasonable purposes have actually punched a rather larger one.

If you have trusted this root, your communications could potentially be silently intercepted by anyone who owned a Cyberoam box, not just the legitimate owners of the network you were using. This would be true whether you were on that network, or elsewhere (e.g. if you went to another location with your phone or laptop). Furthermore, anyone who purchases a Cyberoam box can try and extract the root (they may have physical security in place, but that’s just a speedbump) and then they don’t even need a Cyberoam box to MITM you.

From reading their online docs, this problem seems to also occur with similar devices from Sonicwall (PDF; page 2) and Fortigate. (Thanks to a commenter on the Tor blog for noticing this.) I suspect that many vendors use this insecure configuration by default.

The Cyberoam default root certificate is not trusted by the Mozilla root store – Cyberoam is not a CA – and we do not plan to take action at this time. However, this is another important lesson in the unintended consequences of intentionally breaking the Internet’s security model. Messing with the Internet security infrastructure breaks things, in unexpected and risky ways. Don’t do it.

Enumerating Trusted Mozillians

It’s no secret that there is a MoCo-internal meeting, currently held once a month. Gary Kovacs (MoCo CEO) explains it as being a place to discuss things which are not relevant to the wider community, like office configuration. This month, the topic of the Thunderbird leak did come up, and Mitchell said that a) we should try and help the person who did this understand how harmful it was, and b) we need to continue to try and find ways to safely share, to a group wider than “employees”, information which shouldn’t (yet) be made public. For a), see my previous blog post, actually posted just before the meeting. Here are some thoughts on b).

The leaked email was sent to everyone in the Mozilla Community Directory (Phonebook) who is “vouched”. What exact responsibility you are taking on when you vouch for someone isn’t clearly defined (that I can find), but the Contributor Engagement team is very keen that anyone who is a new or even a potential contributor to Mozilla creates a profile there as soon as possible. And if one of the purposes of the Phonebook is to get metrics about the size and interests of the whole community, that makes good sense.

When I designed the predecessor project to the phonebook, Domesday, it had a system of user tags, some of which had to be bestowed on people – you couldn’t award them to yourself. One tag I envisaged was called “trusted” – a group narrower than “having an account and being a community member” but certainly wider than “employee”. There were heated arguments during the design phase about whether such a thing was even necessary.

I think this incident proves that it is. It’s not possible for one “vouched” marking to both serve as “member of the community” and “trusted member of the community”. Phonebook needs to grow the technical ability, and Mozilla needs to grow the social processes, to mark people as trusted, with a mechanism for the person who incorporates them into the trusted community to be known and held accountable for their conduct. And no free passes – start with Mitchell and Brendan as trust roots, and employees need to find someone who will publicly put trust in them, just like everyone else. (The free pass for employees was, IMO, a significant and unnecessary inequality in the Mozillians vouching implementation.)

Trustworthiness is not something that can be programmatically determined, and it is not related to project activity or long service. This is a human problem. We need a mechanism to identify who is trusted and who is not, because only then will we be safely able to distribute stuff that shouldn’t be public wider than “MoCo-only”, and break down the employee/volunteer barrier.

(Some may want to argue that the category of “stuff which shouldn’t be public” shouldn’t exist at all within any part of Mozilla. I think a little thought will reveal that this can’t be so; there are plenty of legal, diplomatic, and partner-related things where publication would damage Mozilla’s interests. Not to mention, on occasion, people’s real opinions of industry developments.)

Not Getting It

I have a lot to say about the recent announcement about Thunderbird. But before I talk about the substance of the proposal, the way it was decided and presented, the framing and all the other aspects, I want to talk about this.

That link is to a pastebin, posted on Friday, of a copy of an email that was circulated to all Mozilla employees and Mozillians about the upcoming changes. It begins:

On Monday Mitchell Baker will be posting on the future of Thunderbird.
We’d like you to be aware of it before it goes public. However, this
is *confidential* until the post is pushed live Monday afternoon PDT.
Please don’t tweet, blog or discuss on public mailing lists before
then.

Clearly, the poster decided not to respect that request. In a personal comment at the bottom, he explains why:

The fact that this message was marked “confidential” is part of a
deeply, deeply troubling trend. The biggest irony? Uninitiated
employees–those being discussed in .governance right now, and who
feel that there’s actually quite a lot at Mozilla that shouldn’t
happen in the public–will point to this incident to try to make their
point, in a tremendous display of Not … Getting It.

Recently, Harvey Anderson, MoCo’s General Counsel (chief lawyer), asked me to put together a document explaining Mozilla’s position on Non-Disclosure Agreements (NDAs). With the rise of B2G, we are increasingly working with partner companies in the mobile space whose backgrounds are very different from ours. Mobile companies can be among the most closed companies you are ever likely to find. And, to some extent, this is OK. They have confidential product plans, feature lists, ship dates and so on, and they want to keep them quiet in a very competitive market. That’s their business, not ours.

However, it means that the first thing they want to do, before they tell you or show you anything, is to get you to sign a broad NDA. This presents a problem for Mozilla. We can sign NDAs – but the only people who are bound by them are the people we employ. That means that any information transmitted under the NDA will have to be restricted to employees only. If that became widespread, it would drive a wedge between employees and the community because only employees would be in the know about what’s going on. We could get all volunteers to sign NDAs with us – but that has a host of problems too. We can try and reduce the scope of the NDA – and we do – but that’s not a complete solution either.

NDAs are a problem. So I wrote this document, which is designed to be given to new partners to explain to them Mozilla’s position on the question. Among other things, it tries to convince them to delay the need to sign an NDA for as long as possible. Here’s an excerpt, from the section titled “Trust”:

Mozilla has a long reputation as a trustworthy partner. We have good relationships and business partnerships with major players such as Google, Microsoft and Twitter. On more than one occasion we have received information without an NDA which other companies can only see under NDA. This is because Mozilla people realise the importance to our partners and to our reputation of keeping appropriate confidentiality.

So we try and use this accumulated trust and good reputation to postpone or eliminate the point where an NDA becomes necessary in a relationship, relying instead on verbal agreements and making sure that involved community members are clear on any confidentiality assurances we have given.

In other words: “please don’t make us sign an NDA. You can trust us to keep our mouths shut about your private stuff.”

Can you imagine how I now feel, having written those words only a few weeks ago? I thought what I wrote was true, and that I could be proud of our community’s reputation for discretion. Seems like I was wrong. If we can’t keep our own private stuff private, how on earth is anyone ever going to believe we can keep theirs?

Note that this point is entirely independent of whether Mozilla needs to be more open, and whether the Thunderbird change-of-direction should have been handled in a different way. I may well write more about that later. I continually push for more openness at Mozilla – to the point where I’m sure at least a few MoCo people think I’m a pain in the arse on the subject. My work on NDAs is an example of me trying to prevent project openness dying the death of a thousand small cuts. No-one can accuse me of being part of the group who thinks “there’s actually quite a lot at Mozilla that shouldn’t happen in the public”. I’m an advocate of open-by-default. I’ve done presentations which have a slide “If there’s no reason for it to be private, it should be public.”

And this really does not help.

I really hope this leak is a one-off, isolated exception. Because if Mozilla’s open development of B2G (our attempt to open up the mobile market) gets closed up by us having to sign broad NDAs with all our partners, because none of them trust us any more with their confidential information, then I would suggest that it’s the person who thinks breaking a requested confidence is a great way to make the project more open who is Not … Getting It.

Another Victory: More Germans Protected

Regular readers of this blog may remember some of my chronicles, under the name “Protecting Germans”, of the efforts of our German legal team to deal with “subscription trap” websites, which are particularly a problem in that country. Such sites try and trap you into signing up for a subscription to get software which is available for free download elsewhere. Firefox is regularly abused as one of the popular software programs whose ‘availability’ prompts users to register on such websites.

Now, I am pleased to be able to tell you that a couple of months ago, in the Hamburg criminal court, sentence was passed on 7 operators of such fraudulent download websites, handing down sentences of 3 years and 9 months for the ringleader, and shorter sentences and fines for the other accused. This is the first ever criminal trial against the operators of subscription trap sites, and the judgment has been eagerly awaited by the public prosecutors in other German cities, who are building cases against other people involved in such schemes.

It is important to note that the court partly founded its judgement on the infringement of Mozilla’s trademarks. The main focus of the proceedings from the outset was on criminal fraud (vis-à-vis the consumers) and the trademark infringement claims were only given their due attention and relevance as a result of our supportive work. (Mozilla participated in the proceedings as one of the harmed rights-owners.)

Furthermore, the main proof which persuaded the court of the defendants’ intention to infringe Mozilla’s trademarks was their knowledge of the civil injunctions we had obtained as early as 2007 and 2009 against two of their websites.

We therefore feel that our support and participation in the proceedings was truly significant and worthwhile. The German press has been applauding the decision, which will hopefully set a precedent for other criminal proceedings against online fraudsters.

I personally feel that this is a vindication of our policy of maintaining and defending the Mozilla trademarks, and especially the Firefox trademark.

You can also read the official Mozilla blog post about this.

Suspect Syndication

Sometimes you discover the weirdest things about the Internet via unsuspected routes.

My post about Facebook and email addresses got a lot of pingbacks from around the world. Often, they were syndications, perhaps of dubious legality, of earlier articles. In several cases, the legality was clearly dubious, because the syndicator had gone to some effort to disguise the text. There were four like this one, where, fascinatingly, the text appears to have been run through a system which uses synonyms and other changes to make it not recognisable from a simple web search. Compare the original, from CNN Money (and also my blog, which they are quoting):

Blogger Gervase Markham, one of the first to draw attention to the change, was scathing in his comments on it.

“Facebook silently inserted themselves into the path of formerly-direct unencrypted communications from people who want to email me. In other contexts, this is known as a Man In The Middle (MITM) attack,” he wrote, referring to a tactic hackers use to intercept electronic messages. “What on earth do they think they are playing at?”

with this barely-understandable version:

Blogger Gervase Markham, one of a initial to pull courtesy to a change, was sardonic in his comments upon it.

“Facebook silently extrinsic themselves in to a trail of formerly-direct unencrypted communications from people who wish to email me. In alternative contexts, this is well known as a Man In The Middle (MITM) attack,” he wrote, referring to a tactic hackers make make make make make use of of of of of to prevent electronic messages. “What upon earth do they consider they have been personification at?”

Some of the changes don’t even seem like synonyms – “attention” -> “courtesy”? Note also the words repeated 5 times – looks like they replace “use” with “make use of”, but have run the algorithm over the text more than once!

Here’s another one, which makes heavy use of entities, replacing letters with lookalikes from Cyrillic or simply HTML entities:

Th&#1077 exchange, first uncovered b&#1091 hacker Gervase Markham, means th&#1072t &#1072n&#1091 email post you received through Facebook since Friday h&#1072&#957&#1077 been routed back into the Facebook Post inbox, rather th&#1072n into your email inbox. Annoying? I don’t know. something to &#609&#1077t really angry about? I don’t know — maybe you w&#1077r&#1077 expecting &#1109&#959m&#1077 vastly time sensitive email to come through Facebook. but f&#959r the m&#959&#1109t &#1088&#1072rt, w&#1077’d estimate th&#1072t public are more shocked th&#1072t th&#1077&#1091 h&#1072&#957&#1077 &#1072n @facebook email take up th&#1072n the fact th&#1072t Facebook pulled a switcharoo.

Does that look normal? Here’s the source:

Th&#1077 exchange, first uncovered b&#1091 hacker Gervase Markham, means th&#1072t &#1072n&#1091 email post you received through Facebook since Friday h&#1072&#957&#1077 been routed back into the Facebook Post inbox, rather th&#1072n into your email inbox. Annoying? I don’t know. something to &#609&#1077t really angry about? I don’t know — maybe you w&#1077r&#1077 expecting &#1109&#959m&#1077 vastly time sensitive email to come through Facebook. but f&#959r the m&#959&#1109t &#1088&#1072rt, w&#1077’d estimate th&#1072t public are more shocked th&#1072t th&#1077&#1091 h&#1072&#957&#1077 &#1072n @facebook email take up th&#1072n the fact th&#1072t Facebook pulled a switcharoo.

Can I Get A Witness?

The developer who started the Witness web app has had to bow out of the project. Are there any other Djangonauts/Pythonistas out there who would like to finish the building of something relatively small, self-contained and useful to Mozilla? Here’s a description of the project:

“Witness” will be a web app which provides proof that person A has agreed to legal document X.

There are loads of applications for this:

  • Proof that a Mozilla contributor has agreed to our Committer’s Agreement
  • Proof that someone has agreed to the IPR policy necessary for contributing to a standards body mailing list
  • Proof that someone has agreed to a trademark licence

These things can be done without an app, but it’s dull and tedious for the person doing the paperwork. Much better to get a computer to do it.

It would involve, among other things, playing with Persona/BrowserID. If you are interested, drop me a line and I’ll point you at the code.

How To Make A Decent Password Strength Meter?

This discussion came up in mozilla.dev.identity – how do you make a decent password strength meter? Now it could be that someone’s already done this (links?), but I’ve never been embarrassed about reinventing the wheel, so here are my thoughts.

IMO, most password strength indicators suck. They give a fixed bonus for adding punctuation or numbers or upper-case letters, and you can’t have a strong password until you have several of those categories. Therefore, to take random examples, a lot of them think “correct horse battery staple” is a worse password than “Tr0ub4dor&3”.

Inspired by xkcd, here’s a straw-man proposal for a Unicode password strength meter which avoids some of the obvious flaws, while still not being overly-complex to implement. Note that this is about strength (resistance to brute force attacks), not about memorability or anything else.

  1. Classify every code point by its Unicode script. (The data needed for this is not large, as most scripts are in contiguous ranges.)
  2. For each script used, take the number of commonly-used characters (this would be a predefined lookup table), and add the values together to make an “entropy” value, which is a rough proxy for the size of the character space from which the password’s characters were taken. So e.g. an Arabic numeral is 10, an unaccented Latin letter is 26, an uppercase Latin letter is 26, a Chinese character would be about 20,000.
  3. Multiply the entropy by the password length in characters.
  4. Make sure it’s over a certain threshold, which can vary depending on the application. You might use 300 for web forum membership login, and 1000 for a bank. One could develop recommendations.

e.g.

“Tr0ub4dor&3”:

  26 (lower-case Latin letter)
+ 26 (upper-case Latin letter)
+ 10 (Arabic numeral)
+ 15 (simple punctuation)
= 77

77 * 11 = 847

“correct horse battery staple”:

  26 (lower-case Latin letter)
+ 15 (simple punctuation)
= 41

41 * 28 = 1148

Now, the flaw of this proposal is that the measure assumes all the password characters are independently chosen. Perhaps the way to solve that is to add or multiply a bonus for “script transitions” – letters to punctuation, one alphabet to another alphabet, etc. Because words, the most common case where successive characters are not independent of each other, are most often all one script.

“Tr0ub4dor&3” has 7 such transitions, “correct horse battery staple” has 6. But “intelligentsia”, while being long, has none.

Thoughts?