Re: Geopriv compromise proposal

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