Sharing data in the sharing economy

Controlling access to sensitive information in decentralized marketplaces — with NuCypher’s latest partner, Origin Protocol.

The world’s largest taxi company owns no vehicles. The world’s largest accommodation provider owns no real estate. Etc.

If Origin Protocol realizes its ambitions, we can update the clichés. The world’s largest taxi company will own no cars, but also no driver or rider data. The biggest accommodation provider won’t run big hotels, nor big server farms. To many, this is the inevitable future of P2P marketplaces — where citizens transact services and goods without intermediaries to manage the platform, set and maintain policies, accumulate data, and of course, take a hefty commission for their trouble. Instead, they leverage decentralizing technology — smart contracts, distributed storage, consensus mechanisms — in order to fully self-govern.

Origin’s vision is a plurality of these marketplaces, each purpose-built for a unique service (e.g. freelance design work, lodging, a ride from A to B) — but with crucial underlying functionality in common. In most marketplace set-ups, renters and rentees need to create and edit listings, discover one other, filter lists of offerings based on chosen criteria, reserve assets ahead of time, transfer payments quickly and securely, and rate and review following a usage period. Instead of each domain-specific marketplace building out these functions from the ground up, they can harness Origin’s protocols — a generic layer focused on the transfer of data and value. You can find out more in their technical white paper.

From NuCypher’s point of view, the aforementioned functions throw up a range of privacy challenges, most of which are tractable, all of which are interesting. Before we dive into a real-world flow, it’s worth mentioning another exciting aspect of this partnership. Origin’s role as a protocol — with over 30 applications already scheduled to develop on top — means that together, we’ll be aiming to generalize secure data sharing workflows across a diverse set of use cases.

Origin’s enviable partner list, as of April 2018.

Public neighbourhood, private address

But for now, let’s stick to one domain. This section walks through a decentralized Airbnb user flow, and examines some hypothetical privacy requirements.

1. Host creates apartment listing.
   The existence of the listing and basic details (host name/alias, listing name) should be viewable by everyone, and hence can be stored in distributed storage in unencrypted format.
2. Host adds supplementary information to the listing.
   - Photos, extended descriptions, etc. — these would likely be public, as above.
   - The apartment’s street address would need to be inextricably connected with the listing entity — so it couldn’t be changed post-booking— therefore it’s probably hosted in the same directory. However, it’s expedient to keep it obscured at this stage of proceedings. We’ll come back to this.
   - Data derived from the address — e.g. the neighbourhood where the apartment is situated, its distance from public transport, etc — this information is useful to prospective guests, but not sensitive, and therefore would likely be public. However, this probably means that the marketplace application (or more likely, a maps API) must be granted access to the host’s address, which may be undesirable. The alternative is the host independently adding this information, which is both extra work, and may tempt exaggeration.
   - The apartment’s calendar availability could have rather nuanced privacy requirements. It may be preferable to a host to limit access to their calendar to genuinely interested guests. Each calendar query could come in the form of desired period submitted by the guest, returning the binary result of bookable/non-bookable. This set-up would require a one-to-many sharing scheme where the data recipients are not always known in advance. With a standard public key scheme, the host would have to be online to approve new inbound requests for access.
3. Guest and host communicate.
   This is a one-to-one chat, which should almost certainly be private and secure. Again, a public key scheme would be adequate, but with certain limitations. For example, it would be tricky to revoke access to the open channel of communication, if the host/guest became abusive, started sending spam, or began using it for an inappropriate purpose.
4. Guest books/pays for the apartment.
   Ideally, the reservation, or attempted reservation, should solely be shared with the host, lest the whole world know one’s intended travel plans. Of course, payment details on both sides would have to be entirely secret and secure. However, publishing some metadata related to the reservation and payment to a distributed ledger may help maintain the integrity of the network, by serving as proof that a listing actually hosted the number of guests that it claims to have.
