<br><br><div class="gmail_quote">On Thu, Mar 22, 2012 at 9:21 PM, Adam Barth <span dir="ltr"><<a href="mailto:abarth@webkit.org">abarth@webkit.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I wonder if we could expose the parent document's origin, so you could<br>
write the check as follows:<br>
<br>
if (parent.location.origin != location.origin)<br>
    return;<br>
<br>
It's slightly subtle because we wouldn't want to expose the origin of<br>
child frames (then you could probe the redirect structure of private<br>
networks), but exposing ancestor origins seems tenable.<br></blockquote><div><br></div><div>Let's suppose I have some unannounced product like <a href="http://unannounced.google.com">unannounced.google.com</a> and say it embeds an iframe.</div>

<div><br></div><div>Isn't it a information disclosure issue that anyone can now detect the usage of <a href="http://unannounced.google.com">unannounced.google.com</a> when they are framed (especially if "unannounced" were more descriptive)?</div>

<div><br></div><div>dave </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Adam<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Thu, Mar 22, 2012 at 9:16 PM, David Levin <<a href="mailto:levin@chromium.org">levin@chromium.org</a>> wrote:<br>
> Suppose I am using a framework does window.frameElement for various<br>
> reasons. When that framework is used in an iframe, it causes errors to<br>
> appear in the console.<br>
><br>
> For example, suppose the framework does this:<br>
><br>
> var a;<br>
> try {<br>
>     a = window.frameElement; // WebKit outputs a console error here.<br>
>     if (!a)<br>
>         return;<br>
> } catch (e) {<br>
>     return;<br>
> }<br>
> ...<br>
><br>
><br>
> Now if I had this new method, I would change the framework to do this:<br>
><br>
> var a;<br>
> try {<br>
>     // WebKit doesn't throw an exception for x-origin parent access, but it<br>
> will puts errors in the console.<br>
>     // Do an explicit access check to avoid having the error appear in the<br>
> console.<br>
>     var canAccessParent = window.parent.webkitCanAccess;<br>
>     if (canAccessParent != undefined && !canAccessParent)<br>
>         return;<br>
>     a = window.frameElement;<br>
>     if (!a)<br>
>         return;<br>
> } catch (e) {<br>
>     return;<br>
> }<br>
> ...<br>
><br>
><br>
> Does that help? (The use case is about avoiding spurious console error<br>
> messages, so console error messages are real errors.)<br>
><br>
> dave<br>
><br>
><br>
> On Thu, Mar 22, 2012 at 8:44 PM, Sam Weinig <<a href="mailto:weinig@apple.com">weinig@apple.com</a>> wrote:<br>
>><br>
>> Hey Dave,<br>
>><br>
>> Can you describe the use case for this new property?  When would an author<br>
>> use it?<br>
>><br>
>> -Sam<br>
>><br>
>> On Mar 22, 2012, at 4:16 PM, David Levin <<a href="mailto:levin@chromium.org">levin@chromium.org</a>> wrote:<br>
>><br>
>> Resurrecting a really old thread so continue the conversation now that I'm<br>
>> hitting this issue :).<br>
>><br>
>> On Mon, Aug 16, 2010 at 2:16 PM, Sam Weinig <<a href="mailto:sam.weinig@gmail.com">sam.weinig@gmail.com</a>> wrote:<br>
>>><br>
>>> I am not sure I agree.  Does our behavior actually cause any real bugs in<br>
>>> the places you have tracked down?  The log spam really doesn't seem like an<br>
>>> issue, we can remove it if we want to, but have found it useful in the<br>
>>> past.<br>
>><br>
>><br>
>> Speaking as someone who working on a web app, the log spam is<br>
>> a significant issue because:<br>
>><br>
>> It clutters up the console output making it harder to find the real error.<br>
>> (It is hard to explain how much worse this makes the experience until you<br>
>> have to deal with a sophisticated web page. Image looking at the logs from<br>
>> your app and seeing lots of error messages -- many of which are this one and<br>
>> then a real one hidden among them -- from personal experience.)<br>
>> When more sophisticated end users see it, they think there is a problem in<br>
>> the app and report it (and it could be that they include this in their error<br>
>> report and ignore other more important things).<br>
>><br>
>> I understand that that the console/log spam is useful to detect real<br>
>> issues as well (given that WebKit doesn't throw an exception in this case).<br>
>><br>
>> Would people find it acceptable to have window.webkitCanAccess so that a<br>
>> web page can use that property first to detect the cross origin issue and<br>
>> avoid doing an access which would trigger the console spam? (I would also be<br>
>> fine with an exception instead of log spam.)<br>
>><br>
>> Thanks,<br>
>> dave<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> webkit-dev mailing list<br>
>> <a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
>> <a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
>><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> webkit-dev mailing list<br>
> <a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
> <a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
><br>
</div></div></blockquote></div><br>