- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 31 Aug 2010 17:03:16 -0700
2010/8/31 Kornel Lesi?ski <kornel at geekhood.net>: > On 31.08.2010, at 23:39, Tab Atkins Jr. wrote: >>>>> At least as currently drafted, srcdoc is not a security feature. It's a >>>>> convenience feature. It is also designed to work well in tandem with a >>>>> particular security feature (sandbox). But by itself, it is not a security >>>>> feature. >>>> >>>> Data URLs already provide this. >>> >>> What about existing UAs that implement data: URIs, but not sandbox? >> >> What about them? >> >> (Remember, the context of the "use data urls" suggestion was to solve >> the minority use-case of wanting to fill an <iframe> without a network >> request, without triggering sandboxing.) > > Yes, it's OK for data without sandboxing. Ok. > However, "inline data without sandboxing" does not cover all use cases of srcdoc. It covers very few use-cases, actually. @srcdoc is meant to address the case of "inline data *with* sandboxing". > There's another use case of "inline data _with_ sandboxing and fallback for HTML4 UAs", for which data: URI currently cannot provide. Indeed; that's what @srcdoc is for. Could you be clearer about what point you're trying to make? What use-case are you trying to address that you think the suggestion in this thread (make @srcdoc imply @sandbox) is incompatible with? At the moment it appears that you're confused about the goal of the change I'm suggesting, but I could just be missing something. ~TJ
Received on Tuesday, 31 August 2010 17:03:16 UTC