- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 21 Jan 2010 02:14:19 +0000 (UTC)
- To: "sird@rckc.at" <sird@rckc.at>
- Cc: Adam Barth <w3c@adambarth.com>, public-web-security@w3.org
On Wed, 20 Jan 2010, sird@rckc.at wrote: > > Hmm, I agree with Adam Barth, bad developers <exist> in the world, and > stupid filters that are surviving exist as well.. anyway I think that > data: URIs should be on several blacklists already.. since they are > vulnerable already on FF. Black-list based filters are already vulnerable. Any attack intending to break a black-list based filter is almost guaranteed to eventually find a way, on some browser, to attack a user. I just don't think it's a useful use of our time to try to defend against these cases. > And on another subject, > > data:text/sandboxed-html,<USER DATA> > > would be an awesome way to sandbox content inline, almost without the > need of the sandbox="" element, but I would like to ask to reconsider to > add a new argument for sandboxed content, to avoid old browsers from > popping a download dialog: > > <iframe sandbox-src=""> > > Wouldn't that solve that specific issue? If you're using text/sandboxed-html, you're not targetting legacy UAs, so I don't really think that's a problem we need to worry about. > This way you also give a failsafe in case the UA doesn't support it > > <iframe sandbox-src="usercontent.php?id=1331" > src="error-nosandbox.html"/> You can already do that with scripted feature testing. If an author is not going to support legacy UAs, though, I'd recommend redirecting legacy UAs long before they are exposed to the sandboxed iframes. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 21 January 2010 02:14:49 UTC