W3C

- DRAFT -

Geolocation WG F2F 2011 #2

07 Sep 2011

See also: IRC log

Attendees

Present
Lars_Erik_Bolstad, W_Maslowski, Steve_Block, Andrei_Popescu, Matt_Womer, Diana_Cheng, ??, Ernesto_Jimenez
Regrets
Chair
Lars Erik
Scribe
Matt, lbolstad

Contents


<andreip> thanks

<matt> Scribe: Matt

V2 Backwards Compatibility

-> http://lists.w3.org/Archives/Public/public-geolocation/2011Jun/0059.html Geolocation V2 and backwards compatibility

<dougt> o/

<andreip> thanks Matt!

steveblock: The idea was to have v2 backwards compatible: a page written for v1 will work in v2.
... We thought about versioning the API, but decided it would be nice not to.
... We thought it would be nice if pages written for v2 would work with v1 as well.
... So, this basically meant three things: 1. making coords optional 2. optional Position.address property and 3. add PositionOptions.requireLatitudeLongitudeAccuracy

dougt: I talked about instead perhaps getting back an address object.
... On many systems there are two different subsystems, one for location, one for geocoding.
... So, you're implementation will have to get the location, then do geocoding.
... 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.

steveblock: That would require an extra round trip, which is likely to not be acceptable to developers.

dougt: But geocoding costs more than location typically. This would make it very explicit.

andreip: The one round-trip was a requirement for search for instance.

steveblock: I think that discussion is orthogonal actually to this.

dougt: The server may return long/lat, then a second JS call could return the geocoded address.

andreip: How would you know that it's ready?
... We only want geocoding when we need it.

dougt: Then this would do that.
... You would add another flag.

steveblock: If we want to return another address block we'd have to have another flag to indicate address.

dougt: When would location even be null

steveblock: The classic phone example, where they know their address but not lat/lng.

andreip: Right now we don't have any implementors that support just civic address.
... Do we want to support that?

steveblock: I think it makes sense.

diana: Was there a requirement that coordinates be optional from the mailing list?

steveblock: I don't think so, there was just talk about how to do it in a simple way.

[[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.]]

dougt: I don't like the flag, but we don't have another proposal.

steveblock: While it's ugly, you can pretend it's not there unless you care about these subtle differences.

andreip: I don't like the name, it's way too long.

steveblock: Could be something else.

dougt: Why wouldn't we just add a flag to positionOptions to say "fetch geocoded info if available"?
... Then your implementation can fetch it from cache, or whatever.

andreip: What would you do to enable a v1 call?

dougt: No, I was thinking a positionOptions property "getGeocodedInfo", and everything else just works the same.
... Then impl asks the geocoder, get civic address if you have that flag set.

steveblock: Then the phone case of having just address, but not coords.

andreip: So you'd get back the v1 object, then call a second api?

wmaslowski: ??

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.

dougt: Android does actually.
... So, if this is the best proposal, let's work on that name.
... Can we make this requireCoords, and then make --

steveblock: This was to make coords optional, but...

<andreip> :)

<andreip> name of the flag would be requireCoords

steveblock: requireCoords being false would mean you'd have to null check all the coords.

dougt: How badly does it break v1?

steveblock: I think it's pretty bad.

dougt: You just have to test for lat/lng.

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.

steveblock: I guess we could say something like "enableCompatibilityMode" or something, but I think it's best to be specific.

<dougt> ^ i was hoping, but i knew it was bad. (fwiw)

PROPOSED RESOLUTION: We will use Steve's proposal, but will use requireCoords instead of enableLatitudeLongitutdeAccuracy

andreip: Everyone is fine with the IR?

[[no objections]]

Address Object

dougt: We shipped with what's in the Editor's spec now.
... I would be in favor of building from that.

andreip: We spent a lot of time trying to map this to the GeoPRIV stuff.
... I believe this is very close to the Microsoft proposal.

dougt: This is a subset of other formats and I think it's something others can digest.
... We want to be in sync with Contacts API too.

andreip: We could take it from the Contacts API.

dougt: Or at least import it as a subset.
... I just don't understand how this is a new problem.

wmaslowski: We introduced two separate formats to do the same thing, that's bad.

-> http://portablecontacts.net/draft-spec.html#schema Portable Contacts schema

[[group looks at above schema]]

dougt: Most of this will map directly.
... 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
... The ones I have are: street #, name, city, county, region, country, country code.

andreip: If the object is to be compatible with this, then we are.

lbolstad: The feedback I got was about the ContactAPI

andreip: Can we ask them why?

<dougt> http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/geolocation/nsIDOMGeoPositionAddress.idl?force=1

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.

