With this patch, a shatter’d visage is obscured,
Its’ sneer of cold command in history orphaned.
That one whose results were long once, and secure,
But now resides, antique, imprinted on things best forgotten.
— J.C. Jones’ epitaph for SHA-1
I spoke on Sunday at the FOSDEM conference in the Policy devroom about the Mozilla Root Program, and about the various CA-related incidents of the past 5 years. Here’s the video (48 minutes, WebM):
Given that this only happened two days ago, I should give kudos to the FOSDEM people for their high quality and efficient video processing operation.
Like every year for the past ten or more (except for a couple of years when my wife was due to have a baby), I’ll be going to FOSDEM, the premier European grass-roots FLOSS conference. This year, I’m speaking on the Policy and Legal Issues track, with the title “Reflections on Adjusting Trust: Tales of running an open and transparent Certificate Authority Program“. The talk is on Sunday at 12.40pm in the Legal and Policy Issues devroom (H.1301), and I’ll be talking about how we use the Mozilla root program to improve the state of security and encryption on the Internet, and the various CA misdemeanours we have found along the way. Hope to see you there :-)
Note that the Legal and Policy Issues devroom is usually scarily popular; arrive early if you want to get inside.
Mitchell has been focussed for a while on how Mozilla can make good decisions which are made quickly rather than getting bogged down, but which do not bypass the important step of getting the opinions of a diverse cross-section of interested and knowledgeable members of our community.
In relation to that, I’d like to re-draw everyone’s attention to Productive Discussion, a document which came out of a session at the Summit in Brussels in 2013, and which explains how best to hold a community consultation in a way which invites positive, useful input and avoids the paralysis of assuming that consensus is required before one can move forward.
If there’s a decision you are responsible for making and want to make it using best practice within our community, it’s a recommended read.
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! :-)[0]
[0] 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.
He takes it home and presses a button on his home’s IoT hub, then swipes the thermometer across the top. A 5 cent NFC tag attached to it tells the hub that this is a device in the “temperature sensor” class (USB-style device classing), accessible over Z-wave, and gives its public key, a password the hub can use to authenticate back to the sensor, and a URL to download a JavaScript driver. The hub shows a green light to show that the device has been registered.
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:
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:
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. :-)
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.
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.)
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?