W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: <iframe doc="">

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Sun, 24 Jan 2010 14:16:21 -0600
Message-ID: <dd0fbad1001241216w3e050918t1bcd0213fb91ce74@mail.gmail.com>
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: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?

Received on Sunday, 24 January 2010 20:17:09 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:57 UTC