8 min read

Privacy Angels

This is a proposed blockchain powered online privacy standard. It came from discussions I had with Simon Deane-Johns [our lawyer at Zopa and a contributor to the Midata initiative(link is external)]. The nicer legal wording is to his credit; any design errors are to mine.

If you are unfamiliar with the ethereum blockchain and its smart contracts, take a look at this Wired article(link is external) first.

Introduction

Privacy Angels allow organisations to obey strict privacy rules at low cost. This makes it possible to combine German-style privacy laws with the more market-driven use of personal data in the English speaking world.

Angels shadow private data, allowing data subjects to observe and direct its spread. In practice, Privacy Angels would be implemented as smart contracts on the Ethereum blockchain. A single Angel shadows a single transfer of information to a single organisation (e.g. data controller). One data subject and one set of private data may have many Angels, new Angels being created as the data is transferred.

Privacy Angels are not a panacea, but do tidily solve a problem that more complex privacy standards like P3P(link is external) tried and failed to manage. By pushing the complexity from large technical specifications into “agents” on a blockchain, we now have something that can be implemented with a few (hundreds) extra lines of code. Unlike a hosted privacy service, we avoid political issues over who has control (and the ability to monetise) the "choke-point" at which the privacy policy is executed.

Blockchain-style consensus systems might seem like an anarchist nerd’s toy, but they do give us practical tools to solve thorny control issues on the open internet.

Previously we might have attempted decentralisation by having, say 30,000 developers interpret a hundred page specification consistently, so that every party might have an implementation that suited them and they could trust. Or we might, simply anoint five golden master servers and their owners. (Still how the internet’s domain naming system works.)

This much left undone that we can now begin to address.

Description

As smart contracts, Angels are computer programs and can execute arbitrary logic. Ethereum smart contracts can communicate with each other and with clients of the blockchain. Such clients could include real people, but also normal servers or relays to outside systems, for example, SMS, push notifications or email.

The state of any blockchain smart contract is completely public. Privacy Angels are observable to all, but the actual personal data they shadow are not a part of them. There is no need for an Angel to be publicly attributable to the data subject. The participitants computers will know which Angels are theirs – and this is all that is necessary for the mechanism to work.

A privacy Privacy Angel protocol needs only to standardise the format of the named organisation the Angel authorises and the fingerprint [e.g. hash] of the data it relates to. And then to define a small number of functions which allow the transfer of its data to requested and registered. Since the Angel smart contract represents a single transfer, the creation and termination of the smart contract itself can serve to mark the beginning and end of an organisation’s control over the data. All actions that change a smart contract’s state are recorded permanently on the blockchain. As such, no additional audit trail is required.

The actual logic by which the Angel determines if a data transfers should be allowed is entirely under the data subject’s control. It might check a whitelist of pre-approved organisations, contact the user for approval, look-up an organisation’s jurisdiction, etc. Although the user would probably not author the Angel’s logic themselves, they could freely choose among templates provided by third parties they trust.

This service description begins with an illustration of how Privacy Angels would operate in a typical consumer scenario involving shared personal data. The description then outlines some issues to be considered in an implementation.

The organisation name used in an Angel should follow the conventions of X.500, e.g. the same as the relevant website domain. It may be desirable for such a site to have a semantic web mark-up indicating the location of a privacy policy, but this is beyond the scope of the Privacy Angel framework.

Illustration – applying for a loan:

Suppose I make a credit application. That will include a great deal of personal information, it will also be necessary for several organisations to co-operate to issue the loan. I will be okay with this, but I’d also like to know when and where it happens and, in some cases, have a right to opt-out. So the lender’s online application form would come marked with the following bit of HTML.

<input type="hidden" name="privacyangel-for-3478rfe81" value="" />

(‘3478rfe81’ being the Ethereum ‘address’ of the loan company’s underwriting unit.) It might also be useful to specify in some fashion the organisations the Angel should approve to be practicable.

My browser has a plug-in that reads this special HTML markings and offers to create a Privacy Angel for me. I click ‘yes’. This Angel exposes only four standard methods :-

CanTransferTo( entity name ) -> Yes / No
RequestTransferTo( entity name, transferees address ) -> Privacy Angel or No
DeclareTransferTo( entity name, transferees address ) -> Privacy Angel
DeclareDeletion()
Event::Retract() // Event raised if I withdraw the right to use my information

Since I am creating the Angel smart contract, there doesn’t need to be a standard as to how I interact with it after it has been created. The behaviour may be anything I find convienient.

As previously discussed, being blockchain smart contracts, each Angel can be observed to have the following attributes :-

  • unique identity
  • an owner
  • to have been created (and possibly ended) at a certain time
  • to authorise a particular organisation

