10:17:46 <RRSAgent> RRSAgent has joined #approximate-geolocation
10:17:50 <RRSAgent> logging to https://www.w3.org/2025/03/26-approximate-geolocation-irc
10:17:50 <breakout-bot> RRSAgent, do not leave
10:17:51 <breakout-bot> RRSAgent, this meeting spans midnight
10:17:51 <breakout-bot> RRSAgent, make logs public
10:17:52 <breakout-bot> Meeting: Approximate geolocation
10:17:52 <breakout-bot> Chair: Matthew Reynolds
10:17:52 <breakout-bot> Agenda: https://github.com/w3c/breakouts-day-2025/issues/5
10:17:52 <Zakim> Zakim has joined #approximate-geolocation
10:17:53 <breakout-bot> Zakim, clear agenda
10:17:53 <Zakim> agenda cleared
10:17:53 <breakout-bot> Zakim, agenda+ Pick a scribe
10:17:54 <Zakim> agendum 1 added
10:17:54 <breakout-bot> Zakim, agenda+ Reminders: code of conduct, health policies, recorded session policy
10:17:55 <Zakim> agendum 2 added
10:17:55 <breakout-bot> Zakim, agenda+ Goal of this session
10:17:56 <Zakim> agendum 3 added
10:17:56 <breakout-bot> Zakim, agenda+ Discussion
10:17:56 <Zakim> agendum 4 added
10:17:56 <breakout-bot> Zakim, agenda+ Next steps / where discussion continues
10:17:57 <Zakim> agendum 5 added
10:17:57 <breakout-bot> Zakim, agenda+ Adjourn / Use IRC command: Zakim, end meeting
10:17:57 <Zakim> agendum 6 added
10:17:57 <breakout-bot> breakout-bot has left #approximate-geolocation
10:25:34 <tidoust> tidoust has joined #approximate-geolocation
20:58:53 <antosart> antosart has joined #approximate-geolocation
21:02:53 <RobSmith> RobSmith has joined #approximate-geolocation
21:04:32 <Ian> Ian has joined #approximate-geolocation
21:05:16 <Ian> -> https://github.com/explainers-by-googlers/approximate-geolocation/blob/main/README.md#proposal Explainer
21:06:13 <tara> tara has joined #approximate-geolocation
21:06:22 <scheib> scheib has joined #approximate-geolocation
21:08:04 <reillyg> reillyg has joined #approximate-geolocation
21:08:28 <reillyg> present+ Reilly_Grant
21:08:34 <reillyg> present+ Matt_Reynolds
21:08:40 <reillyg> present+ Alvin_Ji
21:08:45 <reillyg> scribe+
21:09:02 <reillyg> present+ Vincent_Scheib
21:09:13 <reillyg> present+ Ian_Jacobs
21:09:22 <tara> present+
21:09:54 <reillyg> Ian: Here to see what's coming up from an anti-fraud perspective.
21:10:15 <reillyg> Tara: Interested in what we can do about precision from a privacy perspective.
21:10:23 <reillyg> present+ Antonio_Sartori
21:10:41 <reillyg> present+ Rob_Smith
21:11:09 <reillyg> Rob: I work on synchronizing video with location and member of the Open Geospatial Consortium.
21:11:27 <reillyg> RRSAgent, please draft the minutes.
21:11:27 <RRSAgent> I'm logging. I don't understand 'please draft the minutes.', reillyg.  Try /msg RRSAgent help
21:11:42 <Ian> RRSAGENT, make minutes
21:11:43 <RRSAgent> I have made the request to generate https://www.w3.org/2025/03/26-approximate-geolocation-minutes.html Ian
21:12:53 <reillyg> present+ Hongchan_Choi
21:13:00 <reillyg> present+ Jack_Hsieh
21:13:19 <reillyg> present+ Marijn_Kruisselbrink
21:13:57 <Ian> (This is a proposal that would be brought to the WebApps WG or a joint effort)
21:14:23 <npdoty> npdoty has joined #approximate-geolocation
21:14:25 <reillyg> present+ Nick_Doty
21:14:49 <reillyg> Ian: Have there been any conversations with payments industry folks yet?
21:15:47 <reillyg> Matt: Nothing externally, but this came up internally to Chrome's implementation of payments.
21:16:09 <reillyg> ... I aware that there are regulatory requirements but am unfamiliar with the details.
21:16:22 <npdoty> q+ on civic address
21:16:53 <Ian> q+
21:16:54 <reillyg> ... There are many ways to coarsen location. I have looked at at least one way that Android has done this.
21:17:02 <reillyg> ack npdoty
21:17:02 <Zakim> npdoty, you wanted to comment on civic address
21:17:44 <reillyg> Nick: Civic address, one of the considered alternatives, was specced out at one point.
21:18:24 <reillyg> ... It may be easier for users to understand civic address (e.g. city or state) rather than a fuzzed lat/long.
21:19:07 <reillyg> 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.
21:19:16 <reillyg> ... That will make it easier for applications to adopt these changes.
21:19:17 <RobSmith> q+
21:19:26 <reillyg> ack Ian
21:19:28 <npdoty> harder for the application to continue to use its same functionality
21:19:44 <npdoty> but applications often get themselves super into trouble when they get a coarse location that's represented as a lat/lon pair
21:19:56 <reillyg> Ian: For fraud detection something like "is this not the usual location of this device" is useful.
21:20:29 <reillyg> Matt: We should consider more use cases in this proposal.
21:20:30 <Ian> See this proposal in the Anti-Fraud CG for example => https://github.com/antifraudcg/proposals/issues/18
21:20:51 <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)
21:20:56 <reillyg> ... Saw a proposal from Martin at Mozilla of providing the user with a choice of nearby locations to provide to the site.
21:21:25 <reillyg> ... However, we want to use this API in contexts where we don't know how to populate that list.
21:21:35 <reillyg> ack RobSmith
21:22:05 <reillyg> Rob: Civic address gives users a good intuition on how to classify the coarseness.
21:22:22 <npdoty> q+ misunderstanding by app/recipient
21:22:30 <npdoty> q+ to note misunderstanding by app/recipient
21:22:36 <reillyg> ... We can stick with lat/long, but use civic address concepts those to classify precision.
21:23:29 <reillyg> Matt: That seems reasonable. The location fudger approach is to quantize everything to a grid, which provides square regions.
21:23:53 <reillyg> ... This is a good alternative to make the arbitrary grid more understandable.
21:23:57 <reillyg> ack npdoty
21:23:57 <Zakim> npdoty, you wanted to note misunderstanding by app/recipient
21:24:36 <reillyg> Nick: The other concern with lat/long, which you argue is a compatibility advantage, could be a drawback.
21:25:05 <reillyg> ... If a developer gets a lat/long they could assume it has higher precision than it actually has.
21:25:30 <reillyg> ... E.g. returning the centroid of the state.
21:25:54 <RobSmith> q+
21:25:59 <reillyg> ... Could lead to unpredictable bad behavior.
21:26:15 <reillyg> Matt: We provide an accuracy value, but applications may ignore it in how they display the data.
21:26:44 <Ian> -> https://maps.google.com/pluscodes/ Plus Codes
21:27:12 <reillyg> 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.
21:27:34 <reillyg> Nick: There's no getting around developers making mistakes.
21:28:52 <Ian> RRSAGENT, make minutes
21:28:53 <RRSAgent> I have made the request to generate https://www.w3.org/2025/03/26-approximate-geolocation-minutes.html Ian
21:28:59 <reillyg> ack RobSmith
21:29:26 <reillyg> Rob: The accuracy field in the Geolocation API seems more about measurement. Perhaps a separate "quality" factor.
21:29:26 <npdoty> the geopriv documents may be very useful here: https://datatracker.ietf.org/wg/geopriv/documents/
21:29:37 <npdoty> both in terms of defining civic address and different categories of places
21:29:45 <npdoty> and some good detail on fuzzing location and why it often doesn't work
21:30:22 <tara> q+
21:31:08 <reillyg> Matt: Instead of a numerical value, could we provide an enum which maps to civic address concepts?
21:31:20 <reillyg> ... Perhaps this would be harder to ignore.
21:32:34 <reillyg> Reilly: I don't see the benefit of an additional field.
21:33:00 <reillyg> 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.
21:33:04 <reillyg> ack tara
21:33:18 <Ian> present+ Martin_Thomson
21:33:34 <mt> mt has joined #approximate-geolocation
21:33:40 <reillyg> Tara: How much is your design constrained by legal requirements around preciseness?
21:33:42 <mt> q?
21:34:07 <reillyg> present+ Martin_Thomson
21:34:49 <reillyg> Matt: That is definitely a challenge. We want to be able to request something safe that will meet legal requirements.
21:35:16 <reillyg> Ian: What are the signals you're getting on this?
21:35:25 <reillyg> Matt: Negative signals from Mozilla. Neutral from Safari.
21:35:55 <reillyg> Martin: There's a long history with this sort of thing.
21:36:13 <reillyg> ... Any of the methods I'm aware of to fuzz geolocation fail from a privacy perspective.
21:36:25 <reillyg> ... Presenting this as a privacy feature would be a mistake.
21:37:07 <npdoty> q+ on longitudinal
21:37:14 <reillyg> ... There are additional cues which defeat fuzzing, particularly when location is provided over time.
21:37:38 <reillyg> ack npdoty
21:37:38 <Zakim> npdoty, you wanted to comment on longitudinal
21:38:27 <reillyg> 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.
21:38:42 <reillyg> ... For one-time requests it can be useful.
21:39:16 <reillyg> ... Perhaps don't allow it for watchPosition() and have protections against repeated requests.
21:39:23 <mt> https://datatracker.ietf.org/doc/html/draft-thomson-geopriv-location-obscuring-03 attempts to solve for the movement thing, which ultimately fails
21:39:37 <reillyg> Matt: We control how frequently the API provides positions and could track movement explicitly.
21:40:22 <reillyg> q+ to discuss the guarantees we're giving to users.
21:40:34 <reillyg> ack reillyg
21:40:34 <Zakim> reillyg, you wanted to discuss the guarantees we're giving to users.
21:40:37 <Ian> (Interesting idea: Always return same point in area each time the data is returned)
21:41:07 <RobSmith> q+ to mention previous guidance geospatial document
21:41:08 <npdoty> there's still a danger when you have coffee in the same place and it's near the border of two cells
21:41:27 <mt> q+
21:41:34 <tara> reillyg: how are we communicating to users that they may be signalling different things to a site (in terms of location)
21:42:06 <tara> ...if I am trying to buy from a Home Depot, I might only need to reveal what city I am in.
21:42:33 <Ian> ack Rob
21:42:33 <Zakim> RobSmith, you wanted to mention previous guidance geospatial document
21:42:36 <tara> ...if I am driving around buying tools in various cities, that's a different pattern (history)
21:43:17 <reillyg> Rob: The group I'm involved with is Spacial Data on the Web. I contributed to a "responsible use of geolocation data" document.
21:43:22 <Ian> -> https://www.w3.org/2024/11/sdw-wg-charter.html Spatio-temporal Data on
21:43:23 <Ian> the Web Working Group charter
21:43:27 <RobSmith> https://w3c.github.io/sdw/responsible-use/
21:43:40 <reillyg> -> https://w3c.github.io/sdw/responsible-use/
21:43:50 <reillyg> Rob: This was written to provide practical guidance.
21:44:10 <reillyg> ... From different perspectives: developer, user, legislator, other
21:44:56 <reillyg> ... The "other" category turned out to be the largest. Included "passive use". E.g. CCTV cameras in a shopping center.
21:45:55 <reillyg> ... It's not always obvious what passive information (e.g. the user is posting vacation photos) could be abused for.
21:46:10 <reillyg> ack mt
21:46:51 <reillyg> Martin: There's an inherent presumption that Home Depot needs to know where you are in order to provide the choice of nearest store.
21:47:44 <reillyg> ... I would like to think of this problem as one of who get's to decide.
21:48:03 <reillyg> ... The website could publish a list of locations and the browser could choose which is closest.
21:49:19 <reillyg> Matt: That's a very positive way of looking at it, similar to how we approach privacy for other device APIs we work on.
21:49:34 <RobSmith> q+
21:49:36 <reillyg> ... It doesn't work for a use case where there isn't a list of items to choose from.
21:49:37 <npdoty> q+ to raise support choosing which information to present
21:49:46 <Ian> RRSAGENT, make minutes
21:49:48 <RRSAgent> I have made the request to generate https://www.w3.org/2025/03/26-approximate-geolocation-minutes.html Ian
21:49:54 <reillyg> Martin: Do you have an example which doesn't invoke picking from a list.
21:50:25 <reillyg> Matt: A search engine doesn't know which items to present until it's done the query.
21:50:35 <npdoty> maps apps often have a list of locations to choose from, including an option about current location
21:50:57 <npdoty> (home, the last three places I searched for, work, the city)
21:51:25 <reillyg> Martin: This seems tractable.
21:51:43 <reillyg> ... There aren't that many coarse grid locations on the globe.
21:54:38 <reillyg> ack RobSmith
21:54:54 <reillyg> Rob: Would a two-step process be a solution?
21:55:19 <reillyg> ... 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.
21:55:33 <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.
21:56:13 <mt> This comes back to a basic sort of PIR design, which might involve some amount of leakage.
21:56:23 <Ian> q?
21:56:27 <Ian> zakim, close the queue
21:56:27 <Zakim> ok, Ian, the speaker queue is closed
21:57:09 <reillyg> Reilly: Question on how to implement such a scheme for a large data set.
21:57:36 <reillyg> Martin: An example such as "all dog groomers across the planet" is a tractable private data retrieval problem.
21:57:43 <reillyg> ack npdoty
21:57:43 <Zakim> npdoty, you wanted to raise support choosing which information to present
21:57:44 <npdoty> https://www.w3.org/TR/privacy-principles/#support-choosing-info
21:58:50 <reillyg> 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.
21:59:13 <mt> This comes back to the <input type=geolocation> idea
21:59:21 <RobSmith> Apologies. Have to run to my own session. Great discussion. Bye for now
21:59:27 <reillyg> ... E.g. people look up information about places that they are going to, rather than where they currently are.
21:59:53 <mt> ...and we are at time, thanks all.  Sorry I had to miss the first half.
22:00:04 <Ian> RRSAGENT, make minutes
22:00:06 <RRSAgent> I have made the request to generate https://www.w3.org/2025/03/26-approximate-geolocation-minutes.html Ian
22:00:20 <reillyg> Matt: That is very compelling and has worked for other APIs. I'm curious how we could apply it to Geolocation.
22:00:20 <reillyg> RRSAgent, make minutes
22:00:21 <RRSAgent> I have made the request to generate https://www.w3.org/2025/03/26-approximate-geolocation-minutes.html reillyg
22:00:27 <reillyg> scribe-
22:00:41 <Ian> RRSAGENT, make minutes
22:00:42 <RRSAgent> I have made the request to generate https://www.w3.org/2025/03/26-approximate-geolocation-minutes.html Ian
22:08:16 <reillyg> reillyg has left #approximate-geolocation
22:15:11 <Ian> RRSAGENT, set logs public
22:15:18 <Ian> Ian has left #approximate-geolocation
22:58:55 <tidoust> RRSAgent, bye
22:58:55 <RRSAgent> I see no action items