<dougt> ^^^ what mozilla shipped

wmaslowski: They said Portable Contacts maps most easily to those, so used those.

andreip: So, we're fine.

wmaslowski: You could have two formats, but alignment would be better.

andreip: Given that contacts was to be compatible with this, and theirs is a subset of ours, then it seems ok.

dougt: We have a format, it's a subset, but it's bigger than Portable Contacts. Not sure what else we can do.

steveblock: We're aiming for something simple.

diana: ??

dougt: What would we do differently if we sent them something?

diana: That we should align with them.

andreip: Then we'd have to go back to Geopriv and realign with them.

dougt: I don't like looking for reasons not to move forward.
... We should tell them what we're doing and why.

andreip: I'm happy to do that.
... We had the discussion with IETF a year ago, everyone can read that.

lbolstad: Should we mention this in their last call?

dougt: Their contact format is a subset of ours. It's almost straight. They only have four or five fields that map to ours.
... I think we pull out the street number, but you can concatenate those two.

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.

andreip: Is streetAddress not the full address making the other contact fields redundant?

steveblock: ??

andreip: So the only complete way of reading that is from the streetAddress?

ernesto_jimenez: I've never done the internationalization of addresses in JavaScript.

andreip: Ours is pretty simple though, just mapping fields to fields, not changing the data here.

ernesto_jimenez: Except streetAddress
... Like family name and given name.

andreip: We also have additional information we can use.
... We wouldn't be able to generate the streetAddress

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.

-> http://dev.w3.org/2009/dap/contacts/ Editor's Draft

wmaslowski: They removed formatted in the latest.

andreip: I think we're perfectly fine.

lbolstad: We could ask them to align theirs with ours if we care, so the mapping is direct.

ernesto_jimenez: It wouldn't be possible as the address format from the device is out of our control.

andreip: What you have here is exactly what we have minus the two fields.

lbolstad: Do we, as a working group, want to give formal feedback that in order to make this mapping easier, add our two fields?

dougt: We could do that.

<dougt> matt: s/should/could

<dougt> MoSCoW and all.

<lbolstad> ACTION: andreip to send feedback to the DAP wg suggesting they align their Address object with ours [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action01]

<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].

<steveblock> ACTION: steveblock update V2 spec with requireCoords and send diff to list [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action02]

<trackbot> Created ACTION-82 - Update V2 spec with requireCoords and send diff to list [on Stephen Block - due 2011-09-14].

<steveblock> ACTION: steveblock update V2 spec with requestAddress and send diff to list [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action03]

<trackbot> Created ACTION-83 - Update V2 spec with requestAddress and send diff to list [on Stephen Block - due 2011-09-14].

Proximity Alarm

dougt: enableAccuracy...
... Reason it's there isn't privacy.

andreip: Right.

steveblock: The idea was to maybe use it for wifi for a while, then when you get somewhere pick up higher accuracy.

dougt: I'd rather see a JavaScript library built on top of that...

<andreip> http://lists.w3.org/Archives/Public/public-geolocation/2011Jul/0001.html

lbolstad: The use case on proximity alarm would be something like a store wants to offer a coupon.

dougt: How would you build that? It'd be "I'm this far from this location"?

andreip: Get the location, calculate the distance.

dougt: From where?

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.
... I think the idea is to only use say wifi rather than GPS, or cache nearby cell ids, to avoid unnecessary round trips.

dougt: All of this is implementable with the current API.

steveblock: Not really.
... Not in one request.

dougt: Anyone doing this now?

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.

steveblock: I think we've agreed that it doesn't add new functionality, but does save power.

andreip: You could have lots of proximity alerts and know where you are...

wmaslowski: You could limit it to an arbitrary number, but if you pick wrong.

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.

andreip: What information would someone provide to the API to make this work?

steveblock: I imagine it'd be an API call per registration.

andreip: So stores wouldn't use it.

matt: Stores aren't the only use cases. Location based reminders are pretty good use case.

andreip: But we're arguing whether it gives a privacy advantage.

wmaslowski: ?? data uri … ??? warning about … would have some privacy gain, but wouldn't be a functionality gain...

andreip: If I try to use the current API to do coupons, then they can't because the battery drains?
... Any real developer wanting to use this API?
... Or is it a fictional use case?

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...
... You could build this feature based on the current geolocation API.

diana: User might feel comfortable on sharing "let them know when I'm near", but not "know where I am all the time"

steveblock: You could imagine a UA that prompts when the proximity is hit.

dougt: Are there apps that do this right now? Are they popular apps?
... Ignoring privacy you can do this today.

