Blockchain Team, Early Privacy Discussion Summary


The Blockchain Team met for a privacy discussion on Feb 18, 2020. The discussion was prompted by a draft of a features list for the Liberty Platform reference client, which raised some questions about desirable features, possible features, and how these could affect user privacy.

The understandings that came out of this discussion start with the need to identify the areas in the platform that need to be considered when discussing privacy.

The discussion focused almost entirely on the privacy questions that arise around tagging people - in photos or any other post.

We identified possible sources of privacy leaks:

  1. The blockchain itself - smart contracts and messages that are stored on chain
  2. DSNP - messages that are archived or gossiped throughout the network
  3. Us App and Reference App, i.e. applications that Project Liberty controls
  4. Liberty Foundation approved apps
  5. Applications using Liberty SDK
  6. Well-intentioned applications
  7. Ill-intentioned applications
  8. Network abusing applications
  9. Leaks due to user error, misunderstanding, or ignorance
  10. Intentional leaks by users

We also need to see the potentially conflicting interests:

  • PrivacyUser, the user that wants privacy and control vs. EasyUser, the one that wants convenience, transparency and freedom
  • PrivacyUser vs. Application developers that just want to serve EasyUser
  • DSNP’s designed use vs. an Application’s actual use
  • Liberty Foundation vs. Application developer needs and desires (to wit, profit motive).

Within this framework of understanding, we refocused the privacy discussion around tagging users.

On the DSNP, but not on chain

Allowing tagging of users to be part of the DSNP protocol - though not on chain explicitly - is useful to the platform and possibly to users; given that the point of the platform is to give people the ability to quit one application while still owning their data. A user that decides to change apps – for any reason – on the platform shouldn’t have to recreate all their data. On the other hand, users may not know that their social identity that they use through one app may also show up on another. Users have many reasons to keep their social activities separated and will need to know that their social identity activity can be viewed across applications. Most users are not used to this idea. Being able to tag somebody else may identify them in a space they don’t want associated with them elsewhere.

Can’t control usage, but can make it harder to behave badly

There are clear limitations to what can be controlled at each level. Liberty obviously cannot control users or outside applications entirely, however, it can attempt to make it cheap and convenient to be a good actor on the platform, and expensive and inconvenient to be a bad actor. Anyone can say, in plain text, “Ang Lee is in this photo,” and an Application can certainly include data in a tag that includes whatever identifier they want, whether it’s one that is meaningful only to that application, a simple profile name, the Liberty socialID, etc.

Some ideas that could be explored:

  • A tag could be a separate metadata post, like a kind of reply
  • Tags using the Liberty socialID could be detected by a user application and the user could be prompted whether to cryptographically sign the tag, thus legitimizing it. “Honest” applications could then filter out any unsigned tags.
  • Tags could be a rotatable identifier instead of the social identity, such as a key list. If the key list is rotated, the ID loses its connection to the user.
  • Users could set preferences for if they can be tagged or not, which “Honest” applications could abide by even if other applications do not (i.e. not showing tags that include that user, even if another application allowed the tag).
  • Involve Application developers in the discussion to come up with creative ways to meet their needs that do not exploit user privacy. Help them implement solutions and where possible, enhance SDKs and the platform to make these solutions easy and convenient to use.

This also obviates the need for the Liberty Foundation in the development and dissemination of privacy (and other) standards.

1 Like

Is the reference client serving the “EasyUser” or the “PrivacyUser”?

(We could bring in some of the more specific/concrete personas we’ve been discussing recently, but I actually kind of like those two above as a first pass when discussing things at this level.)

One possibility is that the reference client serves EasyUser by default, but when PrivacyUser digs into the client’s settings, she finds a lot of things to work with – eventually, I mean. Definitely not saying the reference client should have all that stuff coming out of the gate.

The tl;dr here is I very strongly feel it should serve Privacy User. I realize that we are talking about the reference client here, however, the reference client (aka example client) needs to lead by example, in my opinion. People will fork or otherwise blatantly copy the reference client; we should make it as easy as possible for other developers to follow our lead.

So if serving “EasyUser” by default means making everything public/open by default, I very strongly recommend against that. Everything should be private and locked down, unless the user explicitly makes it not private. We can’t make everything public by default and at the same time say that we respect privacy (which is stated in our Bedrock Principles as well as our Design Principles), nor can we say that we want you to control your data (also part of our Design Principles) but then right off the bat in our example client, user data gets posted to the public sphere without telling them beforehand; this shouldn’t be done, not even in a mere reference client.

Anyway, it’s a great lead-in to building a privacy-focused app that takes you on a tour of your privacy features right away to show you how you control your content!

Agreed, especially if it’s used as a motivator to make the initial tour privacy-focused!