This was originally posted as a guest post on January 31t 2014. Since then, it has been requested that I post under my own name.<\/p>\n
Introduction<\/strong><\/p>\n I am a Firefox Engineer at Mozilla. I have worked on Desktop Firefox, Firefox for Android, and Firefox Sync. I currently work on Firefox for Windows 8 Touch, (n\u00e9e Firefox Metro). I also serve on Mozilla\u2019s Privacy Council.<\/p>\n On Data Privacy Day, I presented a perspective on what we can do differently. My primary audience is fellow engineers or those engaged in engineering related activities. When I say \u2018we\u2019 I am largely referring to engineering as group. The remainder of this post is a written expansion on the presentation. The Air Mozilla recording is available here<\/a>.<\/p>\n Goal<\/strong><\/p>\n My goal is to start a public discussion about what engineers need to know about user privacy. Eventually the result of this discussion will evolve into a short training or set of best practices so engineers can ship better code with less hassle. Since this is the start of a public discussion, the content below will probably raise more questions than answers.<\/p>\n There be scaly dragons. Ye have been warned.<\/p>\n Privacy? That Word is so Overused. What is it Exactly & Why do I Care?<\/strong><\/p>\n Privacy is a culturally laden word and definitions vary widely. Privacy means different things to different people at different times, even within the nascent field of privacy engineering<\/a>. So for sanity\u2019s sake, the following are my table stakes definitions.<\/p>\n Privacy<\/strong><\/em>: How & by whom the personal information of an individual is managed with respect to other individuals.<\/p>\n User Data<\/strong><\/em>: Any data related to users that they generate or cause to be generated; or that we generate, collect, store, have custody and control over, transfer, process, or hold interest in.<\/p>\n Why do we care? The reason Mozilla exists is to defend and promote the open web. Firefox & FirefoxOS are great products but they are not the raison d\u2019\u00eatre outlined in the Manifesto; they are means to an end. The Mozilla Manifesto<\/a> declares that for a healthy web, users must be able to shape their own experiences on it. Ain\u2019t nothing shapes your experience online more than than the data generated for, by, and about you. Whoever controls that controls your experience on the web. So our goal of the open web is directly linked to individuals ability to control that for themselves.<\/p>\n Acknowledging the Elephant in the Room<\/strong><\/p>\n Let\u2019s start by acknowledging the elephant in the room: whether or not Mozilla products should even handle user data. That would be a rich discussion on its own. This is not that discussion. This discussion assumes we\u2019re going to handle user data. Regardless of your views, let\u2019s agree that there are some things we will need to do differently when we choose to handle user data. Let\u2019s figure out what those are.<\/p>\n Ok, So We Care; There\u2019s Another Team at Mozilla for That.<\/strong><\/p>\n There is a misconception I run into often that I\u2019d like to clear up. Data safety & user privacy is everyone\u2019s job, but especially an engineer\u2019s job. At the end of the day, engineers make the sausage. No one has more leverage over what gets written than the engineer implementing it. The privacy team is here to help, but there are three of them and hundreds of us. The duty is really on us not them. Whether our code is fast, correct, elegant, secure, and meets Mozilla\u2019s standards is chiefly our responsibility.<\/p>\n Ok, So it\u2019s Kinda My Job. What do I Need to Think About or do Now?<\/strong><\/p>\n I have good news & bad news. The good news is that it boils down to writing more stuff down & making more decisions upfront. Stated more formally:<\/p>\n Sounds simple eh? Seasoned engineers should feel their spider sense tingling. It\u2019s not miscalibrated. That\u2019s the bad news. It\u2019s how you do it that matters. The devil is in the details. So let\u2019s tackle the easier one first: what I flippantly referred as \u2018writing more stuff down\u2019<\/p>\n Active Transparency (aka write more stuff down)<\/em><\/strong><\/p>\n Passive Transparency<\/strong><\/em>: unintentional, decisions aren\u2019t actively hidden, but are difficult to locate. May not even be documented<\/p>\n Active Transparency<\/strong><\/em>: intentional, everything is written down, easily searchable & locatable by interested parties<\/p>\n If you haven\u2019t heard these terms before, don\u2019t panic. I made them up years ago when I was a volunteer contributor trying to articulate how I was part of an open source project, actively following Bugzilla, but couldn\u2019t figure out what was going on in the \/storage module<\/a>, let alone the rest of the Firefox code base.<\/p>\n Active transparency is functioning transparency. It requires sustained effort. Information, history, and decisions of a feature can be searched for, located, and consumed by all inclined.<\/p>\n Passive transparency is what happens unintentionally. People aren\u2019t trying to hide information from each other. It just happens and no one notices until it is too late to do anything about it.<\/p>\n We often don\u2019t notice because those who code marinate in information. We rarely bother to test whether or not anyone else outside can figure out what we\u2019re living and breathing life into. I hear grumbling already: \u2018Sounds like useless paperwork, not worth it\u2019. What you really mean is \u2018not worth it to you right now\u2019, but it\u2019s worth much to the people who will be responsible for it after you ship it, and there will be many of them.<\/p>\n One of the ways user data based features differ dramatically from application features of yore is that control will change hands many times over. Future development, operations, database administration, etc teams cannot read your mind. They also can\u2019t go back in time to read your mind.<\/p>\n As an added bonus, privacy is not the only reason to be actively transparent. Active transparency is vital to building our community. Like open source software, it\u2019s not really open if no one can find it and participate. Active transparency applies to the decision making process as much as to source code.<\/p>\n Proactive Planning (aka Making More Decisions With More People)<\/em><\/strong><\/p>\n Now we move on the harder part \u2013 more decisions you\u2019ll need to make with more people. Getting agreement on requirements is often one of the most difficult and least pleasant part of of an engineer\u2019s craft. When handling user data, it will get harder. Your stakeholders will increase because the number of people who handle the data your feature generates or uses over its lifetime has increased.<\/p>\n The reason for enduring that pain at the beginning is that effective privacy is something you\u2019ll only get one shot at. It\u2019s usually impossible or cost-prohibitive to bolt it on to stuff after it\u2019s built.<\/p>\n Proactive planning decisions will make up the bulk of the rest of the post. They are phrased in question form because the answers will be different for each project. They should not be interpreted as an all-inclusive list. The call to action for you is to answer them (and write the reasons down in a searchable location. Ahem \u2013 active transparency!)<\/p>\n 30,000 Foot Views<\/strong><\/p>\n The problem space can be vast. Below are two high level categorizations to jumpstart your problem solving, so that your feature can concretely bring to life the Manifesto\u2019s declaration that users must be able to shape their own experience.<\/p>\n First Way to Slice It<\/strong><\/p>\n An intuitive place to start is interaction.<\/p>\n Interactions between events and their data, or the data lifecycle<\/strong><\/p>\n Interactions between us and their data<\/strong><\/p>\n Interactions between users and their data<\/strong><\/p>\n Second Way to Slice It<\/strong><\/p>\n Another way to group key decisions is by basics plus high level concerns, such as:<\/p>\n Things to Think About \u2013 Basics<\/strong><\/p>\n To start off, most of these seem pretty obvious. However there can be gotchas. For example, how identifying a type of data is can be tricky. What is seemingly harmless now could later be shown to be strongly identifying. Let\u2019s consider the locale of your Firefox installation. If you are in en-us (the American English version), locale is not very identifying. Seems obvious. However, for small niche locales, it can be linked to a person.<\/p>\n Things to Think About \u2013 Benefits and Risks<\/strong><\/p>\n There will always be risk in doing anything. There exists a risk that when I leave my house an anvil with drop on me. That doesn\u2019t mean I never leave my house. I leave my house because the benefits(like acquiring dinner) outweigh the risk. Similarly, there will always be risk when handling user data. That doesn\u2019t mean we should handle it, but there had better be benefit to the user. \u2018Well, it might be useful later<\/em>\u2018 is probably not going to cut the mustard at Mozilla as a benefit to users.<\/p>\n Things to Think About \u2013 Openness, Transparency and Accountability<\/strong><\/p>\n For a Mozilla audience, this is preaching to the choir.<\/p>\n Things to Think About \u2013 Contributors and Third Parties<\/strong><\/p>\n The use of third party vendors adds additional nuances, as I alluded to earlier.<\/p>\n At Mozilla, we sometimes release data sets so researchers can contribute knowledge about the open web for the public good.<\/p>\n Things to Think About \u2013 Identity and Identifiers<\/strong><\/p>\n There\u2019s probably nothing more personal than someone\u2019s identity.<\/p>\n Things to Think About \u2013 Data Lifecycles and Service History<\/strong><\/p>\n This is an area that most application developers will have trouble with because we often don\u2019t think about the mid-life or death of our feature or the data it uses. It ships, it\u2019s out! Onto the next thing!<\/p>\n Not so fast.<\/p>\n Things to Think About \u2013 User Control<\/strong><\/p>\n To shape their own experiences on the web, users need to have control of their data.<\/p>\n Things to Think About \u2013 Compatibility and Portability<\/strong><\/p>\n In my not-so-humble opinion, it\u2019s not an open web if user data is held for ransom or locked into proprietary formats.<\/p>\n That\u2019s a Lot of Extra Work, No. Not OK. Not Cool.<\/strong><\/p>\n Yes, it is.<\/p>\n Handling user data is going to increase your workload. So does writing test coverage. We do it anyway. We write tests to meet our standards for correctness; we must write code that meets our standards for privacy.<\/p>\n I didn\u2019t say it would be easy, but it\u2019s doable. We can do it better and show that the web the world needs can exist.<\/p>\n The Privacy Team is Here to Help. Talk to Them Early and Often<\/strong><\/p>\n That a metric ton of questions to ponder. I don\u2019t expect you to remember them all. The privacy team is working on a new kickoff form and a checklist of considerations to make this process smoother (Additional note I spent most of today on just this goal). They may even merge those two things. For now, use the existing Project Kickoff Form<\/a> and check out this wiki<\/a> containing the questions I\u2019ve listed above.<\/p>\n Not sure if you need a review? Just have a question? Something you want to run by them? Drop them an email or pop into the #privacy irc channel.<\/p>\n Have an Opinion? Join the Effort.<\/strong><\/p>\n The Mozilla Privacy Council needs more engineers, including volunteer contributors. No one knows more about building software than we do. User-empowering software won\u2019t get built without us. Help shape the training, best practices, the kickoff form, and privacy reviews of new features. To get involved, email stacy at mozilla dot com.<\/p>\n Special thanks to the Metro team for their patience with my delayed code reviews this week.<\/p>\n Thank you for reading. May your clobber builds be short.<\/p>\n","protected":false},"excerpt":{"rendered":"\n
\nBreak that habit. You test your code to prove it works; so test your transparency to prove it works (or doesn\u2019t). Ask someone in marketing or engagement to figure out the state of your project or why your design is in its current state. Can they explain your tradeoff, constraints or design decisions back to you? Can they even find them?<\/p>\n\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n