- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 21 Mar 2014 09:22:24 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Ian Hickson <ian@hixie.ch>, Arun Ranganathan <arun@mozilla.com>, Travis Leithead <travis.leithead@microsoft.com>, public-webapps <public-webapps@w3.org>, Adam Barth <w3c@adambarth.com>, Paul Irish <paul.irish@gmail.com>
On Fri, Mar 21, 2014 at 6:57 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Fri, Mar 21, 2014 at 1:34 AM, Jonas Sicking <jonas@sicking.cc> wrote: >> We could. Would love to see proposals for that. Right now the >> specification for origin handling is fiction and as far as I know >> there is no proposal that all involved parties agree to. An important >> question is if we can fix data:'s origin handling, without making it >> complicated enough that we don't want to use it for anything else. > > I wish I was more familiar with the problems you are alluding too. I > can definitely see how you do not want to simply load data URLs you > did not create yourself in any context. But e.g. loading a (random) > data URL in <img> and then drawing it on <canvas> and analyzing the > data is fine. Putting a (random) data URL in <iframe> is asking for > trouble, Exactly. Same thing with `new Worker(dataurl)` > but putting a trusted one there is fine and not different > from <iframe srcdoc>. srcdoc is more similar to eval(). I.e. it would always be foolish to take an unchecked string from an untrusted 3rd party and stick it in srcdoc. The contents of the <iframe srcdoc>/eval() always executes in your security context so it shouldn't be a surprise when it happens. On the other hand, <iframe sandbox srcdoc> is always safe and never executes in your security context. The situation with <iframe src="..."> is much more complex, which is why it's easier to make mistakes. / Jonas
Received on Friday, 21 March 2014 16:23:22 UTC