<object> has .contentDocument and maybe .getSVGDocument. <embed> has getSVGDocument. We should probably either add security checks in all these methods or auto-wrap these nodes in XOW.

It occurred to me that we probably already do through the magical code in xpcconvert.cpp. If so, can we just close this?

If we do, then yes. That should be mochitestable, right?

Yeah, although currently XOWs do a lot of work to be entirely invisible from JS. The only XOW-specific test I can come up with right now is to test if cross-origin |getSVGDocument().createAttribute.__parent__ === window| i.e., all functions that come off of the cross-origin object actually appear to be from the calling code's scope.

I was more thinking test that the right security checks happen. If we don't hand back an XOW, they won't, right?

CC'ing moz_bug_r_a4 to see if he can turn this into an XSS flaw (or worse). Inspired by bug 455472

Not blocking on this as we think this is a non-issue as far as the code goes, right?

Is commnt 1 referring to this part: 1248 // Reaching across scopes from content code. Wrap 1249 // the new object in a XOW. 1250 jsval v = OBJECT_TO_JSVAL(flat); 1251 XPCJSObjectHolder *objHolder = nsnull; 1252 if (!XPC_XOW_WrapObject(ccx, scope, &v) || 1253 !(objHolder = 1254 XPCJSObjectHolder::newHolder(ccx, 1255 JSVAL_TO_OBJECT(v)))) ? If so I agree that it looks like the code is a non-issue. I do think we should block on blake confirming that...

Setting low severity per comment 7.

This mochitest proves that there's no security bug here.

Comment on attachment 353729 [details] [diff] [review] Mochitest Excellent. Thanks for writing this up!

http://hg.mozilla.org/mozilla-central/rev/202d8f3d8439 - Marking "fixed" though there wasn't a bug here to begin with.

not a security exploit per comment 9, keeping hidden until bug 455472 is unhidden.