Signed Extended Preferences

Entitlement: signedExtendedPrefs. This capability requires a valid signed Extended Preferences file. It does not authorize chrovia.prefs or individual configured features; those require their own entitlements.

Obtain a compatible file

Ask the provider of your License for the signed-configuration delivery procedure for your deployment. Supply your License ID and the complete browser configuration you want to use. If you do not have an agreed delivery procedure, contact Chrovia support before enabling this capability. The browser does not offer a command or JavaScript method to sign a file.

Obtain a complete Extended Preferences file compatible with your License. Do not combine the signature from one file with configuration from another, or use an unsigned documentation example unchanged.

Install and verify

1. Fully quit the browser instance, including any process left running after its windows close.
2. Back up its current Extended Preferences file.
3. Put the supplied file in the root directory passed to --user-data-dir, not its Default subdirectory. Keep the exact filename, without .json or .txt.
4. Launch with the intended License and check the configured feature, such as the instance label.
5. If you also have extendedPrefs, read a known application field from your Provision Service Worker. A missing value alone does not diagnose a signature problem; also check the License, file location, field name, and API context.

For new instances, you may place the file in the Provision root as a default. It is copied only when the instance has no Extended Preferences file. Replacing the Provision default does not update existing instances.

Change configuration or renew an expired file

Send the complete revised configuration to your configuration provider and obtain a replacement signed file. Install it while the instance is closed, then restart and verify the change. Follow the same procedure when the file expires or you replace the License with one requiring a different configuration delivery arrangement.

Do not edit internal or the supplied signature object in an issued file. Local edits and prefs.set() calls do not renew its signature. A change that appears to work during the current run can prevent preferences from loading on the next launch.

Keep application data editable

Put application fields that need runtime writes outside internal, alongside it. For example, my_plugin.ready can be updated independently of protected browser settings. Preserve those application fields when replacing the file if your application still needs them.

A signed file is not a secret vault. People with file access and authorized preferences consumers can read its contents. Restrict access and do not log sensitive values.

Handle invalid configuration

Missing, modified, incompatible, or expired signed configuration prevents all Extended Preferences reads and writes, including application fields outside internal. prefs.get() can return undefined, and writes can resolve without changing anything. These methods are not signature-status APIs.

Check the exact filename and instance directory, confirm that the file and License belong to the same deployment, and restore an unmodified compatible file. If it is expired or you need different settings, obtain a replacement rather than editing the issued file.

Software passkey registration and sign-in can update protected credential data. If you combine local passkeys with signed preferences, arrange for an updated signed file before the next launch; backing up a credential alone is not enough. See software authenticator.

See EP storage and APIs and License installation.