– DRAFT –
Geolocation and Privacy

Matthew Reynolds is chairing

Slideset: https://docs.google.com/presentation/d/1bwtIGafSj2oBeXRT1vjI0e9HexW1l-Tcsb_svKPrETQ/edit?slide=id.p#slide=id.p and archived PDF copy

mattreynolds: A lot here but I care more about some of these than others.

let's review the immediate history of this starting all the way back in the 1998 mobile web access workshop

8 years ago we formed the geolocation working group to get the API working.

<npdoty> questions I'm still thinking about from our last breakout conversation:

<npdoty> why not civic address/administrative category?

<npdoty> how are we going to convince developers not to use centroids or assume the lat/lon is precise?

GML group has been developing ways to represent geolocation data.

PIDF format is used to represent geo information and has been worked on by a few groups

[slide] At the joint workshop in 2000 for WAP-W3c - user and subscriber privacy were different things. And locational privacy was not well domained yet

Agnostic about legal and policy issues in 2000 but that is changing now.

Who owns location information was an important topic. These days we think about it as being the user. But devices may have different properties at different times and the employer owns your location data in specific contexts.

[slide] IETF GeoPriv group

Location estimates will often have to travel through multiple parties to create a location estimate. How are privacy concerns passed through these different entities who handle the data.

<geopriv> element would have locaiton info and usage rules that contain the policy requirements with different flags

There is also notes that are human facing.

[slide] A process for obscuring location in IETF GeoPriv

<npdoty> usage rules! a "policy aware web" they called it.

Generally agreed: Withholding location data entirely is the only way to really ensure it is not recovered

[slide] Civic Location at IETF GeoPriv

Civic Address seems better than lat/long for understanding what is going on and is easier to approx

You can just delete things off the bottom of. this object to reduce accuracy.

[slide] GeoXACML from the Open Geospatial Consortium

Precision and allowing transformation are interesting privacy considerations but not super relevant.

[slide] Geolocation on the early web

IP table always possible.

Google had a clientLocation via ajax and a Gears browser add-on

Gears used Wi-Fi APs and cellular nodes

<npdoty> I'm loving this blast from the past history. Skyhook! Google Gears!

Mozilla did something similar with Geode but paired with site permissions to determine emitted accuracy.

[slide] Gear Geolocation API 2008-2011

[slide] Mozilla Geode (2008-2009)

Mozilla had a fuzzing algorithm but did not bring that into the final version in firefox, determined it was not effective.

[slide] 2008 spec discussions

Who is responsible for privacy is a big discussion. Who gets to handle it. Does it get delegated? Must we concern ourselves with it in the API. Eventually the user agent is decided to take responsibility

Can browsers leverage geopriv?

If we build it into the API maybe the gov't can enforce laws for this?

We decided not to do that.

[slide] Location accuracy / uncertainty

Instead of giving a point and uncertainty value, give a boundary ?

<npdoty> it was rather a heated, controversial decision when the Geolocation WG finally decided to reject all the policy/rules approach

enableHighAccuracy did end up making it into the spec

[slide] Civic location

Considered a civic object and rules but didn't happen

<npdoty> my long ago predecessors at the Center for Democracy & Technology spent a lot of time and effort, but browser implementers refused not just the geopriv ruleset, but also anything similar

If the civic address were part of the spec the web dev would not have to create their own lat/long civic address lookup. Unclear that there was actually a use case.

[slide] W3C actual location APIs

Geolocation WG - Geolocation API and attempted a geofencing API

Geolocation WG ended 2017

Device and Sensors WG picked it up. In 2018 took up the Geolocation Sensor API

Current proposals - <geolocation> element & approx geolocation

[slide] Geofencing API

Approximate location as a boundary but abandoned

[slide] Geolocation Sensor API

Goal: Geolocation API with better ergonomics and consistency

But privacy considerations don't seem to address the location specific concerns effectively in this proposal.

[slide] Geolocation Sensor API

Better integrated with permissions API and has promises

