RE: Mozilla security review of Access Control

On Thu, 21 Feb 2008, Close, Tyler J. wrote:
> 
> Beyond the vendor lock-in issue, there are additional problems that make 
> such designs not viable.
> 
> The social networking site has an incentive to support updates from as 
> many third-party sites as possible. Combine this incentive with the 
> prohibitive cost of vetting a third-party mashup and you have a strong 
> bias towards accepting updates from everyone. As the site's policy moves 
> in this direction, it becomes more vulnerable to spam. The site's 
> operator is faced with a distasteful tradeoff between wider adoption and 
> spam.
> 
> In contrast, the design I described in the previous email does not 
> create such a tradeoff. By requiring explicit user consent you can cut 
> down on spam (depending on how you define spam, eliminate it) while 
> still having a policy of accepting requests from anyone.

I'm just telling you what our use cases and requirements are, in the hope 
that the editor will take those into account and provide a way to do what 
we believe we need.

It is your right to disagree that the spec should address our needs, but 
that doesn't change what we perceive our needs to be.


> Sending the user's credentials without the user's consent creates a host 
> of security problems, such as the one around headers the WG is currently 
> struggling with and the one's I've written about on this list recently, 
> without enabling any actually viable designs.

I disagree with that conclusion, and I think that Anne's proposal for 
headers is a fine solution.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 21 February 2008 23:57:58 UTC