Privacy-As-Code: Correcting TikTok’s $92M BIPA violation using Fides Open-Source | by Cillian Kieran | Ethyca

Privacy-As-Code: Correcting TikTok’s $92M BIPA violation using Fides Open-Source

Cillian Kieran
6 min read
· May 19, 2022

We’re applying open-source devtools to the most high-profile privacy cases in recent years. This time, we build a solution to a landmark case in biometric privacy and purpose specification.

Press enter or click to view image in full size

Using Fides to enforce privacy policies in the codebase

Introduction

We spend a lot of time at Ethyca talking about the future of privacy. It makes sense; the Fides open-source privacy engineering platform promises a future where true Privacy by Design is achievable for any business, with any type of technical infrastructure. But in seeking to illustrate just how that future could differ from today’s status quo, it’s useful to look at recent high-profile privacy cases, and show how applying Fides could have led to a different, better outcome for users and businesses.

For example, if you were TikTok in 2019, Fides could have rooted out a certain type of unlawful data use pre-deployment, before offending code ever handled user data. And by doing so, it could have prevented the privacy violations that led to a $92M fine from the State of Illinois.

TikTok’s violation under BIPA

When it comes to privacy laws in the United States, BIPA is a heavyweight, in large part because it’s one of the few US privacy laws that gives a private right of action; individuals have the right to sue a company for violations. Beyond its enforcement features, BIPA places tight technical demands on how companies must respect biometric identifiers and biometric information of Illinois residents. The law defines a biometric identifier as:

a retina or iris scan, fingerprint, voiceprint, or scan of hand or face geometry.

And BIPA defines biometric information as:

any information, regardless of how it is captured, converted, stored, or shared, based on an individual’s biometric identifier used to identify an individual.

With these categories of personal information, BIPA contains strict requirements on how companies must collect users’ opt-in consent to process this information. Companies must also respect a suite of other restrictions on biometric data processing, retention, disclosure, and more.

As the 2019 TikTok lawsuit points out, biometric privacy is particularly high-stakes since the information involved is often immutable. While I can change my password or my home address, I’m not going to be able to change my fingerprint.

Looking at Section 15(c) of BIPA:

No private entity in possession of a biometric identifier or biometric information may sell, lease, trade, or otherwise profit from a person’s or a customer’s biometric identifier or biometric information.

Now, you might contend that this data use can be viewed as integral to the particular defendant’s business model, rather than an unfortunate misalignment between product and legal stakeholders… and you may well be right! But it’s also very easy to imagine the misalignment scenario. Indeed we know that at some of the world’s largest companies, privacy engineers are lamenting that:

“We can’t confidently make controlled policy changes or external commitments such as ‘we will not use X data for Y purpose.’ And yet, this is exactly what regulators expect us to do.”

So the example of TikTok and BIPA proves a very suitable candidate to demonstrate Fides’ privacy engineering power. With this context, I’m going to use Fides to proactively flag any code that could violate Section 15(c). In other words, the CI pipeline will have an automatic check that any code handling a biometric identifier or biometric information — I’ll hereafter group these as “biometric data” — cannot be used for any of the cases prohibited above.

Examine our policy

As with the Facebook/FTC example I discussed in my previous post, let’s translate the legal requirement into a technical guardrail on the codebase. The Fides policy would be:


Fides Policy to enforce correct use of biometric and health data – Medium

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters

# Policy for valid use of biometric and health data
policy:
- fides_key: biometric_data_policy
name: Biometric Data
description: Policy that describes valid uses of biometric and health data.
rules:
- name: Disallow Biometrics for Profit.
description: Disallow the use of biometric data for profit-related purposes.
data_categories:
matches: ANY # If any of these data categories are being used
values:
- user.derived.identifiable.biometric_health
- user.provided.identifiable.credentials.biometric_credentials
- user.provided.identifiable.biometric
data_uses:
matches: ANY # And the use of the data is for any of the following...
values:
- advertising
- train_ai_system
- improve
- third_party_sharing
data_subjects:
matches: ANY # And the data subject is a customer
values:
- customer
# And the data is identifiable, trigger a violation
data_qualifier: aggregated.anonymized.unlinked_pseudonymized.pseudonymized.identified

With these pieces together, this policy could be summarized as:

If any form of customers’ biometric data is processed for purposes of advertising, training an AI system, improving a product, or sharing with third parties; then trigger a violation in the automated privacy check.

This policy, in tandem with up-to-date annotation of the codebase’s privacy behaviors (here is how a dev can do that), becomes an indispensable tool in aligning the tech stack with modern laws like BIPA. There are myriad organizational and governance benefits to integrating privacy checks into the CI pipeline, and proactively flagging code for non-compliance cuts out the technical debt that makes privacy improvements elusive for so many companies today.

Conclusion

Ultimately, users deserve systems that are trustworthy: systems that behave as users expect them to. The common thread of the biggest privacy stories is that companies break their promises around personal data processing. Even when engineers deeply care about users and seek to respect their data, it can be an uphill battle to keep track of loose ends across complex data infrastructure. An incomplete picture of data context and data control can cause even the best-intentioned team to expose users to significant privacy risks.