Brave Browser: 1.96.61 to 1.98.60

This policy can be used to allow Chrome DevTools on specific URLs. Chrome DevTools availability is evaluated at the target level. URL patterns are matched against the URL of each target being inspected (such as the main frame of a page, an embedded subframe, an extension, or a web application). The resulting behavior depends on whether the DeveloperToolsAvailabilityBlocklist policy is also set. If this policy is set and DeveloperToolsAvailabilityBlocklist is not, a target's URL must match a pattern on this allowlist for Chrome DevTools to be allowed for that target. If a target's URL does not match this allowlist, Chrome DevTools will be blocked for that target (for example, a subframe whose URL is not on the allowlist cannot be inspected, but the main page remains inspectable if its URL is allowlisted). For information on the URL format, see https://support.google.com/chrome/a?p=url_blocklist_filter_format. If both this and the DeveloperToolsAvailabilityBlocklist policies are set, this allowlist takes precedence. If a target's URL matches a pattern on this allowlist, it will be allowed, even if it also matches a pattern in the blocklist. If a target's URL matches a pattern on [removed: the][added: this] blocklist (but not the allowlist), it will be blocked. If a target's URL matches neither, the DeveloperToolsAvailability policy will be used as a fallback. If this policy is not set, the availability of Chrome DevTools is determined by the DeveloperToolsAvailabilityBlocklist and DeveloperToolsAvailability policies. Blanket host wildcards (i.e., "*" or "[*]") are not allowed; use the DeveloperToolsAvailability policy to enable the feature globally.[added: This policy affects Chrome DevTools, direct Chrome DevTools Protocol (CDP) access (for instance, when launched with --remote-debugging-port or --remote-debugging-pipe), and Chrome DevTools Protocol (CDP) access via chrome.debugger APIs. Both this policy and the RemoteDebuggingAllowed policy apply: RemoteDebuggingAllowed controls whether remote debugging can start, while this policy restricts whether individual targets can be inspected even when remote debugging is running.] This policy is limited to 1,000 entries. Example value: example.com https://ssl.server.com hosting.com/bad_path https://server:8080/path .exact.hostname.com file://*

This policy can be used to block Chrome DevTools on specific URLs. For information on the URL format, see https://support.google.com/chrome/a?p=url_blocklist_filter_format. Chrome DevTools availability is evaluated at the target level. URL patterns are matched against the URL of each target being inspected (such as the main frame of a page, an embedded subframe, an extension, or a web application). The resulting behavior depends on whether the DeveloperToolsAvailabilityAllowlist policy is also set. If this policy is set and DeveloperToolsAvailabilityAllowlist is not, a target's URL matching a pattern on this blocklist will block Chrome DevTools for that target (for example, a subframe whose URL matches this blocklist cannot be inspected, but the main page remains inspectable if its URL is not blocklisted). If a target's URL does not match any pattern, the availability is determined by the DeveloperToolsAvailability policy. If both this and the DeveloperToolsAvailabilityAllowlist policies are set, the allowlist takes precedence. If a target's URL matches a pattern on the allowlist, it will be allowed, even if it also matches a pattern in this blocklist. If a target's URL matches a pattern on this blocklist (but not the allowlist), it will be blocked. If a target's URL matches neither, the DeveloperToolsAvailability policy will be used as a fallback. If this policy is not set, the availability of Chrome DevTools is determined by the DeveloperToolsAvailabilityAllowlist and DeveloperToolsAvailability policies. This policy [added: affects Chrome DevTools, direct Chrome DevTools Protocol (CDP) access (for instance, when launched with --remote-debugging-port or --remote-debugging-pipe), and Chrome DevTools Protocol (CDP) access via chrome.debugger APIs. Both this policy and the RemoteDebuggingAllowed policy apply: RemoteDebuggingAllowed controls whether remote debugging can start, while this policy restricts whether individual targets can be inspected even when remote debugging is running. This policy ]is limited to 1,000 entries. Example value: https://example.com example.com https://ssl.server.com hosting.com/bad_path https://server:8080/path .exact.hostname.com * file://*

Setting the policy to Enabled disallows screenshots taken with keyboard shortcuts or extension APIs. Setting the policy to Disabled or not set allows screenshots. [added: As of Brave version 154, enabling this policy also prevents extensions from attaching the debugger via 'chrome.debugger.attach()'. ]Note that on Microsoft® Windows®, macOS and Linux, this does not prevent screenshots that are taken with operating system or third party applications.

