Re: Geopriv compromise proposal

On Thursday 18 June 2009, Doug Turner wrote:
> heh.  funny noises.  true enough.  just feels that we have been  
> discussing the same thing for 8 months -- well before the face to
> face   in December.  I hope you understand my frustration at not
> being able to make a decision.  :-)

Yes, despite the fact that you don't see me on the mailing-list that 
often, I was following the debate. Having nearly 10 years of privacy 
behind me, I unfortunately can't promise you that you get rid of such 
a human rights issue by "decision". So far, the group has rejected 
geopriv as too complex/complicated. That was a decision (here you have 
one). The second issue is to make the "Guidelines" conformant with 
minimal requirements (the disucssion with TLR) so that we don't get 
bashed in the EU for this specification. The third issue is this 
optional thingy from me that isn't really important, but may help a 
lot when it comes to discussions with the privacy folks, data 
commissioners and governments. (see below)
>
> Also, I hope you understand that the post sounds like the starting
>   point of a discussion that Mitchell is having about data.  I do
> not think it would be prudent to draw the line between a framework
> to discuss data and "we must have privacy rules associated with
> geolocation".

This is the constant misunderstanding. I do not want this group to 
come up with ""we must have privacy rules associated with 
geolocation". I want to be able to outsource this issue. But some kind 
of hook/glue must be there. (Thomas always tells me "hook" is the 
wrong word) Otherwise we'll have 10 projects using 10 different 
bindings/hooks/methods and thus fragmenting this narrow space with 
already scarce privacy resources. It would enable projects like 
PrimeLife to come up with something useful without re-inventing the 
API. 

AND it would not put any burden in this specification on the folks 
wanting to implement just some one-time "yes" and get slaughtered 
afterwards for it, whether the policy hook is available or not. (I 
already said that the element should NOT go into the CR exit criteria)

So the goal here is zero burden, because I know that privacy is seen 
as a burden rather than a benefit by many implementers and is one of 
the lowest priorities on business agendas despite a lot of public lip 
service. So not your fault, not the fault of this group. But I see a 
chance to do something about it without bothering too much. That's why 
I wrote so much email those past 2 days, effectively bothering :(

Best, 

Rigo