matt: And ignoring battery life

dougt: Users don't care.

lbolstad: Should we be proactive and thinking about this now?

steveblock: In previous cases we've had someone create the api and use it and then standardize.

andreip: I think we need for it to get more traction.

<dougt> not sure that is capturing the thought.

lbolstad: Should we drop it?

steveblock: I think there's an action item to end the thread until there is a concrete requirement.

dougt: The cool thing in proximity alarms is making it happen when the page loads.

steveblock: Or in the background.

<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 [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action04]

<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].

dougt: We implemented …?? … and it's very similar.

[[exploring Web Notifications]]

dougt: When a proximity alarm happens, you could have a notification show.

steveblock: This isn't about background events though.

<lbolstad> Open issues: http://www.w3.org/2008/geolocation/track/issues/open

ISSUE-43?

<trackbot> ISSUE-43 -- Proximity interface -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/43

<dougt> we are going through the open issues and resolving some.

ISSUE-81?

<trackbot> ISSUE-81 -- Civic address format transformations -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/81

ACTION-72?

<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

<trackbot> http://www.w3.org/2008/geolocation/track/actions/72

ISSUE-98?

<trackbot> ISSUE-98 -- Update v2 to include all recent changes in v1 -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/98

-> 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.

lbolstad: What is the minimum period for the LC?

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

lbolstad: We need a charter extension Matt?

matt: Yes.

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

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.

dougt: So we probably need a charter extension.

<dougt> because there is no way to get these specs to rc before dec.

issue-88?

<trackbot> ISSUE-88 -- Should we change the orientation axes ? -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/88

DeviceOrientation Events

andreip: We can close the issue as we resolved it on the mailing list.

ISSUE-93?

<trackbot> ISSUE-93 -- Add window.ondevicemotion, window.ondeviceorientation ? -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/93

<steveblock> ACTION: steveblock Add non-normative text regarding origin for Geolocation V2 and DeviceOrientation [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action05]

<trackbot> Created ACTION-85 - Add non-normative text regarding origin for Geolocation V2 and DeviceOrientation [on Stephen Block - due 2011-09-14].

<steveblock> ACTION: steveblock Add window.ondevicemotion and window.ondeviceorientation [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action06]

<trackbot> Created ACTION-86 - Add window.ondevicemotion and window.ondeviceorientation [on Stephen Block - due 2011-09-14].

<dougt> hi matt

<dougt> we're back

OK, I'll dial back in.

<lbolstad> scribe lbolstad

<dougt> ACTION: matt hand out geolocation stickers to dougt. [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action07]

<trackbot> Created ACTION-87 - Hand out geolocation stickers to dougt. [on Matt Womer - due 2011-09-14].

<lbolstad> scribe: lbolstad

<dougt> change the due date? ;p

<matt> ACTION-87 due 2011-11-03

<trackbot> ACTION-87 Hand out geolocation stickers to dougt. due date now 2011-11-03

<dougt> heh

<matt> trackbot, good boy

<trackbot> Sorry, matt, I don't understand 'trackbot, good boy'. Please refer to http://www.w3.org/2005/06/tracker/irc for help

issue-95?

<trackbot> ISSUE-95 -- Should we separate out compass heading? -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/95

discussing the issues raised around event listeners and side effects

http://lists.w3.org/Archives/Public/public-geolocation/2011Jul/0023.html

should we or should we not give the (immediate) initial state when an event listener is added ?

do we care about the initial value?

in practice the slightest noise would generate an event anyway

but not if this is filtered out

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.

the very first event listener will cause the underlying sensor APIs to be triggered

and will receive an event, which is fine because fresh data became available

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

we'll bring this up on the www-dom mailing list

<steveblock> ACTION: steveblock Send email to www-dom regarding initial event [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action08]

<trackbot> Created ACTION-88 - Send email to www-dom regarding initial event [on Stephen Block - due 2011-09-14].

<matt> issue-100?

<trackbot> ISSUE-100 -- Figure out how to send initial event to new listeners -- open

<trackbot> http://www.w3.org/2008/geolocation/track/issues/100

back to issue-95...

does it make sense to separate out compass heading and accuracy as separate properties, as Apple have done ?

after a lengthy discussion we struggle to find good reasons for adding sensor-specific properties to the interface

<scribe> ACTION: andreip to follow up with Dean Jackson to get more details on webapps breaking as a result of combining compass and gyro data [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action09]

<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].

Keylogging based on accelerometer data

http://www.cs.ucdavis.edu/~hchen/paper/hotsec11.pdf

Should this be addressed in the spec or left to the UAs to mitigate ?

