See also: IRC log
<maxf> hello
<lbolstad> scribe: maxf
LEB: we've received last call comments (we should apologise for the delay)
… we set a deadline for the responses: Nov 12
… meanwhile some implementers have shipped their implementation
… next milestone is PR and we're supposed to show interoperable implementations to reach it
Matt: CR can be very short if the criteria are already fulfilled
Andrei: let's look at my list
… first default values for positionOptions objects
… we implemented the API in gears then later found WebKit were doing things differently
<andreip> https://bugs.webkit.org/show_bug.cgi?id=27254
Doug: happy to have enableAccuracy set to false, timeout to +Inf, maxAge to 0
<matt> http://dev.w3.org/geo/api/spec-source.html
<andreip> http://dev.w3.org/geo/api/spec-source.html
<matt> http://dev.w3.org/geo/api/spec-source.html#position-options
<matt> http://dev.w3.org/geo/api/spec-source.html#geolocation_interface
agreement in enableAccuracy set to false. timeout is mentioned as +Inf, except pseudo-algorithm in 5.1 is ambiguous
Doug: in FF we have an internal default timeout that's less than infinity.
… otherwise device could be called forever.
andrei: then could be a error return
doug: ok
andrei: not TIMEOUT error, though
<scribe> ACTION: andrei to fix the "otherwise" statement about position in 5.1 [recorded in http://www.w3.org/2009/11/02-geolocation-minutes.html#action01]
<trackbot> Created ACTION-24 - Fix the "otherwise" statement about position in 5.1 [on Andrei Popescu - due 2009-11-09].
<scribe> ACTION: andrei to add text about internal timeout [recorded in http://www.w3.org/2009/11/02-geolocation-minutes.html#action02]
<trackbot> Created ACTION-25 - Add text about internal timeout [on Andrei Popescu - due 2009-11-09].
andrei: maximumAge set to 0 by default?
all agree
<matt> [[so I think we agreed that with +Infinity for the timeout, we will use a platform specific timeout rather than waiting for ever]]
<andreip> https://bugs.webkit.org/show_bug.cgi?id=27255
the specification is clear on this one. No action needed.
<andreip> https://bugs.webkit.org/show_bug.cgi?id=27256
andrei: next is when timeout actually starts
discussion about whether the implementation can acquire the permission before the user gave consent
<matt> Ubiquitous Web Applications WG comments
doug: ok with GPS, but perhaps not ok with over-the-web geolocation service
… GPS is even fuzzy, with A-GPS for instance
andrei: we should explain the issue in the spec and mention we recommend not doing any work before consent
… next: if there's an error before consent is given, what happens? suggest there shouldn't be any callback fired before consent
… doug: would like to go further and nothing happens before consent is given
s/...//
<scribe> ACTION: andrei to add statement that the geolocation API should not be called before consent [recorded in http://www.w3.org/2009/11/02-geolocation-minutes.html#action03]
<trackbot> Created ACTION-26 - Add statement that the acquisition should not happen before consent [on Andrei Popescu - due 2009-11-09].
<andreip> actually: the implementation should not do any work before acquiring the permission
andrei: timeout starts when user consents
john: what about a timeout on the getting the user consent?
doug: can be implemented in the script
andrei: next is: calling geolocation methods in the callbacks
<matt> [[ so that action-26 is to update the privacy concerns and the pseudo code? ]]
… also: handling negative values for timeout and maxAge
… it's in the algorithm. We did it to do like setTimeout
… so no change
matt: should it be specified in the IDL?
andrei: not sure you can do that
<scribe> ACTION: andrei to check default values in the IDL [recorded in http://www.w3.org/2009/11/02-geolocation-minutes.html#action04]
<trackbot> Created ACTION-27 - Check default values in the IDL [on Andrei Popescu - due 2009-11-09].
andrei: issue with timeout in FF. In case of a watch a timeout would not restart after a successful callback
doug: ok!
andrei: affect google maps, too
<scribe> ACTION: doug to fix FF on timeout in watchPosition [recorded in http://www.w3.org/2009/11/02-geolocation-minutes.html#action05]
<trackbot> Created ACTION-28 - Fix FF on timeout in watchPosition [on Doug Turner - due 2009-11-09].
matt: spec's not necessarily clear on that
<matt> http://dev.w3.org/geo/api/spec-source.html#position_options_interface
doug: probably need to clarify
<scribe> ACTION: andrei to clarify timeout on watchposition in section on timeout [recorded in http://www.w3.org/2009/11/02-geolocation-minutes.html#action06]
<trackbot> Created ACTION-29 - Clarify timeout on watchposition in section on timeout [on Andrei Popescu - due 2009-11-09].
andrei: it's in the algorithm but should be clarified
http://people.opera.com/~maxfro/geolocation/
<matt> [[ I just wanted to point out that the algorithm stuff in the editor's draft is new, and should get reviewed careful and kept in sync with the prose descriptions: http://dev.w3.org/geo/api/spec-source.html#geolocation_interface ]]
<matt> scribe: Matt
maxf: The statement that geographic information is provided in WGS84 is in an informative section.
andreip: In 5.4, under coordinates.
maxf: The expression permission bit is not clear.
jmorris: "Made available by the user agent requesting..."?
nickdoty: This might be a good time to talk about the implementation provider. Like in fx you send off a JSON array each time the implementation is called.
dougt: Every time the user accepts.
nickdoty: Not only are we going to give it to the script but from the service either.
andreip: Not made available to any entity at all.
jmorris: Does it solve it say "outside of the user agent"?
lbolstad: The script is outside or inside the UA?
jmorris: The API is the border between the script and the UA. You don't want anything to go either off to a third party or over the border.
lbolstad: I think this is covered in action-26
action-26?
<trackbot> ACTION-26 -- Andrei Popescu to add statement that the geolocation API should not be called before consent -- due 2009-11-09 -- OPEN
<trackbot> http://www.w3.org/2008/geolocation/track/actions/26
jmorris: That would address: "don't go out and get it from a third party", but it doesn't address handing it off to the script.
andreip: Well, it has nothing to hand off until permission is given.
maxf: The surrounding wifi APs? Does that constitute location information?
@@ something about cached values @@
lbolstad: How position is
acquired is an implementation detail.
... Part of the acquisition is getting wifi APs and cell
towers.
... Then you hand it off to a location provider, who turns it
into lat/long.
... We don't have to do it that way, we could ship with a built
in location database.
<alissa> it seems to me that the "made available" language is vague and could be clarified regardless of how action-26 is fixed
lbolstad: Could use, IP, etc.
dougt: Let's have Andrei write out ACTION-26 and hash it out.
<nickdoty> consensus (?) that "location information" includes WiFi IDs, cell tower IDs, etc. and that this information should not be made available without permission
maxf: Passing NULL for success
callback, some implementations raise an exception immediately,
others do nothing, others throw an exception at the time the
callback should be called.
... No location acquisition should happen before the exception
is raised.
... XHR for instance, even if you set the callback to NULL, the
XHR happens.
dougt: Maybe like you want to give the location provider your location, but you don't want to bother with a function in your script?
andreip: Doesn't seem all that
important.
... We list in the IDL that it's a required argument.
... The WebIDL spec should say what happens when the parameter
is NULL.
... If WebIDL doesn't say anything, then we should say in the
spec that you should throw immediately.
<scribe> ACTION: andreip to clarify what happens when a NULL is passed in for successCallback [recorded in http://www.w3.org/2009/11/02-geolocation-minutes.html#action07]
<trackbot> Created ACTION-30 - Clarify what happens when a NULL is passed in for successCallback [on Andrei Popescu - due 2009-11-09].
maxf: "Should we really show the full URI, not just the domain?"
andreip: According to HTML5 the document origin is the domain name.
<Hixie> and scheme and port
<Hixie> there's an origin spec now, if you're doing origin stuff, use that
<Hixie> http://tools.ietf.org/html/draft-abarth-origin
matt: Can we use IRI or URI RFCs and use host or ohost instead?
andreip: sure
jmorris: From a privacy perspective, I'd like to see more info... I might want to give one page of Google my location, but not all of Google?
lbolstad: We had talked about this.
andreip: The same origin policy makes this complicated. www.google.com/foo or www.google.com/bar then all I have to do is make a frame from bar to foo and use the DOM to access the stuff in /foo.
jmorris: If one hand has permission already, the other can get at it no matter what.
andreip: Yes, unfortunately.
jmorris: Isn't the permission you're going to be obtaining from the user more granular than you just said? If I go to a pizza place, you give it for the entire domain.
dougt: I don't think the full URI helps the user.
jmorris: Yes, the full URI is ugly.
amachin: Sub domains? www.google.com is different than maps.google.com?
andreip: That's right.
nickdoty: There are iframe work arounds for that as well.
andreip: If both documents set the domain you can get around it.
<scribe> ACTION: andreip to update the definition of origin to something we can normatively reference (IRI or URI RFCs perhaps) [recorded in http://www.w3.org/2009/11/02-geolocation-minutes.html#action08]
<trackbot> Created ACTION-31 - Update the definition of origin to something we can normatively reference (IRI or URI RFCs perhaps) [on Andrei Popescu - due 2009-11-09].
<alissa> is there an update on the iframe issue from device APIs?
maxf: "If the attempt fails, the
errorCallback is invoked with a new PositionError object,
reflecting the reason for the failure."
... The type of errors we can get, the description of
POSITION_UNAVAILABLE covers both errors with the provider and
the provider hasn't been able to return the position for
non-error reasons.
... If you don't provide enough information will a 3rd party
return an error or return a position for instance?
andreip: I think Google returns
based on IP. The accuracy won't be ideal.
... The app can then just reject the location.
maxf: Or a GPS can not get a satellite but it's not an error.
andreip: Then it would just timeout.
maxf: I didn't find a use case
for UNKNOWN_ERROR.
... The current wording makes it seem that POSITION_UNAVAILABLE
is the catch all.
dougt: I don't think we use it at all.
<scribe> ACTION: maxf to mail the text of http://people.opera.com/~maxfro/geolocation/ for persistence purposes [recorded in http://www.w3.org/2009/11/02-geolocation-minutes.html#action09]
<trackbot> Created ACTION-32 - Mail the text of http://people.opera.com/~maxfro/geolocation/ for persistence purposes [on Max Froumentin - due 2009-11-09].
maxf: Like if you're using a server based thing and you can't connect, I return a POSITION_UNAVAILABLE, which isn't helpful.
matt: Do these errors though effect how the author responds? on one do you retry or give up?
dougt: There are four errors: denied, unavailable, timeout -- those you can handle. The fourth we added to say we didn't know what happened. UNKNOWN_ERROR you should never get a position.
lbolstad: In both UNKNOWN and UNAVAILABLE your handling would probably be the same.
jmorris: Well, if I was told the position was unavailable, I might not try again.
maxf: I think just renaming UNKNOWN_ERROR to ERROR would make things better.
d
dougt: How?
maxf: Because UNKNOWN_ERROR can be an internal error...
dougt: What happens if the error is not in any of these three codes?
andreip: Does it matter?
maxf: I care about an internal error, it's misleading to report unavailable. It's a special case of not available.
dougt: I'd be in favor of
dropping UNKNOWN_ERROR completely, and in cases of not being
able to get your position it's UNAVAILABLE.
... As a human if I ask you where you are, you're not going to
say UNKNOWN_ERROR, right?
lbolstad: There is some sort of message, not just the error codes.
dougt: We thought returning a message was a bad idea.
andreip: We return the message returned to us.
maxf: We return a generic error message.
jmorris: I cannot imagine what private information might be in those error strings... if there's no real value to the error string, why not just not pass the error string.
andreip: Might as well drop the error message.
maxf: It's useful for debugging.
dougt: In the case of this being
debugging I'd suggest that looking at a wire trace would be
equally as informative.
... The message is not needed and could be an information
leak.
... I wanted to drop UNKNOWN ERROR and the message.
RESOLUTION: Drop
UNKNOWN_ERROR
... Drop message
maxf: "This operation must first
attempt to obtain the current location of the device and invoke
the appropriate callback."
... 'Appropriate' refers to the earlier getCurrentPosition(),
we should be explicit.
andreip: It should be in the algorithm section now.
http://www.w3.org/TR/geolocation-API/#geolocation_interface getCurrentPosition()
<scribe> ACTION: andreip to fix 'appropriate' to point to description in algorithm [recorded in http://www.w3.org/2009/11/02-geolocation-minutes.html#action10]
<trackbot> Created ACTION-33 - Fix 'appropriate' to point to description in algorithm [on Andrei Popescu - due 2009-11-09].
maxf: "It then must continue to
monitor the position of the device and invoke the appropriate
callback every time this position changes."
... This is vague and might lead to very high updates.
andreip: The draft is updated to say:
[[In step 5.2.2 of the watch process, the successCallback is only invoked when a new position is obtained and this position differs signifficantly from the previously reported position. The definition of what consitutes a significant difference is left to the implementation. Furthermore, in steps 5.2.2 and 5.2.3, implementations may impose limitations on the frequency of callbacks so as to avoid inadvertently consuming a disproportionate amount of resources.]]
matt: ah, no that was about the word 'cheaply', not 'appropriate'...
lbolstad: In the options we don't offer an option for granularity you may want.
andreip: We have some algorithm...
dougt: We do something where we do less updates closer to the poles for instance.
andreip: The spec says it's left to the implementation, I think that's fine.
nickdoty: You could imagine different use cases where you only get updates every few feet vs every few miles.
lbolstad: I think CoreLocation offers this ability.
dougt: But not to script.
matt: So we don't want this feature?
No.
dougt: It can be very expensive, with round trips to the network, etc.
maxf: What is a change in position? If your position object returned by the success object, would say, a change of accuracy constitute a change in position?
andreip: I think we (Gears? Spec?) take that into account and only do a position change if accuracy increases.
dougt: It's somewhat orthogonal to the API. We could spec it out and all implement it the same way.
jmorris: You might have more usecases if there is a commonality.
dougt: If you have a non-browser that say uses feet or something, it might be drastically different.
jmorris: From the perspective of a site, wouldn't you want the same pattern of information regardless of who it's from?
dougt: You may have them different even with the same data set.
andreip: You won't be getting the same behavior anyways because we use different providers, etc.
peter: There is a representation
of a bounding box inside/outside and another might have a
point.
... If you're going to go down into the details of getPosition
is, you have to go down into the details of what you're
representing.
maxf: I'm suggesting a wording
modification. Replacing "every time this position changes" with
"every time the implementation reckons the position has
changed" or something.
... Otherwise it'd be invoking the callback any time it'd
like.
... If it's just an implementation detail you might as well not
put it into the spec.
... If you leave the position changes undefined, then you might
as well say any time you like.
[[In step 5.2.2 of the watch process, the successCallback is only invoked when a new position is obtained and this position differs signifficantly from the previously reported position. The definition of what consitutes a significant difference is left to the implementation. Furthermore, in steps 5.2.2 and 5.2.3, implementations may impose limitations on the frequency of callbacks so as to avoid inadvertently consuming a disproportionate amount of resources.]]
andreip: The updated text is better?
maxf: "The watch operation
continues until the clearWatch method is called with the
corresponding identifier "
... What does clearWatch() do when an unknown identifier, or an
already cancelled one, is passed?
dougt: We clamp it at like a 1000 watch positions.
andreip: And when you hit the max?
dougt: Just fail.
maxf: Suggest nothing happens if you pass one that's not known.
dougt: There are two cases, out of bounds would throw.
maxf: In that case it throws because it breaks the IDL. But if it's a valid int that isn't used, it should do nothing.
dougt: We don't throw from clearWatch unless it's a type problem.
<scribe> ACTION: andreip to update the spec to clarify that an unknown watch ID is a noop. [recorded in http://www.w3.org/2009/11/02-geolocation-minutes.html#action11]
<trackbot> Created ACTION-34 - Update the spec to clarify that an unknown watch ID is a noop. [on Andrei Popescu - due 2009-11-09].
maxf: there are some typos and some rfc2118 items as well.
<scribe> ACTION: andreip encoutered == encountered [recorded in http://www.w3.org/2009/11/02-geolocation-minutes.html#action12]
<trackbot> Created ACTION-35 - Encoutered == encountered [on Andrei Popescu - due 2009-11-09].
<scribe> ACTION: andreip to update spec with rfc2118 keywords in clearWatch section [recorded in http://www.w3.org/2009/11/02-geolocation-minutes.html#action13]
<trackbot> Created ACTION-36 - Update spec with rfc2118 keywords in clearWatch section [on Andrei Popescu - due 2009-11-09].
maxf: "The same default value is used in ECMAScript when the timeout property is omitted. " I don't know what that means.
andreip: In ECMAScript you can omit parameters...
maxf: But in other languages you can do that as well.
[[In ECMAScript, the enableHighAccuracy, timeout and maximumAge properties are all optional: when creating a PositionOptions object, the developer may specify any of these properties.]]
[[The same default value is used in ECMAScript when the timeout property is omitted.]]
[[The same default value is used in ECMAScript when the maximumAge property is omitted.]]
all from: http://dev.w3.org/geo/api/spec-source.html#position_options_interface
andreip: I believe in WebIDL you can drop the PositionOptions object, but if you don't you have to specify ALL of the properties.
maxf: I'm surprised by that.
andreip: I believe Cameron said that.
maxf: Since this specification wants to be language agnostic, I think the ECMAScript statements should be moved to be together.
http://lists.w3.org/Archives/Public/public-geolocation/2009Jul/0009.html
[[It doesn’t make sense to say that the attributes (at the IDL level) are optional. An object that implements an interface must have those attributes. But in ECMAScript, native objects that implement an interface needn’t have properties to represent those attributes, since all that happens is that a [[Get]] on the object is performed with the relevant property name.]]
maxf: I'd still submit that the
ECMAScript comments should be moved together.
... The specification is not bound to a single language and
there could be others... I don't know.
andreip: Perhaps move them to the end, saying: "This is the ECMAScript behavior"
<scribe> ACTION: andreip to group together ECMAScript statements and propose to the list [recorded in http://www.w3.org/2009/11/02-geolocation-minutes.html#action14]
<trackbot> Created ACTION-37 - Group together ECMAScript statements and propose to the list [on Andrei Popescu - due 2009-11-09].
[[The maximumAge attribute indicates that the application is willing to accept a cached position whose age is no greater than the specified time in milliseconds. If maximumAge is set to 0, the implementation must immediately attempt to acquire a new position object. Setting the maximumAge to Infinity will force the implementation to return a cached position regardless of its age. If an implementation does not have a cached position available whose age is no gr
than the specified maximumAge, then it must acquire a new position object. In case of a watchPosition(), the maximumAge refers to the first position object returned by the implementation.]]
maxf: Wording unclear. At least "will force" should be "must".
[[The coords attribute contains a set of geographic coordinates together with their associated accuracy, as well as a set of other optional attributes such as altitude and speed.]]
maxf: altitudeAccuracy, accuracy,
speed, heading, speed should be unsigned.
... Withdrawing that, can't have a signed double anyway.
andreip: We want the precision of a double there anyway.
maxf: Should we say those values must be positive or null?
andreip: Seems like a bug, not sure about heading though.
m
ax
f
S
maxf: Should heading also be
limited to 0,360?
... Heading is confusing, because you could have several
headings be the same, e.g. 0 is the same as 360, 90 is the same
as 450.
lbolstad: The v2 issue is whether we move it to a different location.
maxf: In this version, do we want to mention possible values?
andreip: Yes, I don't see why not.
dougt: It's specified as being in degrees. 720 is valid.
maxf: So it's up to script authors to know they're the same?
<jmorris> http://tools.ietf.org/html/draft-singh-geopriv-pidf-lo-dynamic-07
jmorris: I was going to bring up some comments about velocity and heading that probably makes more sense in v2.
<jmorris> this is what Richard Barnes suggests the IETF is doing on heading and velocity
amachin: Why are we using a double for speed? Shouldn't float be enough?
andreip: In ECMAScript float and double is the same... accuracy and heading perhaps?
dougt: Does the IETF draft consider anything other than orientation relative to ground? e.g. on a plane?
jmorris: I don't know, talk again tomorrow.
maxf: "The accuracy and
altitudeAccuracy values returned by an implementation should
correspond to a 95% confidence level. "
... What does confidence mean?
andreip: It's based on sampling statistics.
maxf: I don't know statistics, what do you do?
dougt: We don't do anything with it.
a
ndr
dougt: Can we drop it?
andreip: Yes.
peter: If you do statistics, do 2 or 3 sigma, not 95%
-> http://lists.w3.org/Archives/Public/public-geolocation/2008Oct/0043.html confidence discussion
maxf: If it is implementable then
we should leave it.
... I'm not sure it's even possible.
dougt: We can't really guarantee
that. We've outsourced this stuff... they provide us the
accuracy but never see their confidence level at all.
... And we can't guarantee which provider we'll use at any
particular time.
... We're going to pick the best location with the two
different sources.
nickdoty: The accuracy doesn't mean much without confidence.
dougt: To a developer? If I say: "I am within 100meters of here" what does that mean?
nickdoty: In English you'd assume 100% confidence.
lbolstad: Is there a confidence
within other APIs?
... This is information we don't have access to...
... It's a SHOULD requirement.
maxf: My original comment was what does it mean?
lbolstad: We can discuss what it is offline, but I think it's problematic to have it in the spec.
tlr: We're giving a measurement
without any guarantee...
... You're talking about a sensor with a measure and a standard
deviation.. not giving that measurement without knowing the
quality...
... Passing on information that you've gathered from sampling,
but passing that information on without accuracy seems
problematic.
a
n
dr
andreip: But we don't get that
information at all..
... In Gears we say the horizontal accuracy is 95%
confident.
<andreip> http://code.google.com/p/gears/wiki/GeolocationAPI
matt: Do we need to research a bit more before removing it?
andreip: I think it's fine as a SHOULD.
dougt: It gives a false impression though.
lbolstad: So it's fine to leave it in there.
andreip: Agreed.
maxf: "POSITION_UNAVAILABLE
(numeric value 2) The position of the device could not be
determined. One or more of the location providers used in the
location acquisition process reported an internal error that
caused the process to fail entirely"
... "one or more"? If at least one of the providers succeeds,
shouldn't that be a success instead? Should it even be
mentioned that there can be more than one, given that this API
is agnostic to the geolocation device?
... If one of them acquired the position then isn't that a
cucess?
andreip: Right, it's only if it fails entirely.
maxf: I think we should not be so specific then.
<tlr_> For the record on accuracy: I agree with Peter that the accuracy parameter needs to be defined in terms of standard deviations.
matt: We don't have providers mentioned in the API elsewhere.
a
ndr
andreip: It's more of an example.
<scribe> ACTION: andreip to update 5.5 POSITION_UNAVAILABLE to say "For instance: one or more..." [recorded in http://www.w3.org/2009/11/02-geolocation-minutes.html#action15]
<trackbot> Created ACTION-38 - Update 5.5 POSITION_UNAVAILABLE to say "For instance: one or more..." [on Andrei Popescu - due 2009-11-09].
jmorris: There is still ambiguity... if it's just a for instance, leave out the one or more.
andreip: "For instance: the position fo the device could not be determined because the location provider reported an internal error"
maxf: "TIMEOUT (numeric value 3)
The specified maximum length of time has elapsed before the
implementation could successfully acquire a new Position
object."
... replace with "the length of time specified by the timeout
property has elapsed before... "
peter: And instead of 'before' you could say 'without acquiring' because you don't know if it's ever going to happen.
<scribe> ACTION: andreip to update TIMEOUT error to say "the length of time specified by the timeout property has elapsed without acquiring..." [recorded in http://www.w3.org/2009/11/02-geolocation-minutes.html#action16]
<trackbot> Created ACTION-39 - Update TIMEOUT error to say "the length of time specified by the timeout property has elapsed without acquiring..." [on Andrei Popescu - due 2009-11-09].
http://lists.w3.org/Archives/Public/public-geolocation/2009Oct/0007.html
<amachin> http://lists.w3.org/Archives/Public/public-geolocation/2009Oct/0007.html
dougt: The classname of the
objects we put in the DOM are prefixed with 'Geo'.
... It's an artifact of the way this was built.
jmorris: Can one implement this API without the Navigator interface?
lbolstad: The way it's written now, yues.
andreip: It says if you implement Navigator you must, and it must be named geolocation.
dougt: We have two issues: it's off navigator and ??
andreip: What really matters is how you find the object name.
maxf: actually, the WebIDL spec does say that the interfaces are class types.
<maxf> in http://dev.w3.org/2006/webapi/WebIDL/#ecmascript-binding
matt: Is it an unreasonable expectation from reading this spec that it may not be a singleton?
andreip: You shouldn't ever new
it, it may be sufficient to say that it can't be
instantiated.
... It may be fine to put NoInterfaceObject on the Geolocation
interface as well.
dougt: I don't want to prevent people from new-ing things.
matt: But we should put this in the spec, then his tests shouldn't try to new it and we'll be okay with the ones that run against window.navigator.
<scribe> ACTION: andreip to add NoInterfaceObject option to Geolocation interface [recorded in http://www.w3.org/2009/11/02-geolocation-minutes.html#action17]
<trackbot> Created ACTION-40 - to add NoInterfaceObject option to Geolocation interface [on Andrei Popescu - due 2009-11-09].
<scribe> ACTION: dougt to respond to Dom's mail about geolocation tests. [recorded in http://www.w3.org/2009/11/02-geolocation-minutes.html#action18]
<trackbot> Created ACTION-41 - Respond to Dom's mail about geolocation tests. [on Doug Turner - due 2009-11-09].
matt: Is anyone maintaining a list of implementations that they'd like to share?
<lbolstad> here's what the cdf working group produced: http://www.w3.org/2004/CDF/TestSuite/WICD_CDR_WP1/wicdmatrix.xhtml
nickdoty: From the research side
Berkeley is interested in a list and doing research on the
section 4 compliance and the services out there.
... I've tried to find some websites, only found a dozen or
so.
andreip: Probably not that many. Lots of Google ones and some iPhone ones. Might not be easy to crawl...
lbolstad: Maybe we should concentrate on test suite, browser behavior, and another volunteer could do the sites for the API?
jmorris: And perhaps a pointer on
the homepage to an external list.
... Everyone may know about twitter and facebook, but others
may know about other sites...
<nickdoty> http://npdoty.name/location/services
<dougt> nickdoty: ^ public?
lbolstad: Do we need two more hours to discuss clarifications to the spec?
an
dre
andreip: Probably not. We could recap the list of action items for this morning.
<nickdoty> Well, it shouldn't be considered a comprehensive list, but I don't mind people looking at it.
-> http://www.w3.org/2002/09/wbs/35125/TPAC09/registrants#geo Current registrants
-- Adjourn for Lunch --
<jmorris> we are reassembling
<jmorris> slowly
<lbolstad> scribe: jmorris
We have the Opera and WebKit test suits
<dougt> ACTION: always save matt a seat. [recorded in http://www.w3.org/2009/11/02-geolocation-minutes.html#action19]
<trackbot> Sorry, couldn't find user - always
Mozilla and Google also have test efforts
lbolstad: goal to turn into one
test suit
... should it be automated
dougt: yes
lbostad: should we split test into two
maxf: one set to check the API
<lbolstad> split into two would be in order to have one part that tests just the API with no dependencies on the location provider
maxf: I created a function that is run b allof the tests
<lbolstad> the other half consisting of tests that requires control of the location provider...
s/b allf/by all of/
dougt: tell a provider to send
test locations
... we should decide what to test
maxf: started with reading spec
and looking for each testable sentence
... wrote test condition throughout spec document
<andreip> the WebKit geolocation tests are here:
<andreip> http://trac.webkit.org/browser/trunk/LayoutTests/fast/dom/Geolocation
maxf: tests that test privacy
setting (hard to make them generic)
... tests to test value from device
... tests for error handling
lbolstad: hard to automate privacy across browsers
maxf: if you want to automate
privacy UI testing, each UI do it themselves
... extra level of difficulty
... opera has "yes/no/remember" but spec does not say anything
about that
andreip: we just test assertions
that the spec makes
... we need javascript
jmorris: is there anyway to test for 4.2 provisions in spec
andreip: not really
lbostad: cannot test what
recipient follows spec
... hard to automate whether disclosure requirements are
complied with
matt: why automate?
dougt: look to ways to optimize, both for W3C requirements and for internal QA
lbostad: want this to beneficial
for own QA purposes
... but we may not be able to automate all of it
... goal to have suite as automated as possible, but may have
manual elements
nickdoty: do we need recipient testing
dougt: how can we enforce or test this?
nickdoty: still, do we need to have two services
lbostad: we could set up test
sites if needed
... but not be valuable
<matt> [[ my point on automated testing was that: if we have parts of the spec that require non-automated testing then we still have to test it to get to PR ]]
nickdoty: looked at sites, and not one is implementing 4.2
dougt: some sites are not in compliance, some are better
nickdoty: most sites are not
clear and conspicuous in their notice
... perhaps we could build a reference implementation
... here is what should be done, here is what should not be
done
lbostad: is it part of
demonstration of interoperability
... would say "no"
[some interest in a reference implementation]
andreip: how did you test
4.1
... privacy should be run manually
<matt> Meeting: Geolocation WG F2F, Day 1
andreip: some tests listed by maxf under 4.1 perhaps should be elseswhere
<andreip> http://trac.webkit.org/browser/trunk/LayoutTests/fast/dom/Geolocation
[looking at webkit test....]
<dougt> mozilla's: http://mxr.mozilla.org/mozilla-central/source/dom/tests/mochitest/geolocation/
dougt: we can probably run our
tests through all browsers
... geolocation_common.js can probably be used in opera,
others
andreip: this approach may be the way to go
dougt: we should keep some
testing manual, but facilitate automated testing if
possible
... by maxf test, do we have two independent implemtations that
work?
maxf: yes
matt: how complete is the maxf test? Who has reviewed it?
lbostad: maxf when through the entire spec
matt: someone should review it for completeness
lbostad: let us use maxf effort
as the starting point
... post to mailing list and ask for review, input
<matt> ACTION: lbolstad to publish MaxF's test suite to the mailing list and request review (after Andrei has made updates to the specification) [recorded in http://www.w3.org/2009/11/02-geolocation-minutes.html#action20]
<trackbot> Created ACTION-42 - Publish MaxF's test suite to the mailing list and request review (after Andrei has made updates to the specification) [on Lars Erik Bolstad - due 2009-11-09].
<matt> ACTION: dougt to review internal test suite and see if there is anything not covered by MaxF's test suite [recorded in http://www.w3.org/2009/11/02-geolocation-minutes.html#action21]
<trackbot> Created ACTION-43 - Review internal test suite and see if there is anything not covered by MaxF's test suite [on Doug Turner - due 2009-11-09].
<matt> ACTION: andreip to review internal test suite and see if there is anything not covered by MaxF's test suite [recorded in http://www.w3.org/2009/11/02-geolocation-minutes.html#action22]
<trackbot> Created ACTION-44 - Review internal test suite and see if there is anything not covered by MaxF's test suite [on Andrei Popescu - due 2009-11-09].
andreip: we should create common loc provider for tests
<matt> ACTION: matt to look into copyright on test suite stuff [recorded in http://www.w3.org/2009/11/02-geolocation-minutes.html#action23]
<trackbot> Created ACTION-45 - Look into copyright on test suite stuff [on Matt Womer - due 2009-11-09].
matt: should the test suite should go onto W3C server?
maxf: copyright questions?
<maxf> http://people.opera.com/~maxfro/geolocation/
matt: I will look at copyright question on test suite
andreip: should we include a stress test
dougt: not part of interoperability
maxf: I will remove them from the test suite
Rahul: send implementation reports?
matt: post URL of test, ask for results
Rahul: good to have test suite in a versioning system
matt: might be easiest to put into wiki for updating, etc.
<matt> ACTION: matt to figure out where to put the test files cvs vs wiki, etc [recorded in http://www.w3.org/2009/11/02-geolocation-minutes.html#action24]
<trackbot> Created ACTION-46 - Figure out where to put the test files cvs vs wiki, etc [on Matt Womer - due 2009-11-09].
<matt> ACTION: dougt to define how to setup the mock location provider and how to tell implementations to use it [recorded in http://www.w3.org/2009/11/02-geolocation-minutes.html#action25]
<trackbot> Created ACTION-47 - Define how to setup the mock location provider and how to tell implementations to use it [on Doug Turner - due 2009-11-09].
andreip: need instructions about how to use the mozilla test location provider
dougt: will provide this info
andreip: timeline for test suite?
matt: do we have a good summary
of changes since last call?
... have anything changed our implementions?
... do we need to do another last call?
dougt: three changes (2 bugs in firefox) -- only in spec: position error - drop unknown error and message
matt; will look at process document for sensitivity of last call process
dougt; many implementations did not use the elements to be removed
<matt> http://www.w3.org/2005/10/Process-20051014/tr.html#last-call
matt: "substantive changes in the document" -- we seem not to be at that level
<matt> http://www.w3.org/2005/10/Process-20051014/tr.html#substantive-change
andreip: prior to meeting, we
just clarified what spec says
... no api changes
matt: we should do a diff to be
sure
... we need to provide diffs from now on
... seems likely that we do NOT need a second last call
[end test suites]
<matt> [[ my gut feeling from the changes we've talked about is that they are minor in nature and don't "invalidate implementation experience", and that we do not need to do a second last call ]]
matt: charter ends at the end of
the year
... we need to gather future work items, getting an extension
or write new charter
... once we know is in V2 we should write a new charter
... Oslo group is looking for home
... layering geoloc into jabber
... second charter could take on other geoloc topics such as
this
... we should not recharter on the old charter -- we should
extend until we know new tasks to do before a new charter
... Response to comments, nov. 12
jmorris: at end of 4.1, replace "E911" with "emergency services"
<matt> http://www.w3.org/2002/09/wbs/35125/TPAC09/registrants#geo
[trying to figure out next steps -- do we discuss last call comments now or at 5pm]
<amachin> http://lists.w3.org/Archives/Public/public-geolocation/2009Aug/0005.html
<matt> s
<matt> scribe: Matt
jmorris: I have one particular
privacy comment I'd like to talk about it.
... I don't think we need to spend time discussing GEOPRIV,
we've discussed this and it's obviously been rejected.
... We'd asked for clarification on "expressed permission"
provision, we don't feel it really clarifies anything as to
what the group understanding of express permission means.
... I have a sentence that we think if added to 4.2 it would
help clarify what we think would be good.
... We think it's a bit vague on express permissions.
<jmorris> We would suggest adding this sentence to the end of the last paragraph of 4.2: Express permission must be obtained explicitly from the user, and cannot be implied or inferred based on a general disclosure on the recipient web site (such as a terms of service or privacy policy document), even if accompanied by a user's acceptance of such a disclosure.
jmorris: "Express permission" maybe clarify that it's not something one can just bury in a privacy policy.
lbolstad: there was a lot of discussion on the mailing list that led to this phrasing.
jmorris: I think this, if added, would resolve our privacy concerns wrt 4.2 express permission language.
dougt: I think this is fine in general, but in the extreme, if you have a website that shares your location, and that's all there is for instance, or in twitter, etc, it'll be spelled out in their terms of use, etc. Would you want them to have this text next to their share location button?
jmorris: I'm not quite talking
about a site where sharing location is the purpose of the site.
The greater concern is say, a website where you order a pizza,
and you're not expecting your location to be shared. We
wouldn't want paragraph 47 in the TOS to be the 'express
permission'.
... My interpretation frankly would be that a twitter or a
facebook that is routinely sharing information should have a
pretty clear consent that isn't buried in ToS. It may be a
preference that persists for a long time. I'm not saying each
time the site needs your location it needs express
permission.
dougt: In maps.google.com there's
a blue button that invokes the geolocation API.
... Or Flickr/maps has a find my location button.
jmorris: Express permission in
the spec only pertains to retention and retransmission, so I
don't know if that helps to answer...
... The term express permission appears three times, once about
UIs, and then two times in 4.2. I'm only addressing those in
4.2
dougt: In your language could you say: "express permission to retransmit or retain must be obtained explicitly from the user"
jmorris: I do think lbolstad was
right and that we should put it to the list to see what others
think.
... Ultimately I think that's a clarification of what's
here.
dougt: It does invalidate something like facebook from it's ToS...
jmorris: I don't think this is a substantive change effecting LC.
dougt: Oh, I'm not saying that.
jmorris: I'd argue this isn't a real change, as I don't think ToS would ever say that ToS is an express permission granter...
[[granter was my own verb]]
<dougt> heh
jmorris: I think this would help recipients to comply with the existing rule actually. I would argue it's not a change, but makes it more clear.
nickdoty: If you add an example
around express permission then what do you mean around the last
paragraph about inconspicuous and clear disclosure.
... If you look at the FTC, they're not happy with behavioral
advertising to be disclosed in a ToS or privacy policy
paragraph 47...
... You don't need express permission to say how it's secured
or retained. But it is supposed to be clearly and conspicuously
exposed.
jmorris: I think this group would
be agnostic on that front. The expressed permission bit is more
operational than that question.
... I suggest that sentence I proposed go in a single fourth
paragraph or in an extra paragraph between 2 and 3, but at the
end of the 3rd paragraph is fine. It might flow better
elsewhere.
dougt: End of the second paragraph?
jmorris: Well, it does related to
the idea of expressly permitted. Don't want it to imply that it
applies only to paragraph 2
... Should I put it on the list?
andreip: I think so.
lbolstad: I'm fine with adding that.
matt: Accepting that text (or similar) are you fine with the rest of our responses?
jmorris: I'm not entirely clear
what CDTs response will be just yet. We numbered our responses,
this would address our number 1.2..
... Will that mean we are satisfied with them all? We haven't
figured it out.
matt: But before 12 November?
jmorris: Yes.
lbolstad: Anything else about CDT comments that we need to address here?
jmorris: I don't think so, either
we'll agree to disagree or CDT will push it further, but I
don't know.
... In process points, I pretty strongly do disagree about
Apple's participation.
... But at the end of the day, the chairs have made the
decision and reiterated the decision, so I don't know if
anything we can discuss will change either of oru views.
... On Skyhook? I can tell you that I am not going to go out
and try to rattle Skyhook's cage, and instead let the concern
drop. In the end if there are patent issues, a patent troll
acquires the patents, whatever, ultimately the members are on
the hook, not me.
... So, I can safely predict that we won't do anything further
on that part. The Apple concern I do think is a problem.
nickdoty: What happens if you have an external script getting a location?
andreip: The script runs in the context of the HTML page, so it's the HTML page that that has access to the location, not the remote script.
lbolstad: If you have an iframe that has an HTML source that is from a differetn domain, and a script within that iframe is also from the other domain...??
<lbolstad> no, if your document includes an iframe with a (html) src from a different domain, then any script inside that iframe document is executed in the context of that other domain
dougt: The proposal from a year ago was only the 'top level' HTML page would have access. Where the iframes would then have to negotiate with the top level page how to get the location.
nickdoty: If yuo include a script from a third party?
dougt: If you write <script
src="other domain"> then it's executed in the domain space
of the original document, so it's only going to present the
documents domain.
... There is only one script context for a simple document.
Fetching the script from a remote domain it will be slammed
into the original script context, regardless of it being on
another domain.
... For instance, mobile fx will default to an answer if you
say the same thing five times in a row.
... It's a paradigm shift for UAs.
<dougt> fu
lbolstad: It looks like we're
done with today's agenda.
... We'll pick up at 8:30.
m
att
matt: Let's meet at 8:30 and start by 9.
amachin: Any changes for tomorrow's agenda?
dougt: Anyone got compass APIs?
andreip: just orientation,
etc.
... We should discuss tomorrow.
Adjourned!