RE: wording for the privacy section

On Wed, 29 Oct 2008, Alissa Cooper wrote:
> 
> This is exactly the discussion we would like to have with the group: how 
> can Geopriv be best implemented within the API?

I think this misses a crucial step, which is where we establish whether 
Geopriv is a good idea, and whether it is appropriate here.


> In addition to the Position attribute in the Geolocation interface, we 
> could have a UsageRules attribute:
> 
> 	readonly attribute UsageRules usageRules;
> 
> where the UsageRules interface is defined as:
> 
> 	interface UsageRules {
>   		readonly attribute boolean retransmissionAllowed;
>   		readonly attribute DOMTimeStamp retentionExpires;
>   		readonly attribute DOMString rulesetReference;
>   		readonly attribute DOMString noteWell;
> 	};
> 
> This data structure maps to the usage-rules element defined in [1], the 
> Geopriv location object format specification.

Could you show what values you would expect to see these attributes 
return? For those attributes that return URLs, could you give examples of 
what the text of those resources would look like in a typical case?

Could you show how a script would use these values?

Could you show what the UI would look like that would deal with these 
values?

I think this information would be helpful in fully evaluating a proposal.



On Wed, 29 Oct 2008, John Morris wrote:
>
> In contrast, any approach that squarely confronts web developers with 
> clear privacy expectations will lead some to focus on privacy, even if 
> -- as you correctly note -- some will not.

I posit that making the API callback include an object that purports to 
describe the user's privacy preferences (as Alissa suggests) will have an 
extremely minimal impact on authors in terms of making them aware of 
privacy, while having a disproportionally high cost on implementors in 
terms of exposing UI, implementing the callback object, and testing these, 
and a disportionally high *cost* on users, in terms of exposing them to an 
interface that they will not understand, and which will almost uniformly 
be ignored anyway.

In fact, I would say that the net effect would be of taking an issue with 
a very well understood privacy model -- only let applications have access 
to your location information if you trust them, a privacy model that has 
worked very well for all private information up to this point -- and 
replacing it with a highly confusing model that will be ignored and that 
will thus disenfrachise users.

Privacy will be respected *less* if we expose fine grained preferences to 
the authors, because authors will feel safer in giving their location 
information in cases where they otherwise would not feel safe.



> Moreover, if the W3C says to web developers, "you must appropriately 
> handle privacy rules in order to claim compliance with our standard," 
> then I guarantee that at least some developers will address privacy when 
> they otherwise would not have done so.

If it makes 10 developers more aware of privacy, but makes 20 users less 
careful about disclosing information, then this is a net loss for users.

However, I highly doubt that it would even make that much difference.

On the contrary, I think that authors today are highly aware of privacy 
issues, and have shown themselves very capable of taking the user's 
concerns into account. Changing the API wouldn't change this.

We would get significantly better results in terms of increasing awareness 
of privacy through education schemes than through changing the API.


> So, doing nothing in this regard ensures that privacy will not be 
> considered. Doing something, in contrast, will increase the protection 
> of privacy.  Will the "something" provide perfect protection -- of 
> course not.  But it will improve a generally bad situation.

I pretty much disagree with everything in this paragraph. The API as is 
will ensure better effective privacy than the proposal; changing the API 
won't increase protection, it will, at best, lower it; and the situation 
is nowhere near as dire as you suggest.


> I am not expecting the law to enforce any technical specification, or 
> any moral.  Instead, I am expecting the law to enforce an "expectation 
> of privacy," which is something that the law does all the time.

Expectation of privacy is a moral stance. (One I happen to strongly agree 
is important, but that doesn't mean it's not a moral stance.)

In this particular case, you are proposing the expectation of privacy to 
be exposed as a technology.

Thus I stand by my comment. You are expecting a technology to support a 
moral stance, and the law to support the technology. IMHO these are both 
highly inappropriate.


> Why are you so unwilling to explore the possibility of using Geopriv, 
> and why are you so unwilling to try to improve the state of privacy -- 
> especially when the charter of this group mandates a "privacy sensitive" 
> output.

We believe privacy to be important; critical even. I believe that the 
current API stands a significantly better change of effectively protecting 
the user's privacy than a more fine-grained, more technology-based, and 
more complicated scheme such as Geopriv or ideas based on Geopriv.

I put forward P3P as a classic example of how technology is a very bad 
vehicle for privacy concerns.


> I suspect that the answer to my question is that many folks on this list 
> have a largely-baked spec that they would like the W3C to give a seal of 
> approval, and they are not interested in actually trying to decide how 
> "best" to fulfill the charter mission.

I assure you that that is not the case. The spec in question was developed 
fully within the W3C.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 29 October 2008 22:20:58 UTC