I built a quick one-off chrome extension about a month ago during the SOPA craziness. Long story short, it unblacked Wikipedia, so that people who needed it could get some work done.
Once the blackout was over, I updated the app to no longer have any effects on any websites. I also modified it so it would put a console.log() saying essentially "The blackout is over. SOPA is still important, but you should uninstall this extension".
Unfortunately, a month later, I'm still showing that 90% of the original users have the extension installed. Certainly it doesn't have that large of a footprint, but as a developer I feel it's my duty to not let my extension become crapware on my user's computers.
Is there a way to forcefully uninstall a chrome extension? Is there some way that would be unintrusive to the user that I could inform them that they should uninstall the extension?
You can update the extension so that it requires the 'management' permission, and then use chrome.management.uninstall to make the extension uninstall itself.
In my opinion, there is no way in this situation. Unless
If your extension makes a request to a server that you can access, such as a web service from you, maybe you can send an alert to your users.
If auto update is enabled in your extension, you can update your extension. In your updated version, you can show users an alert (shouldn't be a real javascript alert. Some kind of alert) to uninstall your extension.
If auto update is enabled, you may update your extension to do nothing. Just a console.log message.
Related
I'm building a Chrome Extension and we published the first version of it recently. We already have a group of users who installed it.
We are now trying to push an update (with bug fixes and new features), but are getting mixed messages from Chrome documentation as it pertains to the user experience for updates. They've mentioned that by default, the updated version will be pushed to the Chrome Web Store, but existing users need to restart their browser for the update to be pushed or manually do to chrome://extensions.
Is there a way to automatically push an update to a user that has already installed our Chrome Extension (without any action required by users)?
We expected the new version to be automatically updated for the existing users. However, when the new version was published, the existing users would still be on the previously version 2-3 days after (without restarting their browser)
We expected the users to automatically access the new version without any action to the browser or extension dashboard.
Normally the browser autonomously checks if there are updates every few hours. If I remember correctly every 4 hours.
Therefore it is unlikely that the browser will not receive the update if the browser has been open for several days.
However, if the extension is MV2, if there is a persistent background script and if at least one extension page is currently open in the browser then the update may be stucked until that page\tab is closed.
Once the latter is closed, the extension should receive and install the update at the next browser check.
If your extension falls into this case then you could define a handler for the runtime.onUpdateAvailable event where you force the reload of the extension.
"Is there a way to automatically push an update to a user that has already installed our Chrome Extension (without any action required by users)?"
If by "a user" you mean "some users but not all",
then you could think of a system that sends a push message from your backend and manage its reception from a service worker which will run the runtime.requestUpdateCheck method only for the desired user(s).
However, this will imply the implementation of a sort of user registration\authentication in order to recognize it at the moment of the forced update request.
Note that you will not be able to selectively allow some users to upgrade while excluding all others. Basically, with this technique you would speed up the update only for one or a part of your users, so this method (not exactly easy to implement) could be overly redundant.
I'm developing a Chrome extensions that would be installed simultaneously with a desktop app, as an "external extension" as the docs call it. But I believe the extension would be disabled, and users would need to manually enable it. It's inconvenient to do this and not at all obvious how (at least to users not very familiar with extensions).
Is there a way to automatically enable the extension, or make it very easy for users to manually enable it? This was asked in the comments on this other stackoverflow question, but no one had an answer.
Another issue is that I think Chrome has to be restarted for the extension to be installed at all. This is obviously very disruptive from a user perspective. Is there a way around this?
Have an extension that has a good number of installs 10k+ and I'd like to open up a walkthrough page after it's installed from the Chrome Webstore only.
The problem is I never requested the tabs permission when I initially deployed it, so requesting that permission now (in order to lookup the focused tab's url and determine if the install happened from the Chrome Webstore host) causes problems because then all existing installs will have the extension disabled when the auto-update rolls out (due to the new permission request).
Are there any other ways of determining if the install is coming from the Chrome Webstore? I'm not trying to bypass any legit privacy/permission issues. Rather, looking for a technique that allows me to open a window only when it's needed.
Appreciate any thoughts.
This is the context: Suppose there is a plug-in, P, available at the Mozilla Firefox add-on site.
Consider a malicious user that modifies P, for example, to make it deviate from the normal behavior. My first question is:
Could the Firefox browser detect that the plug-in is not the original one (i.e., the one that was downloaded from Firefox site? If this can be detected, could the Firefox browser disable the (modified) plug-in?
Now consider the case of a Web site that interacts with the plug-in P. For example, the site allows access to the web content only if the plug-in is original (it has not been modified).
My second question is:
Could the site be able to detect that this malicious user modified the plug-in?
Firefox detecting changes
All extensions which are downloaded from AMO are cryptographically signed by Mozilla (link 2). If the extension is modified in any way, Firefox will automatically detect that there have been changes and will disable the add-on.
However, if the user is running Firefox Developer Edition, Firefox Nightly, Unbranded Beta, or Unbranded Release, they can change a preference such that the modified extension will not be disabled. The modification will still be detected, and the user informed in about:addons (Ctrl-Shif-A, Cmd-Shif-A on OSX). It is also possible for the user to download the source code for Firefox and compile their own version which disables add-on signature checking.
Temporary add-ons
The normal release and beta versions of Firefox do not permit the user the option to permanently install and run extensions which have not been signed, or where the extension has been changed after signing. However, they do, along with all other versions, permit an extension to be loaded as a temporary add-on even if unsigned, or changed. This makes it impossible unsigned add-ons which require a browser restart in those versions of Firefox.
Summary
Mozilla singing add-ons is intended to prevent add-ons, which are malicious, or that just have not been reviewed by Mozilla, from being downloaded and installed by naive users. Thus, to install an unsigned, or changed, add-on, the user has to jump through extra, inconvenient steps (not use a branded release or beta Firefox, or use a temporary add-on install). However, signing does not, and was not intended to, prevent the user from intentionally changing an add-on and not being able to run it.
Website detecting that the extension has changed
No, assuming that the modifications to the extension are intentionally being hidden, there is no guaranteed way for the web page to detect that a change has occurred. The modified extension can spoof any information that is provided to the web page by the original extension code. You can make this hard to do, but it can not be guaranteed.
You have not mentioned why you are wanting your website to be able to detect these changes. Thus, without guessing as to the purpose, it is not possible to provide you with reasonable alternatives.
You're asking for DRM, i.e. the ability to verify that a remote piece of software running on general purpose computing hardware is executing the code which it itself claims to be executing.
This is not possible, since the claimant can always lie and run any code snippet used for interactive authentication in some form of emulator.
Depending on what you're actually trying to achieve you should use user-specific authentication, i.e. tie site access to some token or password instead of the addon, or treat all inputs by the addon as unstrusted and verify them against whatever protocol they should follow.
In short: Validate data, not code.
I need to edit and then publish my Chrome extension. I know that it sometimes takes over an hour to publish an extension, but once it has been published, can I assume that all users are using this new extension version? Or might they still be using the old one for a while? And, if so, for how long?
I publish via the Chrome dashboard. Sorry if this is the wrong place to ask. I have tried searching through Chrome's documentation.
Issue: I need to update my server side code, but if a user is still using the old extension version, then it will fail very badly.
You should not make any assumptions about the extension update frequency. The update frequency is 5 hours by default. This value can be changed by the user through the --extensions-update-frequency flag. In practice, most users will stick to the defaults though. And do not forget that it is unreasonable to expect that all of your users have their computer online all the time.
You should keep the code for the old and new version at the server's side. If you haven't done before, include a version identifier in your request. This version identifier does not need to map 1:1 to your Chrome extension version; just use a value and keep incrementing it for every significant API update.
If you did not include a version identifier in your previous version, just assume that the user is using the old version if the version identifier is missing from the request, and consistently include the version identifier in requests from your new Chrome extension.
If you have set a minimum_chrome_version in your manifest file, then the user will also be stuck at an old version of your extension if they use an older Chrome version.
Though not relevant for your specific situation, extension authors can choose to distribute their extension to a specific percentage of users via the dashboard at the Chrome Web store. When this feature is used, you obviously have users who are still using the old version.
You have to handle in your code the possibility of users having the old version. Its not published how long that might be but from experience it can be a full day at least.
According to the docs and other sources the update happens within a few hours from publishing.
Every few hours, the browser checks whether any installed extensions or apps...
The default update check frequency is several hours,
I suggest you implement a mechanism to check the version of the extension making the request and if it is not current, either fallback to differently handling the request (based on the old server-side code), or inform the user they have to update (although I would not advice that, as it might scare and annoy users).
In order to force an update of one's extension:
but you can force an update using the Extensions page's Update extensions now button.
Basically, you have to go to the Extensions page, check "Developer mode" and press the "Update extensions" button that appears.
Bottom line
I would:
Implement a mechanism to include the version in a request
Maintain two code based on the server (for a few days only)
serve each request based on the version