Re: Additional security and privacy considerations?

On 2 Jun 2009, at 23:35, Andrei Popescu wrote:

> I think we need to close this discussion. After discussing with Thomas
> offline, we have one wording proposal and one question for our group.

Indeed.  The plan is to have one last go-around on the open question,  
perhaps fine-tune the rest of the language, and then see where we are  
in terms of decision.

> Here is the wording proposal:

First of all, thanks a lot for your work on this.

> //-------------------------------------------------------
> //-------------------------------------------------------
>
> I think such wording captures well the privacy concerns that were
> raised by Thomas while clearly indicating that the defenses against
> potential problems are completely up to the implementations to
> consider. We also both think that listing these privacy concerns in
> the spec is a responsible thing for us to do.
>
> 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:
>

I disagree with your view on this one.

The point of limiting the scope of authorizations has come up in this  
discussion, and I haven't heard any reasoned technical argument why  
scoping (in principle) is a bad idea.  More importantly, I haven't  
heard any other (hopefully better!) solution approach that would be  
similarly likely to limit user exposure to errors.

I've heard push-back against specific implementation choices and their  
impact on users.  To address that push-back, I've suggested to move  
the limitation in time into an example, out of anything that resembles  
normative language.  The goal here is precisely *not* to prescribe  
implementation, but to get implementers started to think about  
limiting attack surface.  The goal is also to document that the group  
has had discussions.

That said, if there is a preference to extend that example by adding  
some of the considerations that come in as complicating factors, I  
think that would be fine.

> 1. Adding such concrete implementation recommendations, especially
> without any implementation experience or user studies to back them up,
> is dangerous. 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.

For what it's worth, we're talking about an example in a non-normative  
considerations section, not about normative language.

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

See above; I'd be happy to add more detailed discussion.

(I acknowledge that a "whack a mole" user experience is indeed  
terrible and needs to be avoided; however, I'm confident that one  
could avoid this problem while following through on the example.)

Received on Wednesday, 3 June 2009 12:52:40 UTC