I've written a NPAPI plugin and I want to implement an NSIS installer that can install the plugin automatically.
I've googled a lot and found that from Chrome browser v25, *.crx package installation using the Windows registry does not work any more(the installed extension will be disabled by default). It seems that
Google does not allow any automatic extension installations without being approved by user.
However, I also found that if I install the plugin dll (instead of crx) on user's local machine and write reg keys to
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\MozillaPlugins\#myplugin.com/myplugin with correct dll path, the plugin could be installed automatically as long as my user downloaded and executed my installer, without any notification that the new plugin was going to be installed.
My question is that why my installer works? Is it in contradiction with Google's policy?
Shouldn't all the plugins installed under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\MozillaPlugins be blocked or disabled by default?
Extensions and NPAPI plugins are very, very different, as are the associated risks to users, and they therefore have different policies.
Extensions can't be silently installed because that ends up being used to install malicious extensions that do things like change browser settings and make them hard to change back, easily harvest sensitive information from sites users visit, inject extra ads on every site the user visits (and/or replace ads that support sites with ads that just pay the malware authors), etc.
NPAPI plugins, on the other hand, do absolutely nothing in the browser unless specifically loaded by a page. They aren't particularly interesting as malware, because the added capability that NPAPI plugins give you is the ability to run native code. But if a malware author can get someone to run an installer to install the plugin, they could just as easily install something else instead that runs native code continuously in the background, rather than only when a user visits a site that triggers a plugin (and they can much more easily hide that than a plugin, which has to be in a known location, and shows up in Chrome).
The danger with NPAPI is around exploits of already-installed, non-malicious plugins, whereas the installation of malicious extensions is a real issue.
Related
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?
I developed an addon for firefox which I want to distribute among my group. I don't want to make it visible to everyone. How can I put that restriction for my published addon.
I did the same for chrome extension where my listed emails can install my chrome extension only.
Such an option is not available for extensions listed on AMO. It's either available for everyone or not at all.
Unlike CWS, with Firefox you can opt to self-distribute the extension (AMO will only do the signing, hosting and updating is on you), and then how you control access is up to you.
However, once someone has the XPI file, they can share it with anyone. This is technically true of Chrome extensions as well: once installed, they can be ripped and shared.
If you truly need to limit functionality for non-members, the only way is to offload some non-trivial part of the program to a server that requires access credentials.
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.
We have authored a Chrome extension and would like to ensure that our extension does not at any time participate in being sync'd using Google Account synchronization, even if the user has specified in the Advanced sync settings dialog that extensions be sync'd. Is there a way to prevent this sync'ing on a per-extension basis? Is there some setting we could place in the extension manifest file to accomplish this? Or other way to accomplish this?
If that is not possible, can we force the Extensions checkbox to always be unchecked and unalterable by the user, using enterprise-level techniques such as Group Policy Update? This is not optimal, since we only want to stop the sync'ing of our extension, and not prevent sync'ing of all extensions.
We do see that the SyncDisabled policy registry setting is available to us, but that looks like it will disable ALL data synchronization including Apps, Extensions, Settings, History, etc. This is even less desirable to us, since we don't want to affect other synchronization -- we just want to prevent only our extension from being sync'd.
The use case for this involves the following:
A corporate user installs Chrome on his work computer. Our extension is useful in the enterprise environment and is installed on Chrome.
At some point, using the Chrome browser, this user logs into his personal Gmail account. He has set up his Google Account to turn synchronization on.
Now when this user, using his home computer and Chrome browser, logs in to Google, he will find that our extension has also been installed on his Chrome browser at home -- this is not desirable, since our extension has no usefulness in the home environment. Moreover, the user may consider the presence of our extension an unwanted intrusion into his home computing environment.
The only remedy for this user would seem to be that he could go to the Advanced sync settings and uncheck the Extensions checkbox, but then he would lose the benefit of extension sync'ing of other extensions, which he may want.
Well, if you're doing it in a corporate / managed environment, you don't need to publish your extension on Web Store at all (thus preventing the sync) if you can use Group Policy.
Any extension in ExtensionInstallForcelist will be installed even if it (and its update manifest) is hosted outside Web Store. This will prevent the extension itself from syncing (though will probably still allow chrome.storage.sync to function for it, which is a plus).
Other than that, I don't think there's a way to prevent an individual Store-hosted extension from syncing.
My question is how do third party installer installs addons in the browser like toolbars and able to set homepage and other browser properties??
I want to make an addon which get installed in browser in same way..
is it possible??
In principle, installing extensions along with other software is possible. I'm describing the procedure for Windows.
The following conditions have to be met:
You must be able to write to the HKLM registry subtree (needs Admin rights)
The extension must be published on Chrome Web Store
The machine must be able to download the extension from Web Store
If those conditions are met, you can do it according to the procedure described here. Basically, the installer must create a registry key that will trigger Chrome to download the extension on next launch.
That said, Google has gone to great pains to prevent silent installs and avoid browser settings hijack. Such setting overrides are a weapons race and Chrome is tightening its defenses. Ask yourself whether it's ethical to install your extension this way.
It will probably annoy your users and will flag your extension for more meticulous checks by Google. Remember that Google can disable any extension hosted by the Web Store if it violates its policies.
Also, be mindful of the single purpose policy. A toolbar that also overrides search/homepage/settings will be frowned upon. At a minimum it should be separated into several extensions, at a maximum - don't do it.
An extension can override, say, a homepage, but it's very restrictive. The extension must be in the Web Store as above, and any override pages must be verified for ownership for the Web Store developer account. All in the name of security and comfort of the users.