The security and privacy considerations for the geolocation sensor API seems like it doesn't have a lot there

[slide] <geolocation> element

Make permissions more accessible, secure, less ui spam

PEPC privacy considerations.

User interaction is required to reuse a one-shot element - we can set watch to false when you just need to get location once.

Autolocate use case - user agent can choose how to handle the requests with a different UI for instance.

[slide] Approximate geolocation

Goal: Reduce risk associated with sharing precise location information. This is what most sites likely want and users would want to downgrade.

Most location providers already support obfuscation. iOS/MacOS, Windows, Android,

The problem is we can't enforce privacy constraints on the existing tools from the browser perspective

and also each platform makes its own rules about location "corsening" and when new locations are generated.

If you have too many locations you can reduce accuracy but get a bunch of locations and narrow down your element

This sort of fuzzing is not always useful in securing users' locations

[slide] Future work?

Location APIs that don't expose coordinates - Civic location API, location-based chooser API.

Chooser that doesn't actually reveal the user's location, just the closest object from a set of geo located objects. This might be useful.

Location sources without a third party - GNSS, IP geolocation Database, Network geolocation database.

A database on your own device about nearby networks that approx location might be useful.

<npdoty> I think the threat was that if you request location using multiple platforms at once and they don't use the same fuzzing algorithm, then you can average the results to figure out where the user is. I think potentially we could integrate with OS APIs to make sure that any consumer of the location uses the same fuzzed result, with the same frequency

<npdoty> limits.

Queue open

John Wilander from Apple Webkit: We might want to allow the user to lie intentionally about their location

<npdoty> https://w3ctag.github.io/privacy-principles/#support-choosing-info

mattreynolds: Have heard this before, just give the user a chooser

The user should be in charge of their location and obfuscate it at will is implied by the privacy principles.

Fake location for testing might be an opportunity.

Thomas from Criteo: If there is an implementation that can provide specific fake locations is there a legal concern?

Wilander: The site may pressure you if it is aware of how coarse the user is making their data

<npdoty> some people would like it to be illegal for the user to provide non-current location information. that would be an extreme violation of privacy and free expression, and I don't know of any such laws today.

mattreynolds: the permission estimate we're looking at will tell you what the accuracy mode is

Wilander: users may need to be able to lie about that too

Gerhard: A flawed use case we are struggling with - the user as an attacker

Someone has phished credentials and is now attacking you. and I want to log in as you as an attacker.

Now a lot more attacks with social engineering - someone calls you, asks that you are you, using security information and using app consent to get you to say yes.

We see 'you are trying to log in from Wherever' and the user can see that

and potentially counter social engineering attacks.

The person approving it vs logging in locations can be used to prevent attacks.

Potentially place a location cookie? I want to set a cookie that says I am logged in from X location successfully.

When the request comes in to say 'user does not have the successful location cookie' we can trigger enhanced security.

Looking to see just that he is at a location where previous ceremonies have been successful

banking app / site might be a way to think about it.

<dveditz> An attacker of this type doesn't have to be using a legitimate browser; they could use a VPN to change their IP address and a hacked browser that lies about location.

Trying to make sure that it is a new location, not that there is a specific location

<npdoty> attackers are extremely unlikely to voluntarily report that they are in a new and unusual location

Logged in at this location is the context interested in.

mattreynolds: Not so sure about this but user agent should be a location from the user and if the user wants to fake a location than they should be able to do so.

Gerhard ack

npdoty: what we have written in the privacy principles is that APIs we design should not purport to be promises about a truthful position. If the site wants a position from the user and the user wants to give their current location based on geo location then the user is not making a promise to the website that 'i swear I'm here' and sites should not expect that when planning on dealing with attackers.

Otherwise we'd end up with very invasive technology.

We just don't want to give promises that we are doing that. It locks away some things but opens up a lot more possibility like 'I want to search for things where I'm traveling tomorrow' etc...

Support using the information that the user wants to present. Don't trust the user that they are giving you an accurate location. If you want definitive accuracy - ask someone other than the user.

