Written by    and   

 As you pull off the turnpike, you notice the dreaded flashing red and blue lights of a police cruiser signaling to pull over. You know you were obeying all of the traffic laws, but the officer says that must not have been true at some point on your journey - you’ve arrived too soon, and will be issued a speeding ticket. The electronic toll transponder in your car allows you to pass through toll booths without stopping, but in addition to calculating your toll it also records the time and location your car entered and exited each toll booth. The officer informs you that the only way you could have arrived at this booth so quickly is if you exceeded the speed limit at some point.

Thankfully, this potential capability was purposefully not exploited in real life - it would reduce overall utilization of toll roads! However, electronic toll transponders have certainly been used for more than just calculating tolls. For example, the New York Department of Transportation set up transponder readers in cities to conduct traffic studies. Users of the system understandably react negatively, as their consent to use a transponder to calculate and automatically pay turnpike tolls did not extend to additional data collection and monitoring - a violation of their expectation of privacy. This raises a broader question: how can systems be designed such that they achieve their purpose while also protecting the privacy of users?

In this blog, we will provide you with an overview of the core Privacy by Design principles, as well as a real-world use case walkthrough of how product teams can implement the principles into a system. Privacy by Design principles have guided the Product Data Privacy team in creating a Product Data Privacy Framework for system development at ADI. By raising awareness of these principles, we hope to encourage engineers to begin discussions around data privacy and protection early in the lifecycle. To make Privacy by Design principles actionable to product teams, we illustrate their application in a real-world use case.

The nuances surrounding data privacy and data protection vary by regulation, standard and locale, but the underlying principles and sentiment remain the same. According to the General Data Protection Regulation (GDPR), data protection refers to ensuring the safety of data against unauthorized access. Data privacy refers to enabling the user to make decisions with regards to who can process their data and for what purposes. Data privacy and protection have implications at the system, infrastructure, and organizational level. 

As global awareness of data privacy has grown, the importance of implementing privacy protection into the design of products is now required by regulation. GDPR, for instance, places requirements around implementing Privacy by Design and Privacy by Default into systems. State laws within the United States, such as the California Privacy Rights Act (CPRA), are also incorporating these principles to ensure both consent mechanisms and appropriate security protections are in place for products from inception. 

As requirements around privacy in system development continue to grow and evolve, product teams must take steps to not only ensure that they are compliant, but ahead of the game.

ADI launched the Product Data Privacy group with the goal of helping teams implement privacy practices and provide training and awareness around incorporating privacy into all stages of product development. The Product Data Privacy group is launching policies, processes, and best practices around implementing Privacy by Design and Default into ADI’s development lifecycles.

The figure below lists the seven privacy principles first outlined by Cavoukian in 2009 [1]. Since its inception, several regulations, standards, and best practices documents have extended these basic principles.  

  • The proactive not reactive principle requires considering privacy from the start. The emphasis is on having best practices, policies, and frameworks in place instead of reliance on lessons learned from breaches.
  • Privacy by default means the maximum degree of protections are delivered at all times. This means the customer could take no action and their privacy would remain intact. Major mechanisms include:
    • always having a purpose for the collection, storage, and processing of data
    • ensuring users understand, and consent to, why and how you are using their data
    • limit data collection to what is fair, lawful, and only what is needed
    • make non-identifiable interactions and transactions the default
    • securely destroy personal information in a timely manner
  • Privacy embedded into design implies that privacy is a core feature within a product. We must follow a repeatable process for assessing and mitigating privacy risks. Having a formal methodology for data protection impact assessments, artifacts for documenting privacy design decisions, and mapping of privacy requirements and data through the development lifecycle are all crucial.
  • Full functionality means privacy should work with (positive sum), not against (zero sum), other requirements. Stakeholder requirements should be laid out in parallel with privacy requirements so that both are met. Discussions of privacy vs. functionality should be mitigated or rejected whenever possible. When done correctly privacy will enhance a product, not hold it back.
  • End-to-end security refers to the need for security protections to ensure the privacy of data. Accepted security standards should be applied to product development to maintain the confidentiality, integrity, and availability of the private data in a product at all times.
  • Keeping it open is an essential part of maintaining accountability and trust. Stating that the purpose and processing of personal data is consistent with what was consented by the user is not enough - the implementation must match, including portions handled by third parties.
  • User-centricity requires that we keep the users’ needs in mind. For example:
    • Consent - Informed consent is required. The lack of consent cannot result in a lack of functionality for the user. The ability to withdraw consent is crucial. 
    • Accuracy - Ensure means for keeping the data up-to-date. 
  • Access and Compliance - Users should have access to their personal data, the ability to challenge the validity of the data, and public mechanisms to submit complaints.

Are you interested in how this can be achieved in practice? Stay tuned for our second blog post Privacy by Design: ADI Principles in Practice which will be released next week.

References 

  1. Cavoukian, Privacy by Design: The 7 Foundational Principles 
  2. Gurses et al., Engineering Privacy by Design
  3. Balasch et al., PrETP: Privacy-preserving Electronic Toll Pricing. In 19th USENIX Security Symposium, 2010. 
Anonymous