Private by Default

Learning Library Design Patterns
,
#1

Problem

We need to share and communicate information, but once privacy is lost it can’t be recovered. How do we balance these competing demands? How do we plan for the future where old encryption algorithms can easily be broken? How do we conquer this fear of losing our privacy and maintain a healthy level of sharing and interaction?

Solution

@artbrock gave this advice during the Hackathon in Amsterdam. Don’t store anything private on a public DHT! He explained it with the example of health data: Imagine a health app that lets you share your data with your doctor and vice versa.

In the main DHT of the app you only store rights management data. So when you grant your doctor access to the metrics of your smart watch for example - only that permission is stored on the public DHT. The data from your smart watch however is being stored on a private DHT that is only shared by your own devices and maybe a few trusted people (e.g. family). No unknown third party will ever process it. The doctor stores all her data on her own private DHT, that is only being stored on her devices. The permission you saved on the public DHT of the app now lets the doctor copy the data in question from your private DHT to her private DHT, peer-to-peer. At no point did your data reside on the device of an unknown, untrusted party.

The main reason behind this is, that some time in the future our current encryption keys might be broken. Therefore, even if you encrypt your stuff, you should consider any information on a public DHT insecure. Hence the rule: Try to never save any private data on a DHT

What is private data? Anything that doesn’t need to be public right now. Holochain will allow for needs and implementations to evolve over time and it will be much better to expose and authorize the capability when you actually need it in the future rather than creating a weakness to be exploited in the present. When you decide something needs to be public absolutely and forever, then you can rest assured you have explicitly ruled out the need for privacy.

Implementation

TBD

Warnings

TBD

Related Patterns

If something private needs to be shared with a single agent who might not be online you can take some additional risks and use Asynchronous Private Messaging and Mailbox. You can create DHT’s with limited membership with patterns like Member Whitelist and Membership by Invitation.

1 Like
Asynchronous messaging, small groups and encryption
#2

I should note that I don’t feel sufficiently experienced to write these patterns, but hopefully putting these out there will help engage others to correct and complete them. I’m open to backing off if this is creating too much confusion in this important resource.

#3

@abrahampalmer thank you so much for jumping into the fray; this is exactly what I hoped would happen. I want this to be a space for co-evolution, so every contribution is valuable IMO. Gonna give it a more critical read soon! Just finished, and I want to say that this is a really well-written framing of the need and the pattern. I want to edit for structure, but I’m a bit worried about Discourse’s editing flow — would love to be able to fork and submit a pull request rather than editing directly!

Here are the thoughts:

  • There’s an opportunity to abstract the implementation of privacy; we could talk about private DHT with trusted friends vs private source chain entries and the strengths/weaknesses of each. These could even be written up as their own patterns and linked from here.
  • I feel like some of the stuff in ‘Solution’ could be moved to ‘Implementation’ but I’m not sure what yet.