Remotely-hosted code

3,258 views
Skip to first unread message

Chrome Developer

unread,
Feb 13, 2019, 11:59:23 AM2/13/19
to Chromium Extensions
Can anybody explain what extactly means: 

Beginning in Manifest V3, we will disallow extensions from using remotely-hosted code.  This will require that all code executed by the extension be present in the extension’s package uploaded to the webstore.  Server communication (potentially changing extension behavior) will still be allowed.

For example, I have request to server that return json file.
I want to use some data from the file to use with chrome.tabs.executeScript. Is it still available in Manifest V3?

What kind of files I can use from server: txt, json, css ?
What kind I can NOT use: js?

PhistucK

unread,
Feb 13, 2019, 1:07:12 PM2/13/19
to Chrome Developer, Chromium Extensions
I reckon it is anything that must be run using eval (or the code field of executeScript). JavaScript code. JSON is not executable, it is just data which can be parsed with JSON.parse.

PhistucK


--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.
Visit this group at https://groups.google.com/a/chromium.org/group/chromium-extensions/.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/deb5dbd0-5952-4e4a-868d-8bc917c163e0%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

Darren Govoni

unread,
Feb 13, 2019, 1:13:41 PM2/13/19
to PhistucK, Chrome Developer, Chromium-extensions
I'm pretty certain it's more than that. An extension can open a popup that itself loads code like a webpage because that's what in fact it is. Those <script> tags in the popup menu (extension) are expected to behave just like any webpage. But Google are suggesting prohibiting the basic web model for extensions which would essentially make them "local only" web pages. Which is pretty useless. Just as it would be for web pages. No longer "web" at all.

PhistucK

unread,
Feb 13, 2019, 2:11:34 PM2/13/19
to Darren Govoni, Chrome Developer, Chromium-extensions
I meant, beside the obvious cases of <script src="http://w.com/script.js"></script>.

PhistucK

PhistucK

unread,
Mar 28, 2019, 6:48:52 AM3/28/19
to Simeon Vincent, Chromium-extensions

@Simeon -

What about using Google Analytics or Google Tag Manager (for example) in a Chrome extension?
Do you expect all of the extensions to embed a local version of the analytics/tag manager code (and they must update the local version, along with the extension, every time it updates)?
Do you expect extensions to track their analytics in a customized fashion?
Do you expect extensions not to track their analytics?
Same for any third party service that requires code execution (analytics, maps, content-distribution-network based custom elements that can have security issues fixed...).
Or will there be a review-based white list for remote services?


Note, though, that Google Tag Manager might be a security hole, because it can embed whatever JavaScript code the owner of the tag decided to add.

PhistucK

Simeon Vincent

unread,
Apr 1, 2019, 10:08:03 PM4/1/19
to Chromium Extensions, sim...@chromium.org
What about using Google Analytics or Google Tag Manager (for example) in a Chrome extension?
Do you expect all of the extensions to embed a local version of the analytics/tag manager code (and they must update the local version, along with the extension, every time it updates)?

As I understand the RHC plan, if an extension wanted to load GA, GTM, or any other 3rd party library in the extension's context, it would be expected to embed the analytics library as you've described. That said, you will still be able to load other pages or resources in sub-frames.

Let's look at an example. Say you wanted to display a map in your extension's popup using Mapbox. Today, you can embed Mapbox's <script> and <style> tags directly in your popup.html as described in their sample and you're good to go. Tomorrow, you'll need to embed an iframe points to a page (probably on your domain) that contains the map. If you need to detect interactions with the map, your sub-frame will have to postMessage those interactions to popup.html.


Do you expect extensions to track their analytics in a customized fashion?
Do you expect extensions not to track their analytics?

To my knowledge there are no changes specific to analytics use in extensions. As long as the developer has a privacy policy that details how and what data is collected, stored, shared, etc. then they should be in the clear.


Same for any third party service that requires code execution (analytics, maps, content-distribution-network based custom elements that can have security issues fixed...).
Or will there be a review-based white list for remote services?

I don't believe I've discussed whitelisting 3rd party script providers with the extensions team, but I expect that wouldn't get much traction. My impression is that there's a reticence towards whitelists and special treatment of specific providers because that would unfairly bias extensions towards existing incumbents and generally foster an uneven playing field. Requiring all assets to be bundled with the extension isn't a perfect solution, but I do think it will notably improve security for the average user.

---

I'd love to hear about real world cases where bundling 3rd party script in your extension doesn't cut the mustard.

Simeon - @dotproto
Extensions Developer Advocate


On Thursday, March 28, 2019 at 3:48:52 AM UTC-7, PhistucK wrote:

@Simeon -

What about using Google Analytics or Google Tag Manager (for example) in a Chrome extension?
Do you expect all of the extensions to embed a local version of the analytics/tag manager code (and they must update the local version, along with the extension, every time it updates)?
Do you expect extensions to track their analytics in a customized fashion?
Do you expect extensions not to track their analytics?
Same for any third party service that requires code execution (analytics, maps, content-distribution-network based custom elements that can have security issues fixed...).
Or will there be a review-based white list for remote services?


Note, though, that Google Tag Manager might be a security hole, because it can embed whatever JavaScript code the owner of the tag decided to add.

PhistucK


On Wed, Feb 13, 2019 at 9:10 PM PhistucK wrote:
I meant, beside the obvious cases of <script src="http://w.com/script.js"></script>.

PhistucK


On Wed, Feb 13, 2019 at 8:13 PM Darren Govoni wrote:
I'm pretty certain it's more than that. An extension can open a popup that itself loads code like a webpage because that's what in fact it is. Those <script> tags in the popup menu (extension) are expected to behave just like any webpage. But Google are suggesting prohibiting the basic web model for extensions which would essentially make them "local only" web pages. Which is pretty useless. Just as it would be for web pages. No longer "web" at all.

