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

[Smylers]

Michal Zalewski writes:

> On Fri, 26 Sep 2008, Maciej Stachowiak wrote:
>
> > 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).
>
> ... 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.

That's adding further complexity to a design which was hardly elegant in
the first place.  We seem to be playing Whac-a-Mole in two different
directions (vulnerabilities and usability glitches) and hoping that
where they meet will be a robust spec for this feature.

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

I don't think an iframe ceasing to work because it's top border has been
scrolled off the screen by a pixel is a non-issue; that would be most
confusing, and frustrating, to users.

> 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.  Whereas the current proposal has whether
something works changing as it jiggles up and down the page, something
which may seem arbitrary or random to users: they experience the page
sometimes not working but don't know why.

Smylers