- From: Leonard Rosenthol <lrosenth@adobe.com>
- Date: Tue, 26 Jan 2010 08:58:05 -0800
- To: Adam Barth <w3c@adambarth.com>
- CC: Maciej Stachowiak <mjs@apple.com>, "public-html@w3.org" <public-html@w3.org>
I completely understand why, today, plugins are an easy scapegoat for what is clearly a larger issue concerning preventing unexpected behavior in a "sandboxed" environment. However, you seem to be missing my point. That the issue is _NOT_ plugins - the issue is the content involved - regardless of where it comes from. How many emails you have to send is a specious argument. We're talking the proper implementation of a technology.... Leonard -----Original Message----- From: Adam Barth [mailto:w3c@adambarth.com] Sent: Monday, January 25, 2010 11:22 PM To: Leonard Rosenthol Cc: Maciej Stachowiak; public-html@w3.org Subject: Re: What defines a "plugin"? WRT sandboxing? On Mon, Jan 25, 2010 at 9:24 PM, Leonard Rosenthol <lrosenth@adobe.com> wrote: > What exactly are we trying to prevent? We're trying to prevent malicious content from leveraging plug-ins to escape the security restrictions imposed by @sandbox. Presently, there exist a great many plug-ins that do not understand the sandbox security model and therefore would allow sandboxed content to circumvent the restrictions of the sandbox. Therefore, the only safe course of action is to prevent sandboxed content from interacting with these plug-ins. To answer your specific question, if Safari allowed sandboxed content to instantiate a QuickTime <video> that circumvented the sandbox security model, I would email security@apple.com and they would issue a patch to fix the vulnerability. If Safari allowed sandboxed content to instantiate a Gears <object> that circumvented the sandbox security model, I can either email security@apple.com or security@google.com. If I email security@apple.com, there's not much they can do except prevent the content from instantiating Gears. If I email security@google.com, there is not much they can do short of preventing Gears from being used by all content. Instead of waiting for the vulnerability to be reported in a shipping product, we're fixing the vulnerability in the specification by doing what security@apple.com would have to do anyway. Adam
Received on Tuesday, 26 January 2010 16:58:55 UTC