Geolocation WG F2F December 2008 -- 09 Dec 2008

<dougt> matt is explaining to me what to do.

Group management

<matt> scribenick: dougt

chairs have an idea of what is going on, what active issues are...

matt: tool of choice seems to be "tracker"
... tracker web thing, irc client, leaves open management, html5 uses it.

lars: we have some actions in the list.

dougt: notes that wormer has two overdue.

matt: we can use wiki
... bugzilla too.
... we have something for last call too.
... recommended that use the tools, tracker.

<matt> http://www.w3.org/2008/webapps/wiki/Tracker_Guidelines

matt: each group can work how they want.
... there are over 600 emails. some of them are resolved.
... we should track them.

andreip: i will populate the tracker.

<tlr> ACTION: matt to explain stuff [recorded in http://www.w3.org/2008/12/09-geolocation-minutes.html#action01]

<trackbot> Created ACTION-7 - Explain stuff [on Matt Womer - due 2008-12-16].

<tlr> ACTION-7: closed

<trackbot> ACTION-7 Explain stuff notes added

<trackbot> If you meant to close ACTION-7, please use 'close ACTION-7'

<tlr> close ACTION-7

<trackbot> ACTION-7 Explain stuff closed

<scribe> ACTION: andreip is to populate tracker with issues reported in the mailing list. [recorded in http://www.w3.org/2008/12/09-geolocation-minutes.html#action02]

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

<scribe> ACTION: andrei is to populate tracker with issues reported in the mailing list. [recorded in http://www.w3.org/2008/12/09-geolocation-minutes.html#action03]

<trackbot> Created ACTION-8 - Is to populate tracker with issues reported in the mailing list. [on Andrei Popescu - due 2008-12-16].

<matt> http://www.w3.org/2008/geolocation/track/

dougt: we have been discussing how the w3c tools work

<scribe> ACTION: andreip is to update the specification to reflect Postion.coords discussion. [recorded in http://www.w3.org/2008/12/09-geolocation-minutes.html#action04]

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

<scribe> ACTION: andrei is to update the specification to reflect Postion.coords discussion. [recorded in http://www.w3.org/2008/12/09-geolocation-minutes.html#action05]

<trackbot> Created ACTION-9 - Is to update the specification to reflect Postion.coords discussion. [on Andrei Popescu - due 2008-12-16].

matt: last comment tool is very useful. bugzilla is an overkill.

<matt> http://www.w3.org/2008/geolocation/wiki

matt: media wiki instance.
... chairs can provide input on which tools we use.
... i do have strong feelings about use cases.

andreip: tool chain for the spec itself?

matt: there are lots of tools for spec generation

matt and andreip are having a discussion of what tools to use to generate the actual specification document.

<matt> ACTION: matt to check if dev.w3.org still does CVS checkout and setup redirect if needed [recorded in http://www.w3.org/2008/12/09-geolocation-minutes.html#action06]

<trackbot> Created ACTION-10 - Check if dev.w3.org still does CVS checkout and setup redirect if needed [on Matt Womer - due 2008-12-16].

matt: we should talk about teleconferences....

andreip: we will see how it goes

matt: we have nothing regularly scheduled.

lars: as needed works best.
... we should keep them at 2pm et when needed.

<tlr> I wouldn't worry about the slots on the bridge.

lars: next f2f

matt: travel budgets are being cut, so....

dougt: why have any travel?

ph: f2f is better.

thank you. ;-)

yeah, and ph joined the meeting.

<tlr> 2-6 November 2009 or 16-20 November 2009, San Francisco Bay Area, California, USA (in conjunction with AC 2009) [under consideration - dates subject to change based on space availability*]

<tlr> -- http://www.w3.org/2002/09/TPOverview.html

<scribe> ACTION: marc look into e911 over the web. [recorded in http://www.w3.org/2008/12/09-geolocation-minutes.html#action07]

<trackbot> Created ACTION-11 - Look into e911 over the web. [on Marc Linsner - due 2008-12-16].

<matt> http://www.w3.org/2008/geolocation/charter/#coordination

<matt> ACTION: lbolstad to look into joining Hypertext Coordination WG [recorded in http://www.w3.org/2008/12/09-geolocation-minutes.html#action08]

<trackbot> Created ACTION-12 - Look into joining Hypertext Coordination WG [on Lars Erik Bolstad - due 2008-12-16].

<matt> ACTION: amachin to look into joining Hypertext Coordination WG [recorded in http://www.w3.org/2008/12/09-geolocation-minutes.html#action09]

<trackbot> Created ACTION-13 - Look into joining Hypertext Coordination WG [on Angel Machin - due 2008-12-16].

matt: reviewing the coordination with external groups/organizations

<matt> scribe: andreip

use cases

amachin: sent an email to the list asking for use cases
... open some period of time for collecting use cases

<dougt> ACTION: andrei remove use cases that reference Addresses [recorded in http://www.w3.org/2008/12/09-geolocation-minutes.html#action10]

<trackbot> Created ACTION-14 - Remove use cases that reference Addresses [on Andrei Popescu - due 2008-12-16].

andreip: the existing use cases where added before the API was sketched

dougt: worried that turn-by-turn directions use case may not be approriate for this API
... the real question is whether turn-by-turn can be implemented with this API

jmorris: the charter seems to imply that the API should not be constrained to the current focus, so are we excluding APIs that don't fit the current focus? Or do we accept broaded use cases?

<dougt> i only worried because most car navigation systems have a compass

matt: we should have a broader collection of use cases

<dougt> you probably can build a turn by turn stuff -- it just probably will not be as great as one of the ones that have a compass

well Google Maps for Mobile does turn by turn quite well without a compass

but sure, that would help

I think turn by turn is a valid use case

<dougt> i agree with andreip.

<dougt> the use cases are meant to tease out what the spec is suppose to be able to do.

matt: what should we do with the minutes
... should we publish them to the public list or not?

andreip: public

dougt: public and published immediately

<matt> RESOLUTION: Meeting minutes will be made available public immediately

RESOLUTION: Meeting minutes will be made available public immediately

<dougt> RRSAgent: draft minutes

<tlr> ScribeNick: andreip

<matt> list of members

Philipp H: people who have joined the WG have made certain commitments wrt to parents. We should ask people outiside the WG who make big contributions to the API to sign the same commitment as the current WG members.

dougt: what about 'derived work'?

<matt> Patent Policy FAQ

dougt: The API at LocationAware.org is very similar to what became the W3C editor's draft and it is one of the first detailed specs that show how to do location

<acooper2> http://www.w3.org/2004/01/pp-impl/35520/nmlc

Philipp: again, please ask the people who made signifficant contributions to the spec to sign the same commitment as the one signed by WG members

jmorris: I'll post a link to the use cases docs that was used by geopriv.

<scribe> ACTION: jmorris to take out the Web-specific use cases from there and present them to the list [recorded in http://www.w3.org/2008/12/09-geolocation-minutes.html#action11]

<trackbot> Created ACTION-15 - Take out the Web-specific use cases from there and present them to the list [on John Morris - due 2008-12-16].

<jmorris> this is an expired 5-year old IETF geopriv use case document looking at use cases and privacy -- acooper2 and I will pull out of this document the web-specific use cases and post them to the list. see fyi the original doc at http://www.cdt.org/standards/draft-cuellar-geopriv-scenarios-03.txt

alecbernston: what do we really want from use-cases?

matt: here are the categories of use cases we should have
... 1: things for the current spec , 2 use cases for v next

dougt: what is missing from the current set of use cases?

alecbernston: advertising support?

acooper2: the current "up to date local information" use case could be adapted to cover advertising

alecberntson: the use case about cheaply acquiring last position is still there

andreip: we still have that functionality in the spec

dougt: are there any other specs that have use cases?
... are there other W3C specs that have use cases

<matt> http://www.w3.org/2008/webapps/wiki/Widgets2_UC%26R

<dougt> ^ that we can model after.

http://dev.w3.org/2008/video/mediaann/mediaont-req/mediaont-req.html

<maxf> http://www.w3.org/TR/mmi-use-cases/

<scribe> ACTION: amachin to look at the OMTP use cases for location and contribute them to the list [recorded in http://www.w3.org/2008/12/09-geolocation-minutes.html#action12]

<trackbot> Created ACTION-16 - Look at the OMTP use cases for location and contribute them to the list [on Angel Machin - due 2008-12-16].

dougt: let's review the existing use cases
... then talk about other possible use cases

lbolstad: the use cases lead to requirements

matt: to be clear nothing will be added to the fpwd

<matt> BONDI Publications

dougt: sure, unless we find something really obvious that needs to be there

<matt> Find POI

dougt: use case 1 can be satisfied

andreip: use case 2 has been expanded with suggestions from Samsung

dougt: the use case 2 can be satisfied with the Geo API

matt: it may rely on other APIs

<tlr> maxf, http://dev.w3.org/geo/api/spec-source.html

some discussion about the online / offline detection functionality in use case 2 is feasible

and whether it should be taken out of the use case text

dougt: use case 3 is out of scope for now since v1 has no support for civic address

andreip: sorry about that, I forgot to remove it, should not be there at all

jmorris: sounds like use case 3 would be satisfied by next versions of the spec

dougt: Gears exposes location providers in the DOM (gearsLocationProviderUrl)
... a mall app would be able to use its own location provider
... the current API already has heading. there may be a different spec in the future that will provide device orientation.

Philipp: do people build compasses into phones?

andreip: G1 has it

dougt: the orientation should not be in the position object
... accelerometer and compass are useful when you don't care about geolocation

alecberntson: "Alerts when points of interest are in the user's vicinity" doesn't seem to be 'natively' implemented
... should we cut it?

dougt: this can be implemented with JS

alecberntson: since we don't directly support it, is it relevant?

andreip: we should maybe change the wording to make it clear that it's not natively supported

alecberntson: what is the goal of the use cases, exactly?

jmorris: we should look at their privacy implications

acooper2: what about other people's / devices position

dougt: the API doesn't support this. An app can post the location to a server and see which people are close by

<tlr> the notion that the API should prevent users from "spoofing" input into a web application is a bit mind-boggling.

acooper2 argues for possibility to spoof your own location

alecberntson: next is the "Up-to-date local information" use case

dougt: this should be "locally targetted content" to include advertising, etc
... the last use case should be dropped since it's no difference to the second use case

<acooper2> http://dev.w3.org/geo/api/spec-source-CDT-diff.html

looking at the CDT / Geopriv edits to the use cases

acooper2: the edits highlight the privacy implications of each use case
... if I go to nytimes.com and I see a UI saying doubleclick wants to use my location, does that mean that if I click OK, doubleclick will be allowed to show me ads on any other stite?

dougt: this is a discussion for tomorrow (security mtg) since it applies to a lot of other APIs
... the constraints related to code running in iframes and framesets (e..g. restrict them from acessing Geolocation) is a UA consideration
... I have 2 thoughts about solving "clickjacking" : 1 NPAPI plugins cannot show UI elements since those can be spoofed. They should negociate with the Browser the display of any UI.

2. certain APIs can only execute in top level documents

dougt: a subdocument can receive location using window.postMessage()

jmorris: if the spec required UAs to allow access to this API only from TLDs, that does help to some degree but I would need to think about it more
... wrt to IP being used for identification, IPv6 is a lot less transient than IPv4

dougt: based on Mozilla logs, you cannot really uniquely identify people based on IP due to usage of proxies and DHCP
... is it possible to restrict all device APIs to TLDs? This should be a topic of discussion for tomorrow's Device API meeting

<tlr> TLD = top-level document

<tlr> (in this context)

acooper2: if we want to consider privacy implications for the use cases, what is the expectation on how the spec would address them

matt: is it worth having a use case that spells out that the API can only be used in top level documents

acooper2: this is maybe at a higher level of abstraction than the level of the current use cases

jmorries: should we discuss requirements? it seems it is not a requirement that the API is privacy sensitive

dougt: how is that so?

jmorris: this is what we discussed yesterday, and it is debatable but I would say that it should be at least a requirement

alecberntson: given the current wording of the privacy section, we could have a requirement that says " there must be consent"

dougt: we should make recommendations about what are the sensible ways in which companies should deal with location data

alecberntson: it would be a good idea to spell out all these things since they may not be obvious to everyone

dougt: we should finish that discussion

1. best practices for Web sites

2. best practices for UA

<matt> dougt: I don't think the UAs will disagree but the UAs will undoubtedly prompt the user on the first use of this. I don't care if there's a remember me button or whatever.

<matt> dougt: First time usage should have first time opt-in per URI or origin or...

andreip: what would go into best practices?

dougt: at least the on/off switch and the per-origin user prompt

the management of location permissions after the prompt should be left to the UA

dougt: this is not binding. I can deploy a version of Mozilla that never prompts in certain scenarios. That's why the text should say "SHOULD"?

so the conclusion is that the recommendation for UA should be "prompt once per origin on first visit"

alecberntson: actually it should be "acquired received consent"

andreip, acooper2: what about on/off?

dougt: hixie was against it

acooper2: it's clearer to say "shoult prompt" instead of relying on the fuzzyness of "content" which may mean anything

Steve: you could say "You MUST acquire constent" and that "you SHOULD promopt"

lbolstad: still people may read this an think that prompting is actually required

lbolsad: the problem with dialogs is that people tend to ignore them

not igore them but not pay close attention to them

alecberntson: I sort of like the idea of saying "must acquire" AND "should prompt"

<alecberntson> The 4 "SHOULD"s: a UA should:

<alecberntson> prompt

<alecberntson> use origin for permission ganularity

<alecberntson> provide on/off switch

<alecberntson> be fail-safe, i.e. doing nothing does not cause location to be returned

<tlr> example use case for non-interactive use: use the API for flight location information in an airplane seatback

tlr: you should have an explicit use case like the API being used to show the aircraft position on a map (on the screen of the in-flight entertainment system) and explain how it constituses a valid exception to the set of privacy guidlines for UAs

<tlr> acooper2, jmorris, got a link to that version?

dougt: who wants to take the recommendation for Web sites / location recipients?

jmorris: we'll strill try to convince the W3C that the approach that the group is taking is wrong. If the current approach will stand, we will consider spending some effort making it as good as possible.

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

<matt> trackbot, status?

alecberntson: MS has done some research into this: we think it's good to alert when the location is retrasmitted

<alecberntson> Alert the user when retransmit - when you 'give out' location

<alecberntson> Logging requires consent, clear way to delete history

we save the default location information in the registry. There is a button that allows users to delete it.

<matt> trackbot, inint

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

<matt> trackbot, init

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

<matt> ACTION: doug will take a shot at providing wording for a privacy recommendation for location recipients [recorded in http://www.w3.org/2008/12/09-geolocation-minutes.html#action13]

<trackbot> Created ACTION-17 - Will take a shot at providing wording for a privacy recommendation for location recipients [on Doug Turner - due 2008-12-16].

<inserted> scribe:maxf

<matt> ACTION: Matt to make tracker instance public [recorded in http://www.w3.org/2008/12/09-geolocation-minutes.html#action14]

test suites

matt goes through the Process document

In order to exit Candidate Recommendation a spec has to demonstrate implementability

when entering CR, the group defines what implementability is

<matt> charter about exit criteria

usually, a test suite is written and the criterion is to have 2 implementations pass each test

In some cases, the CR phase can be skipped if implementability is already demonstrated

PH: a test suite isn't a conformace test suite, it's more for aligning implementor's understanding. And also to push back on some features, as the group realises they're not easily implementable.

Doug: is there a standard framework?

matt: there are ones we can repurpose

dougt: we have some testcases

andreip: us too

matt: we have to gather up this implementation experience and demonstrate every feature is covered

we mentioned in the charter that we'll be developing a test suite, but ddn't give much detail

andreip: practically, we contribute tests in the mailing list?

matt: we should establish that. Changes with each group

sometimes it's code, sometimes it's prose. There's a lot of different ways

dougt: we need to define what's interoperability. We need to build something we can all use

steve: the tests we have are very specific to our framework

we'd have to repurpose them.

matt: somebody needs to take up the lead
... otherwise there's not much we need to talk about

dougt: delivery dates?

dougt and andreip : end of January?

<scribe> ACTION: andreip and dougt to deliver test cases by end of january [recorded in http://www.w3.org/2008/12/09-geolocation-minutes.html#action15]

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

<scribe> ACTION: andreip to deliver test cases by end of january [recorded in http://www.w3.org/2008/12/09-geolocation-minutes.html#action16]

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

<scribe> ACTION: andrei to deliver test cases by end of january [recorded in http://www.w3.org/2008/12/09-geolocation-minutes.html#action17]

<trackbot> Created ACTION-18 - Deliver test cases by end of january [on Andrei Popescu - due 2008-12-16].

<scribe> ACTION: doug to deliver test cases by end of january [recorded in http://www.w3.org/2008/12/09-geolocation-minutes.html#action18]

<trackbot> Created ACTION-19 - Deliver test cases by end of january [on Doug Turner - due 2008-12-16].

Lars-Erik: how do the W3C test are made not to be about conformace but interoperability?

e.g. DOM3 Core is supported 95% but user agents, marketing claim. But those test suites aren't meant to be about conformant

s/conformat/conformance/

Philip: conformance test suites are usually big, and we don't want WGs to burn themselves building ones

Matt: we won't know until we start it

Lars-Erik: so we'll start by getting Google and Mozilla donating testcases?

Google+Mozilla: yes.

<matt> ACTION: matt to find test suite FAQ, licesensing, etc [recorded in http://www.w3.org/2008/12/09-geolocation-minutes.html#action19]

<trackbot> Created ACTION-20 - Find test suite FAQ, licesensing, etc [on Matt Womer - due 2008-12-16].

lbolstad: ok, we can either finish early, or talk about something not on the agenda

amachin: other business about accuracy attribute/parameter, names

discussion about enabling high accuracy

steve: can have a flag to make the device spend more resource into getting a better fix
... desired accuracy vs required accuracy

alec: in our implementation we have low, default and high

marc: but you should recommend some kind of time anyway

alec: true, but the idea is to tell it could use more resources.

[discussion on meaning of the high accuracy flag: name, meaning, provider, charging]

matt: wondering about what it means with different providers

andrei: can be defined above.

matt: can just pass the flag and get the best value from all the available providers.

but if you can get charged from the service, you don't know if you'll get charged or not

Alec: can choose among free providers

matt: can get very complex

andrei: just a flag

steve: name is misleading. HighAccuracy doesn't mean you'll get more accuracy

requestedAccuracy, attemptedAccuracy...

Alec: we want a better name but can't find one. attemptHighAccuracy?

Angel: targetAccuracy?

Alec: then what does true mean?

andrei: fine with attempt

<inserted> scribe:maxf

marc: use cases?

<matt> [[ There is one scenario that we had in mind here: imagine an application

<matt> that sets up a long-running position watch and that the application

<matt> can live without having very accurate position information (e.g shows

<matt> POI in the user's area or something similar). Imagine also that the

<matt> application is meant to be used on mobile devices, which are generally

<matt> powered by small batteries. ]]

<matt> use case for high accuracy

steve: using a watch to get a better result than a one-off, because you get more time for a better response.

dougt: "wait this long, and I'm hoping for this type of accuracy"

and if not, there's a fallback.

Marc: IETF has a work item on watching by distance moved, not just time

<maxfroumentin> [ongoing discussion on highAccuracy and update frequency]

<mlinsner> IETF project for location filters - http://tools.ietf.org/html/draft-ietf-geopriv-loc-filters-03

use case is watchPosition, e.g. weather depending on location only

doug: setTimeout?

alec: changing the timeout is awkward.

Marc: [missed, sorry]

doug: other issue was orientation. is there an oppostunity to do it under this charter?

or completely different thing?

matt: we're not chartered for another recommendation
... something like compass for heading, seems like it falls in this charter, but then acceleromaters? Not sure
... starts to get too far away

andreip: google interested

alec?: we already implement it

angel: Bondi have support for it

Lars-Erik: can it be in this spec?

Doug: wouldn't be under position though

Lars-Erik: there is already a heading attribute, but that's based on movement
... but direction could be in position object

andreip: you're kind of forcing it on position implementor

alec: doesn't necessarily make sense, if you're in front of a desktop

[agreement that direction is quite different]

[and so required a different interface]

matt: we also talked about other work on device APIs and this seems to be one special case of it
... we;ll have a better idea after the workshop tomorrow

philip: you can argue that orientation is part of geolocation?

andreip: there are use cases

philip: but they could fit in the same charter

<matt> ACTION: matt to look into orientation, compass, accelerometer specs [recorded in http://www.w3.org/2008/12/09-geolocation-minutes.html#action20]

<trackbot> Created ACTION-21 - Look into orientation, compass, accelerometer specs [on Matt Womer - due 2008-12-16].

<matt> logging thread

[logging has been pushed back as a privacy nightmare]

<matt> PROPOSED RESOLUTION: logging as proposed in http://lists.w3.org/Archives/Public/public-geolocation/2008Dec/0005 is out of scope

RESOLUTION: publish first Working Draft before the 18th december moratorium.

argreement to leave placeholders for open issues

<scribe> ACTION: andreip to create placeholders [recorded in http://www.w3.org/2008/12/09-geolocation-minutes.html#action21]

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

<matt> ACTION: andrei to create placeholder privacy recommendations for implementors and location receivers [recorded in http://www.w3.org/2008/12/09-geolocation-minutes.html#action22]

<trackbot> Created ACTION-22 - Create placeholder privacy recommendations for implementors and location receivers [on Andrei Popescu - due 2008-12-16].

meeting adjourned

<jmorris> http://www.google.com/search?client=safari&rls=en-us&q=chez+gerard+london&ie=UTF-8&oe=UTF-8

<matt> i/: ttest suite/scribe:maxf/

- DRAFT -

Geolocation WG F2F December 2008
09 Dec 2008

Attendees

Contents

Group management

use cases

test suites

discussion about enabling high accuracy

Summary of Action Items

Scribe.perl diagnostic output

- DRAFT -

Geolocation WG F2F December 2008 09 Dec 2008

Attendees

Contents

Group management

use cases

test suites

discussion about enabling high accuracy

Summary of Action Items

Scribe.perl diagnostic output

Geolocation WG F2F December 2008
09 Dec 2008