5. Guest receives check-in instructions.
   This package generally includes the exact street address, directions, parking details, door key-codes, etc. In paying for the accommodation, the guest has effectively purchased temporary access to this data, for them alone. Access is often time-sensitive — imagine booking a room a few hours before arriving, but having to wait for the host to come online before you got the address.
6. Following stay, guest leaves a rating and review.
   As mentioned in 4), the integrity of the listing universe would be boosted by a public, immutable review system — where subsequent guests could browse through historical ratings, and be certain that they were provided by guests who actually stayed. Private feedback between the guest and host is a nice-to-have.
7. During a stay, there is a dispute between host and guest.
   Leaving aside the broader issue of involving a central arbiter, whatever/whoever is determining fault and compensation (whether it is the local authorities or network validators), will have to have private data (relating to the engagement) shared with them in order to arrive at a conclusion. This is again, one-to-many sharing.

Clearly, there are a raft of varying, nuanced privacy requirements associated with decentralized marketplaces. This doesn’t only apply to short-term rentals of lodging — see the appendix at the bottom for some more examples from other types of marketplace.

Decentralized KMS + decentralized Airbnb

Fortunately, proxy re-encryption is a viable solution in many, if not all of these cases. Taking the private address + public neighbourhood challenge, we could harness NuCypher tech in the following way:

1. The user registers as a host on the marketplace platform. The application generates a unique key pair for that host. Among other things, this means it can securely receive data from the host, without permanently storing it.
2. The host enters their apartment’s street address whilst creating a listing. For now, this is encrypted into ciphertext and seen by no-one other than the host.
3. The host then approves that the marketplace application will have temporary access to the street address, and that this access is only available while the application is yielding useful information to improve their listing. After that, it is to be immediately revoked.
4. This triggers the generation of a special re-encryption key, securely constructed from the host’s private key and the application’s public key, both created earlier when the host registered.
5. The re-encryption key is split and sent to multiple proxies (nodes in the NuCypher network), which perform a specific transformation service. Once this is complete, the application’s requests for access to the apartment’s street address are accepted, and so the application can temporarily see and use the address in certain functions.
6. The application performs some operations with the street address, yielding various pieces of useful information, such as a map of the neighbourhood in which the apartment is located, the nearby amenities, the distance from public transport, etc.
7. The completion of 6) causes the proxies to delete their key fragments, thereby revoking the application’s access to the host’s street address.
8. The useful information (neighbourhood, etc.) is automatically added to the listing page. Prospective guests benefit from this information, and can also be certain that this information was derived from the actual address they will be staying at. The host gets more bookings.

NuCypher can help generate equivalent information on a trustless Airbnb.

Though it may seem a little esoteric, this kind of approach would actually enable a decentralized Airbnb to provide much of the value-adding platform features and functions that have helped establish the dominance of the actual Airbnb — without having to trust the application to hold sensitive user information. If it seems a little complicated, that’s because it is!

In the interests of keeping this piece as short as possible, I will resist the temptation to explore how NuCypher could solve other privacy challenges alluded to in the previous section —but look out for a follow-up post.

Nonetheless, I hope this piece begins to illustrate the challenges, and vast promise, of invoking NuCypher technology in the context of decentralized, peer-to-peer marketplaces. There’s no doubt Origin Protocol is taking the right approach in seeking to generalize these hard-fought solutions across a wide variety of domains, and we’re very excited to join them on that journey!

Appendix

Examples of private data with sharing requirements, by marketplace.

Domestic work (plumbing, carpentry, etc.)
House address, job details.

Highly-skilled work (UX design, web development, etc. )
Completed jobs, company information, NDAs, code samples.

Travel/culinary experiences
Meeting points, special requirements.

Taxi service
Driver location, rider location, route, items left in car

Food delivery
House address, order details.

Education (tutoring, etc.)
Course material, grades, personal feedback.

Co-working spaces
Entry passcodes, meeting room bookings.