Thread by @LeaKissner

First up at #PEPR21 "Privacy for Infrastructure: Addressing Privacy at the Root" by Joshua O’Madadhain and Gary Young from @Google.

Because hey, privacy is a full-stack problem, from humans and the societies they build all the way down to the hardware. Infrastructure is key.

Both Josh and Gary have been at Google for "a while" (I think that's about 15 years each) and are both wizzes when it comes to privacy, especially in infrastructure.

Infrastructure is systems that provide other systems or products with capabilities [not the security kind]

Types:
* storage systems
* network systems
* data processing systems
* server frameworks
* libraries
* system integrations
* etc.

Data-agnostic system
* it's not aware of the types of data which it handles. Used because generality, simplicity, avoiding responsibility ("we just handle data, it's the client's job to do it right")
* related concept: data processor vs controller

Note that if the system is data agnostic, it's effectively responsible for making sure that client teams know how to use it correctly, because the infrastructure can't handle privacy issues.

Why infrastructure privacy reviews?
* can't we just review the products rather than the infra?
* scaling: solving privacy at the infrastructure level benefits *all* users of *all* clients

To look at:
* what (user) data does the product handle (collect, read, white, process)?
* what does the product use the data for?
* where is the data stored? For how long?
[missed one]

for infra: also, how does the infra help its clients meet their needs

Infra privacy concerns
* data: client provided (what kinds of data? is data-agnostic?) vs system generated (usage logs, error messages)

* clients: who are the current and intended clients? (how does the system know?) how many clients can the system handle? (how much time does it take to get clients into a good state?)

* use cases: what categories of data are in scope (personal data?)? current uses? planned uses? possible uses? (could unplanned use cases present privacy issues?)

* access control: how is access to the system controlled, how do clients control access to their data? is access to the data logged? (who, what when, how, why -- people who manage a system should not have unfettered access to it)

* retention/deletion: how can clients delete data? how long does each step of deletion take? [this stacks through different layers of a stack or pipeline]

* meta: what infrastructure does the system depend on? is it properly configured?

Configuration and cost externalization?
how much configuration is needed by clients to achieve a good privacy stance?
1. Zero config (bad stance not possible across everything)
2. good privacy stance by *default*

3. good privacy stance *requires per-client configuration/code* -- who does this work? clients? infra team? both? how difficult/specialized is this?
4. good privacy stance not possible [don't be here]

Build vs buy in infrastructure

Build:
+ can be tailored to your requirements (including privacy)
- requires time and investment

Buy:
+ off-the-shelf, (mostly) predictible costs
- less visibility into/control over privacy stance

Even leading infra may have a bad privacy stance!

Infra privacy warning signs:
1. negotiating with infrastructure teams only indirectly through clients
2. evaluating infra using product focus
3. undocumented infra standards & expectations
4. assume off-the-shelf infra will satisfy bespoke privacy innovations/commitments

5. infra goals not aligned with client goals
6. with great power comes great vulnerabilities: turing-complete is not your friend. Can be used for literally *everything*. Hard to make safe.
7. uncontrolled externalized of privacy costs onto clients [or privacy team]

Future of infrastructure privacy review
* systemization: identifying, documenting, and applying common solutions
* infrastructure-oriented risk frameworks
* annotation and automation

[like any livetweet thread, this isn't a complete transcript -- don't forget to check out the #PEPR21 talks live or the videos afterward!]

Q: When is it a good idea to let go of control of your data and give it to a 3rd party?
A: If and only if you think they can meet your needs better than you can. It depends on your in-house expertise -- some companies have a lot more of it than others.

Evaluating that is beyond the scope of this talk ;)

Q: What about API as contract?
A: Example: think about a deletion API. You might want in the documentation how long it takes a deletion to show up and complete [remember that when you tell a database to delete isn't when it removes the data]

Q: Do you have examples of an API with a privacy contract?
A: ... I can think of some internal ones but haven't seen this happening externally. Sorry.

Q: Data categories and annotations and how they flow through infra -- how build a data map?
A: we think it's important that systems which allow large-scale storage of untyped data is important, but can fall back to the idea of having the metadata on the container

For example, tagging the schema [note that schema isn't sufficient and Gary isn't being limited there]. The infra doesn't need to care about the semantics of the tags, just need to identify certain values.

Josh points out that you need tags at different levels: column, row [e.g. "this user's data can only be in X location" or "this is especially sensitive"]

Q: what are some techniques to avoid backup data showing back up when it's supposed to be deleted?
A: First: tags around backups so it can only be used for system integrity -- can't go back to use it for other purposes.

[Note: look into the data deletion talks later in the conference -- the trick here is that your data deletion system should keep looking for data which should be deleted and keep doing it. That way it handles backups and other kinds of failure.]