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-last30daysfor access to inbox emails from the last 30 days
gmail-readonly-label-publicfor access to inbox emails tagged
gmail-readonly-topic-travelfor access to inbox emails classified as
gmail-readonly-pg13for access to inbox emails where bad language has been removed
|Scope||GMail API query|
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 firstname.lastname@example.org.
Pokémon Go tops Twitter’s daily users, sees more engagement than Facebook, S. Perez, July 2016. ↩
"‘Pokémon Go’ Creator Closes Privacy Hole But Still Collects User Data,", N. Olivarez-Giles, WSJ Online Article, 13-Jul-2016. ↩
U. Erlingsson, A. Birgisson, J. G. Politz, Ú. Erlingsson, A. Taly, M. Vrable, and M. Lentczner, "Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud," in Proceedings 2014 Network and Distributed System Security Symposium, San Diego, CA. ↩