Re: Geopriv compromise proposal

On Jun 17, 2009, at 2:01 AM, Rigo Wenning wrote:

> On Tuesday 16 June 2009, Ian Hickson wrote:
>> On Tue, 16 Jun 2009, Rigo Wenning wrote:
>>> And NO, this is not at all harmful in the sense that Ian Hickson
>>> described. I have understood the remarks differently. Ian Hickson
>>> may clarify. Because this would mean that you and others would
>>> consider P3P harmful to browsers and exposing users to risks.
>>
>> P3P has exactly the same problems as I described, yes. This is one
>> of the reasons why it hasn't been implemented in most browsers.
>
> It has been implemented in IE and everybody else did the bare minimum
> as present in IE. And the alleged reasons I'm aware of are very
> different from your assertion here.
> https://bugzilla.mozilla.org/show_bug.cgi?id=62399
> https://bugzilla.mozilla.org/show_bug.cgi?id=202959
>
> There was a strong preference for other things. P3P simply wasn't sexy
> enough to be considered in the race for limited implementer cycles. So
> implementation ended around 2005 in mozilla. Plugins are still going
> on. Search engine use P3P metadata to rank results now. So it is far
> from being over.. This was in a certain political climate. This
> climate has _changed_.
>
>>
>> (In short, it relies on the site being honest, and then on the
>> browser trusting the site and exposing the same information but
>> with the browser's authority behind it.
>
> This is a rather dramatic misunderstanding of the semantics, protocols
> and social assertions of things like P3P and XACML. (see below)
>
>> Most browser vendors refuse
>> to implement this because it undermines the user's trust in the
>> browser, leading to the same issues such as the user no longer
>> trusting TLS warnings.)
>
> This is a very surprising viewpoint. If your assumption that content
> displayed via the browser (and here it is just something not HTML,
> like geodata) would be attributed to the browser, liability attorneys
> would have really new fun ideas about browser vendor's liability.
> Fortunately, the browser is seen as a tool and not affected by the
> content it displays. With exactly one exception: The padlock. TLS is
> transport, not content. TLS uses X.509 with unintelligible messages.
> WSC WG was created because of the special case.
> The element in an API is completely orthogonal to this issue.
>
> Let me go further, if you mention the trust relation to a browser. Not
> to tell the user anything and faking a "nothing is wrong" message by
> just hiding the privacy nightmare going on under the hood is rather a
> way to completely destroy the trust into the browser (if there is any
> left and whatever "trust" means here).
>
> What if your car would have no dashboard and the vendor would say:
> Just trust me, the car goes exactly the right speed. Let's specify the
> dashboard elsewhere and let's design the engine with a complete
> disregard to the sensors that the dashboard will need. Now somebody is
> crashing with high speed into a wall... Geodata is _very_ dangerous
> and _very_ sensitive. Imagine you could locate the kids on Facebook to
> better target them.
>>
>>> And only because you (or your understanding of the majority of
>>> user agents) don't want to implement it, doesn't mean that others
>>> won't make a plugin/Extension using exactly that option (see e.g.
>>> Prime).
>>
>> I think if there is a desire to have an optional addition to the
>> Geolocation API, it should be specified in a separate
>> specification. There is clearly not consensus on having this kind
>> of thing in the core API, and having things in the core API that
>> aren't implemented will prevent us from getting through CR.
>
> See above. I think this is the core of the conflict. The bundling of
> API and metadata transport bucket has a value on its own. It makes it
> more likely that implementers are reminded of their social
> responsibility. And I think the process is not an issue here. As you
> may know, the Group defines CR exit criteria. And the element for
> policy transport and binding could be left out of the exit criteria.
>
> Best,
>
> Rigo



We are beating a dead horse.  From the vote a bit ago, it sounds like  
no UA is going to implement this sort of meta data along with the  
position information.

Matt, Chairs, Andrei, Can we take a formal vote on this to put to bed  
this issue, or must we continue to argue about the same thing for  
another 8 months?

Doug