Re: Additional security and privacy considerations?

On Jun 2, 2009, at 5:35 PM, Andrei Popescu wrote:

> While predicting or preventing these situations is inherently
> difficult, mitigation and in-depth defensive measures are an
> implementation responsibility and not prescribed by this
> specification. In designing these measures, implementers are advised
> to enable user awareness of location sharing, and to provide easy
> access to interfaces that enable revocation of permissions, even when
> users have previously granted authorization.
> //-------------------------------------------------------
>

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 . . .

> 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?


> They are likely to get ignored by implementers who will
> do what they think best for their product, making the spec less
> credible. At the same time, people can wrongly accuse implementers of
> ignoring the spec, as Doug rightly pointed out.

I agree with Thomas here -- this suggestion is in a non-normative  
section of the spec, the section states clearly that defensive  
measures are not prescribed by the spec, and the sentence talks about  
what additional measures "might" include. Anyone claiming that an  
implementation is non-conformant because it provides no way to  
reauthorize would clearly be in the wrong. It seems like you gain a  
lot more on the privacy story end of things by leaving the sentence  
in, and it's such a subtle suggestion that you don't lose much  
reputationally by not implementing it.

>
>
> 2. I have concerns about this solution. There is no expiry interval
> magic constant that applies well to all Web applications, while the
> user experience of having to repeatedly and for no apparent reason
> grant permissions to the same origins is terrible.

But the sentence doesn't specify a constant. It seems to me that the  
sentence leaves open the possibility (for a UA that wants to implement  
this) that the first time a user ever authorizes location to be sent  
to a site, the UA could ask if he wants to be reminded/reauthorized,  
and if he says no, then he would never have to re-grant permissions.  
Or the trigger for reauthorization could be something else altogether,  
like if the user goes into a privacy mode or clears all local data or  
takes some other action. I'm not trying to suggest implementations --  
the sentence just strikes me as extremely vague (on top of not  
actually requiring anything), so I'm having trouble understanding why  
it's being treated like a mandate.

Alissa

Received on Thursday, 4 June 2009 19:27:59 UTC