<div dir="ltr">On Tue, Sep 30, 2008 at 2:44 AM, Michal Zalewski <span dir="ltr"><lcamtuf@dione.cc></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Well, so I agree. Yet, given the choice between:<br>
<br>
  1) Telling developers that they can't do any "privileged" gadgets safely<br>
     at all, not theirs, and for reasons that are hard to explain to<br>
     regular developers too - and pretending that the problem does not<br>
     exist while people continue to depend on the unsafe logic (because<br>
     whether we like it or not, seems that gadgets, mashups, and other<br>
     methods of tightly integrating various applications and data sources<br>
     on client side is here to stay),<br>
</blockquote><div><br>We can easily offer these developers the following options:<br>a) developers of privileged gadgets can whitelist domains that they trust to not subvert the UI<br>b) privileged gadgets can be offered to the world as long as the IFRAME's own UI is not trusted. For example, gadgets whose purpose is to offer a postMessage API to untrusted container pages would be just fine.<br>
c) spawn new windows/tabs to perform or confirm privileged operations<br>d) mix of strategies ... for example, gadgets could offer privileged UI to trusted container pages, but for untrusted containers, attempts to use the privileged UI would spawn a separate window/tab to perform the operation<br>
<br>We might also be able to help by extending the browser UI, for example by supporting extra panes like the old Netscape sidebar UI (but better). But to explore that further, I'd want to better understand the use cases that are not served by a) b) c) or d) above.<br>
<br>I honestly think that, compared to an extremely complex, mysterious and ever-changing set of UI threat mitigation strategies, which will inevitably diverge across browsers and across browser versions and will constantly interfere with the user experience, the above approach will be actually end up more attractive to developers.<br>
<br></div>Rob<br></div>-- <br>"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]<br>

</div>