Privacy/Reviews
Privacy reviews are one of the tools that we use to help avoid making mistakes when it comes to privacy.
The goal is to ensure that the folks designing a new feature, building a new product, planning new engagement, or otherwise doing something awesome have everything they need to make smart privacy choices, and to apply the privacy principles to their project.
Generally, the driver is not the privacy team: it's the person leading this particular initiative. The people actually building the widget are in the best position to understand what's important, and how best to implement it. The privacy team is there to provide subject matter expertise, help and suggestions: they're a stakeholder, not the ultimate decision-maker.
Contents
The process
When to start
Generally, a new project should start a privacy review when it's:
- mature enough to be concretely described, but
- early enough to implement feedback.
If the project isn't mature enough for you to describe what it does and how it might do it, it won't be practical to identify potential risks or give concrete advice. On the other hand, if you've already built almost everything then it'll be a lot of work to implement any changes or take advantage of new advice. If in doubt, it's best to get started sooner rather than later. We can always delay the conversation for a while and return when you have a clearer picture, but it's much harder to go back to an earlier point to implement suggestions.
Kicking off
The best way to start a privacy review is to fill out the project Kick-Off Form here. This won't just open a privacy review bug and assign it to the right member of the privacy team, it'll also file bugs for all sorts of other things (such as legal and security) to make sure you don't miss anything.
Once you have a privacy review bug filed, you should start adding documentation. It's a well-established fact that the privacy team are ravenous consumers of information. The more background you can provide, the easier it'll be to get a handle on your project, and start helping out. Have you got wiki pages, open bugs, newsgroup posts, Github readmes, Google docs, IRC histories, or 3D blueprints? Label it, and attach it to your bug.
Now's also a good time to look at the bug and make sure that everything is in order. If the automatically-generated bug is MoCo confidential, does it need to be; could it be public instead? What about stakeholders; are the right people CC'd on the bug; are there any decision makers or information-holders who've been left out? Make sure that you've added all that detail to the bug, so that we can minimize the amount of telephone that needs to be played.
Discussion
After downloading all your documentation, grabbing your gists, and generally perusing the product, your privacy team-member will want to sit down and talk with you, probably by Vidyo. In fact, apart from a question or two about scope and documentation, it's likely that the first comment in your privacy review bug will be a member of the privacy team asking you to set aside some time to explain things to them.
Why do they ask you to pick a time? You know who needs to be in the room, who's critical and who's optional. You know the time-zones and best contact methods for everyone on your team. In short, you're the one running the show. Set aside some time, and get everyone lined up.
Once you're all in the room, your privacy professional is going to pepper you with questions. They need to get completely up to speed with every apsect of your project so that they can give you all the advice and suggestions that you need to take over the galaxy make sure you account for privacy considerations.
Feedback
In your first meeting, you probably won't get many answers from the privacy team. Their spidey-senses may be tingling, but they're going to go away with a book of notes, and consult the ancient tomes of privacy design, long-forgotten newsgroups, previous similar projects, and the great privacy masters of Galcyon VI. This might take a few days. Soon, however, you'll get some feedback, perhaps in your bug, perhaps in an email, or perhaps in a followup conversation. This feedback will fall into two categories.
Non-normative info & advice is subject-matter expertise distilled and adapted for the type of project you're working on. This is stuff that you should think about, principles that you should account for, and other knowledge that we're trying to download into your brain. Use it wisely.
Specific suggestions and risks are things that could go wrong, and ways that you might be able to improve. Sometimes you'll get strong suggestions, sometimes a bunch of possible tweaks. Still, when we say "suggestions", we're not messing about: they really are suggestions. The privacy team may be in the best position to tell you about risks that you may not have thought of, but you're in the best position to decide what makes sense for your project: is that a risk that you just need to take, or a cunning tweak that you just hadn't thought of. That's up to you.
Except in extreme circumstances, feedback is usually non-blocking. Once we've provided our feedback, we'll likely close the privacy bug and let you make the final decision. You're of course always welcome to ask us additional questions.
Technical followup
Some things are easy to describe, but complicated to implement just so. For those cases, we have the security team on standby for technical followups. If the privacy review is a normative component of the design process, then the technical followup is conformance testing.
Current reviews
Note: this section only displays publically-visible bugs. Confidential bugs of any type are not visible here.
Products and features
No results.
0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);
Vendors
No results.
0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);
Initiatives
No results.
0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);
Partners
No results.
0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);
