- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Fri, 28 Aug 2015 08:07:00 +0200
- To: Brad Hill <hillbrad@gmail.com>, Kepeng Li <kepeng.lkp@alibaba-inc.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On 2015-08-27 20:10, Brad Hill wrote: > Almost all popular plugins have their own, proprietary, interpretation > of what the "same origin policy" means for them. Flash, Java and Silverlight > all have special rules about requesting policy files and enabling SOP bypasses > based on them, treating the host from which they are loaded as part of their > origin vs. operating under the origin into which they are loaded, loading > additional code, creating new child browsing or execution contexts, etc. > > Basically this means it's impossible to reason about the security properties > of what allowing a plugin in a sandbox actually means, and most plugins can > scape the sandbox, so there is no practical value to such a directive. > We could imagine a well-behaved plugin that respects the Same Origin Policy > and doesn't allow sandbox escapes, but that's not what we actually have in the > world. So there is very little value in doing the work to specify or engineer > this, especially as traditional plugins are being deprecated in growing number > of user agent implementations. Totally agree. However, it seems that the browser vendors are slowly but surely drifting towards a replacement known as Chrome Native Messaging [1] which [unintentionally] introduces a new core Web API: https://github.com/cyberphone/web2native-bridge#api This has recently passed beyond the point of theory: https://chrome.google.com/webstore/detail/web2native-bridge-emulato/jphfmfbdedghfhhjijaogeloiehomfni -Anders 1] https://lists.w3.org/Archives/Public/public-webappsec/2015Aug/0116.html > > -Brad
Received on Friday, 28 August 2015 06:07:35 UTC