<div dir="ltr">On Tue, Sep 30, 2008 at 11:16 PM, Ian Hickson <span dir="ltr"><ian@hixie.ch></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;">

<div>On Tue, 30 Sep 2008, Robert O'Callahan wrote:<br>
> ><br>
> > I don't think this would really work for Google. Many widgets (e.g.<br>
> > the mapping widget) are expected to be placed on any site, but how<br>
> > could the widget provider know who is evil and who isn't? What about<br>
> > if an otherwise not evil site is compromised? (This happens regularly,<br>
> > especially with, e.g., sites with forum software or blog software.) We<br>
> > don't want a vulnerability in a widget host site to immediately allow<br>
> > this kind of attack on all the widgets that that site hosts.<br>
><br>
> Choose your friends carefully.<br>
<br>
</div>I'm not sure how that helps here. Are you saying widget providers<br>
shouldn't do business with site owners who use popular blogging tools?<br>
<div></div></blockquote><div><br>I'm saying that widget providers shouldn't let privileged UI be framed by sites they don't trust to do their job right.<br><br>Maybe that sounds harsh. But of course it's less harsh than the reality of the situation we find ourselves in today.<br>

<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>> But really, why does this mapping widget need to expose UI that can be<br>


> abused to do evil things with my Google account?<br>
<br>
</div>In the case of the mapping widget it doesn't, but consider a chat widget,<br>
that enables users to chat with the site owner. If this widget had a<br>
button that sent a message, a hostile site could perform a DDOS attack on<br>
the site owner by embedding the widget host itself in an iframe, and<br>
aligning everything such that all the users tricked into going to that<br>
page and logged in to the chat widget would cause the victim site owner to<br>
get messaged, potentially resulting in thousands of such messages.</blockquote><div><br>In this example, the site owner is at fault because they should have ensured that their widget-hosting page was not frameable by the hostile site. So it doesn't show a weakness in the model.<br>

<br>So far in this discussion, we have a shortage of examples where a gadget has to be widely embeddable, and it has to have UI that triggers privileged operations, and those operations have to enable harmful consequences to agents other than the embeddor, and opening a new window or tab to confirm those operations is unreasonable. These are the examples that demand elaborate "option 3" measures. Since the claim is that these examples are common, I'd like to know more about them.<br>

<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><div>
> > Secondly, consider Google Image Search, or Reddit with its "open link<br>
> > with reddit toolbar" option, or any other site that allows arbitrary<br>
> > Web navigation in a frame or iframe while hosting some sort of toolbar<br>
> > content from its own page in another frame or container page. This<br>
> > option would mean that many sites would stop working with these<br>
> > containers, despite these containers not doing anything evil (there's<br>
> > no overlapping content, the user is fully aware of what's going on,<br>
> > etc).<br>
><br>
> If I understand correctly, with Michal's option 3, those sites would<br>
> also stop working as soon as the user scrolled down in the framed page<br>
> (so that the top-left of the framed page is out of view).<br>
<br>
</div>Any solution that breaks those sites is a non-starter IMHO.<br>
<div><div></div></div></blockquote><div> </div></div>Apparently "option 3" doesn't break them, although I have some questions about that.<br><br>But it seems strange to say that breaking such sites is a "non-starter". Suppose a major browser added support for universal Origin headers and Access Controls and some kind of "Requires-Access-Controls" server header. If I run a site and I care about security and I don't care about being framed in Google Image Search or these other framing sites (assuming they don't drive much traffic to my site, or at least the parts of my site I want to protect) --- why shouldn't I welcome these measures and deploy them?<br>
<br>Are you saying it would be irresponsible of browser vendors to support such features, because it would allow selfish behaviour of some sites to disrupt services provided by third parties?<br><br>Rob<br>-- <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>