Re: ISSUE-10 Re: Geopriv compromise proposal

I share the discomfort at being railroaded. I find it somewhat ironic  
that, during an earlier UI-related discussion, the standard pushback  
was: "Do you have a user study proving this?" As far as I can tell, no  
evidence, except repeated assertion, is offered that user confusion  
will ensue in the model proposed by Rigo. Also, the alternative isn't  
some ideal privacy behavior; the alternative are inscrutable privacy  
statements that are inaccessible due to modal interfaces.

Henning

On Jun 18, 2009, at 5:06 PM, Rigo Wenning wrote:

> On Thursday 18 June 2009, Andrei Popescu wrote:
>> Rigo, we have now decided on this (please see the Chairs' earlier
>> email). I really appreciate your contribution but I think it's time  
>> to
>> move on.
>>
> Dear Andrei,
>
> I tried to be helpful, I wanted to have an issue opened
> that clearly expresses what I was suggesting. I look at this
> issue and I find it closed the same day while we were still
> in discussion.
> Not only that. I find in ISSUE-10 the same bogus argumentation
> that I clearly rebutted again below. It is used as the central
> argument for closing the issue. This is very rude. I will
> accept real arguments but not the bogus arguments given in
> there. This group has to invest 2 more neurons to get rid of me.
>
> Tell me why it is expensive to ignore an optional attribute?
>
> I clearly say here that I'm not satisfied with the way this group
> closes this issue.
>
> If you don't have real arguments, do it. It will take less time:
> add an attribute to PostionOptions interface:
> =========================================snip========
> [NoInterfaceObject]
>  interface PositionOptions {
>    attribute boolean enableHighAccuracy;
>    attribute long timeout;
>    attribute long maximumAge;
>    attribute  URI policy;
>  };
>
> The policy attribute is optional. The policy attribute carries a URI
> that points to policy file (e.g. XACML, P3P, EPAL). A user agent  
> knowing
> about the policy format found at the URI given may help the user  
> with the
> decision making in the sense of section [Security and privacy  
> considerations]
> The policy file linked by the attribute has the same scope as the  
> location
> request it attributed to.
>
> User agents that do not understand any policy language MUST ignore  
> this
> attribute. User agents that know about a policy language, but do not  
> know
> about the namespace of the policy under the given URI MUST ignore
> this attribute.
>
> =========================================snap========
>
> Additionaly write in your CR exit criteria:
> Two interoperable implementations with all SHOULDS and MUSTS except  
> for the
> optional policy attribute.
>
> I hear a "we" as chairs go for Last call with open issues
> http://www.w3.org/2008/geolocation/track/issues/open
>
> Having open issues isn't the point in time to go for last call.
>
> I WANT this email linked from the issue tracker under ISSUE-10
>
> I consider ISSUE-10 closed if there is a response other than  
> "delivering
> content to the user by a browser makes the user believe the browser
> makes an assertion". It is not a statement by the browser and never
> will be. A policy will NEVER state: "I the browser, tell you that
> your location information will be used in a certain way". (If you
> make such an assertion in your browser, call you legal department NOW)
> A policy will always indicate who makes that statement: "I, service
> A, make the following promises". Otherwise it is no serious
> policy and can just be ignored. If you don't believe them, turn
> off location sharing or even turn on TOR and here goes your
> enforcement. Saying "there is no enforcement" I could just as well
> ask "why isn't there a TOR implementation natively in the browser"?
>
>
> Best,
>
> Rigo
>
>

Received on Thursday, 18 June 2009 21:23:21 UTC