Say I choose a recommended minimal template from a selection pre-installed on my browser that only allows my information to be shared with, say, FCA-approved firms with good privacy policies. This might be read from a list placed on the blockchain by a consumer protection body. Any sharing outside those parameters would require my consent. To achieve that, the only thing the Angel needs to know is the fingerprint of the data I submit, the loan company’s identifier ‘niceloans.com’ and its ethereum address (‘3478rfe8711’ in this example). The plugin can read this information from the website and load it into the Angel as it is created.

My browser plug-in then spawns the Privacy Angel on the blockchain and fills that into the lender’s application form:

<input type="hidden" name="privacyangel-for-3478rfe81" value="98wufuery384589re" />

When I submit my application form, the lender keeps the address of the new Angel in a field in its database alongside my data.

When my loan application gets to its underwriting team, the lender will want to share my application data with a credit bureau, which is fine. So its system will call CanTransferTo( ‘ethicalbureau.co.uk’ ) to check and get back ‘Yes’. It will then call RequestTransferTo( ‘ethicalbureau.co.uk’, ‘fshgfhu11’ ) to the credit bureau.

If successful, the call to RequestTransferTo will return the address to a new Angel which will govern the credit bureau’s use of my data.

The loan company can then pass both my personal information and the address of the new Privacy Angel to the bureau. The bureau now has an Angel to call if it wants to transfer my data further.

The bureau can check that the Privacy Angel exists and that they were authorised to receive my information. If I want to check where my data is, I can simply see that my original Angel has created a single child Angel relating to each organisation – one for the lender and one for the bureau.

In a few days or years, the lender and the credit bureau each might decide not to retain my information. In this case they can each simply call DeclareDeletion() on their respective Angels. The corresponding smart contracts will terminate. This will be observable to everyone on the Ethereum blockchain.

Supposing that the lender is later audited. This typically would mean that the data about a small number of clients is transferred to the auditors. It is unlikely that such a transfer request would be automatically allowed by my Angel. In such a case, my Angel would instead ‘gateway out’ and ask me for permission (e.g. by an alert in a smartphone Privacy Angel app, or by email or text). How that might happen does not need to be standardised. In the meantime, the audit firm would know [by checking the status of the lender’s Privacy Angel on the blockchain] that they could not see my data because I was refusing and that the lender is not somehow trying to hide anything. If a court or regulator were to force the disclosure of my information by the lender for some reason (e.g. investigating potential fraud), the company can still call DeclareTransferTo( ‘fca.gov.uk’ ) to let me know.

The loan company could also used DeclareTransferTo to notify me in the event my information was stolen. For example using the “organisation name” ‘police-report:234958723’.

If a few years later I notice that the lender still has my application despite not needing it, I could cause a Retract event to be raised on the lender’s Angel and the loan company could observe this, purge my data and confirm with DeclareDeletion() terminating its Angel.

Preliminary Requirements and Next Steps

There are some components that would need to be created to allow Privacy Angels to be deployed :-

  • Ethereum (or someone similar) needs to release a final version of their programmable blockchain;
  • A template smart contract which defines the interface and all other Privacy Angels can derive from. This base contract with the elements if defined would be the Privacy Angel standard. (This would be an open standard, if only because the definition of any smart contract becomes public when it is released onto the blockchain.)
  • Some sensible default Angels derived from the the base contract - No Marketing, EEA-only, etc. It is not necessary that these be created by the same organisation originating the base Privacy Angel. Ideally this would be done by a consumer organisation such as Which?.
  • Browser plug-ins that recognise Privacy Angel protected input forms. Initially they would probably be created by the organisation releasing the base contract, but if the mechanism was widely adopted this would probably be done by the browser publishers.
  • Server-side libraries for data controlling organisation’s developers to interact with the Angels on the blockchain.

Each organisation using the Privacy Angel protocol would simply need :-

  • Access to an ethereum client API (like Etherface);
  • An Angel field in their client database;
  • A few extra lines of code using a Privacy Angels client library to call customer Angels through the Ethereum client.
if Angel.canTransferTo( “sensiblecompany.com” ):
    sensibleAngel = Angel.requestTransferTo( “sensiblecompany.com” )
    doTransferToSensible( clientInformation, sensibleAngel )
else:
   displayFallbackMessage()

Obviously the above example is highly simplified. For a realistic implementation the data controller would have to consider that :-

  • The Angel might not respond for hours
  • There would need to be similar small changes around every data transfer in and out of each participant
  • APIs would need to be altered to start passing Privacy Angel addresses
  • What are the consequences to a participant when a customer retracts an Angel?

These are different considerations to those raised by traditional privacy systems. Rather than the complexity arising from the difficulty of calculating the client’s privacy limits; the problem of calculating the limit is now externalised to the blockchain and the issues remaining for the data controller arise from reacting to changes in those limits.