Re: Why privacy can't be left to chance (a response to RE: wording for the privacy section)

Hi,

I strongly agree with Doug. I am not sure where the idea that this WG
is not concerned about privacy came from, but it's certainly wrong.
And our mailing list is a witness to this.

However, I doubt that this specification is the correct place for
defining a detailed privacy mechanism / framework that all
implementations absolutely must implement. Rather, I personally feel
that we need to provide clear guidelines that should stress that the
location of the user is sensitive personal information and that any
implementation / user agent of this spec must ensure that it is not
made available without the user's informed consent. But it is up to
the user agent to determine what is the most effective way of
implementing the spec guidelines.

Thanks,
Andrei


On Fri, Oct 31, 2008 at 5:22 PM, Doug Turner <doug.turner@gmail.com> wrote:
>
> Phil et. al,
>
> We are all concerned.  It is wrong to suggest that we, or at least I, am
> unconcerned about privacy.
>
> I doubt anyone is thinking about rolling out this API without the very
> strict protections for the user.  The assertion is that UAs will figure out
> what is best for their users.
>
> I urge you to take a look at the implementations in firefox 3.0 w/ the Geode
> addon, or take a look at Firefox 3.1beta -- both have implemented this draft
> spec and have continued to protect the user's privacy -- without the need
> for GeoPriv or any other similarly complex addition to the spec.
>
> Doug Turner
> Mozilla Corporation
>
>
> On Oct 31, 2008, at 9:48 AM, Phil Archer wrote:
>
>>
>> Hi,
>>
>> Much as I would like to be, I am sorry that I can't actively participate
>> in this group. But I have been alerted to the discussion on privacy and its
>> place in the group's thinking. Let me try this approach:
>>
>> Many companies spend a lot of money on protecting their users. Google
>> offers safe search, for example, which works extremely well. Vodafone is a
>> world leader in online safety work (mainly through the excellent Annie
>> Mullins, head of Content Standards for Vodafone Group).
>>
>> Why? Because it hurts their business if end users suffer abuse in any way.
>> Issues like cyber bullying, inappropriate content, illegal content, viruses
>> and so on all come down to one issue - brand protection. So you can bet that
>> any implementation of the GeoLoc WG by Vodafone, or Google, or anyone else
>> you've heard of, will be sensitive to privacy. But, though it hurts them to
>> hear it, Google isn't the Internet, and Vodafone isn't the mobile space.
>> There are services that make a feature of their lack of safety.
>>
>> The world is full of vulnerable people. And vulnerable teenagers are
>> especially vulnerable. They may have had a poor education (so forget safety
>> messages like "don't give out your location to just anyone"). They may be
>> suffering real physical abuse (typically from a step-father) so forget
>> "parents should always be able to know where I am" for all cases. And even
>> where they are not particularly vulnerable, teenagers, of course, take risks
>> (the world stops progressing the day that isn't true!)
>>
>> Of course the API must force consideration of privacy. If developers don't
>> care about it - and Hixie is, of course, right that many won't - well, they
>> jolly well should. This is real people we're talking about. Making it easy
>> for an end user to advertise their location in a way that can lead to a
>> malicious person finding out where they are is irresponsible and could
>> seriously hurt the bottom line of businesses that implement any such system.
>>
>> Please listen to John Morris. He's right to be very concerned.
>>
>> Phil Archer
>> Latterly with the Family Online Safety Institute.
>> Chair W3C POWDER WG.
>>
>> --
>>
>> Please note my new e-mail address. My ICRA/FOSI e-mail addresses will not
>> function after the end of November.
>>
>> Phil Archer
>> e. phil@philarcher.org
>> w. http://philarcher.org/
>>
>>
>
>
>

Received on Friday, 31 October 2008 18:03:08 UTC