W3C home > Mailing lists > Public > public-geolocation@w3.org > June 2008

Re: Draft Charter

From: Erik Wilde <dret@berkeley.edu>
Date: Mon, 23 Jun 2008 15:34:49 -0700
Message-ID: <48602509.8030607@berkeley.edu>
To: "public-geolocation@w3.org" <public-geolocation@w3.org>

hello.

Chris Wilson wrote:
> Ian Hickson <ian@hixie.ch> wrote:
>> - We think the first paragraph's emphasis on prviacy could mislead people
>>   into thinking that the API should constrain how user agents expose the
>>   privacy options to the user. We would like the charter to explicitly
>>   allow the deliverables to defer the user interface aspects of privacy,
>>   and the privacy model in general, to the user agents, within the
>>   constraints required to obtain interoperability at the API level.
> We respectfully disagree.  Although I agree with Ian that I would prefer the specification to not *constrain* how user agents expose privacy in the UI, I believe quite strongly that 1) privacy in the context of this API is incredibly important, as it has the potential to set up the future of web applications to be incredibly harmful to user privacy, 2) the _consideration_ of privacy and how it _might_ be exposed to the user might lead to different ideal design decisions in the API (e.g. if I know that the user might automatically enable "country and state" level of geolocation, then I might want to ask for just that precision - which, of course, would need to be reflected in the API.)  I do not think the importance of privacy in designing this feature can be overstated.

i agree with this one. if there is a single implementation that will 
allow simple scripting code to track users with gps precision, this will 
create a huge backlash against anything vaguely associated with 
browser-supported geolocation. the IETF even created a separate 
specification for privacy requirements 
(http://www.ietf.org/rfc/rfc3693.txt), and i do agree that "the 
importance of privacy in designing this feature can [not] be overstated."

>> - We think that the charter should not require the working group to
>>   publish the requirements as an explicit WG note. It should be
>>   acceptable for us to publish the requirements in the spec itself as an
>>   appendix, or on a wiki, or on our WG home page, etc.
> It would be a very good idea, in my opinion (and perhaps this is primarily related to the previous point about privacy) to get the requirements for the spec straight before writing the spec.

i think getting the requirements straight would be extremely helpful, 
because there are so many different ways in which this feature can be 
designed (it should or at least could be much more than just a browser 
API for map apps). the discussion of the current draft more or less 
depends on people coming up with new requirements or people saying that 
some requirements are not essential. with well-defined requirements, 
there would be a much better structured way of approaching the problem. 
i also have to admit that the total lack of requirements in some areas 
of w3c work (CSS comes to mind) sometimes makes it really hard to 
understand certain design decisions, and having explicit requirements 
also makes specification work much more accountable. explicit 
requirements are a very helpful thing, and treating them as first-class 
citizens would be a good idea. the requirements document, btw, would be 
an excellent place to be very explicit about how privacy should be handled.

cheers,

erik wilde   tel:+1-510-6432253 - fax:+1-510-6425814
        dret@berkeley.edu  -  http://dret.net/netdret
        UC Berkeley - School of Information (ISchool)
Received on Monday, 23 June 2008 22:35:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 March 2012 18:13:39 GMT