<matt> Scribe: DKA

<scribe> ScribeNick: DKA

Intros and Welcome

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

More Privacy

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

UA users do not know what they should be setting in general

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

The API is complex, especially with rulesets.

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.

Websites currently can implement this now and allow the use to remain in control

<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

The civic address discussion

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