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

Michal Zalewski lcamtuf at dione.cc
Fri Sep 26 10:49:01 PDT 2008

On Fri, 26 Sep 2008, Maciej Stachowiak wrote:

> Maybe I didn't read very well, but I don't see how the "clause for UI action 
> optimizations" would prevent what I described. Could you spell it out for me 
> please? It seems to me that the embedded iframes for iGoogle gadgets (or 
> similar) will indeed be disabled when scrolled partly off the top of the page 
> (or maybe dead to UI events only when you bring the mouse near them, which 
> amounts to the same thing).

What I meant is that we can conceivably inhibit disabling IFRAMEs if they 
end up off the screen as a result of non-scripted user-initiated 
scrolling - a change that does not require the design to be scraped.

I was simply referring to the fact that similar optimizations were already
present in the design, so it is not a very far-fetched idea to extend it
to incorporate this. We did not, because it seemed to be a non-issue.

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.

> I am also not sure what you mean by "the other thread".

Err, sorry - the other branch of this one.

> P.S. I cited this example because it is a Google property, but I am sure 
> there are many others like it. We can't expect content authors to 
> immediately fix them all.

Yet opt-in proposals expect content authors to immediately add security 
checks everywhere, which is considerably less realistic than having a 
handful of webpages adjust their behavior, if we indeed break it (which I 
don't think would be likely with the design). It feels better, but I am 
inclined to think it is considerably less beneficial.


More information about the whatwg mailing list