We have an extension developed for internal use that uses WebRequest API. The extension is installed using "ExtensionInstallForcelist." Based on various documentation, it seems like we would be able to continue to use WebRequest API but there are parts that are still unclear.
The timeline on https://developer.chrome.com/docs/extensions/mv3/mv2-sunset/ states that "January 2024 - Manifest V2 enterprise policy expires."
Does this mean that starting January 2024, Chrome will stop running Manifest V2 extensions, even the one that is installed using "ExtensionInstallForcelist"?
This article says "public" extension is one that is published to the webstore. Does that definition also apply to "unlisted" extensions? Right now, we perform initial install from our server using "ExtensionInstallForcelist" but update from the webstore having the extension unlisted.
The reason why we update from webstore was because updates used to be only allowed from the webstore. (We may have missed something) But it looks like starting from version 89, there was an option introduced that would allow updates from outside of the webstore. The option is "override_update_url" in ExtensionSettings. Does anyone have experience with this option?
Related
I'm currently migrating a chrome extension from manifest v2 to v3.
The extension uses Google ReCaptcha for some features. It works well with manifest v2.
But for manifest v3, remote code is not allowed anymore.
So I must bundle a specific version of Google ReCaptcha (for example) instead of just loading it from this.
So, my questions are:
Does it even work? If it works, is it risky?
Are there any better approaches for my use case?
Given the crackdown on VPNs in China, I was wondering if there is a user-friendly way of allowing Chinese users to install and update Chrome web extensions?
Distributing the CRX of the extension for users to install manually, as others have suggested, is tolerable (though not ideal), but I would particularly like to avoid the requirement for users to re-install the extension whenever an update is available.
As far as I can tell from the docs, it is not possible to publish an extension in the Web Store with an "update_url" parameter in the manifest that doesn't point to https://clients2.google.com/service/update2/crx. Is there any way of distributing an external Chrome extension to these users with a private "update_url"that will allow auto-updates?
Edit
I have read the relevant documentation on alternative distribution methods/hosting/packaging etc that seem to suggest that https://clients2.google.com/service/update2/crx is the only valid update URL. However, since there are a large number of Chrome users in China I am curious if there is a viable solution to the problem of distributing extensions and updates to them - this seems like quite an important issue and it's one that, as far as I can tell, is not explicitly addressed in the docs.
As far as official docs go, you have Alternative Extension Distribution Options:
All Chrome extensions must be distributed either directly from the
Chrome Web Store, using inline installation, or using the mechanisms
described below. Failure to comply with one of these distribution
methods constitutes a violation of the Chrome extension policy and may
result in the extension and/or the software distributing it to be
flagged as unwanted software.
Usually, users install their own extensions from the Chrome Web Store
or some other site via inline installation. But sometimes you might
want an extension to be installed via other means. Here are two
typical cases:
I'm currently developing a Chrome extension and planning to publish it on Chrome market. I'm aware of open-source community benefits, however, do not want to share the source code and a bit worried about copyrights. Currently, the plan is to minify and obfuscate the source code before publishing. So the questions is:
Does Chrome Market accept extensions with minified and/or obfuscated source code?
Thanks in advance! :)
Any existing answers above have been rendered obsolete by the terms change on January 1st, 2019. This change was announced on October 1st, 2018.
In summary:
Google Allows minified code.
Google disallows obfuscated code.
The specific policy, available at https://developer.chrome.com/webstore/program_policies, is as follows:
Developers must not obfuscate code or conceal functionality of their
extension. This also applies to any external code or resource fetched
by the extension package. Minification is allowed, including the
following forms:
Removal of whitespace, newlines, code comments, and block delimiters
Shortening of variable and function names
Collapsing files together
2019 Update:
Google allows minified code, but not obfuscated one. See Brian's answer
Original answer:
Yes, you can use obfuscation tools (like jscrambler) before publishing your extension. I don't know if that may delay the publishing time, but I know for sure that are some published Chrome extensions with obfuscated/minified source code.
I, for instance, minify the code of my extension (LBTimer) with Google's Closure before publishing it.
It looks like they don't approve minified and obfuscated code. You can check thread on the Chromium Google Group, from April '16.
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-extensions/1Jsoo9BPWuM
No, you cann't. This is email I received from Google Chrome Team: All
of the files and code are included in the item’s package.
All code inside the package is human readable (no obfuscated or minified code).
Avoid requesting or executing remotely hosted code (including by referencing remote javascript files or executing code obtained by XHR requests).
You can get a more specific answer if you contact the Google Chrome team.
Update with own experience:
I wasn't able to submit a build obfuscated with this javascript-obfuscator (more specifically, gulp version in my case) They were complaining about "your code is suspicious" so I guess something triggered an alert in their system.
However uglyfy worked for that - I still had to figure out a way to rename all the prototype functions as uglify doesn't seem to do that (or at least I wasn't able to find a way to do that)
Original answer:
To sum up, it seems like chrome extensions are allowed to be minified and obfuscated.
For more details, keep reading.
First of all, there are two different terms - chrome extension and chrome app and different rules applies based on that. Chrome app has more strict requirements and it seems like mcastilloy2k's answer is suitable for chrome app (at least it looks like it is based on the available policies for both).
And regarding the below google's answer:
Avoid requesting or executing remotely hosted code (including by
referencing remote javascript files or executing code obtained by XHR
requests).
If it's for chrome extension and not for chrome app that seems strange as per the extension FAQ from google which explicitly states that extension is allowed to make external requests to execute custom API aka 'remotely hosted code':
Capabilities
Can extensions make cross-domain Ajax requests?
Yes. Extensions can make cross-domain requests. See this page for more
information.
Can extensions use 3rd party web services?
Yes. Extensions are capable of making cross-domain Ajax requests, so
they can call remote APIs directly. APIs that provide data in JSON
format are particularly easy to use.
Can extensions use OAuth?
Yes, there are extensions that use OAuth to access remote data APIs.
Most developers find it convenient to use a JavaScript OAuth library
in order to simplify the process of signing OAuth requests.
Another discussion in this google groups thread shows that rejection might not be connected with obfuscation at all:
Eventually, these are the things I needed to do to get my extension
passed (but I keep my fingers crossed in case some other validation
test still has to be performed):
I created a privacy policy and added a link to it on the Google Chrome developer dashboard.
I explained in more detail what my extension is doing. It seems that Google needs this to have a better understanding of the extension.
In the description I explicitly stated how the extension handles personal or sensitive user data.
Eventually that was enough to get the extension
pass the checks even with minified & obfuscated code (but remember I
keep my fingers crossed).
Moreover one can always go and check existing extensions out there, like Grammarly for example, who has obfuscated code (to some extent at least) and who uses external API.
I have a client that has Google Maps using JavaScript API v2 on their websites, which will eventually be deprecated (discontinued/not supported) until May 19, 2013 according to
https://developers.google.com/maps/documentation/javascript/v2/introduction
I just like to know what are the impacts on the website if I do not yet upgrade my code to JavaScript API v3 by May 19? e.g. Will my Google Map API v2 stop working (because Google has taken v2 API offline)
I ask this question because I have 6 websites that needs to be upgraded to API v3 and may not meet the deadline by May 19.
Thanks
One possible implication is Google Web Toolkit, which is not (and will not) be supported in Google Maps v3. If you have a complex, large site built with GWT, using v2 and you haven't already rewritten your site.. you may be up the creek.
I would like to write a google chrome extension to intercept http traffic and to create graphs similar to how network tab does it. Is there API available to do this? I found there's WebRequest API: http://code.google.com/chrome/extensions/trunk/experimental.webRequest.html but it says it is still in experimental stage, I wonder how stable it is at this point and if there're any good samples that use it. Thanks!
Experimental is just that. Experimental. It could have breaking changes in an release of chrome. The other downsides of experimental is only being available in the dev channel of Chrome (or more unstable such as canary), extensions using experimental can not be uploaded to the Web Store, and user have to have the enable experimental extensions flag.
If you still want to use the experimental webRequest API I wrote a simple example in another answer.