08:39:35 RRSAgent has joined #geolocation 08:39:35 logging to http://www.w3.org/2011/09/07-geolocation-irc 08:39:39 steveblock has joined #geolocation 08:39:43 Meeting: Geolocation WG F2F 2011 #2 08:41:22 andreip has joined #geolocation 08:41:36 Present: Lars_Erik_Bolstad, W_Maslowski, Steve_Block, Andrei_Popescu, Matt_Womer, Diana_Cheng, ?? 08:45:06 thanks 08:45:19 Scribe: Matt 08:45:23 Chair: Lars Erik 08:46:11 ernesto_jimenez has joined #geolocation 08:46:13 Topic: Device Orientation 08:47:03 -> http://lists.w3.org/Archives/Public/public-geolocation/2011Jun/0059.html Geolocation V2 and backwards compatibility 08:47:03 dougt has joined #geolocation 08:47:13 o/ 08:47:28 thanks Matt! 08:48:22 steveblock: The idea was to have v2 backwards compatible: a page written for v1 will work in v2. 08:48:35 steveblock: We thought about versioning the API, but decided it would be nice not to. 08:48:45 steveblock: We thought it would be nice if pages written for v2 would work with v1 as well. 08:49:33 steveblock: So, this basically meant three things: 1. making coords optional 2. optional Position.address property and 3. add PositionOptions.requireLatitudeLongitudeAccuracy 08:50:15 dougt: I talked about instead perhaps getting back an address object. 08:50:29 dougt: On many systems there are two different subsystems, one for location, one for geocoding. 08:50:42 dougt: So, you're implementation will have to get the location, then do geocoding. 08:51:03 dougt: If it's a watch, if you do the lat/long without the address first, then when the geocoding happens get back the address object. 08:51:35 steveblock: That would require an extra round trip, which is likely to not be acceptable to developers. 08:51:46 dougt: But geocoding costs more than location typically. This would make it very explicit. 08:52:07 andreip: The one round-trip was a requirement for search for instance. 08:52:25 steveblock: I think that discussion is orthogonal actually to this. 08:52:59 dougt: The server may return long/lat, then a second JS call could return the geocoded address. 08:53:17 andreip: How would you know that it's ready? 08:53:34 andreip: We only want geocoding when we need it. 08:53:44 dougt: Then this would do that. 08:53:54 dougt: You would add another flag. 08:54:18 steveblock: If we want to return another address block we'd have to have another flag to indicate address. 08:54:24 dougt: When would location even be null 08:54:41 steveblock: The classic phone example, where they know their address but not lat/lng. 08:55:05 andreip: Right now we don't have any implementors that support just civic address. 08:55:12 andreip: Do we want to support that? 08:55:18 steveblock: I think it makes sense. 08:56:06 diana: Was there a requirement that coordinates be optional from the mailing list? 08:56:16 steveblock: I don't think so, there was just talk about how to do it in a simple way. 08:57:17 [[I think just being able to put my address into my browser would be nice. When I'm at work, it's on a wired network with no GPS, which could be a common use.]] 08:57:23 dougt: I don't like the flag, but we don't have another proposal. 08:57:41 steveblock: While it's ugly, you can pretend it's not there unless you care about these subtle differences. 08:57:47 andreip: I don't like the name, it's way too long. 08:57:51 steveblock: Could be something else. 08:58:33 Present+ Ernesto_Jimenez 08:59:05 dougt: Why wouldn't we just add a flag to positionOptions to say "fetch geocoded info if available"? 08:59:26 dougt: Then your implementation can fetch it from cache, or whatever. 08:59:38 andreip: What would you do to enable a v1 call? 08:59:50 dougt: No, I was thinking a positionOptions property "getGeocodedInfo", and everything else just works the same. 09:00:09 dougt: Then impl asks the geocoder, get civic address if you have that flag set. 09:00:33 steveblock: Then the phone case of having just address, but not coords. 09:00:55 andreip: So you'd get back the v1 object, then call a second api? 09:01:05 wmaslowski: ?? 09:01:33 andreip: The drawback to me is that I have to call a second method and then wonder why it doesn't work, if I forgot to put that option on the position object. I haven't seen APIs work like that. 09:01:40 dougt: Android does actually. 09:02:25 dougt: So, if this is the best proposal, let's work on that name. 09:02:55 dougt: Can we make this requireCoords, and then make -- 09:03:07 steveblock: This was to make coords optional, but... 09:04:05 :) 09:04:24 name of the flag would be requireCoords 09:04:38 steveblock: requireCoords being false would mean you'd have to null check all the coords. 09:04:48 dougt: How badly does it break v1? 09:04:53 steveblock: I think it's pretty bad. 09:04:59 dougt: You just have to test for lat/lng. 09:05:54 andreip: That reminds me of one thing in v1: reports of those using the API that we did for writing the IR, we found it's used quite a bit, and we can't break v1. 09:07:26 steveblock: I guess we could say something like "enableCompatibilityMode" or something, but I think it's best to be specific. 09:08:45 ^ i was hoping, but i knew it was bad. (fwiw) 09:09:14 PROPOSED RESOLUTION: We will use Steve's proposal, but will use requireCoords instead of enableLatitudeLongitutdeAccuracy 09:09:21 andreip: Everyone is fine with the IR? 09:09:36 [[no objections]] 09:09:59 rrsagent, draft minutes 09:09:59 I have made the request to generate http://www.w3.org/2011/09/07-geolocation-minutes.html matt 09:10:06 rrsagent, make logs public 09:10:36 s/Topic: Device Orientation/Topic: V2 Backwards Compatibility/ 09:13:05 Topic: Address Object 09:13:17 dougt: We shipped with what's in the Editor's spec now. 09:13:27 dougt: I would be in favor of building from that. 09:13:41 andreip: We spent a lot of time trying to map this to the GeoPRIV stuff. 09:14:07 andreip: I believe this is very close to the Microsoft proposal. 09:14:19 dougt: This is a subset of other formats and I think it's something others can digest. 09:15:04 dougt: We want to be in sync with Contacts API too. 09:15:10 andreip: We could take it from the Contacts API. 09:15:17 dougt: Or at least import it as a subset. 09:15:22 dougt: I just don't understand how this is a new problem. 09:15:46 wmaslowski: We introduced two separate formats to do the same thing, that's bad. 09:17:24 -> http://portablecontacts.net/draft-spec.html#schema Portable Contacts schema 09:17:30 [[group looks at above schema]] 09:17:41 dougt: Most of this will map directly. 09:18:17 dougt: I don't want to spend two hours talking about the address object. I'd rather say we have a subset and make it extensible and optional. Maybe have a flag for more 09:18:37 dougt: The ones I have are: street #, name, city, county, region, country, country code. 09:19:24 andreip: If the object is to be compatible with this, then we are. 09:19:39 lbolstad: The feedback I got was about the ContactAPI 09:20:09 andreip: Can we ask them why? 09:20:33 http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/geolocation/nsIDOMGeoPositionAddress.idl?force=1 09:20:38 wmaslowski: They had a long discussion about what to use. To start they had their own, then aligned with ?? and the Portable Contact guys, vCard and OMA. 09:20:41 ^^^ what mozilla shipped 09:21:00 wmaslowski: They said Portable Contacts maps most easily to those, so used those. 09:21:04 andreip: So, we're fine. 09:21:17 wmaslowski: You could have two formats, but alignment would be better. 09:21:37 andreip: Given that contacts was to be compatible with this, and theirs is a subset of ours, then it seems ok. 09:21:58 dougt: We have a format, it's a subset, but it's bigger than Portable Contacts. Not sure what else we can do. 09:22:14 steveblock: We're aiming for something simple. 09:22:20 diana: ?? 09:22:29 dougt: What would we do differently if we sent them something? 09:22:38 diana: That we should align with them. 09:22:48 andreip: Then we'd have to go back to Geopriv and realign with them. 09:22:55 dougt: I don't like looking for reasons not to move forward. 09:23:00 dougt: We should tell them what we're doing and why. 09:23:04 andreip: I'm happy to do that. 09:23:15 andreip: We had the discussion with IETF a year ago, everyone can read thta. 09:23:19 s/thta/that/ 09:24:24 lbolstad: Should we mention this in their last call? 09:24:42 dougt: Their contact format is a subset of ours. It's almost straight. They only have four or five fields that map to ours. 09:24:57 dougt: I think we pull out the street number, but you can concatenate those two. 09:25:47 lbolstad: So we build a website and get an address object, and you want to store it in your address book, then you'd have to map it. 09:26:19 andreip: Is streetAddress not the full address making the other contact fields redundant? 09:26:27 steveblock: ?? 09:26:35 andreip: So the only complete way of reading that is from the streetAddress? 09:28:41 ernesto_jimenez: I've never done the internationalization of addresses in JavaScript. 09:28:56 andreip: Ours is pretty simple though, just mapping fields to fields, not changing the data here. 09:29:01 ernesto_jimenez: Except streetAddress 09:29:12 ernesto_jimenez: Like family name and given name. 09:29:20 andreip: We also have additional information we can use. 09:30:18 andreip: We wouldn't be able to generate the streetAddress 09:31:58 matt: I think streetAddress is just num, street name, type, rather than full thing, as there's a formatted object. And that object talks about a 'street' property, so I bet streetAddress was renamed from street. 09:32:25 -> http://dev.w3.org/2009/dap/contacts/ Editor's Draft 09:32:34 wmaslowski: They removed formatted in the latest. 09:32:44 andreip: I think we're perfectly fine. 09:33:03 lbolstad: We could ask them to align theirs with ours if we care, so the mapping is direct. 09:33:18 ernesto_jimenez: It wouldn't be possible as the address format from the device is out of our control. 09:33:27 andreip: What you have here is exactly what we have minus the two fields. 09:34:01 lbolstad: Do we, as a working group, want to give formal feedback that in order to make this mapping easier, add our two fields? 09:34:33 dougt: We should do that. 09:36:26 matt: s/should/could 09:36:31 MoSCoW and all. 09:36:36 ACTION: andreip to send feedback to the DAP wg suggesting they align their Address object with ours 09:36:37 Created ACTION-81 - Send feedback to the DAP wg suggesting they align their Address object with ours [on Andrei Popescu - due 2011-09-14]. 09:36:38 s/We should/We could/ 09:37:52 ACTION: steveblock update V2 spec with requireCoords and send diff to list 09:37:57 Created ACTION-82 - Update V2 spec with requireCoords and send diff to list [on Stephen Block - due 2011-09-14]. 09:38:26 ACTION: steveblock update V2 spec with requestAddress and send diff to list 09:38:27 Created ACTION-83 - Update V2 spec with requestAddress and send diff to list [on Stephen Block - due 2011-09-14]. 09:38:44 rrsagent, draft minutes 09:38:44 I have made the request to generate http://www.w3.org/2011/09/07-geolocation-minutes.html matt 09:40:09 .. enableAccuracy... 09:40:16 dougt: Reason it's there isn't privacy. 09:40:19 andreip: Right. 09:40:41 steveblock: The idea was to maybe use it for wifi for a while, then when you get somewhere pick up higher accuracy. 09:41:01 dougt: I'd rather see a JavaScript library built on top of that... 09:41:25 http://lists.w3.org/Archives/Public/public-geolocation/2011Jul/0001.html 09:41:33 i/enableAccuracy/Topic: Proximity Alarm/ 09:43:51 lbolstad: The use case on proximity alarm would be something like a store wants to offer a coupon. 09:44:06 dougt: How would you build that? It'd be "I'm this far from this location"? 09:44:19 andreip: Get the location, calculate the distance. 09:44:24 dougt: From where? 09:44:48 steveblock: Say a store offers a coupon to popup when you're x distance from the store. You know the store lat/lng and when you get close a coupon pops up. 09:45:13 steveblock: I think the idea is to only use say wifi rather than GPS, or cache nearby cell ids, to avoid unnecessary round trips. 09:45:22 dougt: All of this is implementable with the current API. 09:45:24 steveblock: Not really. 09:45:34 steveblock: Not in one request. 09:46:12 wmaslowski has joined #geolocation 09:46:23 dougt: Anyone doing this now? 09:47:31 matt: I believe from what I've read about iOS 5 that they've got a location based reminders app that is built on APIs that do things like this. 09:47:54 steveblock: I think we've agreed that it doesn't add new functionality, but does save power. 09:48:24 andreip: You could have lots of proximity alerts and know where you are... 09:49:11 wmaslowski: You could limit it to an arbitrary number, but if you pick wrong. 09:49:30 dougt: You could opt in for a site, and say "never remind me again", then when you're annoyed by it you can opt out. 09:50:42 andreip: What information would someone provide to the API to make this work? 09:50:52 steveblock: I imagine it'd be an API call per registration. 09:51:01 andreip: So stores wouldn't use it. 09:51:54 matt: Stores aren't the only use cases. Location based reminders are pretty good use case. 09:52:02 andreip: But we're arguing whether it gives a privacy advantage. 09:52:46 wmaslowski: ?? data uri … ??? warning about … would have some privacy gain, but wouldn't be a functionality gain... 09:53:02 andreip: If I try to use the current API to do coupons, then they can't because the battery drains? 09:53:17 andreip: Any real developer wanting to use this API? 09:53:22 andreip: Or is it a fictional use case? 09:54:03 dougt: I think there is a privacy gain: if you can reduce the set of lat/lng registered, then you have a gain, but if you can register 10000... 09:54:55 dougt: You could build this feature based on the current geolocation API. 09:55:11 diana: User might feel comfortable with sharing "let them know when I'm near", but not "know where I am all the time" 09:55:40 steveblock: You could imagine a UA that prompts when the proximity is hit. 09:55:48 dougt: Are there apps that do this right now? Are they popular apps? 09:56:34 dougt: Ignoring privacy you can do this today. 09:56:39 matt: And ignoring battery life 09:56:42 dougt: Users don't care. 09:57:08 lbolstad: Should we be proactive and thinking about this now? 09:57:52 steveblock: In previous cases we've had someone create the api and use it and then standardize. 09:58:26 andreip: I think we need for it to get more traction. 09:58:37 not sure that is capturing the thought. 09:59:36 lbolstad: Should we drop it? 10:00:04 steveblock: I think there's an action item to end the thread until there is a concrete requirement. 10:00:32 dougt: The cool thing in proximity alarms is making it happen when the page loads. 10:00:35 steveblock: Or in the background. 10:00:35 ACTION: andreip to reply to the proximity thread saying we're dropping it for now and will revisit it later if there's demand 10:00:36 Created ACTION-84 - Reply to the proximity thread saying we're dropping it for now and will revisit it later if there's demand [on Andrei Popescu - due 2011-09-14]. 10:00:55 dougt: We implemented …?? … and it's very similar. 10:04:43 [[exploring Web Notifications]] 10:04:51 dougt: When a proximity alarm happens, you could have a notification show. 10:04:57 steveblock: This isn't about background events though. 10:13:12 Open issues: http://www.w3.org/2008/geolocation/track/issues/open 10:13:59 ISSUE-43? 10:13:59 ISSUE-43 -- Proximity interface -- open 10:13:59 http://www.w3.org/2008/geolocation/track/issues/43 10:20:02 we are going through the open issues and resolving some. 10:22:12 ISSUE-81? 10:22:12 ISSUE-81 -- Civic address format transformations -- open 10:22:12 http://www.w3.org/2008/geolocation/track/issues/81 10:22:56 ACTION-72? 10:22:56 ACTION-72 -- Andrei Popescu to to add the new requirements talked about at the f2f to the requirement section -- due 2010-11-11 -- OPEN 10:22:56 http://www.w3.org/2008/geolocation/track/actions/72 10:27:01 ISSUE-98? 10:27:02 ISSUE-98 -- Update v2 to include all recent changes in v1 -- open 10:27:02 http://www.w3.org/2008/geolocation/track/issues/98 10:29:08 -> http://services.w3.org/xslt?xmlfile=http://www.w3.org/2005/08/01-transitions.html&xslfile=http://www.w3.org/2005/08/transitions.xsl&docstatus=fpwdlc-wd-tr FPWD and LC at the same time. 10:30:50 lbolstad: What is the minimum period for the LC? 10:31:05 matt: I'll have to find out. It's I believe the greater of the two periods, whichever is longer the LC or the FPWD 10:31:18 lbolstad: We need a charter extension Matt? 10:31:20 matt: Yes. 10:32:43 lbolstad: If we can do a combined LC and FPWD, then the most optimistic would be for us to finish LC after the end of December. Get to CR, then a few months, then PR 10:33:03 matt: Actually, you can do a 0 day CR, which is basically going straight from LC to PR. You have to have your implementation report ready, etc though. 10:33:14 dougt: So we probably need a charter extension. 10:33:38 because there is no way to get these specs to rc before dec. 10:36:26 issue-88? 10:36:26 ISSUE-88 -- Should we change the orientation axes ? -- open 10:36:26 http://www.w3.org/2008/geolocation/track/issues/88 10:37:48 Topic: DeviceOrientation Events 10:48:05 andreip: We can close the issue as we resolved it on the mailing list. 10:49:20 ISSUE-93? 10:49:20 ISSUE-93 -- Add window.ondevicemotion, window.ondeviceorientation ? -- open 10:49:20 http://www.w3.org/2008/geolocation/track/issues/93 10:49:36 ACTION: steveblock Add non-normative text regarding origin for Geolocation V2 and DeviceOrientation 10:49:37 Created ACTION-85 - Add non-normative text regarding origin for Geolocation V2 and DeviceOrientation [on Stephen Block - due 2011-09-14]. 10:52:36 ACTION: steveblock Add window.ondevicemotion and window.ondeviceorientation 10:52:36 Created ACTION-86 - Add window.ondevicemotion and window.ondeviceorientation [on Stephen Block - due 2011-09-14]. 11:53:44 steveblock has joined #geolocation 11:53:48 hi matt 11:53:51 we're back 11:54:44 OK, I'll dial back in. 11:55:13 andreip has joined #geolocation 11:55:15 wmaslowski has joined #geolocation 11:56:39 lbolstad has joined #geolocation 11:58:24 rrsagent, draft minutes 11:58:24 I have made the request to generate http://www.w3.org/2011/09/07-geolocation-minutes.html matt 11:58:47 scribe lbolstad 11:58:48 ACTION: matt hand out geolocation stickers to dougt. 11:58:51 Created ACTION-87 - Hand out geolocation stickers to dougt. [on Matt Womer - due 2011-09-14]. 11:59:07 scribe: lbolstad 12:00:12 change the due date? ;p 12:00:51 ACTION-87 due 2011-11-03 12:00:51 ACTION-87 Hand out geolocation stickers to dougt. due date now 2011-11-03 12:00:59 heh 12:01:06 trackbot, good boy 12:01:06 Sorry, matt, I don't understand 'trackbot, good boy'. Please refer to http://www.w3.org/2005/06/tracker/irc for help 12:03:27 issue-95? 12:03:27 ISSUE-95 -- Should we separate out compass heading? -- open 12:03:27 http://www.w3.org/2008/geolocation/track/issues/95 12:15:51 discussing the issues raised around event listeners and side effects 12:15:52 http://lists.w3.org/Archives/Public/public-geolocation/2011Jul/0023.html 12:18:36 should we or should we not give the (immediate) initial state when an event listener is added ? 12:20:11 do we care about the initial value? 12:20:40 in practice the slightest noise would generate an event anyway 12:24:23 but not if this is filtered out 12:33:26 the "controversial" part of the spec is this: when a new listener registers for the event, implementations should fire the event as soon as sufficiently fresh data is available. 12:34:32 the very first event listener will cause the underlying sensor APIs to be triggered 12:35:22 and will receive an event, which is fine because fresh data became available 12:36:01 the question is what a second event listener, whether in the same document or not, should receive cached sensor data as soon as it is added 12:41:39 we'll bring this up with the www-dom mailing list 12:41:49 s/with/on 12:41:53 s/with/on/ 12:41:58 ACTION: steveblock Send email to www-dom regarding initial event 12:41:58 Created ACTION-88 - Send email to www-dom regarding initial event [on Stephen Block - due 2011-09-14]. 12:59:19 issue-100? 12:59:19 ISSUE-100 -- Figure out how to send initial event to new listeners -- open 12:59:19 http://www.w3.org/2008/geolocation/track/issues/100 13:09:19 back to issue-95... 13:10:09 does it make sense to separate out compass heading and accuracy as separate properties, as Apple have done ? 13:27:57 after a lengthy discussion we struggle to find good reasons for adding sensor-specific properties to the interface 13:32:26 ACTION: andreip to follow up with Dean Jackson to get more details on webapps breaking as a result of combining compass and gyro data 13:32:27 Created ACTION-89 - Follow up with Dean Jackson to get more details on webapps breaking as a result of combining compass and gyro data [on Andrei Popescu - due 2011-09-14]. 13:34:02 Topic: Keylogging based on accelerometer data 13:37:02 http://www.cs.ucdavis.edu/~hchen/paper/hotsec11.pdf 13:39:22 Should this be addressed in the spec or left to the UAs to mitigate ? 13:40:17 Doug: The obvious protection is to block events to background or non-visible documents/apps 13:40:34 Doug: Preferable not to even mention this in the spec 13:45:40 Resolution: We won't address this in the spec, but we expect implementations to provide adequate protection by for instance not firing events to non-visible/background web pages 14:18:12 Topic: Cache polling 14:18:13 http://lists.w3.org/Archives/Public/public-geolocation/2011Aug/0001.html 14:19:29 A site can specifically request a cached location by setting maximumAge to Infinity 14:19:56 This location could be one that the user is not expecting to share with the current site 14:21:55 We agree that this could be considered data leakage, on the other hand the threshold for sharing location in the first place is already high 14:22:40 Also, no site can rely on getting a cached position of a certain age 14:23:40 The wg consensus is that no API change is required to address this, but that UAs should perhaps consider protecting against sites receiving old position data shared with other sites 14:24:16 Topic: Two security issues 14:24:21 http://lists.w3.org/Archives/Public/public-geolocation/2011Aug/0006.html 14:25:48 First one: The spec does not explicitly specify the lifetime of a watchPosition process 14:26:38 We should ask hixie for a clarification here 14:28:28 ACTION: andreip to clarify with hixie what the Geolocation spec should say about stopping watchPosition processes on document unload 14:28:28 Created ACTION-90 - Clarify with hixie what the Geolocation spec should say about stopping watchPosition processes on document unload [on Andrei Popescu - due 2011-09-14]. 14:29:29 Second one: dougt will reply on the mailing list 14:35:41 DKA has joined #geolocation 14:37:49 \Matt no 15:16:05 Topic: Restrict location accuracy requested by developers 15:17:06 Ernesto: It would probably be a good feature for developers to be able to restrict the accuracy of location requests 15:17:16 e.g. request only city- or country level location 15:17:29 We've obviously had this discussion before 15:19:09 [[We've had the discussion before, but always said: "not doing it with lat/lng" and "address we'll handle in v2", so I don't feel like we've really resolved it]] 15:19:22 steveblock has left #geolocation 15:19:28 ACTION: dchen to collect feedback from developers about location accuracy and present at the next f2f 15:19:28 Sorry, couldn't find user - dchen 15:20:20 ACTION: dcheng to collect feedback from developers about location accuracy and present at the next f2f 15:20:20 Sorry, couldn't find user - dcheng 15:21:11 rssagent, draft minutes 15:21:38 ACTION: dcheng to collect feedback from developers about location accuracy and present at the next f2f 15:21:38 Sorry, couldn't find user - dcheng 15:21:58 trackbot, status 15:22:02 trackbot, reload 15:22:19 rrsagent, draft minutes 15:22:19 I have made the request to generate http://www.w3.org/2011/09/07-geolocation-minutes.html matt 15:22:31 trackbot, status 15:22:36 ACTION: dcheng to collect feedback from developers about location accuracy and present at the next f2f 15:22:36 Sorry, couldn't find user - dcheng 15:22:40 ACTION: Diana to collect feedback from developers about location accuracy and present at the next f2f 15:22:42 Created ACTION-91 - to collect feedback from developers about location accuracy and present at the next f2f [on Diana Cheng - due 2011-09-14]. 15:22:54 rrsagent, draft minutes 15:22:54 I have made the request to generate http://www.w3.org/2011/09/07-geolocation-minutes.html lbolstad