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:
Related
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 an extension that I'd like users to install along with my app. The app's purpose is very simple: use raw sockets to interact with a remote service and pass some messages to the extension. As far as I know, raw sockets are not available to extensions.
I'd like to avoid forcing users to install two separate packages from the Chrome Web Store. Is there a way to package both into one unit?
If not, what would be the recommended practice in this case?
The target platform is Chromebook/Chrome OS.
Thanks.
I don't think this is possible, otherwise there would be no reason to have both (apps and extensions).
But you can encourage your users to install extension from your app and vice versa.
And you can send messages between extensions and apps so you can ping to check if it is installed or use management permission to check.
It's impossible, each extension or apps has an unique extension_id.
and has single manifest.
But I think it is pretty good idea :)
I think it should be supported from webstore side.
I want to detect whether a browser supports the Ember.js library. If not, I will show users a message to let them download the latest version of their browser. How can I do that?
There is an answer to a similar question contributed by an Ember.js core team member.
In it, he states that the majority of the browsers on browserstack.com are supported, meaning they do thorough testing.
Rather than show the message based on a functionality test of the user's browser each time they load your application, I suggest you instead build a list of known incompatible browsers (anything older than what is on BrowserStack would be a good start) and expand it based on monitoring your access logs or reported issues from the likely minority users on unsupported browsers.
That "blacklist" approach would serve most efficient, as Ember.Js and other libraries like jQuery are usually designed to continually support all new browsers.
I am trying to understand classification/naming of scripts,
I havent found any software vocabulary online that I can read,
I have many scripts which my own, and from open sources.
I want to put my script to correct folders.
Whats difference between those concepts in practice?
Plugins are the complete programs and these can be installed in your system and can be used in browser whereas add-ons are not complete programs ,these are used to add functionality to your browser.
for example, Flash Player is a plugin which can be installed in your system as well in browser to play video,
InPrivate Filtering is an add-on which is used in some browser to provide privacy.
So, add-ons provide additional and limited functionality to your browser.
I want to build a cross-platform helper app that lets my users scan the desktop filesystem and find/upload the original, hi-res version of a JPG image they have previously uploaded. The scan may try to match by filename, EXIF data, or by comparing visual attributes using computer vision algorithms.
I read the following and get a little frightened:
Security considerations
Including an NPAPI plugin in your extension is dangerous because plugins have unrestricted access to the local machine. If your plugin contains a vulnerability, an attacker might be able to exploit that vulnerability to install malicious software on the user's machine. Instead, avoid including an NPAPI plugin whenever possible.
My other option is to build a download/install native desktop app that runs in the background. But this approach is would also have unrestricted access to the local machine + my servers via the internet.
Both approaches require the user to download/install native code - but the NPAPI plugin has the promise of easier access and a common framework. So are the security issues the same or is one approach generally preferred over another?
Essentially, both plugins and a regular app have the same kind of access - so installing either one requires quite a bit of trust. There is a difference in attack surface however: while an application is normally something that can only be started by the user, a plugin is accessible to every website (restricting access to selected websites is possible but this protection itself can fail). Also, if you want to package an NPAPI plugin in a Chrome extension you have to consider that Chrome Web Store requires manual review before accepting such extensions (and distributing extensions from your own site is pretty hopeless with the changes made in Chrome 21). But it can potentially provide a better user experience. All in all: not an easy choice to make.