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.


TripIt permission page

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.


PePr flow

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

Some of these scopes translate naturally into GMail API queries 5, 6.

Scope GMail API query
gmail-readonly-last30days q=newer_than-30d
gmail-readonly-label-public q=label:public

Other scopes may require more work on the PePr side, e.g. topic classification or redaction.

Challenges and Future Work

The biggest challenge is of course trust, i.e. to convince service providers like TripIt to start using a service like PePr instead of talking directly to Google and to convince users to trust PePr.

At Cornell Tech, we are using PePr to rewrite some of our applications 7 and make them more "privacy conscious". We are looking at email, location and small data streams in general.

We hope that this work will also convince data providers like Google to offer finer granularity access via richer OAuth scopes.

Stay tuned for more development.

Comments and feedback are welcome at foundry-comments@cornelltech.io.

References