- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 2 Jun 2014 15:21:09 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: WHATWG <whatwg@lists.whatwg.org>
On Mon, Jun 2, 2014 at 6:03 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 6/2/14, 9:00 AM, Anne van Kesteren wrote: >> >> You're not persuaded by the attack scenario? > > Correct. I mean, the same scenario applies to srcdoc, document.write() into > an iframe, etc. Why are data urls special? srcdoc is like eval(). Yes, it's definitely a tool that enables you to run 3rd party code in your own context and with your own principal. However whenever you use the feature you (should) know that it's running code in your own context and with your own principal. So hopefully pages will make sure to not pass untrusted 3rd party code to neither srcdoc nor eval(). We've seen this happen internally in Gecko where chrome code will get XSSed by being tricked to load data URLs. And I've been trying to move us towards only allowing data: to run with a chrome principal if chrome code explicitly opts in to that. I don't see why websites wouldn't face the same challenges and why the same solution wouldn't work there. / Jonas
Received on Monday, 2 June 2014 22:22:05 UTC