Upgrade to 69 made our extension unable to load
Reported by
ofekshi...@gmail.com,
Sep 5
|
|||||||
Issue description
Chrome Version : 69.0.3497.81
What steps will reproduce the problem?
(1) Build any toy extension, in its manifest.json include:
...
"background": {
"persistent": true,
"scripts": ["background.js"]
},
...
"content_security_policy": "script-src 'none';
...
(2) Add the extension to chrome 68. Everything runs fine
(3) Add the extension to chrome 69. Open the extension's background page.
What is the expected result?
The extension was able to load and run.
What happens instead?
On chrome *69 only*, the extension fails to load and console at the background page shows (with my particular ext id):
Refused to load the script 'chrome-extension://gpdhifpjckmgifbagfkfbkghcpphopce/background.js' because it violates the following Content Security Policy directive: "script-src 'none'".
'none':1 Failed to load resource: net::ERR_FILE_NOT_FOUND
,
Sep 5
,
Sep 5
,
Sep 6
Thank you for taking this seriously. Can we expect a chrome 69 update with a fix? Approximately when?
,
Sep 6
,
Sep 6
Reporter, there's no guarantee the fix makes it into 69 because the stable channel gets updates quite rarely and only for critical stuff (like crashes, security, etc.) that affects lots of people. Can you modify your extension's CSP? There should be no need for such a restrictive rule. If you want to run some third-party code in the extension page context, you should do it in a sandboxed page/iframe instead, see http://developer.chrome.com/extensions/sandbox
,
Sep 6
@woxxom, our extension is installed on >1M endpoints, many of which have little or no www access (installations not via the chrome store), and with quite a few extension versions to patch. Currently every endpoint that upgrades to 69 breaks our product, due to this chrome regression. So while we can work around this regression we'll have a hard time distributing it in a timely manner. And paying customers continuously lose functionality due to this bug. We respectfully urge you to reconsider and issue a chrome fix.
,
Sep 6
,
Sep 6
This seems to be working as intended. `script-src 'none'` means *no* script should be allowed to execute on the page, including the script from the page itself. `script-src 'self'` allows scripts from the same origin to be loaded, and no others. You could also add specific scripts, like chrome-extension://<id>/script.js. Prior to revision 38d9d19a09dd6d90ab023d4d83e7bf6bc9d5731f, there was a bug where CSP rules were being (incorrectly) ignored. It seems like the right fix here would be to specify script-src 'self' or script-src <your scripts> in the CSP of the extension. Will that work, or is there something I'm missing? Removing ReleaseBlock-Stable for now.
,
Sep 6
As Devlin stated, the right fix is to update the CSP.
,
Sep 8
A solid case could be made that since an extension is pure script there is no meaning to script-src 'none' for an extension and chrome should special case 'none' when used in this context. More importantly, it seems clear that setting this behaviour was never the intended goal for this commit and it is a side effect of some other change. Please consider that backward-compatibility and avoiding breaking customer code in the field might take priority here. As noted above, deploying the suggested extension fix (more like a workaround) involves patching multiple extension versions and deploying to private stores, and is far from straightforward for us.
,
Sep 8
>A solid case could be made that since an extension is pure script I guess you meant "an extension's background script is pure script" but it's an incorrect assumption. The background page of an extension is neither a DOM-less WebWorker nor an abstract "something that runs scripts", it's a standard DOM page and it's always constructed even if you use the modern syntax with just "scripts" inside manifest.json's "background" section instead of "pages" or the ancient "background_page". That's how extensions always worked since the background pages were introduced in the extension API. If you examine such autogenerated background page in devtools you'll see it is standard DOM with the <script> elements pointing to the scripts listed in manifest.json. >More importantly, it seems clear that setting this behaviour was never the intended goal for this commit and it is a side effect of some other change. Your extension relied on a bug in the browser's handling of CSP for extensions, and the bug was accidentally fixed by this commit.
,
Sep 8
This is an unintended, breaking change, in a non-standardized area where the right thing to do is debatable. Many other vendors are known to prioritize keeping cusomers' existing code working in such cases. It would be disappointing if google elected otherwise.
,
Sep 8
> non-standardized area where the right thing to do is debatable What is this "non-standardized area"? Do you mean the fact that the background pages are standard DOM pages? If so, I can agree the documentation is vague and it probably became even more vague after the last simplification.
,
Sep 8
As woxxom@ points out, background pages are implemented as standard DOM pages, and CSP should be applied to them in the manner described in the CSP spec. According to that spec, script-src 'none' will prevent any script from executing. Out of curiosity, what was the intended effect of including script-src 'none', or what would the expected behavior have been?
,
Sep 8
The intention was of course that no other script would be able to run. That worked for many versions. בתאריך שבת, 8 בספט׳ 2018, 17:48, מאת rdevlin.… via monorail < monorail+v2.1119303457@chromium.org>:
,
Sep 8
Per the CSP spec, if you want to allow the origin to run but no external scripts, you should specify 'self', rather than 'none'. Updating your extension to do that should fix the issue. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by woxxom@gmail.com
, Sep 5513 bytes
513 bytes Download