[whatwg] Dealing with UI redress vulnerabilities inherent to the current web

[Michal Zalewski]

On Sat, 27 Sep 2008, Smylers wrote:

>> All this assuming that the inability to interact with a cross-domain
>> gadget whose top part is off the screen is an usability problem by
>> itself, to a degree that invalidates any security benefit for such a
>> scheme. Many of the earlier security improvements within browsers did
>> rule out far more pronounced usage scenarios, retrospectively breaking
>> other people's applications. Examples include file:/// scripting
>> restrictions, Internet <-> file:/// access restrictions,
>> document.cookie restrictions on non-HTTP schemes, CANVAS readback once
>> non-same-origin images are rendered, third-party cookie restrictions,
>> etc. Not all of these solutions were perfect, but they do provide some
>> context.
>
> The above changes generally clobber something from working at all, and
> can provide an error message.

Except most of them don't, and just silently break stuff in situations 
that are perhaps even less intuitive to the user. They all have one 
redeeming quality: they are elegant, can be summed up in one sentence, and 
are very easy to implement for browser vendors.

I really see the points that can be made against #3 on the grounds of 
lacking simplicity, and I can quite easily imagine that clear solutions 
have a much greater appeal; that said, I was looking for a compelling 
reason to dismiss the approach altogether, and aesthetics aside, I do not 
quite see it yet; maybe I'm in the wrong, we can probably leave it at 
this.

Your whack-a-mole analogy is of course true, but it applies so much more 
to many ongoing browser security efforts, most notably including 
implementing robust cross-domain DOM access security checks; hardly a 
simple and well-defined component by itself, and proved to be extremely 
complex to implement right in practice, too. Pretty much *any* effort to 
patch the existing design is bound to be in practice kludgy, regardless of 
how much text is needed to outline implementation goals.

Anyway, to move on - dismissing any particular proposal aside, can we come 
up with any other viable works-by-default scheme that would have a 
comparably beneficial net effect (that is, not making unrealistic 
assumptions about the entire world properly implementing a yet another web 
security check, or not being incompatible with gadgets, embedded ads, 
etc)? If yes, I think it should be a fairly urgent and important goal. If 
not, we should at least make sure that opt-in designs pursued do not break 
too many things (e.g., would not be required to be disabled altogether for 
mashups, gadgets, ads - as on all other fronts, we are working to make 
these safer, with cross-domain inter-frame IPCs, cross-domain 
XMLHttpRequest, etc).

Cheers,
/mz