Message has been deleted
Message has been deleted

Eric Hynds

unread,
Apr 2, 2019, 12:05:22 PM4/2/19
to Chromium Extensions, sim...@chromium.org
As I understand the RHC plan, if an extension wanted to load GA, GTM, or any other 3rd party library in the extension's context, it would be expected to embed the analytics library as you've described.

Are content scripts allowed to inject remote scripts into the page that the extension lives on? In other words, for an extension running on a web page would it be acceptable to inject a remote script tag into that page's window to enhance it with additional functionality? I'm unclear whether manifest V3 prohibits remote scripts only inside the extension's context or any window that the extension has access to as well.

For example, can we do something like this (untested code) inside our content script?

var script = document.createElement('script');
script
.type = 'text/javascript';
script
.src = 'https://some-remote-domain.com/script.js';
window
.parent.document.appendChild(script);

Thanks.

je...@mixmax.com

unread,
Apr 3, 2019, 8:26:43 PM4/3/19
to Chromium Extensions, sim...@chromium.org
@Simeon, I'm intrigued by the same line as Eric Hynds. By "extension's context", do you mean both content and background scripts?

Or, might extensions continue to be able to import remote code into content scripts, just not background scripts?

Simeon Vincent

unread,
Apr 3, 2019, 9:02:59 PM4/3/19
to Chromium Extensions, sim...@chromium.org
Apologies for the confusion. I don't know why I emphasized "in the extension's context" like that in my last message. In retrospect that was just … weird. Sorry about that. I genuinely have no idea why I did that.


Are content scripts allowed to inject remote scripts into the page that the extension lives on? 

No, an extension's content script will not be allowed to inject a remote code into the host page using the technique you described. I believe this will be technically possible (we're not touching the web APIs that allow this) but it will be prohibited by CWS policy.


I'm unclear whether manifest V3 prohibits remote scripts only inside the extension's context or any window that the extension has access to as well.

Extensions will not be allowed to inject remote code in any context. This will be enforced through a combination of Chromium source and review policy changes. As such, a managed deployment (e.g. education, enterprise) may force-install self-hosted extensions that ignore policy-enforced limitations. In general, though, extensions targeting the general public & distributed via CWS will only be able to inject remote code included in the extension bundle.

And for clarity, by remote code I mean JS, CSS, and Wasm not served from by the extension. I believe media and iframes will be allowed.


Or, might extensions continue to be able to import remote code into content scripts, just not background scripts?

Quick point of clarity, background scripts are being replaced with service workers and they don't have access to any kind of DOM. 


Simeon - @dotproto
Extensions Developer Advocate

Atticus White

unread,
Apr 3, 2019, 10:38:39 PM4/3/19
to Chromium Extensions, sim...@chromium.org
Thanks for the clarity @Simeon.

So it sounds like that answers it -- appending a script tag with an `src` pointing to a remote file from the content script into a web page will not be permitted (via CWS distributions).

Guokai Han

unread,
Apr 17, 2019, 2:38:06 AM4/17/19
to Chromium Extensions, sim...@chromium.org
Hi Simeon,

I have two real use cases for remote code from Google.

1. Google Map Place API
I used Google Map Place API for autocomplete user input location. It needs to load a js like this


2. YouTube iframe API
YouTube iframe API let you embed youtube video in your page. It is a iframe + youtube js code. It needs to load this js file:

These two apis can't be used in iframe or packaged as a static file in extension.
In manifest v2, they can work by adding some domains to script-src and frame-src in content_security_policy.
But if manifest v3 disable load remote code, it will not work. And because they are 3rd code, not extension developer's code, we can't do anything.

How to solve these problems in v3? Will these Google services provide special static code for chrome extension developers?

PhistucK

unread,
Apr 17, 2019, 3:46:08 AM4/17/19
to Guokai Han, Chromium Extensions, Simeon Vincent
Can you explain why they cannot be used in an iFrame?
I mean, no one says it will be a nice way to code this, but is it technically impossible?

PhistucK


--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To post to this group, send email to chromium-...@chromium.org.
Visit this group at https://groups.google.com/a/chromium.org/group/chromium-extensions/.

PhistucK

unread,
Apr 17, 2019, 8:11:38 AM4/17/19
to Jackie Han, Chromium Extensions, Simeon Vincent
And still, if you put this in a <webview> (is it available to extensions? I forget) or a sandboxed iFrame, all of those can be done, I think.

PhistucK


On Wed, Apr 17, 2019 at 12:04 PM Jackie Han <han.g...@gmail.com> wrote:
Hi PhistucK,

For example, some 3rd party online JavaScript code may:
  • control the element directly in current page(e.g. google map place api and youtube iframe api, you can see their api docs).
  • generate code dynamically by url parameters.
  • detect user ip and user interaction (e.g. reCAPTCHA api).
  • load more code/resources from the first loaded code.
--
韩国恺(Jackie)

Jackie Han

unread,
Apr 17, 2019, 5:15:22 PM4/17/19
to PhistucK, Chromium Extensions, Simeon Vincent
Hi PhistucK,

For example, some 3rd party online JavaScript code may:
  • control the element directly in current page(e.g. google map place api and youtube iframe api, you can see their api docs).
  • generate code dynamically by url parameters.
  • detect user ip and user interaction (e.g. reCAPTCHA api).
  • load more code/resources from the first loaded code.

On Wed, Apr 17, 2019 at 3:45 PM PhistucK <phis...@gmail.com> wrote:


--
韩国恺(Jackie)
Reply all
Reply to author
Forward
0 new messages