Convenient… and Creepy

The last Mozilla All-Hands was at one of the hotels in the Walt Disney World Resort in Florida. Every attendee was issued with one of these (although their use was optional):

It’s called a “Magic Band”. You register it online and connect it to your Disney account, and then it can be used for park entry, entry to pre-booked rides so you don’t have to queue (called “FastPass+”), payment, picking up photos, as your room key, and all sorts of other convenient features. Note that it has no UI whatsoever – no lights, no buttons. Not even a battery compartment. (It does contain a battery, but it’s not replaceable.) These are specific design decisions – the aim is for ultra-simple convenience.

One of the talks we had at the All Hands was from one of the Magic Band team. The audience reactions to some of the things he said was really interesting. He gave the example of Cinderella wishing you a Happy Birthday as you walk round the park. “Cinderella just knows”, he said. Of course, in fact, her costume’s tech prompts her when it silently reads your Magic Band from a distance. This got some initial impressed applause, but it was noticeable that after a few moments, it wavered – people were thinking “Cool… er, but creepy?”

The Magic Band also has range sufficient that Disney can track you around the park. This enables some features which are good for both customers and Disney – for example, they can use it for load balancing. If one area of the park seems to be getting overcrowded, have some characters pop up in a neighbouring area to try and draw people away. But it means that they always know where you are and where you’ve been.

My take-away from learning about the Magic Band is that it’s really hard to have a technical solution to this kind of requirement which allows all the Convenient features but not the Creepy features. Disney does offer an RFID-card-based solution for the privacy-conscious which does some of these things, but not all of them. And it’s easier to lose. It seems to me that the only way to distinguish the two types of feature, and get one and not the other, is policy – either the policy of the organization, or external restrictions on them (e.g. from a watchdog body’s code of conduct they sign up to, or from law). And it’s often not in the organization’s interest to limit themselves in this way.

Mozilla Strategy and Vision

Not sure if I wasn’t paying enough attention, but I entirely missed the “Mozilla Strategy Articulation and 2016 Topline Targets” session from two weeks ago, recorded on Air Mozilla. This was the start of the 2016 planning process, where Chris Beard outlines our mission and 5-year vision. It should be required viewing for everyone interested in where Mozilla is or should be going in 2016, and in the next 5 years. We are planning for 2016 now; your input is welcomed.

Competition: The Mozilla Manifesto Principles in Simple Words

Randall Munroe of XKCD has written a whole book which explains things using only simple words. It’s called “Thing Explainer“. He’s also written a writing checker for people who want to write more things like that.

I am asking everyone to see if they can write the ten key points of the Mozilla Manifesto in a new way, saying the same things but using only simple words which his checker likes (like this writing that you are reading does).

You are allowed to use “Internet” even though it’s not a simple word, but if you find a way to not use “Internet”, that’s even better. You are also allowed to use “Mozilla” in the heading at the top, which will be “Mozilla Manifesto” but using only simple words.

It’s probably best if you put up your writing somewhere else on the Internet and then add some information here to say where it is. But if that’s a problem for you, you can put your writing here instead.

The person who makes the best writing will get something. I don’t know what yet. But making the best writing should make you happy anyway.

If you think this is a good and fun idea, then please tell everyone you know (in a nice way) so they can try as well.

I hope everything goes very well for you in this.

Promises: Code vs. Policy

A software organization wants to make a promise, for example about its data practices. For example, “We don’t store information on your location”. They can keep that promise in two ways: code or policy.

If they were keeping it in code, they would need to be open source, and would simply make sure the code didn’t transmit location information to the server. Anyone can review the code and confirm that the promise is being kept. (It’s sometimes technically possible for the company to publish source code that does one thing, and binaries which do another, but if that was spotted, there would be major reputational damage.)

If they were keeping it in policy, they would add “We don’t store information on your location” to their privacy policy or Terms of Service. The documents can be reviewed, but in general you have to trust the company that they are sticking to their word. This is particularly so if the policy states that it does not create a binding obligation on the company. So this is a function of your view of the company’s reputation.

Geeks like promises kept in code. They can’t be worked around using ambiguities in English, and they can’t be changed without the user’s consent (to a software upgrade). I suspect many geeks think of them as superior to promises kept in policy – “that’s what they _say_, but who knows?”. This impression is reinforced when companies are caught sticking to the letter but not the spirit of their policies.

But some promises can’t be kept in code. For example, you can’t simply not send the user’s IP address, which normally gives coarse location information, when making a web request. More complex or time-bound promises (“we will only store your information for two weeks”) also require policy by their nature. Policy is also more flexible, and using a policy promise rather than a code promise can speed time-to-market due to reduced software complexity and increased ability to iterate.

Question: is this distinction, about where to keep your promises, useful when designing new features?

Question: is it reasonable or misguided for geeks to prefer promises kept in code?

Question: if Mozilla or its partners are using promises kept in policy for e.g. a web service, how can we increase user confidence that such a policy is being followed?

The Jeeves Test

What is a browser for? What should it do, or not do? What should it be?

