Re: <iframe doc="">

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