The Foundry @ Cornell Tech

Spice-up your Personal Privacy with PePr

16 August 2016

by Arnaud Sahuguet & Jai Chaudhary.

Privacy is a myth?

PokemonGo is one of the tech phenomena of this summer, with more daily users than Twitter and more time spent on the app than Facebook 1. It also started on a very bad privacy note, with the mobile app asking users for full access to their Google account 2. And PokemonGo is not the only one.

TripIt is a trip-planner service. By scanning your email for travel-related purchases (hotel, airline tickets, train tickets, etc.), TripIt can create a consolidated itinerary for you. One way to achieve that is for you, the user, to let TripIt access your inbox. Here is what access TripIt requires from you.

You don't need to be a computer wizard to realize that the access requested is way too broad. It is not clear why the service would need more than the ability to read email in order to perform the task.

Service providers (like TripIt) often request way more than they need because it's easier than asking for less. And data providers (like Google for your email) often do not offer the right kind of access control for the data you want to share.

As a result, you – the user – are forced to write a blank check, hoping that everything will be fine.

What you really want

In his talk about macaroons – the cryptographic tool 3, 4, not the baked good –, Úlfar Erlingsson of Google uses a valet parking analogy to describe this kind of delegation: you need to hand over your car keys to the valet, for them to park your car.

But with the keys, they can do so much more: open the car, open the trunk, open the glove box, turn on the entertainment system, access the GPS system, start the car, drive the car, etc. They can also chose never to return your car.

In a better world, you would like to pick and choose the capabilities you give to the valet, to make sure they can accomplish their mission (parking your car), but not more. Going even further, you may want to restrict access both in terms of time and location (geo-fence) and make sure the keys cannot be handed to another person.

Going back to our GMail inbox example, the kind of restrictions you would like to enforce include:

read-only access to email

access restricted to emails within a date range, e.g. last 30 days

access restricted to emails from certain folders (labels for GMail)

access restricted to emails about certain topics

access to emails where part of the content has been redacted or transformed, e.g. account numbers, location, project names, etc.

In the end Tripit parses the emails looking for travel receipts. Wouldn't it be better for that filtering to happen on the already-trusted platform?

PePr, your Personalization Proxy

An obvious solution to the TripIt problem is for TripIt not to access the data directly but rather via a proxy that provides access to the underlying inbox data, with the restrictions mentioned above.

In the current model, TripIt uses OAuth to access the user's inbox, on behalf of the user.

In the PePr model: (a) TripIt now talks to PePr instead of Google; and (b) PePr defines new OAuth scopes that offer finer granularity access.

From an implementation point of view, PePr simply needs to provide OAuth support: as an OAuth server when talking to TripIt, as an OAuth client when talking to the Google API.

Here are some scopes we have been playing with:

gmail-readonly-last30days for access to inbox emails from the last 30 days

gmail-readonly-label-public for access to inbox emails tagged public

gmail-readonly-topic-travel for access to inbox emails classified as travel

gmail-readonly-pg13 for access to inbox emails where bad language has been removed