- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 16 Jul 2010 03:24:30 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, HTMLWG WG <public-html@w3.org>, Sam Ruby <rubys@intertwingly.net>
On Jul 16, 2010, at 1:03 AM, Julian Reschke wrote: > On 15.07.2010 20:08, Tab Atkins Jr. wrote: >> ... >> ### Summary ### >> >> Most of the objections listed in the Change Proposal were completely >> irrelevant to the actual issue. They are concerns with the sandbox >> security model itself. @srcdoc is merely a convenient way to opt-in >> to the sandbox security model without incurring a network request each >> time. >> ... > > I disagree these are irrelevant. > > @srcdoc, for the first time, introduces HTML markup into attribute values. This is bad design. > > It's perfectly ok to argue that sandboxed iframes will not be as useful as advertised, and thus the most outrageous ugliness in the markup should go, while the remainder of the mechanism could stay. > > See also <http://lists.w3.org/Archives/Public/public-html/2010Apr/0393.html> (oh my, three months gone, no real progress - hopefully now). I think it would be interesting to hear from implementors whether they are interested in implementing this feature, and from Web developers whether they are interested in using sandboxed iframes in general, or sandboxing combined with srcdoc in particular. Note: @sandbox is implemented in WebKit and is currently shipping in Chrome and Safari. @srcdoc is not currently implemented. I do not know what the WebKit community's security experts think about @srcdoc. Regards, Maciej
Received on Friday, 16 July 2010 10:25:04 UTC