Doug: The obvious protection is to block events to background or non-visible documents/apps
... Preferable not to even mention this in the spec

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

Cache polling

http://lists.w3.org/Archives/Public/public-geolocation/2011Aug/0001.html

A site can specifically request a cached location by setting maximumAge to Infinity

This location could be one that the user is not expecting to share with the current site

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

Also, no site can rely on getting a cached position of a certain age

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

Two security issues

http://lists.w3.org/Archives/Public/public-geolocation/2011Aug/0006.html

First one: The spec does not explicitly specify the lifetime of a watchPosition process

We should ask hixie for a clarification here

<scribe> ACTION: andreip to clarify with hixie what the Geolocation spec should say about stopping watchPosition processes on document unload [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action10]

<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].

Second one: dougt will reply on the mailing list

\Matt no

Restrict location accuracy requested by developers

Ernesto: It would probably be a good feature for developers to be able to restrict the accuracy of location requests

e.g. request only city- or country level location

We've obviously had this discussion before

<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]]

<scribe> ACTION: dchen to collect feedback from developers about location accuracy and present at the next f2f [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action11]

<trackbot> Sorry, couldn't find user - dchen

<matt> ACTION: dcheng to collect feedback from developers about location accuracy and present at the next f2f [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action12]

<trackbot> Sorry, couldn't find user - dcheng

rssagent, draft minutes

<matt> ACTION: dcheng to collect feedback from developers about location accuracy and present at the next f2f [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action13]

<trackbot> Sorry, couldn't find user - dcheng

<matt> trackbot, status

<matt> trackbot, reload

<matt> trackbot, status

<matt> ACTION: dcheng to collect feedback from developers about location accuracy and present at the next f2f [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action14]

<trackbot> Sorry, couldn't find user - dcheng

<scribe> ACTION: Diana to collect feedback from developers about location accuracy and present at the next f2f [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action15]

<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].

Summary of Action Items

[NEW] ACTION: andreip to clarify with hixie what the Geolocation spec should say about stopping watchPosition processes on document unload [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action10]
[NEW] ACTION: andreip to follow up with Dean Jackson to get more details on webapps breaking as a result of combining compass and gyro data [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action09]
[NEW] ACTION: andreip to reply to the proximity thread saying we're dropping it for now and will revisit it later if there's demand [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action04]
[NEW] ACTION: andreip to send feedback to the DAP wg suggesting they align their Address object with ours [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action01]
[NEW] ACTION: dchen to collect feedback from developers about location accuracy and present at the next f2f [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action11]
[NEW] ACTION: dcheng to collect feedback from developers about location accuracy and present at the next f2f [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action12]
[NEW] ACTION: dcheng to collect feedback from developers about location accuracy and present at the next f2f [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action13]
[NEW] ACTION: dcheng to collect feedback from developers about location accuracy and present at the next f2f [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action14]
[NEW] ACTION: Diana to collect feedback from developers about location accuracy and present at the next f2f [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action15]
[NEW] ACTION: matt hand out geolocation stickers to dougt. [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action07]
[NEW] ACTION: steveblock Add non-normative text regarding origin for Geolocation V2 and DeviceOrientation [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action05]
[NEW] ACTION: steveblock Add window.ondevicemotion and window.ondeviceorientation [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action06]
[NEW] ACTION: steveblock Send email to www-dom regarding initial event [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action08]
[NEW] ACTION: steveblock update V2 spec with requestAddress and send diff to list [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action03]
[NEW] ACTION: steveblock update V2 spec with requireCoords and send diff to list [recorded in http://www.w3.org/2011/09/07-geolocation-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2011/09/07 15:22:59 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Topic: Device Orientation/Topic: V2 Backwards Compatibility/
Succeeded: s/thta/that/
Succeeded: s/We should/We could/
Succeeded: i/enableAccuracy/Topic: Proximity Alarm
Succeeded: s/with/on/
Succeeded: s/with/on/
Found Scribe: Matt
Inferring ScribeNick: matt
Found Scribe: lbolstad
Inferring ScribeNick: lbolstad
Scribes: Matt, lbolstad
ScribeNicks: matt, lbolstad
Present: Lars_Erik_Bolstad W_Maslowski Steve_Block Andrei_Popescu Matt_Womer Diana_Cheng ?? Ernesto_Jimenez
Got date from IRC log name: 07 Sep 2011
Guessing minutes URL: http://www.w3.org/2011/09/07-geolocation-minutes.html
People with action items: andreip dchen dcheng diana diff email geolocation hand matt out requestaddress requirecoords send spec steveblock stickers update v2 with

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]