- From: Adam Barth <w3c@adambarth.com>
- Date: Fri, 4 Jun 2010 11:47:56 -0700
- To: Artur Adib <arturadib@gmail.com>
- Cc: robert@ocallahan.org, public-html@w3.org, Leonard Rosenthol <lrosenth@adobe.com>, Ian Hickson <ian@hixie.ch>
On Fri, Jun 4, 2010 at 10:50 AM, Artur Adib <arturadib@gmail.com> wrote: > On Fri, Jun 4, 2010 at 1:00 PM, Adam Barth <w3c@adambarth.com> wrote: >> In a year or two, you'll have the same problems you have >> today, except that all these sites will be using Flash to framebust >> rather than JavaScript. > > Not if plugin @sandbox compliance gets there first. > > All I am suggesting is to do things in parallel rather than serially: > introduce the 'allow-plugins' option in tandem with ongoing plugin > compliance, rather than "plugin compliance first, allow-plugins > later". When we eventually add allow-plugins, we'll want some way for the plug-in to signal the user agent that it understands the sandbox security model. We could add the directive now, but because no plug-ins give the user agent that signal today, the directive wouldn't have any effect. I'm glad that you're excited about this feature. I'm sorry it doesn't quite handle your use case yet... Adam > For the reasons I outlined, in the short-term this is *very* useful > for products such as ours. The assumption is that plugin compliance > will catch up sooner than (hypothetical) exploits become pervasive; > as Julian pointed out, the ball has been set in motion in that > direction. If it doesn't (for some bizarre reason), authors can > simply avoid using the option. (In that case, it probably means > plugin makers have gone bankrupt, so the option can be safely set to > 'deprecated'). > > Additionally, neither of us seems to know for sure if Flash has access > to top.location... If it turns out it doesn't, then your example is > not an issue at all. > > -Artur >
Received on Friday, 4 June 2010 18:48:54 UTC