The Honor Code of Data: Privacy-First Design

Protecting customers’ information is about gaining their trust. Privacy is about safeguarding that information. It is what drives confidentiality. Privacy is the customer’s expectation that what they supply will be used appropriately. Someone who posts to Twitter or LinkedIn will have different expectations than someone who uses Facebook. Though all are social media applications, the audience for each post varies.

Confidentiality is the promise that a company makes to ensure that privacy is maintained. Remember, confidentiality is a fundamental component of a secure system.

Designing for privacy adheres to a basic principle: the user does not implicitly consent to any and all use of their data. Software companies are obliged to protect all customers based on the application’s intent. If the product team is questioning why data protection is necessary, they have already eroded the client’s trust.

Privacy considerations begin as the user enters data into the system. The user interface can inadvertently disclose information. Understanding how the user interacts, which fields may need to conceal data, and how much information to reveal in error messages are just a few considerations. In an educational system, the context dictates different privacy needs. A student changing their password on a profile page faces different privacy considerations than a teacher creating an assignment, or a parent reviewing their child’s grades.

After data entry, securing the data for retrieval is essential. The security measures will vary greatly depending on the path from the user interface to the data’s final location. Writing data to disk requires less security than transmitting data to a server with many potential vulnerabilities. In our educational system example, various computers lie between the user and the data’s destination, requiring protection throughout the entire workflow.

The same level of protection applies when data is stored. It must be secured so that if someone gains access, the data appears as indecipherable. If an unauthorized person logs into a database or reads a file, the contents should appear as nonsense. How to utilize this protected dataset will be explained separately. You might wonder how an application can be functional if it cannot be searched, or how teachers can grade student papers without the ability to read to the submissions. We will address the technical methods for reading and searching data later. For now, our focus is on the principles of designing a secure system.

Before addressing the management of stored information, we must consider access permissions. This is encapsulated in the concept of “Deny by Default,” where the system blocks actions unless a user has verified rights. For example, a student cannot read another’s homework unless it’s part of a collaborative project and they are in the same group.

Many practices exist for managing access to information and systems, all falling under the principle of “Least Access Privilege.” This means granting users the minimum necessary privileges. A student might wish to adjust their grades, but only a teacher has that authority. The ways in which a system manages these roles vary, and we will discuss privilege management methods in a subsequent section.

With an understanding of how to design for privacy, we can now progress to the principles that prevent unauthorized viewing of student grades.