Load all JS script from server along with content scripts

[Upendra Sengar]

Hi All,

After recent updates in google chrome webstore, I can see extension publishing time is slightly higher than before. Previously your extension was being published in a max of 2 days (Most of the extensions not all) but now it takes a week to publish so I'm planning to load all JS from the server instead of the local file so this will help us to quickly deliver your updates to customers. Our extension needs frequent updates so we can't wait for days to publish which results in revenue loss.


I want suggestions from all the developers on how can we load the content script from the server (Normal script in the app itself can be loaded directly using a script tag). I know one way to execute the script using 

chrome.tabs.executeScript(integer tabId, object details, function callback)

so first I'll hit the server to bring all the JS script and run executeScript in the target tab so every time the target tab is loaded first our server will be hit to bring JS files then execute the files.

Question :

1. if injecting script on page load then is it fast enough to evaluate our scripts OR page load time increases?
2. should I cache our script version instead of hitting the server again and again?
3. is there any other way to counter this problem? 

Looking forward to everyone's suggestion here. I'm sure everyone wants to have some solution to skip this approval process delay.

[wOxxOm]

1. You'll have to cache the file contents in any extension storage and insert them with chrome.tabs.executeScript (or chrome.declarativeContent API + RegisterContentScript action). Note, you can't just insert a DOM script element into the page because they execute in the so-called page context, not in the isolated world of the content scripts, also some pages have a restrictive Content Security Policy that only allows a few hosts for script URLs.
2. This will be frowned upon or even downright forbidden by the web store reviewers as the external code isn't part of the extension so they can't review it (they want to make everyone think they actually perform an in-depth review which is kinda funny since they don't ask developers for the real source code prior to compilation, bundling, and minification - the way Mozilla does).
3. This will be forbidden in the future when ManifestV3 will be the only supported format according to the current API draft.

[Sean Wilson]

Hi,

Would something like this be acceptable for making a web app that needs to get around CORS restrictions?

- Host the core of your JavaScript on your own website e.g. example.com/app.

- Create an extension that runs a background script that listens for messages from a script running on example.com/app, performs an action then passes back the results back to example.com/app.

- example.com/app can then do actions permitted by the background script e.g. ask the background script to download data from an arbitrary URL (which CORS would usually prevent).

The Chrome team can review that the background script only performs limited actions and only from example.com so that even if example.com/app was compromised it wouldn't be able to do much. 

I'm in agreement that the current situation with Chrome Web Store approval is very bad. We can't be expected to wait days let alone weeks to make updates to Chrome extensions that have paying customers waiting.

Thanks,

Sean

[Deco]

No it would not, this action is specifically forbidden by the CWS team due to malicious JavaScript escalation issues. You will have your extension taken down by employing this, and likely have your account suspended.

--
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 view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/2c17ef4c-b7aa-456c-9dbc-d236a6396278%40chromium.org.

[Sean Wilson]

Hi,

Can you link to where it explains why this approach is forbidden? Why allow message passing from website pages to extensions at all if the page can't ask for and receive data that only the extension has access to? Specifically, this approach won't allow the external page to execute arbitrary JavaScript code via the extension.

Is there an alternative approach to get around CORS without running a proxy server?

Thanks,

Sean

[Deco]

You can find this detailed with the Content Security Policy.

More specifically: 

Script and object resources can only be loaded from the extension's package, not from the web at large. This ensures that your extension only executes the code you've specifically approved, preventing an active network attacker from maliciously redirecting your request for a resource.

Instead of writing code that depends on jQuery (or any other library) loading from an external CDN, consider including the specific version of jQuery in your extension package. 

CORS exists specifically to prevent this type of action, which is why external scripts are forbidden to be loaded from websites as to evade Cross-Origin restrictions. It should be added that attempting to evade CORS by having scripts loaded from an external domain will further raise red flags with the review team, simply put, stay away from this type of approach.

[Sean Wilson]

Hi,

Are you sure this applies here? This example does not load JavaScript from an external resource. The approved code runs inside the Chrome extension and the external JavaScript runs externally. 

Many Chrome extensions rely on doing things regular web pages cannot (like getting around CORS) so that by itself should not be an issue as far as I see. 

Thanks,

Sean

[Deco]

Ah, i think I misunderstand, are you referring to having information within the extension updated through loading in external resources and vice versa, rather an entire scripts?

[Kent Brewster]

Another reason not to do this: the team at Mozilla has forbidden remotely-sourced scripts since mid-year 2018, so you won't be able to land a Firefox version.

--Kent

> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CABcX4UeenH8Rz9uuNpTS31K-ewLCB4vqgTfWAYvftLW4J9PHbg%40mail.gmail.com.

[Chris Cowan]

I work on an extension that adds functionality to Gmail, and one thing I've been considering doing is putting as much of our features as possible inside webpages on our own domain (which we can freely update), and then having the extension's specific job be to just place iframes inside Gmail pointing to the webpages on our domain. Code running inside of cross-domain iframes like that is sandboxed so it can't automatically access the outer page or the extension's privileges. The extension's own code would be relatively small and easily auditable to show that it's not abusing its extension privileges and access to the outer page, and that it doesn't expose these raw permissions to the iframed page.

I obviously can't speak for the Chrome team, but I strongly suspect if that's done well it can address the concerns around remotely hosted code. Some documentation around Firefox add-ons specifically mentions sandboxing as an approach for remotely loaded code (https://developer.mozilla.org/en-US/docs/Archive/Add-ons/Security_best_practices_in_extensions), and I believe the Chrome team cares about remotely loaded code for similar reasons as Mozilla does.

[Sean Wilson]

Hi,

I think I haven't explained myself well as I'm not talking about executing a remote script within an extension's process. 

Below is a concrete example of the approach I meant which lets you update most of your app logic by updating code on a website you control. Can anyone on the Chrome team comment on if this approach is suitable now and in the future? Example:

- Postwoman is a web app for testing REST APIs (similar to Postman). You can try it here in a regular browser tab: https://postwoman.io/

- Postwoman will work without a problem as long as you don't try to test an API with CORS restrictions.

- If you want to get around the CORS restrictions, you can install a specific Chrome extension for Postwoman:

https://github.com/AndrewBastin/postwoman-chrome

- As far as I understand, all the Chrome extension does is act as a simple proxy and nothing more. When you visit postwoman.io 1) the JS that runs on that page (in its own process) is allowed to send a message to the extension (which runs within another process) asking for a URL to be fetched 2) the extension fetches the URL, and 3) the extension sends a message back to postwoman.io with the fetched data.

- The extension code is very short and doesn't do much so it's easy to audit. There's no remote code execution, it's using message passing. 

- This approach lets you freely update the core logic of the app by just updating the website. If the website was compromised, it would be very limited in what it could do (i.e. fetch arbitrary URLs via the extension while the website was open in a tab).

Does that make sense?

Thanks,

Sean

--

--

Sean Wilson - Web app designer + developer

www.seanw.org

Checkbot for Chrome tells you how to boost the SEO, speed & security of your website:

www.checkbot.io

[Sean Wilson]

Hi Chris,

Is the iframe approach you mention essentially the same as the one I describe here?

https://groups.google.com/a/chromium.org/d/msg/chromium-extensions/U18CG2LVU_U/V-8-nXIpDwAJ

Thanks,

Sean