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

[Michal Zalewski]

On Mon, 29 Sep 2008, Hallvord R M Steen wrote:

>> It still completely ignores the question of how we protect gadgets / mashups
>> / whatever that are *designed* to be embedded on potentially untrusted
>> sites, but depend on having the integrity of their UIs preserved
>
> After giving this quite some thought over the weekend, my conclusion
> is that this basically isn't doable - simply because it is a UI issue,
> UI is all about communicating to end users and the likelyhood of
> finding a solution that communicates the complexity of this in a way
> users will understand is practcally 0.

Well, so I agree. Yet, given the choice between:

   1) Telling developers that they can't do any "privileged" gadgets safely
      at all, not theirs, and for reasons that are hard to explain to
      regular developers too - and pretending that the problem does not
      exist while people continue to depend on the unsafe logic (because
      whether we like it or not, seems that gadgets, mashups, and other
      methods of tightly integrating various applications and data sources
      on client side is here to stay),

...and...

   2) Implementing a kludge that does not severely and inherently degrade
      user experience, whilst giving developers at least some security
      that they should have in the first place (most of the security
      problems they are dealing with these days can be tracked back to
      poor or uncoordinated security design decisions in the early days
      of the Web),

I would be kinda willing to side with 2, which is why we came up with the 
kludgy proposal #3 to begin with. It's ugly, it's not perfect, it may 
require multiple workarounds to account for various scenarios, but it's 
the only way to tackle the UI problem we could think of. It also has a 
chance of working in a reasonably seamless manner if carefully reviewed 
and done right, although it might be a bumpy ride.

Not presenting users with overly complex choices or failure scenarios is a 
noble goal, but realistically, it's not how web browsers work these days, 
and so when applied selectively, it might be not the strongest argument 
possible.

As of now, understanding browser settings and error / warning / prompt 
messages requires a fair dose of expertise and experience, and it is 
extremely difficult to operate these applications without this knowledge. 
Some of the ongoing efforts improve this a bit (for example, browsers 
moving away from cryptic SSL security prompts to cryptic interstitials), 
other efforts take us a step back (for example, yellow "security 
notification" bars that are fully spoofable by web pages, and not properly 
anchored into browser chrome).

> The idea I liked most was a sort of "automatically raise IFRAMEs to 
> topmost z-index when focused" combined with some way to temporarily 
> flash the address - but IMO it's not doable because we'll mess up the UI 
> of existing solutions in unexpected ways, and users don't understand 
> URLs and have a quite fuzzy understanding of the basic "different site" 
> concept.

Yup. Plus, it leaves some open questions. Do we simply raise an IFRAME 
when clicked? If yes, the harm might be already done. Do we require 
Eolas-patent-style click-to-activate? If yes, we might seriously annoy 
operators of some IFRAME-based advertisement systems. Do we raise the 
frame just on mouseover? This would result in confusing flickering and 
page layout changes, would mess up drop-down menus expanded over 
different-origin document windows, etc.

Cheers,
/mz