People within the Mozilla project have been recently discussing the user value of some new features in Firefox. I think a person’s view of questions of this nature will depend on their view of the role of the browser. One option is the “featureless window on the web” view – the browser is nothing, the site is everything. But as one participant said, this leads to all the value-add and features being provided by the sites, which is not a recipe for user control, or for using the browser to advance the Mozilla mission.

I think the best vision for Firefox is as your “Internet butler” – quiet and refined, highly capable, provides what you need even before you know you need it, who gently guides you out of trouble but generally does his thing without you needing to think about him or provide explicit direction or management.

Bertie using an early voice interface prototype

So I’d like to propose the “Jeeves Test” for evaluating feature proposals for Firefox. It works like this: imagine Bertie Wooster, relaxing in an armchair in his apartment, with a cigarette, a gin and tonic, and a tablet computer. Then take the user value proposition of an idea, write it in appropriately deferential language, and see if you can imagine Jeeves whispering it into his ear. If you can’t, perhaps it’s not something we want to do.

To make that a bit more concrete, here are some examples of things that might pass: “Here’s an English translation of this Serbian page, sir”, or “For your safety, sir, access to this malware page has been blocked”. And here are some which might not: “For your convenience, sir, I’ve exempted from your popup blocker”, or “You’ll be pleased to find, sir, that the user interface has been substantially rearranged”.

There may be occasions where we’d want to do something which doesn’t obviously pass the Jeeves Test, if the effects on the broader web ecosystem of making the change are significantly positive. Some of the things we do to improve web security but which have a short-term compatibility impact might fall into that category. “Let me ensure this site doesn’t load for you, sir” generally doesn’t go down well, after all. But in those cases, that longer-term or broader value has to be clearly articulated – before we make the change – if we are to avoid an exasperated “Dash it, Jeeves… why?” from our userbase.

Happy Birthday, Mozilla!

17 years ago today, the code shipped, and the Mozilla project was born. I’ve been involved for over 15 of those years, and it’s been a fantastic ride. With Firefox OS taking off, and freedom coming to the mobile space (compare: when the original code shipped, the hottest new thing you could download to your phone was a ringtone), I can’t wait to see where we go next.


Complaining about (BMO) is a Mozilla project activity as old as the hills. Back in 2009, it was realised by the Foundation that to make everyone happy was (and still is) an impossible task, and I was given a mandate to “help people solve their own problems”. So around September 2009, I released the first version of my Bugzilla API proxy software, BzAPI. This software presented a clean, well-documented RESTful interface on the front end, and did all sorts of things on the back end (XML, CSV, RPC, HTML scraping) that developers no longer had to worry about. We made a dev server VM for it so people could try it out –

It was popular. Extremely popular. People started building things, and then more things, all of which depended on this server for Bugzilla data. For various reasons, IT never got around to building a production instance, and so over the last five years, I’ve been maintaining this core piece of Mozilla project infrastructure, which was depended on by TBPL and many, many other tools which interfaced with Bugzilla. At its peak, it serviced 400,000 requests per day.

Over the intervening years, BMO itself acquired a REST API which slowly became more capable, and then a BzAPI-compatible API shim was implemented on top of it by the excellent dkl, so people could change their code to access BMO directly just by updating the endpoint URL. After a few false starts, requests to are now served directly by BMO, via that shim code. Earlier today, the api-dev VM was finally powered down.

Here’s to you, api-dev. Good job.

Signed Committer’s Agreements No Longer Required

For a long time, Mozilla has required people gaining commit access to our core repos to sign a Committer’s Agreement. This is not a copyright assignment or a transfer of rights; it’s basically a commitment to good behaviour, and to making sure code which gets into the tree is allowed to be there and is correctly licensed.

However, the logistics of printing it out, signing it, scanning/photographing it back in etc. were always a barrier to participation. In consultation with our legal team, we have decided that people simply assenting to the document is just as good so, as of now, people are no longer required to go through the process of signing it.

However, all people with commit access to any Mozilla repository are still expected to abide by it :-) We may be adding CONTRIBUTING files referencing the document to our Github repos to make this point more clear.

The Zeroth Human Freedom

We who lived in concentration camps can remember those who walked through the huts comforting others, giving away their last piece of bread. They may have been few in number, but they offer sufficient proof that everything can be taken from a person but the last of the human freedoms – to choose one’s attitude to any set of circumstances – to choose our own way.

This quote is from From Death-Camp to Existentialism (a.k.a. Man’s Search for Meaning) by Victor Frankl. Frankl was an Austrian Jew who spent four years in concentration camps, and afterwards wrote a book about his experiences which has sold over 10 million copies. This quote was part of a sermon yesterday (on contentment) but I share it here because it’s very powerful, and I think it’s also very relevant to how communities live together – with Mozilla being a case in point.

