What is the proper format for the ExtensionSettings policy registry key/value that is used to manage browser extension settings?
When looking at the ExtensionSettings page for Firefox or Chrome they both use an example that shows the registry key Software\Policies\Mozilla\Firefox\ExtensionSettings (REG_MULTI_SZ) being set to a long JSON string with every extension ID and the settings for that particular ID. For example...
{
"*": {
"blocked_install_message": "Custom error message.",
"install_sources": ["https://yourwebsite.com/*"],
"installation_mode": "blocked",
"allowed_types": ["extension"]
},
"[email protected]": {
"installation_mode": "force_installed",
"install_url": "https://addons.mozilla.org/firefox/downloads/latest/ublock-origin/latest.xpi"
},
"[email protected]": {
"installation_mode": "allowed"
}
}
The problem with this method is that if I am installing an extension, and I overwrite what already exists in Software\Policies\Mozilla\Firefox\ExtensionSettings then all of those other settings get removed. So even if I am a non-malicious actor and just make a mistake with my installer I can easily delete every other extension's settings. Instead what I have to do is during install I have to read the current value of Software\Policies\Mozilla\Firefox\ExtensionSettings and then insert my extension's settings into the JSON blob.
So the examples that Firefox and Chrome provides do of course work, however they do not make very much sense to me. Why would it be formatted this way since all of those are additional key/value pairs and that is exactly what the registry excels at storing. So why put all of those into a single key/value instead of breaking them into multiple?
Additionally breaking them a part into multiple key/value pairs does work! So if instead of the example above I were to split them into multiple key value pairs it works just fine!
Software\Policies\Mozilla\Firefox\ExtensionSettings
[email protected] "installation_mode": "force_installed", "install_url": "https://addons.mozilla.org/firefox/downloads/latest/ublock-origin/latest.xpi"
So knowing that this way with multiple key/value pairs works why am I bothering to ask this question at all instead of just doing it the way that makes sense to me? Well the issue is that by breaking it up into multiple key value pairs it actually overrides the other method and makes it so that all those registry settings are ignored. So it doesn't delete them but it still leaves me with nearly the exact same problem.
While I believe "my" way is superior because it uses the registry in a more common sense route, if that is not what the majority of extension developers do then it doesn't matter and I should be conforming to the other way.
As I am typing this question up I did realize just how hard/annoying it is to properly format and make it clear and digestible what the multi key/value format of the registry would look like instead of being a JSON string. So perhaps that is the reason why all the documentation puts it all as one JSON string?
Ausgewählte Lösung
> Ah I understand so essentially the documentation is specific for Group Policy and not for a more generic installation?
It's kind of for everything. Everything you do in the group policy editor maps to stuff in the registry, so I show both in the docs for people that need it.
> For example since I have to have an MSI installer to get my Native Messaging application, manifest, etc all onto the endpoint I figured I might as well also install the extension at the same time by setting the registry values. > However, it seems as though the more "Mozilla approved" method would be to have the MSI handle all the Native Messaging setup, and then use the group policy editor to handle the actual installation of the extension.
In general, we don't recommend that installers modify the registry to install an extension. We would rather the user consent to that install.
Diese Antwort im Kontext lesen 👍 1Alle Antworten (3)
It's not necessarily about how the Windows registry stores it, but using the group policy editor to set the values.
It's very limited in it's UI and doesn't have anything that would allow things to be set the way you describe.
So we've all resorted to JSON to work around the limitations of the tooling.
Ah I understand so essentially the documentation is specific for Group Policy and not for a more generic installation?
For example since I have to have an MSI installer to get my Native Messaging application, manifest, etc all onto the endpoint I figured I might as well also install the extension at the same time by setting the registry values. However, it seems as though the more "Mozilla approved" method would be to have the MSI handle all the Native Messaging setup, and then use the group policy editor to handle the actual installation of the extension.
Ausgewählte Lösung
> Ah I understand so essentially the documentation is specific for Group Policy and not for a more generic installation?
It's kind of for everything. Everything you do in the group policy editor maps to stuff in the registry, so I show both in the docs for people that need it.
> For example since I have to have an MSI installer to get my Native Messaging application, manifest, etc all onto the endpoint I figured I might as well also install the extension at the same time by setting the registry values. > However, it seems as though the more "Mozilla approved" method would be to have the MSI handle all the Native Messaging setup, and then use the group policy editor to handle the actual installation of the extension.
In general, we don't recommend that installers modify the registry to install an extension. We would rather the user consent to that install.