W3C home > Mailing lists > Public > public-geolocation@w3.org > June 2009

Re: Additional security and privacy considerations?

From: Thomas Roessler <tlr@w3.org>
Date: Fri, 5 Jun 2009 18:58:51 +0200
To: Andrei Popescu <andreip@google.com>
Message-Id: <65D6F472-D0D7-4A50-801A-B99715D020C2@w3.org>
Cc: Alissa Cooper <acooper@cdt.org>, Doug Turner <doug.turner@gmail.com>, Greg Bolsinga <bolsinga@apple.com>, Rigo Wenning <rigo@w3.org>, public-geolocation <public-geolocation@w3.org>
On 5 Jun 2009, at 18:02, Andrei Popescu wrote:

>> The way that the first sentence is constructed suggests that the  
>> difficulty
>> of prediction and prevention is somehow at odds with the fact that  
>> defensive
>> measures are not prescribed by the spec. In fact, the two ideas are
>> unrelated (unless I'm missing something). My suggestion would be to  
>> alter
>> the first sentence like so, breaking it into two sentences and  
>> linking it to
>> the third sentence with "however":
>>
>> Predicting or preventing these situations is inherently
>> difficult. Mitigation and in-depth defensive measures are an
>> implementation responsibility and not prescribed by this
>> specification. However, in designing these measures . . .
>>
>
> Yep, good point.

ok with me.

>>> And here is the question:
>>>
>>> Should the wording also contain the following additional sentence:
>>>
>>> "Additional defense measures might include limiting the scope of
>>> authorizations in time by asking for re-authorization in certain  
>>> time
>>> intervals."
>>>
>>> My personal opinion is that it should not. This sentence suggests a
>>> concrete solution direction to solve the above mentioned concerns. I
>>> think we should not add it to the spec because:
>>>
>>> 1. Adding such concrete implementation recommendations, especially
>>> without any implementation experience or user studies to back them  
>>> up,
>>> is dangerous.
>>
>> I don't understand how this is any more concrete than the included
>> suggestions about user awareness and revocation of permission.  
>> There are a
>> million different ways a UA could limit the scope of  
>> authorizations, just as
>> there are a million different ways to indicate when location is  
>> shared and
>> to provide for permission revocation. Why are the first two  
>> suggestions
>> acceptable but not the third?
>>
>>
>
> Revocation of permissions is already discussed in the normative
> section. Here we're just saying "please remember to make the UI for
> revoking permissions easily accessible". User awareness is pretty
> vague, I agree. Perhaps we should replace this entire paragraph with a
> link to this thread? There's a lot more info about implementation
> suggestions (with pros and cons) on this thread than we could ever
> capture in the spec.

A link into mailing list archives is not a useful replacement for  
specification text.  I'd be open to see the paragraph extended into a  
more detailed summary of the key points of this thread.
Received on Friday, 5 June 2009 16:58:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:56 UTC