I'm more interested in avoiding breakage in gadgets that read window.opener. Writing to window.opener is an obscene hack, we shouldn't support gadgets that do that kind of crazy stuff. =)
(BTW - have I mentioned that you might be the first person in history to say "It's secure because it uses VBScript"?) Let me see if I understand where we're at on this... - We think we have an authentication protocol that works, based on the notion that window.opener is a same-origin prototected write-only property similar to document.location. We don't have proof that window.opener is being protected by the same-origin policy, but it seems like a reasonable assumption given the tests we've performed. - We are aware of problems involving leaking javascript context across domains. We're dealing with those problems using VBScript wrappers on the assumption that VBScript does not support reflection. (Why do we believe that, by the way? Mike Samuel pointed out that VBScript descends from COM, which was all about reflection...) - We're prepared to build applications that rely on this change, and then break those applications if someone discovers that window.opener is not as secure as we'd hoped. Cheers, Brian On Thu, Jul 24, 2008 at 5:57 PM, John Hjelmstad <[EMAIL PROTECTED]> wrote: > No, mostly beacuse there's no legitimate use for setting window.opener in IE > when rendering a gadget IFRAME at this point, as far as I know. > > That said, the library could be used pretty directly (or adapted to do the > same), so I'd be happy to add it if you think it's important. > > John > > On Thu, Jul 24, 2008 at 5:54 PM, Brian Eaton <[EMAIL PROTECTED]> wrote: > >> Quick functionality check: does this restore window.opener to it's >> original value after working it's evil magic? >> >> On Thu, Jul 24, 2008 at 4:44 PM, John Hjelmstad <[EMAIL PROTECTED]> wrote: >> > All, >> > >> > As commented in http://issues.apache.org/jira/browse/SHINDIG-416, to the >> > best of my knowledge all security concerns with the IE >> window.opener-based >> > technique have been resolved. The patch works and is very fast, >> significant >> > benefits atop which we can build lots of cool functionality IMHO. As >> such, >> > I'm inclined to commit this patch. >> > >> > But I want to tread very cautiously, so I'm putting out a call for >> dissent. >> > Does anyone object to committing this? Are there any specific security >> > concerns or unaccounted-for attack vectors? >> > >> > Thanks, >> > John >> > >> >