Choosing one’s attitude to a set of circumstances – of which “someone has written something I disagree with and I have become aware of it” is but a small example – is an ability we all have. If someone even in the unimaginable horror of a concentration camp can still retain it, we should all be able to exercise it too. We can choose to react with equanimity… or not. We can choose to be offended and outraged and angry… or not. To say that we cannot do this is to say that we have lost the most basic of human freedoms. No. We are all more than the sum of our circumstances.

Using Instantbird to Connect to IRC Servers Requiring a Username and Password

[Update 2014-01-16: A point of clarification. There are two possible ways to send a password for IRC. One is supported in the Instantbird UI – it’s the one that automatically identifies your nick with NickServ, the bot which makes sure people don’t steal other people’s nicks. The other, which is rarer but which I needed, involves sending a password to connect at all, using the PASS command in the IRC protocol. That is what is documented here.]

I was trying to do this; turns out it currently requires about:config manipulation and is not documented anywhere I can find.

Using about:config (type /about config in a message window, or access via Preferences), set the following prefs:


to the obvious values. Other useful tip: if the IRC server uses a self-signed cert, connect to it on the right port using Firefox and HTTPS, and you can save the cert out of the warning/exception dialog you get. You can then import it into Instantbird using the deeply-buried Certificate section of the Advanced Preferences and it will trust the cert and connect. (I think this is what I did, although memory is hazy.)

slic 1.0.0 Released

I’ve just released version 1.0 of some new software called slic, which I’ve been using to do license analysis on Firefox OS. From the README:

This is slic, the Speedy LIcense Checker. It scans a codebase and identifies the license of each file. It can also optionally extract the license text and a list of copyright holders – this is very useful for meeting the obligations of licenses which require reproduction of license text. It outputs data in a JSON structure (by default) which can then be further processed by other tools.

It runs at about 120 files per second on a single core of a 3GHz Intel I7 (it’s CPU-bound, at least on a machine with an SSD). So you can do 100,000 files in less than 15 minutes. Parallel invocation is left as an exercise for the reader, but could easily be bolted on the side by dividing up the inputs.

The code is Python, and it uses a multi-stage regexp-based classifier, so that with families of licenses it starts with a more generic classification and then refines it via checking various sub-possibilities. Future potential enhancements include a hash-based cache to avoid doing the same work more than once, and integration with a popular online spreadsheet tool to help manage exceptions and manual license determinations.

Global Posting Privileges on the Mozilla Discussion Forums

Have you ever tried to post a message to a Mozilla discussion forum, particularly one you haven’t posted to before, and received back a “your message is held in a queue for the moderator” message?

Turns out, if you are subscribed to at least one forum in its mailing list form, you get global posting privileges to all forums via all mechanisms (mail, news or Google Groups). If you aren’t so subscribed, you have to be whitelisted by the moderator on a per-forum basis.

If this sounds good, and you are looking for a nice low-traffic list to use to get this privilege, try mozilla.announce.

FirefoxOS 3 Ideas: Hack The Phone Call

People are brainstorming ideas for FirefoxOS 3, and how it can be more user-centred. Here’s one:

There should be ways for apps to transparently be hooked into the voice call creation and reception process. I want to use the standard dialer and address book that I’m used to (and not have to use replacements written by particular companies or services), and still e.g.:

  • My phone company can write a Firefox OS extension (like TU Go on O2) such that when I’m on Wifi, all calls transparently use that
  • SIP or WebRTC contacts appear in the standard contacts app, but when I press “Call”, it uses the right technology to reach them
  • Incoming calls can come over VoIP, the phone network or any other way and they all look the same when ringing
  • When I dial, I can configure rules such that calls to certain prefixes/countries/numbers transparently use a dial-through operator, or VoIP, or a particular SIM
  • If a person has 3 possible contact methods, it tries them in a defined order, or all simultaneously, or best quality first, or whatever I want

These functions don’t have to be there by default; what I’m arguing for is the necessary hooks so that apps can add them – an app from your carrier, an app from your SIP provider, an app from a dial-through provider, or just a generic app someone writes to define call routing rules. But the key point is, you don’t have to use a new dialer or address book to use these features – they can be UI-less (at least when not explicitly configuring them.)

In other words, I want to give control over the phone call back to the user. At the moment, doing SIP on Android requires a new app. TU Go requires a new app. There’s no way to say “for all international calls, when I’m in the UK, use this dial-through operator”. I don’t have a dual-SIM Android phone, so I’m not sure if it’s possible on Android to say “all calls to this person use SIM X” or “all calls to this network (defined by certain number prefixes) use SIM Y”. But anyway, all these things should be possible on FirefoxOS 3. They may not be popular with carriers, because they will all save the user money. But if we are being user-centric, we should do them.

Unanimity Is Not a Requirement

People sometimes wonder how to best involve all of the affected/important/relevant parts of the Mozilla community in a decision. The prospect of doing this can lead to a certain amount of fear – of criticism, bike-shedding, etc.

At the last All Hands in October 2013, at a session in Brussels, we produced a Best Practices document called “Productive Discussion” to help with exactly this problem. Given Mitchell’s keynote at the recent All Hands, I thought it was worth reflagging its existence.