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.

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

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.

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

[[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"

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

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.

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.

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

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

Clarifications to the spec

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

Discuss Last Call comments and responses

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

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.

Miscellaneous

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.