Please tell me if the extension was removed (taken down from Chrome Webstore or account was suspended) after 3 months will be it deleted from the Webstore finally? And will be it removed from computers of all users (which previously installed it) or not?
I guess it would depend on how it was removed.
If a developer unpublishes the extension, it is not deleted from Web Store database, and existing installs will continue to exist but no new installs will happen.
If Google catches a malicious extension, it will be, in addition, remotely disabled on users' machines. It's hard to say if it's "deleted" from Web Store or simply unpublished.
Those are the 2 extreme situations. In-between there can be a whole spectrum. If an extension is delisted pending some changes, I'm not sure what happens with existing installs. Google probably explains that when it notifies a developer.
Related
Could anyone explain how Chrome Extension upgrading works?
Let's say I publish version 0.0.1. After a while I've some updates and I publish 0.0.2. Will all users having 0.0.1 be auto-upgraded to 0.0.2? If not, what is the process to sending/updating Chrome Extensions?
Thanks!
After a while I've some updates and I publish 0.0.2. Will all users having 0.0.1 be auto-upgraded to 0.0.2?
Yes. By default, if you publish (not just submit a draft, actually publish and wait for the automated review process to complete) a new version then all users will get it.
..eventually.
Chrome does not get push notifications about extension updates; it instead polls the Web Store for version information once every few hours.
While it would be possible for Google to make this push-based, I think this remains in place as a natural load-balancer (not everyone trying to update at once) and a bit of a safety net in case you published something badly broken.
On the extension side, there are 2 things in the chrome.runtime API that can influence the process.
You can force a check for a new version with chrome.runtime.requestUpdateCheck(). Note that this is rate-limited - you can't check too often.
In principle you could use some other method of delivering a notification to your extension (GCM, WebSockets to your server, polling your server etc.) to discover an update and trigger this check.
You can delay an update after it was detected with a listener to chrome.runtime.onUpdateAvailable event. It can be delayed no longer than the next browser restart.
If your extension has a lot of users (this starts at 10k users), there's an additional option available in the Dashboard's edit item interface.
Is it possible to perform a partial roll out in the Chrome web store?
CWS offers an option to only offer this version to a developer-specified percentage of users. This way you can limit the damage from a bad update.
I'm trying to develop a Google Chrome Extension app VoIP softphone. I will be using the Inline Installation feature (https://developer.chrome.com/webstore/inline_installation) and will be publishing on the Chrome Developer Dashboard (https://chrome.google.com/webstore/developer/dashboard)
My problem is due to the nature of the softphone that has to be always connected, every time I need to publish an updated version of the softphone users will be disconnected, and this will be a big hit on user experience.
Anyone ran into the same issues in publishing a softphone extension app in Google Chrome?
An update may be downloaded at any time, but an extension is only reloaded when the background page goes inactive.
I guess that you're using Web sockets for signaling. Since the connection need to be available at all times, you are probably using a persistent background page. This is enough to prevent a sudden unload. If you use event pages, then you need to jump through some hoops to get the page to stay alive even if the Web Socket is not busy all the time (crbug.com/204573), but also in this case, the extension will not suddenly be reloaded.
If you do want to reload an extension after an update, add a chrome.runtime.onUpdateAvailable listener and call chrome.runtime.reload when it is convenient (e.g. when the user has unregistered their soft phone, and/or when the user is idle, etc.).
The dashboard provides the ability to ramp up your updates. So only a small percentage of users will be affected at any time under your control.
In addition to the a slow ramp you can do it during off hours to minimize user experience.
This won't solve for disconnections during the update but could minimize the impact.
How can I sign my extension so users make sure my extension is safe and it won't steal their information? My extensions needs to access page contents, some users have no good sense of permitting an extension to do so.
Can I sign my extension using a verified sign provider, for example VeriSign?
When you publish an extension to the Chrome Web Store, the only "proof" that users can have of your extension is given by the rating system and the comments of other users. An hypothetical user that wants to install your extension, looks at the ratings and the comments, so make sure that your extensions has a good feedback from its users.
By the way, Google doesn't always look at the internal code of your extension manually, most of the times it only performs some heuristic checks on the code. So the problem is that developers could easily include some malicious code that may not be recognized and that could harm user's privacy in their extension without any problem.
Therefore, due to the Chrome Web Store policy, "validating" your extension is not possible at all. Plus, using SSL servicies (like the one you mentioned) will not make any sense since that your extension's scripts are stored locally.
What you can do is:
Encourage users in rating your extension and leave good feedbacks if they like it.
Redirect users to help links in case of trouble (links like "having trouble?" in your popup and so on).
Write a good worded description, and obviously add some images (or videos, better) to clearly show why an user may find your extension useful.
Always be nice (implied, ahah).
Your extension cannot be signed by an external provider, but it is signed by Chrome Web Store itself.
Every extension has an associated private key used for signing. It ensures consistent extension ID and updates. You can generate one yourself by packaging the extension as CRX (that produces a .pem file) and provide it when publishing on the CWS, or CWS generates it internally when you publish it (and then there's no way to extract it).
From on then, only code signed by this key (by the Web Store engine) will be recognized by Chrome as an update. Furthermore, at least on Windows only CWS-signed packages can be installed.
This security is as strong as the developer's Google account: if it is compromised, CWS will accept an update to your extension, which will be signed with the same key.
Although, as Marco correctly pointed out in his answer, the act of signing something would be just snake oil with respect to security. This signature verifies the identity of the publisher, but nothing more.
There's one more aspect - verified sites. If your extension interacts with a site you control, you can certify this by associating your extension with the site. It will be visible in the Web Store.
CWS-signed packages have an additional warranty of saying "so far, we did not catch this extension breaking any rules". Google can pull the extension off Web Store, and in severe cases blacklist and remove it from all Chrome installs. So that's an additional assurance for the user.
Google runs automated heuristic checks every time you submit your extension, which can trigger manual review. But that's invisible to the user.
That said, make sure to only ask absolute minimum permissions you need. For instance, look into the activeTab permission. It gives full host permissions for a tab when the extension is invoked by the user, but does not result in any permission warning. This was specifically added to address concerns about blanket extension permissions.
I developed an extension for my team with more than a dozen persons. And we used it internally. But some Windows-base-on colleagues now face a problem. When they update chrome to verson 37 and above, my extension is blocked by chrome, due to its not installing by chrome app store. Is there a cheap way to avoid this?
I had tried some methods. We don't want to change chrome into chromium or change their Windows into MacOS, Linux. And we want to update Automatically, so packaging on local is standby. Publishing in chrome app store is also a standby. Is there any other way?
Alternative deployment is available only if your computers are in a Windows domain. You can then use this documentation to set up distribution via Group Policy.
Other than that, no, you have to publish on the Web Store. It's $5, once, it's not that costly. You can set your item to be Unlisted, so that it's not possible to install it without knowing an explicit link, or you can even restrict it to an explicit list of Google accounts.
As a bonus, if you deploy to Web Store providing your packaging key, I think the extension will be turned back on automatically.
Is there a technical reason, why a Google Drive application must be installed through the Chrome Web Store (which severely limits the number of potential users)?
The reason that installation is required is to give users the ability to access applications from within the Google Drive user interface. Without installation, users would have no starting point for most applications, as they would not be able to start at a specific file, and then choose an application.
That said, I realize it can be difficult to work with in early development. We (the Google Drive team) are evaluating if we should remove this requirement or not. I suspect we'll have a final answer/solution in the next few weeks.
Update: We have removed the installation requirement. Chrome Web Store installation is no longer required for an app to work with a user's Drive transparently, but it is still required to take advantage of Google Drive UI integrations.
To provide the create->xxx behaviour that makes a new application document from the drive interface, and to be able to open existing documents from links, there must be some kind of manifest registered with Google's systems and some kind of agreement from the user that an application can access your documents and work with specific file types. There's little way around this when you think about the effects of not doing this.
That said, there are two high level issues that make for compatibility problems.
As the poster says, the requirement to install in the chrome store
severely limits the number of potential users.
But why? Why do the majority of Chrome Web Store applications say that they only work on Chrome? Most of these are wrappers to web applications that work on a range of browsers, yet you click through a selection and most display "works on chrome", aka only installs on chrome.
Before we launched our application on chrome we found that someone had created "xxxxxxx launcher" in the store, that simply forwards to our web app page. We're still wondering why it only "works on chrome". I suspect that some default template for the web store has:
"container" : "CHROME",
in it, which is the configuration option to say chrome only. That said, I can't find one, so I'm very confused why this is. It would be healthier if people picked Chrome because it's the better browser (which it is in a number of regards), not because their choice is limited if they don't. People can always write to the application vendor and ask if this limitation is really necessary.
The second thought is that a standardised manifest format across cloud storage providers would mean a much higher take up in web app vendors. Although, it isn't hugely complex to integrate, for example, with Google Drive, the back-end and ironing out the the details took over a week in total. Multiply that lots of storage providers and you have you lose an engineer for 2 months + the maintenance afterwards. The more than is common across vendor integration, the more likely it is to happen.
And while I'm on it, a JavaScript widget for opening and saving (I know Google have opening) by each cloud storage provider would improve integration by web app vendors. We should be using one storage providers across multiple applications, not one web application across multiple storage providers, the file UI should be common to the storage provider.
In order to sync with the local file system, one would need to install a browser plug-in in order to bridge the Web with the local computer. By default, Web applications don't have file I/O permissions on the user's hard drive for security reasons. Browser extensions, on the other hand, do not suffer from this limitation as it's assumed that when you, the user, give an application permission to be installed on your computer, you give it permissions to access more resources on the local computer.
Considering the add-on architectures for different browsers are different, Google first decided to build this application for their platform first. You can also find Google Drive in the Android/Play marketplace, one of Google's other app marketplaces.
In the future, if Google Drive is successful, there may very well be add-ons created for Firefox and Internet Explorer, but this of course has yet to be done and depends on whether or not Google either releases the API's to the public or internally makes a decision to develop add-ons for other browsers as well.