Some decisions are consequential and irreversible or nearly irreversible – one-way doors – and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation. If you walk through and don’t like what you see on the other side, you can’t get back to where you were before. We can call these Type 1 decisions. But most decisions aren’t like that – they are changeable, reversible – they’re two-way doors. If you’ve made a suboptimal Type 2 decision, you don’t have to live with the consequences for that long. You can reopen the door and go back through. Type 2 decisions can and should be made quickly by high judgment individuals or small groups.
As organizations get larger, there seems to be a tendency to use the heavy-weight Type 1 decision-making process on most decisions, including many Type 2 decisions. The end result of this is slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention. We’ll have to figure out how to fight that tendency.
A small milestone: the first post in my name on the Mozilla Net Policy blog has just been published. It concerns our filing comments for a US Copyright Office consultation on section 512 of the DMCA – the section dealing with safe harbo(u)rs for intermediary liability. Section 512 contains the rules that mean Facebook, Twitter and other platforms actually let you have a conversation and upload images and videos to talk about, rather than restricting that capability because they are too afraid of immediate copyright liability.
This is not to be confused with section 1201 of the DMCA, which gives the rules for the 3-yearly process for getting DMCA exceptions for important things like phone unlocking. We also filed comments in a consultation on that recently.
We hope that the Copyright Office’s recent attention to these sections bodes well for useful reforms to US copyright law.
Mozilla is 18 today. I’ll drink to that! :-)
 This reference may not work in your jurisdiction.
Software licenses are the constitution for a community. The license a group picks for their software is indicative of how they would like their community to work. GPL-using communities have one set of norms around sharing, BSD or Apache-using communities have another way of working together. That is, of course, as long as everyone using the code plays by the rules.
Basically the only organization attempting to make sure that users of GPL code respect the wishes of the authors of that code is the Software Freedom Conservancy. As well as other excellent work like providing a financial and organizational home for projects, they enforce the GPL – most recently, after five years of fruitless negotiation, in a lawsuit against VMWare, who have taken parts of Linux and put them in their proprietary ESXi product.
Whether you are a keen user of the GPL, or of BSD, or whether you don’t much care about licensing, I hope all my readers are keen that the wishes of authors of software about what happens to it, and the obligations you have if you take advantage of their hard work, are respected. The SFC is a small charity, and corporate donations have suddenly become harder to come by now they are insisting that corporations live up to their responsibilities. (How strange…) I’m proud to say Mozilla has supported SFC in the past, and I hope we will continue to do so. But please would you also consider signing up as a supporter, at the very reasonable cost of US$10 a month.
If people don’t like the terms of the GPL, they are free to write their own software to do whatever they want done. But if they use the hard work of others to save time and effort, they need to respect the wishes of those authors. SFC makes that happen; please give them your support.
Mark’s baby daughter keeps waking up in the middle of the night. He thinks it might be because the room is getting too cold. So he goes down to the local electronics shop and buys a cheap generic IoT temperature sensor.
Mark sticks a AAA battery into the sensor and places it on the wall above his baby’s cot. He goes to his computer and brings up his hub’s web interface. It has registered the new device and connected to it securely over the appropriate protocol (the hub speaks Bluetooth LE, wifi and Z-wave). The connection is secure from the start, and requires zero additional configuration. The hub has also downloaded the JS driver and is running it in a sandboxed environment where it can communicate only with the sensor and has access to nothing else. If it were to want to communicate with the outside world, the hub manages the SSL (rather than the device or the driver) so it can log all traffic in cleartext.
Mark views the device’s simple web page (generated by the driver) and sees the room is at 21C. He asks the hub to sample the value every minute and make a chart of the results. The hub knows how to do this for various simple device classes, including temperature sensors.
The next morning, he checks the chart and indeed, at 3am when the baby woke up, the temperature was only 15C. He goes back to the electrical shop and buys an IoT mains passthrough plug and a cheap heater. He registers the plug with the hub as before, then plugs the heater into the passthrough, and the passthrough into a socket in the baby’s room.
Back at the web interface, he gives permission for the plug’s driver to see data from the temperature sensor. However, the default driver for the plug doesn’t have the ability to react to external events. So he downloads an open source one which drives that device class. Anyone can write drivers for a device class because the specs for each class are open. He then tells the new driver to read the temperature sensor, and turn the plug on if the temperature drops below 18C, and off if it rises to 21C. The next night, the baby sleeps through. Success!
The key features of this system are:
- the automatic registration and instant security, based on a cheap NFC tag which implements an open standard, which allows device makers to make their devices massively easier to use (IoT device return/refund levels are a big problem at the moment);
- the JS host environment on the hub, which means you can run untrusted code on your network in a sandbox so you can buy IoT devices without the risk of letting random companies snoop on your data, and every device or ecosystem doesn’t need to come with its own controller; and
- the open standard and device classes which mean all devices and all software is hackable.
Wouldn’t it be great if someone built something like this?
It seems like I’m only managing one blog post a month at the moment. I’m doing loads of things, but don’t seem to have time to blog about them! Currently, the major components of my work are:
- Helping Thunderbird get to a good and sustainable place (status update)
- Running MOSS (applications always open!)
- Copyright work for the public policy team
On that last point, we just submitted a filing to a US Copyright Office consultation on the famous section 1201 of the DMCA, which is the one which regulates the every three years exemption process for bypassing DRM. See our blog post here, which links to our filing. While this process is not really fixable in its current form, I hope we can help to make it a little better.
I am currently running the MOSS (Mozilla Open Source Support) program, which is Mozilla’s program for assisting other projects in the open source ecosystem. We announced the first 7 awardees in December, giving away a total of US$533,000.
The application assessment process has been on hiatus while we focussed on getting the original 7 awardees paid, and while the committee were on holiday for Christmas and New Year. However, it has now restarted. So if you know of a software project that could do with some money and that Mozilla uses or relies on (note: that list is not exhaustive), now is the time to encourage them to apply. :-)
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.
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.
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.
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.)
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?
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 aol.com 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.
The piece does include, at the end, a section on the specific applicability of my analysis to the Mozilla community.
Comments, as always, are most welcome. :-)
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 bugzilla.mozilla.org (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 – api-dev.bugzilla.mozilla.org.
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 api-dev.bugzilla.mozilla.org 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.