Solid & E2EE: Safety by Design

Security: not a toggle switch, a tunable dial

The best security is not defined by any single criterion. Rather, it is a constant balance of naturally contrasted values, implemented through careful considerations and compromises. Solid’s personal data stores, called Pods, open up many more possibilities to balance between oppositional requirements such as 1) empowering people to share their data while 2) safeguarding people from data misuse and theft. The technical solutions and trade-offs of this Web protocol are generating exciting new possibilities of both safety and convenience. In this blog post, we explain why Solid Pods can be a cornerstone of emerging human-centered data security, above and beyond legacy controls such as the failed promises of end-to-end encryption provided by centralized data platforms.

Let us first examine why trade-offs are inherent to practicing good security. For instance, increasing confidentiality often comes at the cost of reducing availability. When we prioritize protecting personal information and safeguarding sensitive data, it necessarily limits accessibility and usefulness of the data for people. Sometimes, certain data needs to be available far more than it needs to be made unavailable (private). If I want to rent a car, it is required that my driver’s license and banking details are shared with the rental company, reducing my privacy for the specific purposes that I expressly grant. When seeking healthcare services, a doctor might need to see my blood group and any medication I have ever taken, in order to help me get the best health advice. Denying availability to achieve absolute privacy may prohibit the minimum knowledge necessary to get services or goods I need or want.

Another trade-off is that enhancing confidentiality can decrease integrity. The more measures we employ to shield data from unauthorized access, the greater the potential for challenges in data verification and steps needed to establish trustworthiness. For example, a government-issued ID provides a strong guarantee with integrity controls (signature, seals, tamper-proofness) that a person is older than 18, while at the same time also potentially disclosing more information than strictly necessary. Other proofs might provide people with more privacy, such as a happy birthday card with a date on it, yet also have far less reliability. While encrypting messages enhances privacy by preventing unauthorized access, it simultaneously introduces challenges to data integrity. The very nature of encryption, which obscures the content from anyone without the decryption key, can hinder the ability to verify the accuracy and authenticity of the information exchanged. In contrast, unencrypted communication may be more susceptible to privacy breaches, but it allows for easier verification of the data's integrity, promoting a higher level of trust in the information being shared.

The above examples show that striking the right balance is crucial — and personal. The more I share the data by making it available, the more I may be also reducing its privacy. The “CIA” triad of confidentiality, integrity, and availability is a well-known model of the trade-offs within information security. It helps us think of privacy as a personalized slider between different considerations, rather than an imaginary universal dial that just needs to be cranked all the way up.

The best security can be viewed as achieving proficiency through measured compromises, a delicate balance between oppositional values. It's not a situation where we completely lose one aspect in favor of another, but rather a continuous adjustment of priorities relative to risk of loss. There exist ways to achieve absolute privacy, such as storing your sensitive data only on your smartphone encrypted with an isolated key, guarded by your biometrics. However, when we exclusively prioritize privacy, we slide the bar away from availability to the extent that losing the phone or the key means our data is gone forever. Was that our intention? Maybe we decide after the loss it was a bad balance and we should have had a way to recover the data. Similarly, if we emphasize availability by maintaining multiple copies of our data and spreading them around, the slider moves in a direction potentially compromising certain privacy measures such as erasing specific data from all locations.  For most people and most cases, the optimal position of the slider is not in either extreme. It's about identifying the desired combination of attributes as necessary and appropriate to risks rather than an always all-or-nothing approach.

We need to ensure that privacy measures are appropriate for necessary access, and ensure that privacy does not undermine integrity of data. Good security requires a thoughtful, measured approach that weighs privacy, availability, and integrity for lowering harms. In all these cases, my Pod is able to protect my data in the ways that work best for me as well as for the betterment of society.

Striking the right balance when using end-to-end encryption

One of the “dials” in security that has been getting increasing attention since 1992 (e.g., Phil Zimmerman’s “web of trust” with PGP v2.0) is end-to-end encryption (E2EE). When does it make sense to turn encryption for privacy all the way up within Solid — and when do we need to use a balanced approach that provides encryption solutions less extremely focused on privacy alone?

E2EE brings confidentiality at a cost

E2EE in the last decade has become a common and standard security measure engineered to shield sensitive information from prying eyes. As its name implies, it employs encryption when transforming data to generate an unreadable format at the sender's device. This unreadable data should be decipherable solely by an intended recipient, ensuring that no unauthorized party in between the sender and receiver, not even service providers, can read it along the communication pathway. E2EE has been popular in messaging apps and other communication platforms, where multiple parties are meant to engage in secure and private exchange of data.

However, an extreme approach to privacy is still not a risk panacea, as we have explained how confidentiality directly affects other important needs for availability and integrity to lower risk. E2EE necessarily compromises other values aspects, and such shortcomings have to be made with caution and purposefulness.

First, the end points notoriously are still vulnerable to compromise, undermining privacy and integrity of the data by shifting threats. In other words you can still lose your data, even if others cannot decipher it while it is in transit.

Second, the debate over communication secrecy is often complex political science, influenced by societal thinking about permissions related to knowledge, like public definitions of imminent harm or crime. A key aspect of this discussion involves the idea of emergency access where availability can save lives by detecting, preventing, or responding to threats. While emergency exits in physical buildings have long been mandated for swift evacuation (e.g., preventing a repeat of the 1911 Triangle Shirtwaist Factory fire disaster), often-times end-to-end encryption implementations favor an assumption that they are best measured on ensuring complete lack of information access. However, information access is crucial in interesting and nuanced ways that also should be considered. Emergency exits have evolved to ensure individual benefits as well as a greater good can be served without excessively compromising any individual rights. In other words, can the individual use the “survival” mechanism or can emergency responders make an individual available. This conversation goes beyond just authorities needing access within a socially defined value system; it also emphasizes individuals benefiting from authorized services, including prevention of criminal activities in their digital environments. If it helps to contextualize, this is not unlike how “anti-malware” operates on data management systems to gather knowledge that serves the individual as well as broader value systems to detect and prevent threats. An emergency access provision plays a crucial role in striking a balance between individual privacy and the societal need for keeping infrastructure trusted through shared measures of harm detection and prevention (e.g. Metropolitan Police Force for London at Scotland Yard founded and run by Home Secretary Sir Robert Peel in 1829).

