<div dir="ltr">On Fri, Sep 26, 2008 at 12:27 PM, 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;">
<div class="Ih2E3d">On Fri, 26 Sep 2008, Robert O'Callahan wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Seems like this will create a really bad user experience. The user scrolling around in the outer document will make IFRAMEs in it mysteriously become enabled or disabled.<br>
</blockquote>
<br></div>
Well, to put this in perspective - we are talking about cross-domain IFRAMEs only, and only a short security timeout; </blockquote><div><br>The timeout only applies after the "obstruction" is removed, right? Until then everything is disabled. So as long as the top-left corner of the IFRAME's viewport is not visible, e.g. because it's scrolled out of view in the top-level document, the IFRAME must remain disabled.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">we could also quite conceivably make an exception for cases where a frame is scrolled into view as a result of the user interacting with the scroll bar, as opposed to page scripts (some optimizations of this type are already mentioned in the proposal).</blockquote>
<div><br>Sure, but each such extension add complexity for implementors, authors and users. Making the disabling happen less often in this way makes it all the more mysterious when it does happen.<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;">
 As noted, my greatest concern is having us pick an easy way out that essentially delegates all responsibility for compensating for an arguably broken design to web applications (as is the case with most of the opt-in solutions) - web developers already face a remarkable burden here, and tend to fail way too often - or devising a fix that cripples some less obvious but common uses (such as gadgets / mashups, or IFRAMEd advertisements).<br>

</blockquote><div> </div></div>Indeed.<br><br>IMHO the basic problem here is allowing IFRAMEs to be cross-origin by default. That causes many problems, some of which you know well, and others you probably don't (e.g. <a href="http://lists.w3.org/Archives/Public/www-svg/2008Sep/0112.html">http://lists.w3.org/Archives/Public/www-svg/2008Sep/0112.html</a> ). In fact, in an ideal world, I think we'd default to same-origin restrictions on everything --- IFRAMEs, images, scripts, etc --- and use a spec like Access Controls to let sites opt-in to allowing their resources to be loaded from specific other origins.<br>
<br>In the real world, we can't do that, but I kinda like option 1 because it (sort of) lets sites opt into that ideal world. (And I'm pushing for all new kinds of resource loads, such as fonts and external SVG "resource documents", to use that approach.)<br>
<br clear="all">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>