- From: Brian Smith <brian@briansmith.org>
- Date: Sun, 3 Aug 2014 20:24:05 -0700
- To: Daniel Veditz <dveditz@mozilla.com>
- Cc: Philip S Constantinou <pconstantinou@evernote.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Mike West <mkwst@google.com>, Adam Barth <w3c@adambarth.com>
On Thu, Jul 31, 2014 at 8:32 PM, Daniel Veditz <dveditz@mozilla.com> wrote: > On 7/31/2014 6:24 PM, Philip S Constantinou wrote: >> Evernote voices our strong opposition to the wording changes regarding >> extensions and bookmarklets in CSP1.1 and our strong support of >> http://lists.w3.org/Archives/Public/public-webappsec/2014Jul/0061.html. > >> To create a great >> user experience, our extensions insert JavaScript into the viewers page >> upon user request. This mechanism risks being broken by the vague >> extension/bookmarklet wording change proposed in CSP 1.1. Philip, Why does your extension inject <script> tags into pages, instead of doing things other ways that are likely to be much more secure and which are not blocked by CSP? Is it the case that web browser makers have made it unclear how to get the equivalent functionality working in extensions without injecting <script>? Are there limitations in the extension APIs such that <script> is more powerful? If so, browser makers may be unaware of those deficiencies. It would be great if you could share what prevents you from switching to the alternative mechanisms that browser extension mechanisms provide. I think it is likely that those deficiencies could be corrected much faster than anybody could make injected <script> work the way you are expecting. I think it would be a good idea for representatives of the various browsers to share links to the their extension API documentation that show how one can convert an extension from the non-CSP-compatible injected-<script> approach to the recommended/supported/working approach. Cheers, Brian
Received on Monday, 4 August 2014 03:24:31 UTC