See also: IRC log
<matt> Scribe: DKA
<scribe> ScribeNick: DKA
Seggers
Angel: How can we start?
Lars-Erik: Can we get an overview of where the spec from geopriv is?
Richard: Two things we want to
enable [with geopriv proposal]
... first ability to communicate privacy information second
clear privacy rules.
... this lays out a systematic framework for what rules a user
should expect to be there for any UA implementing the spec.
<matt> CDT's proposed spec with geo privacy and civic addressing
Richard: a user can have a consistent expectation of what sorts of policies they will be able to set within their UA.
<matt> diff-marked version
Richard: high level goal is to
lay out the privacy framework within the UA - adapted from the
geopriv policy rules.
... we have this generic concept as the UA as a "location
server" - UA gets the location from various sources (e.g.
skyhook, gps chips, etc...)
... UA makes a decision on whether to send that
information.
... the geopriv proposal says how the UA should encode the
location into that message also specifies how to encode privacy
data into the message.
John: I think that we're looking
at the conversation this group is having as going beyond the
specific question of how browsers relate to scripts.
... we think there is a broad issue - how is location privacy
going to be dealt with in the Web in general... and the
Internet.
... so we view this as a broad question to be decided.
... we could talk about the technical suggestions...
Doug: I have lots of privacy
worries from lots of different ways a user can interact with a
web page - divulging information, Credit Card info, etc... Can
we scope this - to have a resolution of what we want to do with
the API...
... some way to support geopriv location providers...
... I don't think that mitigates privacy worries.
John: Yes, location is not the
only privacy concern - what the IETF is trying to do with
Geopriv is to change the game. On the Web, users are presented
with a take it or leave it situation.
... the theory underlying geopriv is to try to reverse that. We
hope this approach could be applied more broadly.
Andrei: I agree we need to scope it. We started by proposing a solution. Can you define what the problem is that this solution will solve?
John: I would articulate the
problem to be the goal of giving users a greater degree of
control over their location information. Most importantly,
conveying to the
... recipients of location information clear expectation as to
what happens to [that information..] If those expectations are
conveyed then it's more likely
... that those expectations will be enforced by law. There's a
great value to communicate the expectations.
Doug: re: guidelines - W3C has
done this using guidelines in the past. I think we should find
other ways to expose [geopriv data] or to think of a general
way that
... web sites can [deal with privacy].
<Hixie> (imho specs should be written to solve technical problems, not to provide leverage for legal policy debates)
John: We've had good guidance
[from governments] on how organizations should handle privacy
but in the U.S. at least these rules have been largely
ignored.
... It's not transparent how a destination web site is using my
information.
... If a privacy policy states a certain thing -
Andrei: You have proposed some sound principles on what do with location information. They make sense. Exposing them through a guideline makes sense.
John: If you don't convey a
specific users' expectation on how information is to be
preserved then it will not be treated any differently then any
other private information.
... we don't think that privacy on the Web is a success story.
The geopriv proposal is trying to change that.
Richard: privacy preferences are dynamic.
Doug: Most users don't need
dynamic preferences...
... We expose any preference through an advanced interface.
People want to turn things on and off. If people are not
following published guidelines - why would this help? Also if a
UA always users default values what's the value to it?
John: It's one thing to say in a guidelines "you should behave in xyz manner" vs specifically communicating the information with each transaction.
Richard: Right now, a privacy policy might say "I'm going to send this out in violation of a regulation" and you as a user have no choice.
Doug: We could expose options off
the position object that provide this data... It could support
geopriv - this could help to support.
... so don't populate the top level with rules.
... Look at existing rules exposed to the DOM - these don't
feel consistent. Date and expires tag might be more
consistent.
<Hixie> if a site is going to send out the data in violation of a regulation, why would they follow unenforced rules given in an API?
Doug: this conversation's not about privacy - it's about how to expose geopriv in geolocation.
John: The idea of geopriv is that
if you're going to expose location then it's mandatory to
expose rules regarding that information. If you don't make it
mandatory then it won't be implemented.
... what we're proposing is to put more privacy sensitivity
into the spec [then might be there in any case.]
... if W3C says "you should pay more attention to privacy" then
people would pay attention.
... It's important for it to be mandatory.
<matt> Scribe:Matt
<Hixie> the w3c says "you must write valid html" but more than 90% of documents are invalid
<scribe> Scribe:DKA
Dirk: Are you aware of what the
legal requirements say on location in Europe?
... for instance, you have to opt in. There is a EU directive -
if you read the text it immediately opens interpretation. Any
local states translate this text into their own language and
their own interpretation.
... it says the user/subscriber must give consent - which is
not clear who this is [or is subject to interpreation]
... e.g. retention period - eu directive states you cannot
retain the data longer than it takes to provide the service.
But in Spain, for example, for law enforcement purposes you are
required to keep your location indefinitely.
... this would be the location server.
<matt> [ use cases, use cases, use cases...! ]
Andrei: normally this location is anonymous.
Dirk: there is a code of practice
for location services in the UK - for the telcoms environment.
The telecoms world and the Internet world are
different...
... this location applies to mobile operators - starting from
that assumption you as a mobile operator concerned with privacy
of your customers.
... in the telecoms space, location was very well protected but
also that there were nearly no service. because the regulations
imposed so many regulations.
... now we're in a different place in time. This new resource
[the Web] for which we have old fashioned telecoms rules, - if
we apply old rules there would be no business. We need to
figure out how to protect privacy without blocking new
businesses.
... a way we use is to talk about active and passive
applications. Active location apps are where you request a
location function to be performed.
... I know that to get that service performed I need to
disclose data. Consent is implicity.
Doug: The question is - how is that [non-retention of data] enforced?
<matt> [ Fnding a Pizza Hut doesn't require Pizza Hut to know who you are, or store your location. Location for delivery is different and requires retention ]
John: U.S. perspective - in
telecoms space in the US we have fairly clear regulations for
location and no rules for privacy outside the telecoms space.
In Europe you have much better baseline regulations.
... right now in the U.S. there is no significant constraint on
what gets done. If [pizza provider] says in its privacy policy
that it can do what it wants with your data then it can do
whatever it wants.
... there are 2 ways that attaching policy info to location
info can effect how strongly privacy is protected. The FTC will
go in some situations and bring legal entities that violate the
customers' expectations. And whether something is a reasonable
trade practice or not turns on what the customer expects.
... another way where expectation or privacy is important: on
the question of whether the government can get access. If the
government goes to [pizza provider] and asks for everyone's
location info that ordered pizza. The hurdle the government
needs to get over is higher if the policy of how the data was
to be used as clearly communicated.
... both sides of the Atlantic are in the state of transitions
- from a telecoms world to a non-telecoms world... I think that
transition in the U.S. will take years more.
... if this group or the W3C allows location to be dealt with
like most other information on the Web then we lose an
opportunity to create expectations of privacy that can be
enforced.
<rbarnes> (marc linsner)
Marc: just including those - there's a default set of what the privacy rules should say of 'just send the default rules'.
Doug: in the Dom why wouldn't you move the privacy rules into the options. Right now you go to maps.google.com, JS loads into the browser, that JS starts tracking where the UA is. That initial call could pass in the rules / expires tag / no retransmittal rules at that point instead of off of the transition object.
<inserted> DKA: I went to the Kai Hendy page and it brought up a dialog that said "Do you want this app to be able to use gears to get your location?" from the user perspective means nothing. That's the opportunity right there to give them a useful interaction. Like, what happens in FaceBook.
Doug: the assumption is that those rules will not change in the course of the transmission session.
<rbarnes> (alec)
Alec: what if when the site requests location the user is asked this in a basic set of options - e.g. maps.google.com will not save this will not transmit this... so also provide data...
Matt: I think we should leave off the table the rdf/xml rulesets - so leave them off the table for now.
John: Happy to focus on that but
suggest we should come back to that discussion.
... a concern I had - thinking about what was said - looking
back at one of the first privacy efforts W3C did - p3p - which
had a good theory and some value.
<matt> [ I just don't want to see the whole thing thrown out because someone doesn't know how to make a good GUI for abritrary rules sent in RDF ]
<Hixie> if the user isn't going to understand "should the web site be given access to your location", they certainly aren't going to understand the prefs exposed by geopriv
John: the real failure of p3p is
that it didn't change the dynamic. The site itself [pizza
provider] would say "these are our take-it-or-leave-it" rules -
geopriv is trying to change that.
... I think that setting privacy rules in the hands of the
developer...
<inserted> DKA: I came over here and implemented a registration page on a dotcom site, and I got a crash course in EU privacy rules. It doesn't necessarily stop the data from being misused, when the company went under, someone sold the data. There is a value though to asking those detailed questions, even if they might simply say they're going to use it however they'd like.
Alissa: every site would just say "we will retain this data and be free to retransmit etc..."
John: You can say the transaction must fail if the user has set a requirement that the recipient is unable to comply with.
Doug: people will think the browser is busted...
John: Studies have shown that at
least Americans do actually care about their location privacy.
There are lots of examples of Americans being spooked out about
big brother tracking.
... I think there's a greater likelyhood that people will pay
attention to location options.
... I know lots of people are giving their locations away using
twitter, etc...
Andrei: If it's true that some businesses are already following data protection rules... [ then why code this in geopriv ]
John: A lot of sites would in
fact pay more attention if the data is transmitted [with each
request].
... this is an effort say to [pizza provider] don't start a
location-aware business.
Alissa: The rules act as a motivator towards doing that kind of things in the right way.
<Hixie> what evidence is there that this api would make people pay more attention?
Alissa: there are lots of businesses that want to retain data and use it [indiscriminately].
Doug: If I enter my zipcode via a form or using a gelocation API then I am going there and giving them my information.
<Hixie> (i argued in http://lists.w3.org/Archives/Public/public-geolocation/2008Nov/0111.html and other e-mails that in fact exposing this api would make the privacy situation _worse_, so i think it isn't at all a given that geopriv would help here)
John: In the transaction you're not thinking about all the possible uses of your location - but if in your UA preferences you have it set up to send rules then you can have a higher degree of comfort.
Andrei: I think it's somehow misleading the user - the user would think they are in control, but in fact there is no guarantee that the end site would honor this.
John: if the user has said "i accept these rules and given my location to xyz.com" and I realize later that xyz.com didn't follow these rules then there will be criticism about that.
Andrei: There will be that anyway.
<matt> DKA: We're conflating three things: 1 are rules good? 2 should we convey rules in some standard way? 3 does it make sense to convey those every time?
<matt> DKA: some of the concern from the mobile side is adding bulk to the messages.
<matt> dougt: There is no protocol.
John: In the great majority of
cases it's a very small number of bits.
... I think there are some other contexts it could get used
in.
Doug: We're not going to design the protocol to send gelocation data to a remote service ...
Matt: That is out of scope of the current charter.
John: We're talking about - what is the fault legal regime. If I'm [pizza provider] and I'm consulting with my lawyers and I want to sell pizzas and I want to tell people where the closest pizza store is, and if I want to retransmit location but users always sent to not allow retransmit and therefore transaction fails, pizzas will not be sold, hence this changes corporate behavior.
Alissa: Company will make a broad statement to you publicly - it's different from users to say what their expectation is. When users say to them: "This what I want you to do" they may be able to deal with it...
Doug: We want users to be able to select web property based on the service, the way they treat you, and their privacy. We're not convinced that putting something in the DOM will yield any better privacy.
<Hixie> as i argued in http://lists.w3.org/Archives/Public/public-geolocation/2008Nov/0111.html and other e-mails, since users don't generally change their defaults, authors will just assume that the geopriv settings are defaults, and thus don't represent the user intent, and they will thus ignore it
<matt> scribe: Matt
lbolstad: It's not like LBS is
anything new, it's been around for years. Have you looked at
how existing services, about storing, exposing, etc...
... It's interesting too that people are more interested in
location information.
... most users never change their preferences.
jmorris: Most LBS stuff is
closely related to the telecom space.
... There are already some legal constraints.
... I can't tell you from knowledge what US companies are doing
with specificity.
[ thinks we could easly pull up some ToS for different operators and LBS apps etc ]
jmorris: Like Loopt, it has no
legal constraints to do it, but they're aggresively protective
of privacy. Lots of different techniques and options.
... I'm pretty familiar with what they do, but that's a
business decision that they made, not a legal constraint.
amachin: Are you using this privacy approach in other fields? e.g. health, banking, etc, in the IETF?
jmorris: Not within the IETF,
most of that work is below the app layer.
... The IETF uses GeoPriv in SIP for instant messaging and
vocie over IP.
... It's part of asking for someone's presence.
... e.g. a family finder using IETF protocols, there would be
geopriv.
rbarnes: The only thing I know of
off hand tht uses geopriv currently is SIP. All of those
policies use the same policy language.
... So the language there is being used, but not the concept of
sending it along.
andreip: Can you give some history to geopriv?
jmorris: The common way new WG's
get formed is to have folks get together, decide on a group,
have a BOF, etc, but in 1998/99/2000 IETF leadership had
proposals for conveying geolocation informatin that ignored
privacy, so the leadership mandated the effort.
... There are a number of other standards bodies around that
have held off on addressing location privacy to see how geopriv
pans out, such as 3gpp, etc.
<Hixie> i think addressing privacy is important
<Hixie> but i think geopriv is actively harming user privacy
jmorris: There's not a huge mass of deployment in the market, frankly if the w3c were to implement these ideas, that would be a tremendous step forward for location privacy.
<Hixie> and the model currently in geolocation (asking the user for permission on a site-by-site basis) is far better
jmorris: the IETF doesn't really do very much at the applications layer other than the real time SIP/IM stuff.
rbarnes: There are other standards organizatinos that are considering and fairly far along in taking up geopriv.
jmorris: Some background for the
civic discussion: geopriv is part of a larger puzzle about how
networks can tell devices where they are for 911
purposes.
... e.g. geopriv can work through a DHCP server, a big campus,
someone changes offices, and the person can plug in to the 'net
and the location gets propogated to 911 services, etc.
<rbarnes> (in particular, WiMAX and OMA/LOCSIP)
andreip: Is that deployed?
alecberntson: There are a fair number of corporations rolling this out.
jmorris: In the US in terms of
the various levels of obligation, a big corporation has
obligations that if someone places a call to 911 at this
building, the ambulance doesn't show up at the main
campus.
... So GeoPriv there is not so much about privacy, but about
civic locations.
andreip: is that the same in Europe?
Dirk: There is an obligation for the operator to send the 'best location'.
mlisner: The lat/lng without z is useless here for instance.
dougt: Can we bring it back to
GeoPriv in the DOM? I've got about 6 reasons for not adding the
attributes
... 1. UA users do not know what they should be setting in
general
... The user should be in charge in all cases.
... Multiple boolean operations are not going to go well.
... 2. The API is complex, especially with rulesets.
... 3. Websites currently can implement this now and allow the
use to remain in control
... 4. it's not clear that transmission with rule data will
work.
... If I transmit the rules with the data, there's no
pre-existing case that it does something special.
... 5. From the UA there's no way to enforce it.
... 6. We're setting users' expectations as to what the site
will do.
... We'll bring up a dialog saying "This site will not retain
this data after this date", but there'ss no way that that will
be useful.
... This does not preclude us from having this as an option
that we can expose.
... We could extend it in various ways, e.g. AP addresses,
etc.
... Provide a consistent, flexible API across
geolocatoin.
... I don't know how much we want to has on the same thing. I
feel like we're spinning.
andreip: Plus the Website doesn't know if the user has expressed an opinion or if it's a default.
jmorris: The defaults would be
privacy protective. If Websites cater to the defaults, then
they'd be catering to the most protective defaults.
... Most users may only go with those defaults... they sign up
for websites... most times though ... and most websites that
receive the information don't have a business need to keep it
longer than 24 hours.
andreip: So, the entire mechanism doesn't work, why bother allowing options?
jmorris: One could say we could
have the spec say you cannot retransmit or retain.
... Then we're building a situation where we know the spec
would be violated and not flexible.
... I suspect we want the spec to be usable by those that do
retain and retransmit.
<Hixie> what if a site's exclusive purpose is to retransmit the geo data (and it is quite clear about this)? what does it do if the user's privs say "don't retransmit"?
jmorris: The use cases assume store and retransmit.
<Hixie> the user isn't goign to go change their defaults just for that site
acooper2: Why do sites expose any privacy protection at all?
jmorris: Are cookies something that some users do use?
<rbarnes> [hixie: in that case, the site could either fail the transaction or choose to ignore prefs]
dougt: Cookies is one that
doesn't get changed.
... Most of the Web breaks if you disable cookies.
andreip: I've seen a lot of UI studies that the great majority of users you shouldn't expose a great amount of settings.
<Hixie> rbarnes, what if the user had in fact said to not retransmit on purpose? how would the site distinguish a bogus default from an explicit user intent?
jmorris: I think the stuff we put together wouldn't require many more options in a UI than what is there.
dougt: If you add one you increase the complexity by a large factor.
<Hixie> _any_ extra options is a problem, imho
andreip: If you lump all the options together too, you end up not having enforcability.
acooper2: Why have one, cookies,
and not the other?
... The downside of location is bigger than cookies.
<rbarnes> [hixie: "bogus default"? The defaults are privacy-preserving on purpose. The user can override if they want the service]
dougt: if you remove them now,
people are going to think Mozilla is screwing your
privacy.
... I wonder if netscape 2 had a disable dialog...
... I think it was added after the fact.
<Hixie> rbarnes, bogus from the point of view of the site (since by using the site, the user is likely saying they want the site to do what it does).
jmorris: I think location is more sensitive than most cookie information.
<Hixie> rbarnes, saying that the user can override if they want the service is unrealistic. users won't.
jmorris: Before we really started trying to restrict third party cookie... had we been building in more privacy defaults... cookies wouldn't have gotten as out of control as they did.
<Hixie> rbarnes, usability study after study has shown that.
jmorris: With location we're at the same point as if we were just designing cookies. Are we going to leave all privacy decisions in the hands of the site that sets it?
<rbarnes> [rbarnes: there are lots of counterexamples to that: pop-up blockers, firefox extensions, etc.]
dougt: Well, it's different in that a UA has control over what cookies are sent, etc.
<rbarnes> [hixie: there are lots of counterexamples to that: pop-up blockers, firefox extensions, etc.]
jmorris: I don't agree with all
of your points, but your 5th point about it not being
enforcable by the UA, I agree with.
... I disagree with the 4th point in that I think it is
clear.
dougt: What is that based on?
<Hixie> rbarnes, both of those actually back up my point. Most users don't have extensions, and pop-up blocker settings aren't changed by most users.
<rbarnes> [hixie: but when there's a site that wants to install an extension or put up a pop-up, i click the "allow" button and move on]
jmorris: It's based on how consumer protection is done in the States. I can find and point the group to enforcement actions where users had clear expectatisno, companies violated them, and then the FTC or some other legal process came in and swatted them down.
<rbarnes> [hixie: the rules are *not* static!]
jmorris: It's a question of faith whether it would do any good. I think most privacy advocacy groups would say the geopriv approach does good relatively to the take it or leave it approach.
<Hixie> rbarnes, you might, most users don't; they bitch about the browser being broken. that's why popup blockers go through so many hoops trying to work out which popups are likely ok and which are not
jmorris: A lot of my efforts have been trying to get the IETF over this enforcability issue.
dougt: Hixie has suggested that
adding this to the API will hurt privacy.
... People wlll look at the API, ruleset, and turned off to it
and taint privacy UI's in general.
Dirk: There is a concern in the
context of privacy. If we specify a number of values in there,
who are we to decide what values should be there?
... In Europe I think it would be hard to specify anything
other than retransmission not allowed and keeping it not
allowed.
... We may be giving developers optios that aren't legal.
jmorris: I think the geopriv
default is consistent with European law. I don't think we'd be
opening an invitation to violate law.
... What right does this body have to set any default? Well,
it's debated in lots of public policy circles as to who should
set these rules, but it's a reality that the technical
standards bodies are setting the rules and policies.
... Whether they know it or not.
... There is a question of the moral authority to set these. In
the absence of law, which we have in the US, then if the
standards body doesn't set it, then it's too late.. The law
cannot go and take back...
... e.g. third party cookies too a long time to unmake that
problem.
... There's no doubt this is a somewhat unusual thing to do. In
the grand scheme of things, the w3c is one of the few bodies
willing to stand up and say there are social minimums, social
norms that we should be validating.
... In this way I think w3c is the perfect body to say that the
social norm is that the user is empowered in this manner. It is
a difficult question.
mlinsner: let me give you an
example with respect to emergency services.
... Cell companies ignored being able to dial 911.
... User expectation was that it would work.
... The FCC came along and made rules that were technically
unable to happen.
... So, what we did in the VoiIP space was to get ahead of the
regulators.
... We're out trying to make sure we don't end up with
regulation that we can't deliver.
jmorris: It's led to a situatin where VoIP does better e911 than cellular.
mlinsner: We can't sit in this
room and dictate policy, but if we can do what matches end user
expectations, and maybe the notewell was the catch all...
... Sure, we can't programatically execute the rules of the
notewell, but at least it'd catch anything extraneous that we
forgot.
jmorris: I think the rules that
the geopriv policy has, covers the vast majority of
contexts.
... There really are two huge questoins raised by the geopriv
proposal: 1. do you send anything down with the location? 2.
should there be requirements on user agents on what options are
offered to users?
<Hixie> i entirely agree that we should handle the privacy aspects of this and make a good job of it
<Hixie> but geopriv, imho, in the context of this api, would damage privacy and hurt users on the long run
jmorris: My perception is that
the UAs are already going down that path... I don't think we're
talking about a 1 question UI to 50 questions. But 1 question
plus an option to set more rules...
... in which case if they don't add more rules the default
protects them.
<Hixie> a direct control solution, like what the iPhone does, is far better for the user
Dirk: On the EU side, the evolution of the regulations... if we don't end up with regulation, it'll be a voluntary code of conduct. Regulators are going to be too late to regulate location [ scribe failure ]
dougt: So, we ship world wide, the defaults we express e.g. the user doesn't specify... say the default was "Yes, retransmit allowed and never expired", if we set that and deployed everywhere?
Dirk: That software would not be compliant in Europe.
dougt: We'd have to ship different software per region?
jmorris: If we set things up with geopriv the UA would have to set the most restrictive default in absence of a clear user preference.
dougt: We would probably set the default, and if there is a region in the world that has a reduced time to live, would we be setting the wrong expectation to the developer?
jmorris: As a practical matter, a default less than 24h is not very realistic. There's no country in the world, I think it's safe to say, that is more privacy protective than Europe.
dougt: The expectation of keeping it 24hrs would be an overstatement if it's per session.
jmorris: My understanding is that
the European standard is that every server makes log entries
and may well store private information... and you may not keep
that more than a day.
... I can't speak to European law, but even if we have a
requirement that you can't keep it beyond the session, we have
to have a recognition that the data center will have logs, etc.
In the US we don't pay attention to that, but they do in
Europe.
dougt: So, I'm a Web developer, and I make an app and see 24hrs, but then I assume it'll be there 24hrs.
Dirk: What if in the US we had a new law that said after the session you have to dump the information?
jmorris: I think the reality is
that that kind of law is unrealistic.
... Logging events is often a requirement.
... Privacy rules in the States, even if they get really tight
will allow for low level of logging.
dougt: I'm not sure I buy that. You're arguing that geolocation is different and requires more protection. Why would I dump that to a log?
jmorris: I'm not saying you
should dump that to a log... the 24 hr period was hit upon in
the IETF as a way to balance protecting privacy and...
... You could transmit the geopriv object in a URL and it'd get
logged. I wouldn't advise it, but it's doable.
... I'd be thrilled to say it's always discarded instantly, but
that's not realistic.
rbarnes: There's also nothing saying they *have* to keep it for 24 hrs.
Dirk: In some cases the user doesn't have the choice to specify that it can stay longer: the law prevents that.
rbarnes: So if you have a Website that wants to store it and puts up a UI, etc, what then?
<Hixie> if the law already protects the user, why do we need this API again?
Dirk: I'll look at the
laws.
... It may be hard to get the two, Europe law and US law might
not fit in the same spec.
<rbarnes> hixie: e.g. to help keep the user from knowing the laws that govern every website on the Internet?
<mlinsner> to Hixie: give the user control such they can express more restrictive than the law allows...
Dirk: In Germany there's draft
law that says every 10 times your location is queried it must
prompt.
... We have to be careful that the standards not take away the
developers need to know the laws.
<Hixie> mlinsner, we've already pointed out that it doesn't give the user any control, as users are not going to understand or care about a preference panel for this
<rbarnes> matt: what do you mean, "what then?" in technical terms, once the user approves, the UA can send rules that allow long expiry
<Hixie> rbarnes, how does it help that?
<Hixie> rbarnes, surely it doesn't do anything at all to affect whether the user needs to know the laws or not?
jmorris: Some national laws may
be stricter than what this spec is suggesting. That's not a
reason not to do it. I think for one, it won't get stricter, I
imagine the industry in Germany for instance would object to
that. CDT is pretty moderate for instance.
... I think the German law would be a harm to innovation.
amachin: Let's take the seven points and go one by one.
dougt: 8 points: the default settnig that UAs may ship with might be in conflict with the minimum requirements of the region it ships in.
jmorris: Highly unlikely.
rbarnes: And irrelevant, the law
is binding the service provider.
... the developer knows where they're developing and they'll do
it based on their laws.
alecberntson: How do you even know what law the developer is bound to?
<mlinsner> Hixie, we admit there is no programmatically way to enforce the rules....the proposal simply allows the user to express their expectation....the after the fact follow-up will determine the end result
jmorris: My answer would be to have the default be the highest level of protection.
<Hixie> mlinsner, well then your assertion (that it gives users control) is false; so again i ask, if the law already protects the user, why do we need this API?
jmorris: If the user doesn't do anything they're protected. If they are signing up for a site that does [geo stuff] then they may have a higher level of understanding.
<Hixie> the highest level of protection is "don't send any data", so if we set the setting to that, sites will definitely just ignore it, again making this pointless
acooper2: I would say that not everyone using a control is not a reason to not have it exist.
andreip: Do you have no prompt?
<DKA> +1 to Hixie's last point.
jmorris: If I were designing a browser, I would, the first time, either in an initial program setup or more likelyl in the first time location was used, I'd have a big dialog saying: here's the defaults, do you want to change those defaults. But if you don't do that, then no privacy is harmed.
<mlinsner> Hixie, when the user desires more restriction than the law allows, we offer a mechanism for the user to express such
Steve: So if I'm writing a geo-enabled photo site, then the user is still confronted with a decision they don't understand.
rbarnes: But if the default is restrictiive, if they hit OK everywhere, then the worse case is that the user ends up where we are today.
<mlinsner> Hixie, without such a mechanism, how can the user expectation be known?
acooper2: Theres an opportunity to be better.
dougt: But we don't know it'll work.
<Hixie> mlinsner, but how is the site to know if the user is setting an actual pref or if the browser is just sending the defaults (which, as noted earlier, likely will be ignored, since they would often be incompatible with the whole point of the site)?
jmorris: Websites right now already know how to tell you things like "Oh you have cookies disabled"
<Hixie> mlinsner, the site can explicitly ask the user for their preference
jmorris: The iimplementations so
far already have a consent screen there.
... It wouldn't be hard to make that consent screen say: Your
default rules will not let this site keep the information.
dougt: But we also have to tell the user that they might be acquiring their location from a third party...
<Hixie> rbarnes, if the user clicks through the mechanism everywhere, we are in a far worse position than today
dougt: So the dialog that we're going to show we need to let the user know that not only are we going to share your location with facebook, but we're also going to send your location to say, Google Gears. And we haven't even touched on that part of the privacy.
<Hixie> rbarnes, today, at least the user has the ability to decide on a site-by-site basis whether they expect the site to know their location
dougt: So that consent dialog that we're going to bring up is going to be even more complex.
<Hixie> (today = with the iphone model)
jmorris: My suspicion is that a user agent will ask if the user wants the UA to remember the setting.
<rbarnes> hixie, presumably that user is clicking through privacy agreements as well
<mlinsner> Hixie, I would expect a site to adhere (hopefully) to the rules they received regardless if such rules are the default from the ua setup, or explicitly set by the user
jmorris: So in the store finder example there may b e two permissions needed. Can we have your locatoin and can say, this map app have your locatoin.
<rbarnes> hixie, remember that the rule you send are not global, they're per-transmission, which gives very fine granularity
jmorris: My assumption is that the user may say to remember that setting.
<Hixie> rbarnes, users would understand a button "Send my position to maps.google.com", they wouldn't understand "do you think your geopriv preferences are set right"
jmorris: When I go to the pizza site, I set save this setting and save it for the map provider... but when I go to pizza site 2 I only have to give permission once.
<Hixie> mlinsner, if the defaults are the strictest we can set them by default, then sites will ignore them, since such defaults are at odds with the sites providing their basic functions
dougt: Can we put text in the specify that the Website should or must present UI?
alecberntson: You mean UI's?
dougt: No, Websites.
<Hixie> rbarnes, the users aren't going to be changing their preferences on a per-site basis. anything we set here will be a global setting for all sites for almost all users.
Dirk: I can imagine there are
cases where the user would not be allowed to switch off their
location....
... Probably out of scope.
DKA: The w3c spec can't tell Websites what to show.
<rbarnes> hixie, again, there's plenty of examples where settings are per-site right now
<rbarnes> hixie, cookies, pop-ups, extensions....
dougt: We would hope that
Websites would never retransmit and not store.
... I think we need to make a call here.
<Hixie> rbarnes, and data shows that users almost uniformly ignore all those settings and leave them all at their defaults
dougt: Specifically talking about
the four attributes.
... Not reverse geolocation.
DKA: Do you mean part of the position object or part of the guidelines?
<rbarnes> hixie, but UAs continue to provide them, so they at least perceive some value?
DKA: ... by the UA that is.
dougt: The question we need answered: do we want any privacy object as part of our specification?
jmorris: That is the most core question. One might say yes to that question and no to the question of what the UA does with the user.
<Hixie> rbarnes, the value is only for the most experienced of users.
<Hixie> rbarnes, if we care about the majority of users, then these features are for all intents and purposes pointless
dougt: There are API changes, but what was the other part?
<rbarnes> hixie, so we should remove the cookie controls, extension controls, etc?
jmorris: The CDT thing has bits
about speaking to the UA authors. It's under Privacy
Considerations for UAs.
... All I'm saying is that one could think about those
decisions separately. One could vote yes on first question and
still reject that second piece.
<Hixie> rbarnes, yes, i have been recommending that for some time. but even if we don't remove them, that's academic -- the argument here is that geopriv would help user privacy, whereas it would in fact hurt it
alecberntson: It seems like we're in agreement on the UA side that we are implicitly saying we should have opt-in... that the user should make a decision.
<Hixie> rbarnes, (just as, e.g., the IE security settings have actually hurt security for IE users)
<Hixie> rbarnes, (due to their complexity)
<DKA> PROPOSED RESOLUTION: The user should be prompted when location information is going to be used...
alecberntson: Let's focus on what we agree on.
rbarnes: In my mind clicking: "Allow" is setting a rule.
<DKA> PROPOSED RESOLUTION: The user should be able to set preferences within the UA as to which sites get to use location.
Dirk: In an 'active' thing we don't require it, it's implicit.
acooper2: But you're just going to a URL, how do you know?
jmorris: Does just going to a Webbsite give implicit permission?
dougt: UAs are becoming the
brokers for devices that are attached to them.
... Websites cannot arbitrarily get access without
permission..
Dirk: at the top level of the browser there is a yes or no...
<Hixie> you don't have to grant permission when you go to the url, you have to grant permission when the api is accessed
<DKA> PROPOSED RESOLUTION: The user should be able to set a preference within the user agent to disable all location-API lookups.
mlinsner: That's not going to stop say, google from giving me google.co.uk to.
alecberntson: I agree to that proposal, but I might argue it should be the default.
dougt: All sites should prompt on
first use of geolocation.
... We could have an out for signed apps or something.
<DKA> PROPOSED RESOLUTION: All sites should prompt on first use of geolocation.
andreip: There's no UI to this resolution.
jmorris: No, but it might be in the compliance section.
dougt: for web browsers, I think it makes sense to be able to turn it off in a UI, but for UAs in general, I don't know.
<DKA> [Hixie: we are in brainstorm mode, trying to find areas where consensus exists...]
dougt: We talked a whole bunch about privacy consideratinos for location recipents...
dougt: We don't have rulesets, etc, where you go fetch XML, try to parse it, etc.
jmorris: The first two rules,
retransmission and retention are in many cases going to be set
to the default of no.
... If you have this external ruleset it could or can add
additional informatino.
... Websites that have developed their own robust things, they
could implement those rules Provide the ruleset, etc.
... But if they don't understand the ruleset, then the two core
rules govern.
... Which for most recipients, they can completely ignore
that.
<Hixie> both retransmission and retention are things that sites will want to offer to users ("share my location with my friends", "save my location history"), and if the user asks the site to do it, the site is going to ignore the preference in the api
andreip: Your spec says that the ruleset may over-ride the other ones.
dougt: My response is bafflement. Do I download the URL and parse it? With what parser? It's complex.
rbarnes: It's written so that a UA or a script never has to download the ruleset.
<Hixie> (and there's just no way any site is going to actually implement the ruleset stuff, that's insanely complex -- i've yet to see even sample code to do this, despite asking in e-mail)
rbarnes: Because it's additional permission, and you follow the rest of the stuff, you don't have to go get it.
<Hixie> (let alone the question of where and how the UA is supposed to publish the user's preferences)
andreip: So if you're google or something you might have to go fetch it.
acooper2: The other two rules are always more restrictive. It always...
andreip: I don't think that's what it says.
jmorris: That's a lack of clarity
in the text then.
... The geopriv text, the specific robust rules in the ruleset
are *always* permissions.
alecberntson: So you can say 'no retransmission, except for these sites'.
andreip: Where is that coming from?
alecberntson: The UA.
mlinsner: Or your provider.
andreip: A UA can receive privacy rules from users or from location providers.
rbarnes: The UA can decide to pass rules from the provider along.
jmorris: Say you have retrans no
and store no, and a ruleset. If you don't retrieve the ruleset
you are protected
... Now you might fetch the ruleset and get permissino.
... But if you set retrans to yes and store to no, then the
ruleset doesn't need to be fetched.
<Hixie> can someone show me some sample code to process this ruleset?
<Hixie> i tried asking in e-mail but there was no response
dougt: I don't think this is
going to be adopted by Web developers.
... If I see a site and it says "Send my location to all my
friends" I'm going to do it.
jmorris: The reality is the user
agent is assumed to be a trusted entity.
... It may welll pass on location to another trusted entity.
The second trusted entity may have a more robust set of rules
either developed internally or by the user... and those rules
[scribe lost]
... But in those scenarios the user can say I trust this other
entity to do the right thing.
... I would like flickr to be able to geotag my photos but only
allow my family to see my precise location while others see
just the country.
<Hixie> why would you ever give your location at all to a site you didn't trust?
<rbarnes> hixie, there are degrees of trust
<Hixie> and if you didn't trust the site, why would you trust it to follow the geopriv settings?
jmorris: There's two ways this could happen. 1. a common place where my privacy rules are set, I tell the UA that my rules are at this URI or 2. I just authorize the UA to have the location.
<Hixie> rbarnes, there's no way the majority of users are going to have any concept of "degrees of trust"
jmorris: The URI capability is
building a potential that doesn't really exist today for there
to be third party privacy services.
... Where I can say "I don't trust any of you, but I trust this
entity"
... I'll tell that entity who can have my location.
... Maybe make it my sole location server.
... Today there is not an external URI service provider out
there that I'm aware of.
<Hixie> we definitely shouldn't be adding features for use cases that don't concretely exist yet
jmorris: So we are encouraging you to build a hook into the spec that won't be used for the next six months.
<Hixie> there's no way to design a feature well if we don't know exactly how it is to be used
<Hixie> no way to evaluate solutions
jmorris: That structure doesn't exist. Location servers that know my intricate set of rules that...
alecberntson: I understand the benefits, but the website should manage it.
dougt: The web is decentralized... I haven't seen a spec where there's a URI in these things.
andreip: He's saying Voda will manage this for you...
alecberntson: It seems to me like we don't disagree that there are some of geopriv would be useful, but tihs part is almost a non-starter.
jmorris: But if you left it in there you don't have any more bits on the wire to not support it.
dougt: But it's brainspace.
jmorris: But it increases the potential for privacy services.
dougt: Anyone whose going to get into this privacy services space for a browser...
jmorris: for anything, not just
browser. there are services that protect your privacy out there
now.
... The browser is going to do part of it anyway...
dougt: If you did build a business around this you could easily write code for clients.
jmorris: I want to be able to turn on my phone and say in my PHONE settings not my browser, that my privacy is at this URI.
<Hixie> the ruleset url alone would do more damage to privacy on the web than any other standard so far, i think. authors would run away screaming when they looked at the spec.
<Hixie> even if they don't have to use it.
jmorris: Then the phone tells the UA that this is the ruleset...
dougt: I'd like the same thing for offline storage.
<Hixie> (this working group should not be in the business of creating niche markets, imho)
<Hixie> er
andreip: I think this will not
work. 1. No one will bother fetching this thing.
... 2. Even if they did try, the ideais complex and how it
interacts with the rest of the rules. 3. I don't see how the
model will fly.
alecberntson: We agreed that even
just the retention and retransmission rules were maybe not
going to be interpretted, so the idea of complex XML being
enforced...
... If this is optional, no one is going to hit this...
dougt: My assertion was that it's complex. I think we should move on to number 3.
<andreip> What I mean is that I don't see any precedent with third party entities are getting paid to make informed decisions about user's privacy needs
dougt: I'm a privacy advocate, so
I'm going to use the site that best meets my needs.
... Just like in any other web type of form, there's going to
be checkboxes.
... Everything that's proposed in the CDT proposal is doable in
Web APIs.
<andreip> I don't see how a model for such entities that manage privacy on behalf of users can fly
jmorris: That's the Web model
right now.
... And some people have said that it's successful.
dougt: I don't think anyone has said that.
<andreip> I am not paying anyone to make decisions on my behalf
jmorris: You're right, number 3 is true, sites can do this, but don't/won't do this. We're advocating trying to change the model and further empower the user to convey some rules
mlinsner: This also matches up with other interfaces in my phone, e.g. my SIP based phone has the same options.
DKA: Is there a middle ground? I think we're looking at a false dichotomy.
<Hixie> the proposal here doesn't change anything except where the UI is exposed
dougt: I've proposed this as an option. e.g. when you start your request you include that you want the privacy options.
<Hixie> the site still has to actually do all the privacy safeguarding
<Hixie> so if the current model hasn't worked, i see no reason to believe this model would
rbarnes: It's my understanding
from the legal guys that it's a critical feature that the
privacy preference be unilaterally made available so that the
site doesn't have to ask.
... So, if I provide information they can either chose to
observe it or chose to ignore it.
... Providing a distiniction is essentially the current model.
What jmorris is proposing that this means they'll always have
access to it.
andreip: This is basically a way for them to say legally speaking that they didn't not know about it.
jmorris: Yes.
andreip: And this will stand?
acooper2: They will argue it.
dougt: It's very weird to build APIs with lawsuits in mind.
jmorris: There are some social issues that can only be addressed through law. Do makers of technology to make it easy to enforce the social goal? Or make it agnostic? Or harmful?
<Hixie> i would be trivial to show that almost nobody sets the preferences, thus making the api not at all representative of the user's wishes
<Hixie> so i highly doubt this would stand up in a court of law
jmorris: I think you're designing
it to be agnostic. We're advocating for you to devevlop the
technology to make it enforcable through law.
... No doubt this is odd.
... This is to help legal rights, not help technical
aspects...
andreip: But if someone has a lawsuit then someone did something wrong.
mlinsner: The law may say transmit at will, but I may say no, you can't.
jmorris: The law today says that
companies can't trample their customers expectations.
... If there is something they can do to not trample then they
should do it.
... If the technology is silent, then it is up to the company,
the end website to say "Do you want location protected or not?"
and we know that they won't ask that.
andreip: Isn't this the same with credit cards?
<Hixie> why won't they ask? they _do_ ask!
<Hixie> (or assume it should be protected)
jmorris: There are civil
liabilities with credit cards, etc. You see most entities using
encryption for credit cards.
... There's already a clear expectation that credit cards will
be protected.
rbarnes: And that all CC information is protected the same way.
andreip: Then why don't forms have this in the standard that CC information cannot be stored?
acooper2: Because there is law for this.
mlinsner: I'm more worried about my locatoin than CC..
lbolstad: I think we've jumped to point 8.
mlinsner: If I give my location to google the law may say Google can give it to starbucks, but that might not be what I want
jmorris: The law right now says
they can do that.
... If I told Google to NOT give my location to Starbucks, then
that gives legal standing.
lbolstad: Then don't give your
location to Google.
... If enough users stop using Google, then they'll have to
change it.
<Hixie> i assure you that the geopriv api wouldn't make the slightest difference to what we do with location data (whereas user preferences, as expressed directly to us, would, as it already does e.g. with cookies and web history and so on)
acooper2: But which search engine ISN'T going to retain my information? If we open it up, what happens when we don't have a choice.
<Hixie> acooper2: so don't send your location information to search engines
<Hixie> acooper2: you don't HAVE to send location information to sites you don't trust
<Hixie> acooper2: you get the choice each time
jmorris: If we're going to have location services on the Web then we're going to have to do whatever the service provider wants. What we're saying is that if we allow the user to express their preference...
dougt: But it's scoped at the
wrong level then. Many things we share on the net should be
protected...
... A form post for instance might want a privacy statement
attached. HTML5 might be the right place for this.
<Hixie> jmorris, allowing the user to express his preference does nothing for most users who will not touch (or understand) the preferences
jmorris: My answer to that is that if we could put this WG on hold and not do anything for a while and solve privacy on a larger scale, but I'm confident we're not going to do that...
<acooper2> hixie: it is incredibly disempowering to suggest that people stop using search today, and it is shortsighted to believe that geolocation on the web will not be just as pervasive in the near future
jmorris: but I think what you're suggesting, that we should do this in a large scale, then there will be 2-3 years worth of services that will havebuilt up without this privacy model, and then we'll have an even harder time.
<Hixie> acooper2, i didn't say stop using search, i said don't tell sites you don't trust where you are.
jmorris: I think location could pave the way for the larger setup...
<rbarnes> hixie, that's the point -- people are going to want location-based services, but without agreeing to blanket privacy policies the way they have to now
jmorris: Rather than do nothing now and wait.
<acooper2> hixie: I was making an analogy to the search market: it may be competitive, but your privacy choices are few with regard to log retention
<Hixie> rbarnes, who are these people? almost everyone i know is quite happy with the blanket privacy policies.
andreip: Say Facebook decides to use geolocation, and the browser implements geopriv, but FB has a setting of it's own... the user says in the Website to do that,t hen which sets of rules apply?
rbarnes: jmorris talked about multiple privacy preference settings... they could have other information beyond what's in geopriv, and they could use it....
alecberntson: but that undermines the legal enforceability in this...
<Hixie> acooper2, if you don't trust a site, then geopriv isn't going to help you at all, since if you don't trust a site to follow your preferences without geopriv, you can't trust them to do anything _with_ geopriv
jmorris: In terms of enfocability, if the user has expressed a clear set of rules in two places then if the users preferences are carried out then no one is likely to be sued, but most of this is going to be services to unknown entities.
<rbarnes> hixie, e.g., <http://yro.slashdot.org/article.pl?sid=08/07/05/2138229>
jmorris: My relationship with Facebook can be easily dealt with here, but most of the time I won't have a pre-eisting relatioship.
Steve: Don't you think this opens it up to the Website to not look at geopriv rules because they've setup a separate agreement?
jmorris: If a site sets up a privacy policy that says they can do what they want with it and they receive a geopriv blob then I think they'd still have a problem.
<acooper2> hixie: the rules allow users to express their preferences to the recipient, and that's all they do.
jmorris: [scribe failure]
Steve: I think the area of conflict is quite large. Clicking on a button is implicit consent for instance, or going to a mapping Website.
<Hixie> rbarnes, the problem there wasn't the lack of fine-grained privacy, it was the text of the blanket policy itself
<Hixie> rbarnes, most authors aren't going to change the defaults, so geopriv is actually exactly equivalent to a blanket policy anyway
<Hixie> acooper2, you can already express your preference to the recipient, on the site's preferences page
jmorris: That isn't a big gray area, but it doesn't fundamentally change the problem. If they're meeting the user expectation the Website will be fine. But if it's a facade then that's not going to override the user controlled expectation. I'd suggest that this gray area shouldn't preclude us from dealing with this...
amachin: Lunch.
<Hixie> acooper2, if the site ignores your preferences (e.g. doesn't offer preferences), then why would we imagine that they would follow geopriv's?
<acooper2> hixie: can you give examples of sites that support geopriv rules in their preferences pages?
<Hixie> acooper2, i'm not aware of any sites that do anything with geo data that is privacy-sensitive
<Hixie> acooper2, (though the lack of anyone doing anything with geopriv is hardly an argument in favour of geopriv, btw)
<acooper2> hixie: lunch time, talk to you later
<Hixie> later
<MikeSmith> hmm
<MikeSmith> matt, oK
<scribe> Scribe: mlinsner
thanks!
everyone is sitting down.....should be going in a few minutes
lars: one proposal is to continue discussion on privacy for 1 more hour knowing that we won't reach consensus
jmorris: the most critical
question is to include the retrans and retention rules be
transmitted
... if we can't agree to these 2 points, we should not discuss
privacy anymore right now
... if we agree on transmitting these 2 (retrans/retention)
then we can discuss further privacy features
rbarnes: we should discuss the more abstraction of what is sent with location information
<rbarnes> (is it worthwhile to communicate privacy preferences through the API, regardless of the specific rules or how they're delivered)
lars: context will vary as to what would be required to be sent
andreip: I feel we haven't explored the solution Doug proposed....the extension where interested parties would ask for the appropriate privacy rules
jmorris: If this is only presented as optional, would this not be more work for the developer to make the decision whether to ask for privacy rules
dougt: are you wanting the privacy rules to be required?
jmorris: yes, but I'm just exploring the option of 'optional'
dougt: explaining what the
optional choice would look like...
... if optional doesn't meet geopriv...then we shouldn't do
optional
rbarnes: we need to distinguish between 2 types of options: - 1) give me your rules about retransmission - 2) there is a specific semantic
dougt: website asks for retransmission value.....post the location data lacking privacy rules...what does that mean in geopriv?
rbarnes: there would be default value
dougt: would the default be fine?
acooper2: no, that is what we have today
lars: can we discuss adding the retrans and retention to the api?
andreip: I'm not sure Google would be in a position to implement these
dougt: mozilla either
<andreip> To implement a UI that exposes these in a meaninful way to the users
<lbolstad> I'm not sure Opera would either
dougt: we have fundamental differences in how to implement this
jmorris: I think the information offer in the geopriv policy is well thought out and captures the right information
acooper2: it would be helpful if it's accepted to support the 2 data points.....
jmorris: it would be valuable to accept the previous resolution, but we may not go away quietly if we don't believe privacy is supported...
chairs: do we have a feeling whether should add these 2 to the specs?
andreip: I don't think we should add them
dougt: I agree (not to add them)
alecberntson: I see value in supporting these, but I'm struggling with how to implement
rbarnes: there is agreement to encourage web site developers to support privacy
andreip: the api is wrong place to support this privacy
jmorris: if w3c requires these rules and implementors ignore them, in time, legal action would rectify the situation.
dougt: the chairs need to decide, if there is an appeal, it will happen
rbarnes: we agree that web developers providing privacy is good, should there be any level of users involvement?
<rbarnes> (rbarnes: is providing privacy preferences a worthwhile way to encourage developers to consider privacy?)
andreip: the current draft says that location information will not be shared without the users consent
acooper2: the draft state 'should'
dougt: the language can be changed
<dougt> but we might not want to -- enterprise application, self signed scripts with special permissions, etc.
alecberntson: the website implementors are the liable party
acooper2: is there any middle ground on designing ui?
jmorris: it is within the rights of w3c to provide the level of compliance to their standards
acooper2: is there any way to move to more than 'made available'....ie site by site privacy rules
dougt: fuzzing.....we will probable retract that
rbarnes: back to the feature of what gets transmitted......by transmiting the 2 values it encourages sites to pay attention to privacy
matt: can we flip that around
alecbertson: I see some value as it does allow the user expression of the rules
acooper2: I don't believe it's substitute for user provided rules
matt, dougt: discussion of how would the scripts work
jmorris: 75% of location requests are going to be emphemeral things, so supporting the geopriv mechanism would be easier on developers than querying each and every time......the geopriv rules will be pushed vs. asked for...
chairs: do we have a proposal?
rbarnes: would anyone agree to a
privacy rules structure in this version of the api?
... 'this is where you put privacy rules'
... for future us
andreip: we can simply add it later...no need for a placeholder
dougt: I'm worried about adding any privacy rules
rbarnes: OK, that was a bad idea
matt: where are we with the proposed options?
dougt: jmorris killed it....it's all or nothing
lars: even though we can't agree today, doesn't mean it will never happen
jmorris: the leaders within this effort aren't interested....hence there will never be interest
lars: we are under a time constraint
dougt: what is the w3c process around this?
jmorris: I think we have an impasse.....further discussion in this venue is probably wasting time....I do value and appreciate that we held the decision until now
chairs: we can provide a placeholder for future work
dougt: we have a lot of apis touching sensitive information.....this needs to be addressed at a higher layer
andreip: if there was a w3c effort on privacy, would you (jmorris) be interested in participating
jmorris: yes....but it will be too late for geolocation
rbarnes: can we list discussion on what the ua is doing wrt to privacy
dougt: can someone look at the
spec?
... what ui developer isn't going to create a ui around
privacy
rbarnes: it needs to be standardized
dougt: no it doesn't
lars: we are not excluding further privacy features in future version of this spec
<matt> ACTION: andreip to look at other specs to see how far they go in dictating UI for UAs, e.g. DOM offline storage, etc [recorded in http://www.w3.org/2008/12/08-geolocation-minutes.html#action01]
<trackbot> Sorry, couldn't find user - andreip
lars: to stick to the agenda, we
need to move on....
... we recognize we have not reached consensus to accept the
cdt proposal and we'll move forward on publishing the spec
matt: the cdt proposal included the reverse geocoding also...
acooper2: this decision only covers the privacy section
<matt> scribe: acooper2
dougt: we're looking at civic address section of geopriv proposal
marc: civic is necessary because
humans understand civic
... need to support existing civic infrastructure
... problem is that even though machine-to-machine should be
lat/long, emergency services people still demand civic
... emergency services require data in its original format,
which means locations input as civic must be delivered as
civic
jmorris: some UAs will have civic
info, and the API will be used more broadly
... there will be devices that have civic and don't know their
geo
marc: at my house, if you reverse geocode, you end up down at the other end of the street
andreip: for that use case, lat/long is not useful, but for many others, it's perfectly fine
marc: do you ever expect this API to be used for emergency services?
alecberntson: there should be
civic support, windows API will have a UI where user can input
its civic information
... you can provide civic automatically through look-up,
reverse geocoding, other ways
marc: IETF has created protocol to pass to host through DHCP
lbolstad: how do we provide a civic address on a mobile phone?
rbarnes: if mobile provider is going to provide based on cell towers, can provide civic
dougt: implementatin costs of doing civic addresses/reverse geo for UAs
alec: two data sources shouldn't be intertwined, should be parallel
jmorris: both sources should be optional
dougt: lat/long must be required bc you will fragment web developers otherwise
rbarnes: but if you don't support civic then you lose civic-only developers
dougt: lat/long is canonical, everyone can provide it -- but maybe not?
alec: windows is supporting
both
... if you reverse geocode people on proxies, they all look
like they're entirely elsewhere
jmorris: VoIP calls that come from Paris but go through California phone system will have California IP addresses, so reverse geo doesn't always work
andreip: there are cases where
reverse geo doesn't work
... but the scope of this API was lat/long only
marc: pizza hut won't be able to find your floor
dougt: the pizza hut use case was
to find a store, not a person
... two new use cases: emergency services and pizza
delivery
alec: auto-form filling is already in the spec
andreip: we had reverse geo in
the first version of the spec, but forgot to take out the use
case
... we took it out due to pushback from skyhook
richard: perhaps it was removed because of the process for acquiring it, not the format
alec: in windows at the very beginning you ask for which format you want, and then you provide whichever
jmorris: it doesn't work on desktops
lars: desktops can reverse lat/long based on IP address
jmorris: taxis that do that for my house end up half a mile away
dougt: you could build an app that allows the user to adjust inaccuracies in the produced civic address
marc: mapping will produce errors
a big percentage of the time
... it's not good enough for pizza driver or emergency services
to find your house
jmorris: what's the down side of allowing fully optional formats?
dougt: schools are setting up
geolocation for telling you what room and floor you are
in/on
... web sites might only implement a certain feature if you
have zip code
... UA that doesn't provide lat/long will not be able to
participate
lars: but it requires reverse geocoding on the device?
andreip: typing your own address is out of scope
alec: desktops represent half of all computers in use
andreip: doubt that half of all interne tusers will type in their addresses
richard: support for civic has benefit of shifting geocoding burden to the service provider
john: why should small device have to make the call to convert to civic?
doug: I don't want the device to have to do geocoding
marc: when you walk onto cisco campus, you get civic. when you walk out on the street, you get lat/long.
doug: I'm on the fence. need to clean up the API. some spec needs to support civic.
john: civic stuff is getting significant deployment from other entities
doug: what is back story on gears address structure?
andrei: geocoding makes sense, so we looked at structures at use inside google and picked one
alec: we went through all
geopolitical jurisdictions and picked
... 5 field: zip, city, state, address 2, address 1
richard: proposal was for most possible expressiveness
john: geopriv started with something pretty simple, but recognized that this is the global internet and addresses in hong kong don't work into the five fields
andrei: we understand that, this
is a web API designed to address needs of javascript
developers
... one of the goals is simplicity
... none of them will like the structure with 30 fields
marc: what you're saying is that corporate enterprises will not participate
doug: we have to figure out
minimal set for the web
... seat and room are intriguing
... maybe there's a way to structure this to make it easier to
comprehend
... maybe we could use mailing address
marc: we went through this with
our developers, and can't guarantee that computer will be able
to parse that out
... A1 through A6 are allowed to be designated by
jurisdiction
... Japan will decide its own hierarchy (has already published
its own spec)
... rest of fields are common throughout
stephen: use cases where the first line actually needs to be parsed out?
marc: decide whether to support civic before tearing it apart
doug: skyhook and myself wanted this dropped because it required reverse geocoding
andrei: position object had extra address attribute
doug: happy to adopt option that
says, "give me reverse geolocation if available"
... no guarantee that it will be available
richard: didn't have an option to say which one you want
marc: if pizza hut wants civic and I only have geo, that's pizza hut's problem
doug: I decide which is cheaper for me is constrained
andrei: value in everything being guaranteed to have lat/long
john: what about devices that don't have lat/long?
alec: UAs have plug-ins already
<matt> last version with civic addresses
stephen: one reason to provide civic directly is to have a simple API that just works
marc: emergency services will want to know if you geocoded
alec: no one will ever use web API for emergency services
john: advocates pushing to have
emergency services accept calls in whatever format
... because of emergency constraints, a lot of devices will
know their civic
... question is whether you want to be able to do anything to
help those people
andrei: majority of devices will know their geo
marc: enterprise networks
doug: not as concerned about enterprise networks
andrei: civic comes from DHCP, why can't you just fuzz?
<matt> [ use cases, use cases, use cases!! ]
doug: haven't solved e911 or pizza delivery
marc: and if you want this API to be used by enterprise campuses, you need to support
john: someone else is going to have to come along and do a civic API
andrei: we're not saying no to civic, we're just saying geo should be mandatory and civic would be optional
alec: we don't want geo to be
mandatory
... if you only work with lat/long then that's all you'll test
for
andrei: onus is on UA to translate to civic if necessary
doug: if web app can't take geo but do take civic...
alec: huge number of web sites already use that model
andrei: huge number of devices that cannot provide civic
john: requires small device to do reverse geocoding
andrei: address info should be optional, but I don't see that many use cases or devices that only require civic
alec: desktops are a huge set of machines that will have civic and not lat/long
john: none of my computers know anything about their location
doug: if you download
firefox/opera on your dekstop, first time you run and we pop up
a UI with an address to fill out and ask you where you are so
you can move pointer
... right there we have your lat/long and your civic
alec: necessitating that UI build service with a map control
john: if you enable both, could create a world where my modem uses DHCP to tell UA where you are without all that UI
marc: won't be a broadband service provider that will provide a lat/long, only will provide civic
john: companies have legal liability if they get the civic address wrong when it's sent to emergency services
alec: nothing is worse with both
being optional
... expanding who can use the API, not constrianing it
john: could have requests default to geo
richard: default is whatever you have
john: not sure if you always send both if you have both
andrei: so we agree on geo being default and send civic if you have it?
alec: geo is preferred, but not mandatory
richard: geo, civic, or geo + civic
alec: don't see why geo is mandatory
doug: pass a flag in option to say what you want, and you get either back, request fails
andrei: one option should be "give me whatever you have"
john: could just fail if app wants civic and UA doesn't have civic
doug: current proposal: add a
flag to options that allows developer to decide whether they
want geo or civic
... options are: 1 geo, 2 civic, 3 geo + civic
stephen: might need require and desire flags
john: send me anything, or send me anything but prefer X, can only deal with X
richard: in geopriv we have tags for which one you want
andrei: extension to PositionOptions
alec: like required and
desired
... civic, lat/long, don't care
<rbarnes> here's the ref for how we've done the type preferences: <http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery-10#section-6.2>
<rbarnes> type=any/geodetic/civic/locationURI, exact=true/false
<rbarnes> (if people are interested in giving out location in URI form, we could discuss that too...)
doug: let's talk about scope.
pretty confident that we could modify v1 to have it easily
added on to v2.
... could look at adding this for v2
marc: if geo object and civic object are separate, what does it matter?
andrei: we need the mailing list discussion because they were against this
doug: pretty confident that we
will have civic addressing in specification at some point
... we can look at API as it is now and think about what will
and will not work
... should talk about what Position object looks like if we add
civic addressing
richard: risk is if we make geodetic positon optional
doug: in gears address is separate from position object, in proposal they're sub-attributes
andrei: not sure if we can justify adding sub-elements to position because it requires typing "geo.X"
richard: makes for a longer if statement the other wa
alec: it's weird to dangle it off
the geodetic position
... civic should be a first class citizen
doug: we don't have a position object anymore, we can push timestamp down
richard: could solve this with inheritance
stephen: value in having a common
timestamp
... to know that they're related to each other
doug: is "geodetic" a word?
richard: yes
alec: we called it "lat/long"
doug: it's now extensible
lars: how does civic relate to
accuracy?
... drop A1-A6?
richard: IETF doc addresses fuzzing civic with a bins approach: just drop fields
stephen: should civic have accuracy field or is it implied?
alec: it's just implied
marc: how do you fuzz geo?
alec: it's complicated, you can only do k-anonymity
doug: not using significant
digits because of boundary conditions
... can use it for a single shot
... but not when I have a relationship with you
john: in IETF they do a definition of the circle with language that limits the number of requests
doug: we dropped it from our implementation
richard: we just went through this in IETF about reducing the number of sig digits for fuzzing
<rbarnes> IETF initially suggested truncation for fuzzing <http://tools.ietf.org/html/rfc3825#section-2>
marc: if you're lacking sig digits in lat/lon, what does that mean?
<matt> k-anonyimity paper
doug: you assume you're in that region
marc: that's not fuzziness?
doug: chopping digits doesn't
provide good enough fuzzing for anyone who moves
... even if your GPS is on the border of the region and you
move, the entity watching knows that you're on the boundary
marc: inaccuracies of being able to measure location should never be used to fuzz location
stephen: if I do an IP-based lookup and I get 'London,' how do I refer to accuracy of the location?
alec: you don't mix civic and some other measurement like meters
<rbarnes> fuzzing for civic location: <http://tools.ietf.org/html/draft-ietf-geopriv-policy-17#section-6.5.1>
alec: plan: we will shop around civic address plan on the mailing list
andrei: we will move format of civic address to mailing list
john: get some older IETF document pointers for the web
context
doug: I expect this proposal to
be shot down because it's not pretty
... if we can group some of these in logical units, maybe that
will help
... are there natural sets?
richard: I sent a link out about
fuzzing in the policy document
... building-level, city-level, etc.
doug: this would be an easier API to suggest if it had more of a hierarchy
alec: this is going to be a
sparsely populated data structure
... you can't prune it down and support everything, but you can
aim it at some use cases
<matt> [ use cases, use cases, use cases!!! ]
doug: if use case is delivering
pizza, you might need something expansive
... we should post to the list and think about moving geodetic
under position
<matt> IETF Civic Address components
alec: will post windows civic addressing proposal
richard: if we can get examples out of U.S. address bindings that might help too
alec: most of the fields are
focused on the last step amount of accuracy
... city/state/zip is where most of the use cases are
doug: is there a name for civic
position? "postal" address or "address"?
... something less technical
john: will A1-A6 be registered with IANA?
<amachin> ACTION: alec to post Windows API civic addressing proposal [recorded in http://www.w3.org/2008/12/08-geolocation-minutes.html#action02]
<trackbot> Created ACTION-6 - Post Windows API civic addressing proposal [on Alec Berntson - due 2008-12-15].
richard: some people did the
mapping for austria
... and are working on a generic mapping
... in austria every structure must have an address, but a shed
in the square will have a related number assigned to it
lars: japanese system is worse because it's according to when building was built
richard: they're starting up a
registry of documents that explain how you map address
conventions onto RFC 5139
... registry hasn't been defined yet
doug: what about the universal postal union?
<rbarnes> geopriv draft on civic address standards: <http://tools.ietf.org/html/draft-ietf-geopriv-civic-address-recommendations-00>
<dougt> http://www.upu.int/
doug: has mailing labels for austria
lars: does windows support austrian weirdness?
alec: you can repurpose them
based on where you are...it's standard format for office mail
merging
... it's used in all countries where Windows Live is
sold/used
matt: does Japanese localization of addresses happen?
alec: probably not perfect, but it works without serious consequences
doug: we should strive for a smaller set of fields for v2 and figure out what we want to go for emergency services
andrei: google's is 9 fields
richard: with acknowledge that that approach is lossy
andrei: will post google proposal too
richard: OASIS has an addressing scheme too
andrei: gears is result of discussion with them
doug: changes to v1:
move current attribs except timestamp onto another attrib off of Position
andrei: don't need to change
anything
... can move properties of position class to geodetic but don't
need anything else?
doug: should we say geo will be null?
andrei: it will just return nothing if it's null
stephen: will just use error code, never call success with no position
andrei: then we need to name the attributes somehow
doug: in v1 FPWD civic addressing is optional
matt: is v2 a separate different document or what?
alec: is v2 before the final recommendation or not?
oug: they don't have to be serial
doug: we will publish something
that will become a recommendation -- that's v1
... other features (reverse geo, 911) are for v2
v1 and v2 will overlap
<rbarnes> http://www.w3.org/2008/geolocation/
<rbarnes> timeline there
v1 -----------|--------------|-----------> recommendation
v2 ----------|-------------|----------------->
FPWD starts 180 day clock on IP disclosures
john: if civic introduces IP issues, is there risk that when you do civic in v2 someone will ask for clock to start over?
marc/andrei: that's not a problem
<scribe> Scribe: jmorris
discussing timeline:
Andreip: missing is test suite and testing cycle
v2 will have civic
matt: other APIs in the work and
could be consolidated
... we do not yet have charter for v2
dougt: should we keep this
together
... or separate?
... we are pushing civic to v2, perhaps as simplified postal
and "hoover" omin-civic address
andreip: naming lat/long object is needed
dougt: we could use "geo"
Stephen: "coords"
or "coordinates"
rbarnes: risk if you later want to add richer types of info
alec: but you have heading and speed so "point" is not good
dougt: we will not support speed, in all likelihood
marc: specific map data?
stephen: "point" sounds like synonym for "position"
andreip: what is wrong with "geo"
rbarnes: if other geodetic shapes
might be added, then "point" is good
... "point" in wgs84, and then we could add a polygon object
some other time
alecbernstein: point does not imply any shape
matt on white board: position.coord[s]
position.geo
position.point
position.coordinates
<scribe> new one: position.fix
rbarnes: vote for "point"
andreip: vote for "coords"
maxf: who will actually care
dougt: coming down to coords or
point
... but object has speed
... leans toward coords, second choice point
informal vote: generally for coords
matt: only change to spec
"position.coords"
... one day of discussion >> one word change!
may reorganize agenda
for tomorrow:
9-10am group issues
10-12: 30 use cases
12: 30 - 13:30 lunch
13: 30 - 15:30 test suites
15: 30 - 17:00 other issues
including: v2, interface design, accuracy, last known position
Lars: how does windows component discover location
alec: driver model with GPS, wifi providers
mlinsner: dhcp options?
rbarnes: where is spec
alecberntson: document in window 7 sdk
<alecberntson> http://www.microsoft.com/whdc/device/sensors/default.mspx
alec: this is a sensor platform
that can treat locaiton info
... white paper is key
no change in the agenda
alec: windows mobile has own location API
dougt: another question on
position options, there is a field "timeout"
... what is behavior for 0 timeout, fail?
andreip: fail immediately
dougt: so negative numbers are failures
andreip: yes
dougt: throwing for any programatic failure
andreip: have not done anything to figure out bugzilla -- we can talk about this tomorrow
issue tracking on agenda tomorrow
matt: is that last topic
dougt: "last known position" is that still on table?
andreip: "Accuracy"
[general questioning of "other" agenda items]
meeting is wrapping up
[general discussion of food, drink....]
adjourned.....
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Dirk_?/Dirk_Seggers/ Succeeded: s/... there is a code/Dirk: there is a code/ Succeeded: i/transmission session./DKA: I went to the Kai Hendy page and it brought up a dialog that said "Do you want this app to be able to use gears to get your location?" from the user perspective means nothing. That's the opportunity right there to give them a useful interaction. Like, what happens in FaceBook. Succeeded: i/etc.../DKA: I came over here and implemented a registration page on a dotcom site, and I got a crash course in EU privacy rules. It doesn't necessarily stop the data from being misused, when the company went under, someone sold the data. There is a value though to asking those detailed questions, even if they might simply say they're going to use it however they'd like. Succeeded: s/Topic:A/Topic:UA/ Succeeded: s/mlinsner:/mlinsner,/ Succeeded: s/dougt: huh?// Succeeded: s/new markets/niche markets, imho/ Succeeded: s/acooper2:/acooper2,/ Succeeded: s/Starting the/Topic: The/ Found Scribe: DKA Inferring ScribeNick: DKA Found ScribeNick: DKA Found Scribe: Matt Inferring ScribeNick: matt Found Scribe: DKA Inferring ScribeNick: DKA Found Scribe: Matt Inferring ScribeNick: matt Found Scribe: mlinsner Inferring ScribeNick: mlinsner Found Scribe: acooper2 Inferring ScribeNick: acooper2 Found Scribe: jmorris Inferring ScribeNick: jmorris Scribes: DKA, Matt, mlinsner, acooper2, jmorris ScribeNicks: DKA, matt, mlinsner, acooper2, jmorris Present: dougt rbarnes acooper2 jmorris mlinsner_ Alec_Bernston DKA lbolstad Dirk_Seggers amachin matt Andrei Got date from IRC log name: 08 Dec 2008 Guessing minutes URL: http://www.w3.org/2008/12/08-geolocation-minutes.html People with action items: alec andreip[End of scribe.perl diagnostic output]