W3C home > Mailing lists > Public > public-webappsec@w3.org > August 2015

Re: CSP Plugin

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>
Message-ID: <55DFFA84.6090805@gmail.com>
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:


This has recently passed beyond the point of theory:



1] https://lists.w3.org/Archives/Public/public-webappsec/2015Aug/0116.html

> -Brad
Received on Friday, 28 August 2015 06:07:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:50 UTC