Re: Additional security and privacy considerations?

Hi Alissa,

On Thu, Jun 4, 2009 at 8:27 PM, Alissa Cooper<acooper@cdt.org> wrote:
> 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 . . .
>

Yep, good point.

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

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

They would clearly be in the wrong, but that's a debate we should
really avoid. As you have seen on the other thread, the consensus is
that we should drop the sentence.

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

It can be mistaken for a mandate by someone less familiar with the way
specs are written. Besides, most people dislike the idea (how about
you?), so why even allude to it? It has the potential to do damage,
while providing little value to anyone. As I said above, a link to
this thread would be a lot more informative.

Thanks,
Andrei

Received on Friday, 5 June 2009 16:03:19 UTC