- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Sun, 24 Jan 2010 14:20:30 -0600
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Shelley Powers <shelley.just@gmail.com>, Ian Hickson <ian@hixie.ch>, "public-html@w3.org WG" <public-html@w3.org>
On Sun, Jan 24, 2010 at 2:16 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > On Sun, Jan 24, 2010 at 2:06 PM, Julian Reschke <julian.reschke@gmx.de> wrote: >> Tab Atkins Jr. wrote: >>> >>> ... >>> If I had to write it by hand, of course I wouldn't be happy. That's >>> not what it's for. If I'm writing it by hand I can skip the <iframes> >>> entirely, because I know what I'm writing and thus don't need to >>> protect myself against myself. This sort of stuff is meant to be >>> generated by code, like this: >>> ... >> >> Indeed. >> >> And that code could also produce properly escaped data URIs. >> >> Can we please try harder to avoid introducing another attribute, and fix the >> problem we have with data URIs instead? > > I'm not certain what the security implications are of missing certain > parts of a data URI's more complex escaping. Are there any surprising > ones? Or do the standard url-escaping functions built into basically > all programming languages cover it completely? > > The main problem with data URIs, as I understand it, is that they are > defined to have a unique origin, regardless of @sandbox directives. > *Is* this something that can be easily changed? What are the > implications of doing so? I forgot the additional problem with data: urls. Several implementations support them now, but don't support @sandbox. If you tried to use a data URL with @sandbox, then, it would "fail open" in these browsers; that is, it would display the content without any sandboxing. @srcdoc, on the other hand, will "fail closed" - legacy browsers will just ignore the attribute entirely. Would using the text/sandboxed-html mime type in data urls have any effect on this? ~TJ
Received on Sunday, 24 January 2010 20:21:18 UTC