Setting the policy controls extension management settings for Brave, including any controlled by existing extension-related policies. This policy maps an extension ID or an update URL to its specific setting only. A default configuration can be set for the special ID "*", which applies to all extensions without a custom configuration in this policy. This policy can override per-extension config from legacy policies. Note that any per-ID extension setting from either ExtensionInstallForcelist, ExtensionInstallAllowlist, ExtensionInstallBlocklist, or ExtensionSettings will only inherit 'installation_mode' and 'update_url' from the "*" defaults. It will not inherit any other properties. With an update URL, configuration applies to extensions with the exact update URL stated in the extension manifest ( http://support.google.com/chrome/a?p=Configure_ExtensionSettings_policy ). If the 'override_update_url' flag is set to true, the extension is installed and updated using the "update" URL specified in the ExtensionInstallForcelist policy or in 'update_url' field in this policy. The flag 'override_update_url' is ignored if the 'update_url' is a Chrome Web Store url. [added: As of Brave version 154, applying 'runtime_blocked_hosts' to an extension with the 'debugger' permission will completely disable 'chrome.debugger.attach()' on all targets. ]On Microsoft® Windows® instances, apps and extensions from outside the Chrome Web Store can only be forced installed if the instance is joined to a Microsoft® Active Directory® domain, joined to Microsoft® Azure® Active Directory® or enrolled in Chrome Enterprise Core. On macOS instances, apps and extensions from outside the Chrome Web Store can only be force installed if the instance is managed via MDM, joined to a domain via MCX or enrolled in Chrome Enterprise Core. Note: This policy only applies to platforms that support extensions. See https://chromeenterprise.google/policies/?policy=ExtensionSettings for more information about schema and formatting. Example value: { "*": { "allowed_types": [ "hosted_app" ], "blocked_install_message": "Custom error message.", "blocked_permissions": [ "downloads", "bookmarks" ], "install_sources": [ "https://company-intranet/chromeapps" ], "installation_mode": "blocked", "runtime_allowed_hosts": [ "*://good.example.com" ], "runtime_blocked_hosts": [ "*://*.example.com" ] }, "abcdefghijklmnopabcdefghijklmnop": { "blocked_permissions": [ "history" ], "installation_mode": "allowed", "minimum_version_required": "1.0.1", "toolbar_pin": "force_pinned", "file_url_navigation_allowed": true }, "bcdefghijklmnopabcdefghijklmnopa": { "allowed_permissions": [ "downloads" ], "installation_mode": "force_installed", "runtime_allowed_hosts": [ "*://good.example.com" ], "runtime_blocked_hosts": [ "*://*.example.com" ], "update_url": "https://example.com/update_url" }, "cdefghijklmnopabcdefghijklmnopab": { "blocked_install_message": "Custom error message.", "installation_mode": "blocked" }, "defghijklmnopabcdefghijklmnopabc,efghijklmnopabcdefghijklmnopabcd": { "blocked_install_message": "Custom error message.", "installation_mode": "blocked" }, "fghijklmnopabcdefghijklmnopabcde": { "blocked_install_message": "Custom removal message.", "installation_mode": "removed" }, "ghijklmnopabcdefghijklmnopabcdef": { "installation_mode": "force_installed", "override_update_url": true, "update_url": "https://example.com/update_url" }, "update_url:https://www.example.com/update.xml": { "allowed_permissions": [ "downloads" ], "blocked_permissions": [ "wallpaper" ], "installation_mode": "allowed" } }

Master switch for Brave's local AI features (history embeddings and any future on-device AI surfaces). When this policy is set to true, the local AI feature surfaces (the [removed: chrome://history side bar toggle,][added: Semantic history search toggle in brave://settings/privacy,] the brave-history-embeddings chrome://flags entry, the EmbeddingGemma model component install, etc.) become available to the user. When this policy is set to false, every local AI surface is hidden and the on-device AI components are not installed. If you set this policy, users cannot change or override it. If this policy is left unset, local AI is enabled by default.

Controls whether users may use remote debugging. If this policy is set to Enabled or not set, users may use remote debugging by specifying --remote-debugging-port and --remote-debugging-pipe command line [removed: switches.][added: switches on desktop platforms, or by enabling the USB debugging system setting on Android.] If this policy is set to Disabled, users are not allowed to use remote debugging.

Setting the policy to [removed: True][added: Enabled] or leaving it unset lets users add, remove, modify, or upload bookmarks. Setting the policy to [removed: False][added: Disabled] means users can't add, remove, modify or upload bookmarks. They can still use existing bookmarks.

Allows you to set a list of site url patterns that specify sites which are allowed to run JavaScript with JIT (Just In Time) compiler enabled. For detailed information on valid site url patterns, please see https://chromeenterprise.google/policies/url-patterns. Wildcards, *, are allowed. [removed: JavaScript JIT][added: Policy exceptions can be set for specific subdomains as well as entire sites. For example, a] policy [removed: exceptions will][added: set for] only [added: subdomain.site.com applies to subdomain.site.com without affecting site.com. In some cases where a subdomain cannot ]be [removed: enforced at a site granularity (eTLD+1). A][added: isolated from its parent site, it may inherit the] policy set [added: on site.com. Exceptions may also not take effect ]for [removed: only subdomain.site.com][added: frames loaded in an existing tab until the site is opened in a new tab. On low-memory Android devices, site-specific exceptions may not be enforced, and sites] will [removed: not correctly apply][added: instead use the policy from DefaultJavaScriptJitSetting, if set, or default] to [removed: site.com][added: the profile's JavaScript JIT setting. To enforce exceptions, Brave may place sites or subdomains whose setting differs from the default into dedicated processes. This can increase memory usage, especially on Android] or [removed: subdomain.site.com][added: when a wildcard pattern matches many subdomains,] since [removed: they both resolve][added: each matching origin may be isolated separately. Isolated subdomains also cannot use document.domain] to [removed: the same eTLD+1 (site.com)][added: access their parent site. Note: In versions 155 and earlier, policy exceptions were only enforced at a site granularity (eTLD+1). A policy set] for [removed: which there is no policy. In this case, policy must][added: only subdomain.site.com did not take effect, even for subdomain.site.com; it had to] be set on site.com to apply [removed: correctly for ][added: to ]both site.com and subdomain.site.com. This policy applies on a frame-by-frame basis and not based on top level origin url alone, so e.g. if site-one.com is listed in the JavaScriptJitAllowedForSites policy but site-one.com loads a frame containing site-two.com then site-one.com will have JavaScript JIT enabled, but site-two.com will use the policy from DefaultJavaScriptJitSetting, if set, or default to JavaScript JIT enabled.[added: Blocklist entries have higher priority than allowlist entries, which in turn have higher priority than the configured default value.] If this policy is not set for a site then the policy from DefaultJavaScriptJitSetting applies to the site, if set, otherwise Javascript JIT is enabled for the site. Example value: [*.]example.edu

Allows you to set a list of site url patterns that specify sites which are not allowed to run JavaScript JIT (Just In Time) compiler enabled. Disabling the JavaScript JIT will mean that Brave may render web content more slowly, and may also disable parts of JavaScript including WebAssembly. Disabling the JavaScript JIT may allow Brave to render web content in a more secure configuration. For detailed information on valid url patterns, please see https://chromeenterprise.google/policies/url-patterns. Wildcards, *, are allowed. [removed: JavaScript JIT][added: Policy exceptions can be set for specific subdomains as well as entire sites. For example, a] policy [removed: exceptions will][added: set for] only [added: subdomain.site.com applies to subdomain.site.com without affecting site.com. In some cases where a subdomain cannot ]be [removed: enforced at a site granularity (eTLD+1). A][added: isolated from its parent site, it may inherit the] policy set [added: on site.com. Exceptions may also not take effect ]for [removed: only subdomain.site.com][added: frames loaded in an existing tab until the site is opened in a new tab. On low-memory Android devices, site-specific exceptions may not be enforced, and sites] will [removed: not correctly apply][added: instead use the policy from DefaultJavaScriptJitSetting, if set, or default] to [removed: site.com][added: the profile's JavaScript JIT setting. To enforce exceptions, Brave may place sites or subdomains whose setting differs from the default into dedicated processes. This can increase memory usage, especially on Android] or [removed: subdomain.site.com][added: when a wildcard pattern matches many subdomains,] since [removed: they both resolve][added: each matching origin may be isolated separately. Isolated subdomains also cannot use document.domain] to [removed: the same eTLD+1 (site.com)][added: access their parent site. Note: In versions 155 and earlier, policy exceptions were only enforced at a site granularity (eTLD+1). A policy set] for [removed: which there is no policy. In this case, policy must][added: only subdomain.site.com did not take effect, even for subdomain.site.com; it had to] be set on site.com to apply [removed: correctly for ][added: to ]both site.com and subdomain.site.com. This policy applies on a frame-by-frame basis and not based on top level origin url alone, so e.g. if site-one.com is listed in the JavaScriptJitBlockedForSites policy but site-one.com loads a frame containing site-two.com then site-one.com will have JavaScript JIT disabled, but site-two.com will use the policy from DefaultJavaScriptJitSetting, if set, or default to JavaScript JIT enabled.[added: Blocklist entries have higher priority than allowlist entries, which in turn have higher priority than the configured default value.] If this policy is not set for a site then the policy from DefaultJavaScriptJitSetting applies to the site, if set, otherwise JavaScript JIT is enabled for the site. Example value: [*.]example.edu

Allows you to set a list of site url patterns that specify sites for which advanced JavaScript optimizations are enabled. For detailed information on valid site url patterns, please see https://chromeenterprise.google/policies/url-patterns. Wildcards, *, are allowed. [removed: JavaScript optimization policy exceptions will only be enforced at a site granularity (eTLD+1). A][added: Policy exceptions can be set for specific subdomains as well as entire sites. For example, a] policy set for only subdomain.site.com [added: applies to subdomain.site.com without affecting site.com. In some cases where a subdomain cannot be isolated from its parent site, it may inherit the policy set on site.com. Exceptions may also not take effect for frames loaded in an existing tab until the site is opened in a new tab. On low-memory Android devices, site-specific exceptions may not be enforced, and sites ]will [removed: not correctly apply][added: instead use the policy from DefaultJavaScriptOptimizerSetting, if set, or default] to [removed: site.com][added: the profile's JavaScript optimization setting. To enforce exceptions, Brave may place sites or subdomains whose setting differs from the default into dedicated processes. This can increase memory usage, especially on Android] or [removed: subdomain.site.com][added: when a wildcard pattern matches many subdomains,] since [removed: they both resolve to the same eTLD+1 (site.com) for which there is no policy.][added: each matching origin may be isolated separately. Isolated subdomains also cannot use document.domain to access their parent site. Note:] In [removed: this case,][added: versions 138 and earlier, policy exceptions were only enforced at a site granularity (eTLD+1). A] policy[removed: must][added: set for only subdomain.site.com did not take effect, even for subdomain.site.com; it had to] be set on site.com to[removed: ][added: ]apply [removed: correctly for ][added: to ]both site.com and[removed: ][added: ]subdomain.site.com. This policy applies on a frame-by-frame basis and not based on top level origin url alone, so e.g. if site-one.com is listed in the JavaScriptOptimizerAllowedForSites policy but site-one.com loads a frame containing site-two.com then site-one.com will have JavaScript optimizations enabled, but site-two.com will use the policy from DefaultJavaScriptOptimizerSetting, if set, or default to JavaScript optimizations enabled. Blocklist entries have higher priority than allowlist entries, which in turn have higher priority than the configured default value. If this policy is not set for a site then the policy from DefaultJavaScriptOptimizerSetting applies to the site, if set, otherwise Javascript optimization is enabled for the site. Example value: [*.]example.edu

Allows you to set a list of site url patterns that specify sites for which advanced JavaScript optimizations are disabled. Disabling JavaScript optimizations will mean that Brave may render web content more slowly. For detailed information on valid url patterns, please see https://chromeenterprise.google/policies/url-patterns. Wildcards, *, are allowed. [removed: JavaScript optimization policy exceptions will only be enforced at a site granularity (eTLD+1). A][added: Policy exceptions can be set for specific subdomains as well as entire sites. For example, a] policy set for only subdomain.site.com [added: applies to subdomain.site.com without affecting site.com. In some cases where a subdomain cannot be isolated from its parent site, it may inherit the policy set on site.com. Exceptions may also not take effect for frames loaded in an existing tab until the site is opened in a new tab. On low-memory Android devices, site-specific exceptions may not be enforced, and sites ]will [removed: not correctly apply][added: instead use the policy from DefaultJavaScriptOptimizerSetting, if set, or default] to [removed: site.com][added: the profile's JavaScript optimization setting. To enforce exceptions, Brave may place sites or subdomains whose setting differs from the default into dedicated processes. This can increase memory usage, especially on Android] or [removed: subdomain.site.com][added: when a wildcard pattern matches many subdomains,] since [removed: they both resolve to the same eTLD+1 (site.com) for which there is no policy.][added: each matching origin may be isolated separately. Isolated subdomains also cannot use document.domain to access their parent site. Note:] In [removed: this case,][added: versions 138 and earlier, policy exceptions were only enforced at a site granularity (eTLD+1). A] policy[removed: must][added: set for only subdomain.site.com did not take effect, even for subdomain.site.com; it had to] be set on site.com to[removed: ][added: ]apply [removed: correctly for ][added: to ]both site.com and[removed: ][added: ]subdomain.site.com. This policy applies on a frame-by-frame basis and not based on top level origin url alone, so e.g. if site-one.com is listed in the JavaScriptOptimizerBlockedForSites policy but site-one.com loads a frame containing site-two.com then site-one.com will have JavaScript optimizations disabled, but site-two.com will use the policy from DefaultJavaScriptOptimizerSetting, if set, or default to JavaScript optimizations enabled. Blocklist entries have higher priority than allowlist entries, which in turn have higher priority than the configured default value. If this policy is not set for a site then the policy from DefaultJavaScriptOptimizerSetting applies to the site, if set, otherwise JavaScript optimization is enabled for the site. Example value: [*.]example.edu

This policy configures Brave to order its preferred encryption ciphers in TLS 1.3 to reflect a preference for algorithms that have been approved by a specific compliance regime. Setting this policy does not guarantee that any specific algorithms will be negotiated. This policy exists to allow server operators who wish to support clients with and without compliance requirements to differentiate between those clients, and only use certain non-default algorithms with increased cryptographic strength for those explicitly configured to prefer them. Setting the policy to 'cnsa' configures Brave to prefer ciphers required for compliance with the Commercial National Security Algorithm Suite versions 1.0 and 2.0 (CNSA 1.0 and 2.0). Not setting the policy, or setting it to 'default', configures Brave to use its default ciphers. Setting this policy is not required for security. The default cryptography used by Brave is strong enough to withstand a brute force attack using the entire power of the Sun. Setting this policy will cause Brave to be slower when accessing websites. This policy only affects TLS 1.3 and QUIC; it does not affect earlier versions of TLS. [added: This policy can be set for the machine and for the user. If set for the user, this policy only affects network requests initiated by the user profile, and may not affect network requests made by Brave to carry out browser-wide background tasks; those are controlled by the machine-level value. If this policy is set at both the machine level and the user level, the machine-level value applies, unless the policy precedence order has been changed by the CloudUserPolicyOverridesCloudMachinePolicy policy. For versions 155 and below, this policy is machine-wide only. ]Example value: cnsa

This policy configures Brave to order its preferred key agreement algorithms (supported groups) in TLS 1.3 to reflect a preference for algorithms that have been approved by a specific compliance regime. Setting this policy does not guarantee that any specific algorithms will be negotiated. This policy exists to allow server operators who wish to support clients with and without compliance requirements to differentiate between those clients, and only use certain non-default algorithms with increased cryptographic strength for those explicitly configured to prefer them. Setting the policy to 'cnsa2' configures Brave to prefer key exchange methods required for compliance with the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0). Not setting the policy, or setting it to 'default', configures Brave to use its default key exchange methods. Setting this policy is not required for security. The default cryptography used by Brave is strong enough to withstand a brute force attack using the entire power of the Sun. Setting this policy will cause Brave to be slower when accessing websites. This policy only affects TLS 1.3 and QUIC; it does not affect earlier versions of TLS. [added: This policy can be set for the machine and for the user. If set for the user, this policy only affects network requests initiated by the user profile, and may not affect network requests made by Brave to carry out browser-wide background tasks; those are controlled by the machine-level value. If this policy is set at both the machine level and the user level, the machine-level value applies, unless the policy precedence order has been changed by the CloudUserPolicyOverridesCloudMachinePolicy policy. For versions 155 and below, this policy is machine-wide only. ]Example value: cnsa2