IRC log of geolocation on 2011-09-07

Timestamps are in UTC.

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