W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2008

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

From: Michal Zalewski <lcamtuf@dione.cc>
Date: Fri, 26 Sep 2008 19:49:01 +0200 (CEST)
Message-ID: <Pine.LNX.4.64.0809261930450.17847@dione.cc>
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.

/mz
Received on Friday, 26 September 2008 10:49:01 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:05 UTC