That's a risk, but you could also worry that the name would leak in the iframe's document.referrer property.
Adam On Mar 23, 2012 12:02 PM, "David Levin" <[email protected]> wrote: > > > On Thu, Mar 22, 2012 at 9:21 PM, Adam Barth <[email protected]> wrote: > >> I wonder if we could expose the parent document's origin, so you could >> write the check as follows: >> >> if (parent.location.origin != location.origin) >> return; >> >> It's slightly subtle because we wouldn't want to expose the origin of >> child frames (then you could probe the redirect structure of private >> networks), but exposing ancestor origins seems tenable. >> > > Let's suppose I have some unannounced product like unannounced.google.comand > say it embeds an iframe. > > Isn't it a information disclosure issue that anyone can now detect the > usage of unannounced.google.com when they are framed (especially if > "unannounced" were more descriptive)? > > dave > >> >> Adam >> >> >> On Thu, Mar 22, 2012 at 9:16 PM, David Levin <[email protected]> wrote: >> > Suppose I am using a framework does window.frameElement for various >> > reasons. When that framework is used in an iframe, it causes errors to >> > appear in the console. >> > >> > For example, suppose the framework does this: >> > >> > var a; >> > try { >> > a = window.frameElement; // WebKit outputs a console error here. >> > if (!a) >> > return; >> > } catch (e) { >> > return; >> > } >> > ... >> > >> > >> > Now if I had this new method, I would change the framework to do this: >> > >> > var a; >> > try { >> > // WebKit doesn't throw an exception for x-origin parent access, >> but it >> > will puts errors in the console. >> > // Do an explicit access check to avoid having the error appear in >> the >> > console. >> > var canAccessParent = window.parent.webkitCanAccess; >> > if (canAccessParent != undefined && !canAccessParent) >> > return; >> > a = window.frameElement; >> > if (!a) >> > return; >> > } catch (e) { >> > return; >> > } >> > ... >> > >> > >> > Does that help? (The use case is about avoiding spurious console error >> > messages, so console error messages are real errors.) >> > >> > dave >> > >> > >> > On Thu, Mar 22, 2012 at 8:44 PM, Sam Weinig <[email protected]> wrote: >> >> >> >> Hey Dave, >> >> >> >> Can you describe the use case for this new property? When would an >> author >> >> use it? >> >> >> >> -Sam >> >> >> >> On Mar 22, 2012, at 4:16 PM, David Levin <[email protected]> wrote: >> >> >> >> Resurrecting a really old thread so continue the conversation now that >> I'm >> >> hitting this issue :). >> >> >> >> On Mon, Aug 16, 2010 at 2:16 PM, Sam Weinig <[email protected]> >> wrote: >> >>> >> >>> I am not sure I agree. Does our behavior actually cause any real >> bugs in >> >>> the places you have tracked down? The log spam really doesn't seem >> like an >> >>> issue, we can remove it if we want to, but have found it useful in the >> >>> past. >> >> >> >> >> >> Speaking as someone who working on a web app, the log spam is >> >> a significant issue because: >> >> >> >> It clutters up the console output making it harder to find the real >> error. >> >> (It is hard to explain how much worse this makes the experience until >> you >> >> have to deal with a sophisticated web page. Image looking at the logs >> from >> >> your app and seeing lots of error messages -- many of which are this >> one and >> >> then a real one hidden among them -- from personal experience.) >> >> When more sophisticated end users see it, they think there is a >> problem in >> >> the app and report it (and it could be that they include this in their >> error >> >> report and ignore other more important things). >> >> >> >> I understand that that the console/log spam is useful to detect real >> >> issues as well (given that WebKit doesn't throw an exception in this >> case). >> >> >> >> Would people find it acceptable to have window.webkitCanAccess so that >> a >> >> web page can use that property first to detect the cross origin issue >> and >> >> avoid doing an access which would trigger the console spam? (I would >> also be >> >> fine with an exception instead of log spam.) >> >> >> >> Thanks, >> >> dave >> >> >> >> >> >> >> >> _______________________________________________ >> >> webkit-dev mailing list >> >> [email protected] >> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> >> >> >> > >> > >> > _______________________________________________ >> > webkit-dev mailing list >> > [email protected] >> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > >> > >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