gkok: From netflix. Just a question to better understand - the user can eventually set their own location? Netflix and many other companies are obligated by contract to gate content to geo. Does this means that the ability to do this via browser is going away b/c user can say they are in another country? The location is the thing the user sets? Even through this is possible through a VPN right now, is this something the browser

supports natrually?

mattreynolds: this is already a thing. But not a fake IP address.

gkok: Is this dealing with obfuscating the IP address?

mattreynolds: there are other efforts for that

Gerhard: Apple does this already down the the specific city.

gkok: If this obfuscation happens and the IP happens then you don't need a VPN anymore to change your location from your real one.

<npdoty> Apple's private relay feature (and some others) which choose a different IP address try to use an IP address from a similar city or region

mattreynolds: often it is not possible to obfuscate past a particular level

<Zakim> npdoty, you wanted to consider problems where the site doesn't understand precision

npdoty: one of the problems that comes up is that sometimes the site - the recipient of the information - is not well prepared to handle inaccuracy. They get a lat/long back and they can put a dot on the map and don't think much about it.

Precision field in the current API isn't well considered by sites / devs

Do we have ideas for how we can help the site developer to understand that the precise looking data is not precise.

We shouldn't send back rough data and make it look precise if possible, even the best meaning developer will hurt the user experience by trying to give them precise data

I don't have a good answer on this

mattreynolds: me either

Apple as an example snaps to a location near you. That seems pretty good.

Wilander: iCloud relay will, by default, maintain general location - general city. It can also say 'use country and time zone' which makes it much less accurate, but for the Netflix use-case works

Gerhard: attackers often come from other countries so that is still better.

Gerhard: when we started looking at the same time we'd see that the locations that are city-wide seem specific but they are not, they are mapped to specific public spaces.

<npdoty> Kashmir Hill did great reporting on this, about a lat/lon that's in the centroid

We've all heard about the misconceptions about geolocation and lat/long like the tale of the farm

https://www.kashmirhill.com/stories/internet-mapping

<Zakim> npdoty, you wanted to comment on civic address

npdoty: If the data just came back atlanta instead of the city hall in atlanta you'd be less likely to think you are getting an exact location

I wonder if we could do something like Civic address

or just change what is returned to the app to use a subobject that makes it clear it is an approx location

mkwst: Mike from Google - making locations approx has different implications in different places. In cities the approx of location means less because there is a lot of people. With sparser population areas there are less places to put it up against as the 'fake' location.

mattreynolds: Android considers this with larger grid cells for rural areas then cities.

<npdoty> some legal regulations have also tried to include this: no more precise than X distance, or only in a place where there are at least 10,000 people

This relies on pop density that isn't public information right now, but it could be, and the device could use it to do similar coarseness on-device without checking in with a server

Another thing might only fuzz one of the lat/long pair.

mkwst: political regions might have different regulations and some of those are very small.

mattreynolds: that's a big risk too, state of RI is very different from state of CA

we should be wary b/c it is only as approx as the size of the region.

npdoty: on the user side - people know that about their admin regions.

If you are in a small country the user knows that there are implications.

Anonymity can be complicated by that but we should think the user understands this

Gerhard: The attractiveness of the population density of millions is attractive from a familiar location standpoint. That is fine to hide in a larger group. We want to aid the client in making a risk decision and EU vs Vatican City is very different in that regard.

<npdoty> Aram: it would be great as a developer to not have to resolve (reverse geocode) lat/lon myself

AramZS: it would be great to not have to deal with resolving lat/long to a location myself as a dev

gkok: knowing that this is likely much less precise and if you need high precision the developer might build a prompt to suggest higher precision in exchange for a better user experience

mattreynolds: IP geolocation sometimes is not good enough for even basic stuff like restaurants near you

User being able to give accurate enough location data for the right context is important.

Tomorrow in the Joint Session between webapps and device sensors group will discuss this more.

RSSAgent, make minutes

RSSAgent end this meeting

Zakim pointer

RSSAgent, end this meeting