Thread by @ireneista

We're live-tweeting PEPR20! After the break, this will be the thread head for the fourth block of talks ("session"), which will be the last one for the first day. #pepr20

"Product Privacy Journey: Towards a Product Centric Privacy Engineering Framework", by Igor Trindale Oliveira, is now starting.

Why a product-centric approach? Other possible focuses would be compliance, design, engineering, users... #pepr20

When embedding privacy into product, it must be a "return to Renaissance" - it forces everyone to work together #pepr20

This is about getting PMs, designers, eng to work together and share responsibilities. Everything matters. All these roles, all their ideas. #pepr20

Anyone who's worked in product development knows that you have to have principles. It's no different in privacy. #pepr20

Some principles... acknowledge that this builds on privacy by design and on data ethics. #pepr20

Principles: No choice is forever. Context is key. Sharing should add value. (3 more that we didn't catch) #pepr20

No choice is forever. People change their minds, so data controls should allow them to. #pepr20

Last year had a talk "no one uses privacy settings". Why? Users can't find the settings in the app; or they are afraid of having a worse experience if they touch anything. The user often has no context for what privacy language means. #pepr20

A UI example shows a control that's highlighted in a red square on a page that's otherwise about normal app usage (not settings), to make it obvious in this context. #pepr20

Context is key. Ask for consent at moments where the user is prepared to think about it. #pepr20

Don't ask if the user is in the middle of using a feature that doesn't clearly need user data. #pepr20

Sharing should add value. It's important to create experiences that users like, whether or not users choose to share data. #pepr20

(We think this is saying: Sharing should *add* value, it shouldn't hold the value hostage.) #pepr20

(That's our interpretation though) #pepr20

Plain language empowers. (4th principle)

Try to avoid jargon, users won't understand it. We as experts know this stuff, but users don't. #pepr20

Tricks erode trust. (5th principle)

People know when they're being manipulated. Avoid leading statements, avoid dark patterns. #pepr20

The Dark Patterns paper is cited. #pepr20

Personal data belongs to individuals. (6th principle)

This is their data. Let them delete it. Make it clear that they own it. #pepr20

A snippet of wording from the CCPA is given to illustrate that truth. #pepr20

Prioritize privacy in every phase of product development! #pepr20

The slides now break down five phases of the privacy product journey. Inspire, acknowledge, conceive, implement, evaluate. #pepr20

The journey starts with inspiration. Inspire the user to see that the product makes sense. Apple has various ad campaigns that are great at this. #pepr20

Acknowledge... understand who your users are and what the company expects from them. Recognize the trade-offs. #pepr20

In summary: Pay attention to user perspectives, the company's expectations, the legal requirements. Aim to have requirements mapped to features, and to have privacy metrics. #pepr20

Conceive: In this phase, pay attention to avoiding dark patterns and to the practices highlighted earlier. #pepr20

Implement: try to make it not only correct, but also fair. #pepr20

Validate: Make sure the privacy requirements are actually met. Do user tests to make sure it's a good experience. #pepr20

There's a slide now which summarizes the pieces of all those phases. We didn't manage to capture every one as they went past, so we definitely won't be able to now. Sorry about that. #pepr20

Now there's a Venn diagram showing which responsibilities are shared by engineering, product management, and design, vs. which are separate responsibilities. #pepr20

Again, this is an information-dense slide so it's hard to capture. #pepr20

Question: (missed it), talk about the journey?

Answer: Our first step was checklists, but also we tried to understand each client's needs. If you create too broad a document, nobody will care about it because it's too much promotion. #pepr20

Question: When you create these more focused artifacts, what do you optimize for? It created this version that does work.

Answer: Yes, exactly. (seems to have been a vague question) #pepr20

Answer: We have to talk about regulation because it is the law, but it's not effective to only talk about that because people just implement bad settings. We try to have champions for privacy on different groups - product management, design, technology. #pepr20

The privacy champions aren't privacy engineers but they care. We try to have one one each team. #pepr20

The champions' role is to raise their hand every time they see something not working well. #pepr20

Question: Have you been able to scale that? Or have you run out of champions?

Answer: It's hard, sometimes a champion does have more than one project. #pepr20

Next talk! "Wikipedia and the Lean Data Diet", by nuria ruiz. (Lowercase intentional.) #pepr20

nuria works for the Wikimedia foundation. #pepr20

The foundation administers the servers, but has nothing to do with Wikipedia's content. #pepr20

The idea of lean data is that you should think very purposefully about what you gather from your users, whether you really need it, and whether it's really providing value to users. #pepr20

Wikipedia exists in the larger context of the free knowledge movement. #pepr20

That matters, because the principles for privacy on Wikipedia extent from that movement. You can't have free knowledge without a strong guarantee of privacy. (Wow! Powerful.) #pepr20

How is this guarantee of privacy expressed? Not an exciting answer: The privacy policy. What's different about this one, though, is that it was built the Wiki way, with community engagement. #pepr20

That community engagement totaled 150,000 words. That is a lot! #pepr20

What does the policy talk about?

You should be able to read or edit without an account. You should be able to register an account without a name, email, or any other PII. Nothing should be shared or sold. #pepr20

There was something there about a 90-day retention period too, but we missed the details. #pepr20

Wikipedia runs on-premises. It's not in anybody else's cloud. This slide has a photo of the hardware! #pepr20

These practices are all about the data. They try to compute metrics in a privacy-conscious manner. They delete a lot of things. #pepr20

Sanitizing data. How? When deleting data, you have to do it at scale. It's hard! Your data is probably in two systems, multiple layers of database and caching. Primary and secondary sources. #pepr20

Usage data - web requests. Shows an example from a web log. This is behavioral data! Users click on a button or a menu and it makes a web hit. Behavioral data must be aggregated or deleted. #pepr20

Wikipedia's peak qps (queries per second) is 200,000. There's a graph. #pepr20

This is 2,000 events per second. #pepr20

Flip flags. Don't use --dry-run, use --execute (if absent, nothing happens). Don't use --tables-to-delete as an optional flag, the default is delete none, not all! #pepr20

An example script invocation, parameters and output. The output ends with a "parameter checksum". Whenever you put an invocation in a template, you need to pass that checksum. This prevents user error! (Cool!) #pepr20

That's deleting... what about sanitizing? Remove the most identifying pieces. Of course the notion of identification carries a notion of risk, it's never 100% safe. #pepr20

Worked example. Behavioral data comes in via an HTTP beacon endpoint, goes through Varnish, several other layers. One backend data store is purged every 90 days. #pepr20

At the same time, the stream is passed through an allow-list of what parts to persist, and the result is saved elsewhere, to a data store that's kept indefinitely and published. #pepr20

This next slide compares a web log's fields with and without the allow-list. Using an allow-list means that if something changes in the log format, new fields will *not* be retained by default. #pepr20

In addition to that, some fields may be transformed. IP address may be coarsened down to country. User-agent may be coarsened down to operating system. #pepr20

Privacy is not the responsibility of one team. All processes and metrics need to take privacy into account from the beginning. #pepr20

Metrics built on privacy from the start... unique devices: daily active users or monthly active users?

Since you don't need to be logged in, these are more accurately called devices or browsers, not users. #pepr20

So, you have an identifier. You can count the distinct identifiers in a 30-day window. #pepr20

One risk with this approach is the idea that you can build a browsing session that actually lasts 30 days! If a government asks for this data, Wikimedia doesn't want to have it. #pepr20

(Well done. The safest data is the data that doesn't exist.) #pepr20

So, the cookie they set contains the date of the last access to the site. #pepr20

That's literally all that's in the cookie. #pepr20

Because of how cookies work, each time the user sends this cookie to the server, it will also be overwritten by the current date. #pepr20

So when you see two subsequent hits in the logs, the last-access value can't be used to determine that it's the same user. #pepr20

The *first* hit by a user on any given day, is distinctive in the logs, because the last access was on a previous day. #pepr20

The logs do have other data that can be used to identify users, such as IP addresses, but that data won't be retained in the same way. #pepr20

Summing it all up, what are the pros and cons of Lean Data? Pro: less work responding to government data requests, easier to make public, guarantee of privacy. Con: extra work developing it, privacy culture takes time, data analysis needs a different mindset. #pepr20

Closing thought: Privacy is a feature! #pepr20

Question: How do you balance privacy needs to solve these product tradeoffs? There's a link in Slack to a Vice article with context.

Answer: Something particular about Wikipedia is that the examples are mostly about readers... #pepr20

Wikipedia edits are public, nothing is ever deleted. That lets you see Amazon and Google's activity working with the site... #pepr20

That means for any piece of text you can see how it came to happen. If you want to start your own Wikipedia tomorrow, you have a head start. #pepr20

Question: How are sanitization practices informed by literature on the history of re-identification attacks?

Answer: It's hard to do well! The attendees here know that. :) Every field that's sanitized is public, so it's open to community scrutiny. #pepr20

Question: Wikipedia's functionality involves a lot of transparency. What factors go into drawing the line about what to share?

Answer: Everything that's shared is shared with the public at large. Will provide the link to the hourly dumps. #pepr20

If it runs on AWS, you are sharing your data with AWS, no way to prevent that. So Wikimedia has their own servers. Was that the question (probably not, but still interesting)? #pepr20

Question: How do you balance the needs of some users against others?

Answer: Although editing records are public, much data is still deleted. In-between data that it's not clear, it depends on where the abuse happens. #pepr20

It's a common theme for example that new editors get into edit wars. That may be kept. Sometimes there are legal repercussions and lawyers get involved. #pepr20

Last talk of the day! "Privacy Professional Boss Mode", by Melanie Ensign. #pepr20

Melanie is a founder of a consultancy specifically for privacy engineering. Their goal is to get beyond compliance, to create a "legion" of ambitious privacy professionals who can bring greater respect for human impact to corporations. #pepr20

Melanie speaks very powerfully. #pepr20

Think about what you were hired for, compare it to what you want to do but aren't yet. #pepr20

The privacy function likely includes other people, not just you. Whether you have a leadership title or not, you can have impact on others around you. #pepr20

To do this you need influence. People do things for their own reasons, not necessarily yours. You need to know how to motivate them. #pepr20

Relying on regulatory hammers to influence others has diminishing returns. You can spin up teams with a looming deadline, but your influence passes when the deadline does. #pepr20

This isn't to say that laws can't affect an industry over time, they can. This is the context of how you motivate other people and other teams to care about privacy. #pepr20

Real influence for privacy relies on moving organizations from compliance to commitment. #pepr20

Teams get competitive about headcount... Projects get delayed by compliance needs, that makes people upset... #pepr20

Every team needs to ship innovative projects for the sake of their own careers. You can't be seen holding them back. You need to come from a perspective of collaborative problem-solving. #pepr20

Nobody can fake enthusiasm for privacy forever. If they stop faking it, your role becomes that of the babysitter, which doesn't elevate you or the goals of privacy. #pepr20

To avoid that you cannot settle for a compliance mindset. You need to be a champion of that culture. #pepr20

If you don't spread that culture, people won't stick with privacy work because they won't find it engaging. #pepr20

How do you know whether you already have influence? Here are some things to ask yourself. #pepr20

Do people remember what you say? Do they carry your words to others? (two more, missed them) #pepr20

(that's ironic) #pepr20

Being heard matters. How do you not only get to the table, but have an opportunity to speak? Influence works its way up one level at a time, you need to recognize the importance of peer relationships to work outside your reporting chain. #pepr20

You also need to make sure the table you're at is the right one for the things you want to do. #pepr20

What are your goals? Who are the gatekeepers? What obstacles do they face? What opportunities do they crave? What do they need? What can you offer? #pepr20

You have to be a strategic advisor. What does that mean? You must be relentless at demonstrating business value. #pepr20

Even if you can't point to revenue, can you reduce the cost of demonstrating compliance, of responding to regulatory inquiries? #pepr20

Make sure you document those improvements, to get credit for them! #pepr20

Understand what tooling your internal stakeholders use. Then see if you can borrow it to achieve privacy goals. For example, reliability dashboards can be extended to cover privacy. #pepr20

Verbal skills are more important than technical ones for exerting influence. You need to be able to articulate your long-term vision in the language of each stakeholder, then deliver within twelve months. #pepr20

Things can change, so your organization should re-evaluate its risk acceptance over time. When you choose to accept risks, make sure to set an expiration date. #pepr20

Make sure to document how things are done. Keep it factual and focused on the risks and opportunities, it will be important if you need to document compliance. #pepr20

Cheat sheet for advisors! Listen. Ask questions and absorb the information. Help think through the problem. Offer information about the options. Follow up (do the work after the meetings). #pepr20

To reach senior leadership, you will be expected to be able to give advice on the spot. Make sure you do the work to make that possible. #pepr20

For senior leadership: Prepare three doable options. One option is to do nothing, and mention this before the lawyers do to avoid anchoring the conversation there... #pepr20

Offer the option of doing *something more*. #pepr20

(We've seen this technique. Great to have such a clear explanation of it. This is good advice.) #pepr20

Question: Doesn't always focusing on the bottom line create the same problems as focusing on compliance?

Answer: If the question is, won't we still have diminishing returns? It depends on who you're trying to influence. #pepr20

If you work for a for-profit company, focusing on the bottom line is your job. You have to. In the public sector, not so much. So recognize what your stakeholders care about. #pepr20

Question: What's different for people who work on privacy from a perspective of internal influence, since you're from an external org?

Answer: Depends on your goals. You have to build connections across teams, and recognize the unofficial hierarchies. #pepr20

Some orgs have a very strict culture of hierarchies and titles. You have to operate within that.

Other orgs have more fluidity and titles have less impact on relationships. More wiggle room about how you collaborate. #pepr20

Question: Leadership wants concise, clear ideas. As an individual contributor with a computer science or engineering background, you don't get to practice that skillset. How do you develop it?

Answer: It starts with your peers. Never go to a meeting without a plan. #pepr20

Have those 3 doable options for every single conversation that you're in. Prepare for meetings in advance. Know why you're there and what your role is. #pepr20

Question: Can you give examples of "doing something more"?

Answer: A personal example from Uber, already public. Uber decided to collect location data from riders up to 5 minutes after a trip ended. #pepr20

They made the announcement but didn't have the capability yet. They took a huge PR hit! Despite not being able to use the data for anything. #pepr20

It took the privacy team 8 or 9 months to get that rolled back, business-wise. Note that they weren't even collecting the data, just suffering from the perception that they were! #pepr20

When they finally convinced the business to make an announcement of the rollback, the privacy team talked to the CSO (? is that the right one) and advocated to make an additional public commitment on top of the rollback. #pepr20

They arranged to talk to Reuters about their ongoing commitment. #pepr20

Question: (missed it)

Answer: Privacy won't win every single debate, there are trade-offs. We can't let perfection be the enemy of progress. Need to accept iterative changes and keep building on it. #pepr20

The business is always changing, the goalposts are always changing. So having the relationships is the most critical thing. #pepr20

Question: How do you approach situations where teams feel like even if they internally live up to promises, the public will assume they're lying?

Answer: Understand when that perception is actually impacting your business. #pepr20

The PR reality is that most companies can survive a negative news cycle. However, trust is hard to rebuild.

Help teams understand that when they are accepting privacy risk, that is a long-term commitment that they are taking on. #pepr20

It's not about headlines, it's about trust. It's about your peers, your competitors, your regulators... not about *your* voice, because when things go wrong, it won't be you who's asked about whether to trust you. #pepr20

And... that's it!!! There will probably be chat on the Slack, and there's a survey for attendees. The conference will start again tomorrow at 8am US/Pacific! #pepr20