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