Lastly, it is worth noting E2EE itself often doesn’t prevent analysis of metadata used in delivery, exposing details about communication patterns and connections that can be as powerful as the knowledge within the message itself. For example phone logs of someone calling a doctor’s can reveal sensitive details about the caller without even hearing the call.

Combining E2EE and Solid

Already, end-to-end encryption on the Web works seamlessly as an implementation to enhance data privacy and security, and the World Wide Web Consortium (W3C) has played a pivotal role in extending these principles even further. A notable example is the widely adopted protocol HTTPS and the evolution of Transport Layer Security (TLS). HTTPS now is foundational for secure communication and almost taken for granted. The evolution of TLS, a protocol that ensures the security of data transmission over computer networks, is a testament to the commitment to advancing encryption standards. Connections between the user's web browser and the server are encrypted, establishing a secure channel of communication.

By setting and refining these standards, W3C ensures that the implementation of encryption technologies aligns with best practices for privacy and security. This not only enhances the protection of user data but also a more resilient and trustworthy digital ecosystem. As the landscape of online threats evolves, W3C's ongoing efforts in shaping and advancing encryption standards contribute significantly to maintaining the safety and integrity of the Web, aligning with the undeniable importance of secure communication in our interconnected world.

Solid extends the Web’s existing security mechanisms even more through protecting endpoints in the form of data access transparency (e.g. access grants) inherent to Pods, empowering users to retain control over their data. If it brings the right trade-offs for a certain case, E2EE with Pods encrypts data at its source and maintains safety throughout transit, ensuring privacy without losing integrity. Only the user and authorized entities possess decryption keys required to access the encrypted data. This implementation reinforces data confidentiality and also varying levels of user control within Solid's decentralized architecture, guaranteeing that unauthorized parties cannot gain access, even when transmitted or stored on distributed infrastructure providers to balance availability and integrity.

If Solid were a transportation network for trains, buses, or cars, then E2EE would be equivalent to individuals having a personal storage box secured with a key. The Solid Protocol aims to define rules and implementations for secure exchange of data, just as transportation networks have been designed for thousands of years based on considerations of efficiency and personal safety. Within a transit network of cars, each one can carry personal documents and assets within a protected glovebox, ensuring that data reaches its destination safely, much like Solid's goal for secure data exchange.

Likewise, E2EE operates as a specific implementation detail within the wider Solid framework for data safety, becoming progressively standard and even mandatory for data protection during transit. Solid goes further than E2EE by providing heightened security through diverse implementation choices and broader values, such as storage encryption and processing encryption, empowering users with greater control over safety measures relevant to their data. Users deposit their data into their Solid Pod, and E2EE can be configured so only the user preferences (e.g. authorized applications, services) have access to the encrypted data on a constantly monitored basis, and only ever transmitted securely with HTTPS or similar.

Conclusion: Enabling different balances through choice

There was a time when end-to-end encryption became advertised as the most compelling path to achieve a sense of security. Decades of failures later, we have learned that, while crucial in some cases, it is not sufficient as a true measure of safety. People should not be blindsided by E2EE’s gains since 1992 to the extent that they overlook significant harm and losses until it’s too late to prevent or respond appropriately to them.

Our viewpoint has always been that we should accommodate the relative position of data owners who need protection, within absolute concepts of safety from harm. Sometimes you feel comfortable giving a family member or friend the key to your house in case of an emergency. And sometimes, you will trust a plumber or housekeeper  with a key. The choice to do so, or not to do so, comes with nuance and also changes over time from experience. The same goes for your data, except that Solid allows you to make such decisions in a much more granular way for your own Pod in an ongoing and flexible way. Your choices can be different for each piece of data, for each different purpose, relative to the latest need, so you are able to create much more specific access keys whenever necessary.

After all, personal security is about striking the right balance for an individual within their groups and commitments, and Inrupt’s goal is to empower people by keeping data safe in the most meaningful and human-centric ways possible.

Appendix: Encryption in ESS today

E2EE is one of the many tools in a security toolbox. Here are some other aspects of encryption that can be used with the Enterprise Solid Server (ESS) today:

• Hardware (Full Disk) Encryption: The system hardware itself or the operating system disk management may offer encryption of everything stored on physical media.

• Container or Volume Encryption: The operating system or the volume management system may offer encryption of everything stored within containers/volumes, allowing for a more granular key control than hardware level. For example, if using Amazon Elastic Block Store (EBS), encrypt the EBS.

• Database Encryption: The database may offer encryption of everything it stores, allowing for a more granular key control than container or volume. When using cloud-managed database services, refer to the key management guidelines provided by the offering.

• File/Folder or Field-level Encryption: The operating system or database may offer encryption at the individual folder, file, or even field-level. This provides a highly granular key control, as decryption can be required for every field based on unique keys.

• Application Encryption: Applications may be written so that encryption happens before data reaches the aforementioned layers, with keys managed entirely outside the service or system that is storing the data.

• Messaging System Encryption: ESS’ services communicate with each other by sending messages through Kafka. Many Kafka deployments already offer data encryption at rest. In addition to this protection, ESS can be configured to encrypt all messages sent to Kafka.