Meeting minutes
<Ian> Explainer
Ian: Here to see what's coming up from an anti-fraud perspective.
Tara: Interested in what we can do about precision from a privacy perspective.
Rob: I work on synchronizing video with location and member of the Open Geospatial Consortium.
<Ian> (This is a proposal that would be brought to the WebApps WG or a joint effort)
Ian: Have there been any conversations with payments industry folks yet?
Matt: Nothing externally, but this came up internally to Chrome's implementation of payments.
… I aware that there are regulatory requirements but am unfamiliar with the details.
… There are many ways to coarsen location. I have looked at at least one way that Android has done this.
<Zakim> npdoty, you wanted to comment on civic address
Nick: Civic address, one of the considered alternatives, was specced out at one point.
… It may be easier for users to understand civic address (e.g. city or state) rather than a fuzzed lat/long.
Matt: For this proposal we haven't looked at that. We're looking at lat/long so that it can be consumed by applications that expect the current form of the data.
… That will make it easier for applications to adopt these changes.
<npdoty> harder for the application to continue to use its same functionality
<npdoty> but applications often get themselves super into trouble when they get a coarse location that's represented as a lat/lon pair
Ian: For fraud detection something like "is this not the usual location of this device" is useful.
Matt: We should consider more use cases in this proposal.
<Ian> See this proposal in the Anti-Fraud CG for example => antifraudcg/
<npdoty> (cite: many many articles where people show up at specific addresses, because it's at the center of a certain rectangle, not realizing that it's not precise)
Matt: Saw a proposal from Martin at Mozilla of providing the user with a choice of nearby locations to provide to the site.
… However, we want to use this API in contexts where we don't know how to populate that list.
Rob: Civic address gives users a good intuition on how to classify the coarseness.
… We can stick with lat/long, but use civic address concepts those to classify precision.
Matt: That seems reasonable. The location fudger approach is to quantize everything to a grid, which provides square regions.
… This is a good alternative to make the arbitrary grid more understandable.
<Zakim> npdoty, you wanted to note misunderstanding by app/recipient
Nick: The other concern with lat/long, which you argue is a compatibility advantage, could be a drawback.
… If a developer gets a lat/long they could assume it has higher precision than it actually has.
… E.g. returning the centroid of the state.
… Could lead to unpredictable bad behavior.
Matt: We provide an accuracy value, but applications may ignore it in how they display the data.
<Ian> Plus Codes
Vince: Varying degrees of precision are possible with Plus Codes, but the failure mode is still that the developer will convert it to lat/long which still has deceptive precision.
Nick: There's no getting around developers making mistakes.
Rob: The accuracy field in the Geolocation API seems more about measurement. Perhaps a separate "quality" factor.
<npdoty> the geopriv documents may be very useful here: https://
<npdoty> both in terms of defining civic address and different categories of places
<npdoty> and some good detail on fuzzing location and why it often doesn't work
Matt: Instead of a numerical value, could we provide an enum which maps to civic address concepts?
… Perhaps this would be harder to ignore.
Reilly: I don't see the benefit of an additional field.
Matt: It could be used to describe the information on a way that isn't tied to the radius of a circle on a map.
Tara: How much is your design constrained by legal requirements around preciseness?
Matt: That is definitely a challenge. We want to be able to request something safe that will meet legal requirements.
Ian: What are the signals you're getting on this?
Matt: Negative signals from Mozilla. Neutral from Safari.
Martin: There's a long history with this sort of thing.
… Any of the methods I'm aware of to fuzz geolocation fail from a privacy perspective.
… Presenting this as a privacy feature would be a mistake.
… There are additional cues which defeat fuzzing, particularly when location is provided over time.
<Zakim> npdoty, you wanted to comment on longitudinal
Nick: I would recommend looking at the geopriv guidance. I don't necessarily agree with all Martin's conclusions, but I do agree that fuzzing has to be very sophisticated to work with data over time.
… For one-time requests it can be useful.
… Perhaps don't allow it for watchPosition() and have protections against repeated requests.
<mt> https://
Matt: We control how frequently the API provides positions and could track movement explicitly.
<Zakim> reillyg, you wanted to discuss the guarantees we're giving to users.
<Ian> (Interesting idea: Always return same point in area each time the data is returned)
<npdoty> there's still a danger when you have coffee in the same place and it's near the border of two cells
<tara> reillyg: how are we communicating to users that they may be signalling different things to a site (in terms of location)
<tara> ...if I am trying to buy from a Home Depot, I might only need to reveal what city I am in.
<Zakim> RobSmith, you wanted to mention previous guidance geospatial document
<tara> ...if I am driving around buying tools in various cities, that's a different pattern (history)
Rob: The group I'm involved with is Spacial Data on the Web. I contributed to a "responsible use of geolocation data" document.
<Ian> Spatio-temporal Data on
<Ian> the Web Working Group charter
<RobSmith> https://
https://
Rob: This was written to provide practical guidance.
… From different perspectives: developer, user, legislator, other
… The "other" category turned out to be the largest. Included "passive use". E.g. CCTV cameras in a shopping center.
… It's not always obvious what passive information (e.g. the user is posting vacation photos) could be abused for.
Martin: There's an inherent presumption that Home Depot needs to know where you are in order to provide the choice of nearest store.
… I would like to think of this problem as one of who get's to decide.
… The website could publish a list of locations and the browser could choose which is closest.
Matt: That's a very positive way of looking at it, similar to how we approach privacy for other device APIs we work on.
… It doesn't work for a use case where there isn't a list of items to choose from.
Martin: Do you have an example which doesn't invoke picking from a list.
Matt: A search engine doesn't know which items to present until it's done the query.
<npdoty> maps apps often have a list of locations to choose from, including an option about current location
<npdoty> (home, the last three places I searched for, work, the city)
Martin: This seems tractable.
… There aren't that many coarse grid locations on the globe.
Rob: Would a two-step process be a solution?
… You first make a request with a coarse location, it sends back a list, then the client knows the fine location and can sort that list.
<npdoty> I like Martin's brainstorming. I think he's imagining that the weather site says here's a list of all the rendered dom elements, and the browser can choose which ones are relevant to the user and should be rendered.
<mt> This comes back to a basic sort of PIR design, which might involve some amount of leakage.
Reilly: Question on how to implement such a scheme for a large data set.
Martin: An example such as "all dog groomers across the planet" is a tractable private data retrieval problem.
<Zakim> npdoty, you wanted to raise support choosing which information to present
<npdoty> https://
Nick: Choosing information to present means designing APIs not to communicate a fact about the user but to allow the user to choose what they want to query about.
<mt> This comes back to the <input type=geolocation> idea
<RobSmith> Apologies. Have to run to my own session. Great discussion. Bye for now
Nick: E.g. people look up information about places that they are going to, rather than where they currently are.
<mt> ...and we are at time, thanks all. Sorry I had to miss the first half.
Matt: That is very compelling and has worked for other APIs. I'm curious how we could apply it to Geolocation.