Microsoft Edge 156.0.4314.42

This policy specifies URL patterns where developer tools are blocked. For information [removed: on][added: about] the URL format, see https://go.microsoft.com/fwlink/?linkid=2095322. [added: Developer tools availability is evaluated for each target being inspected. ]URL patterns are [removed: evaluated][added: matched] against the [removed: URL of every frame on the page being inspected. If any frame matches][added: target's URL, such as a page, a subframe represented by a separate target, an extension, or] a [removed: pattern in this policy, developer tools are blocked for the entire page.][added: web application. Frames that share a target follow that target's policy result.] If you configure this policy and do[removed: no][added: n']t configure the 'DeveloperToolsAvailabilityAllowlist' (List of URL patterns [removed: for which ][added: where ]developer tools are [removed: allowed to be opened) ][added: allowed) ]policy, developer tools are blocked [removed: when any frame matches][added: for targets whose URLs match] a pattern in this [removed: policy.][added: blocklist.] If [removed: no frames][added: a target's URL doesn't] match, availability is determined by the 'DeveloperToolsAvailability' (Control where developer tools can be used) policy.[added: For example, a subframe represented by a separate target can't be inspected if its URL matches this blocklist, while the main-page target remains inspectable if its URL isn't blocklisted and the fallback policy allows inspection.] If you configure both this policy and the 'DeveloperToolsAvailabilityAllowlist' policy, the allowlist takes precedence. [removed: URLs that match][added: A target whose URL matches] the allowlist [removed: are][added: is] allowed, even if [removed: they][added: it] also match[added: es] this policy. [removed: URLs that match][added: A target whose URL matches] this policy [removed: (]but not the allowlist[removed: ) are][added: is] blocked. If a [added: target's ]URL matches neither[added: list], the 'DeveloperToolsAvailability' policy determines availability. If you disable or do[removed: no][added: n']t configure this policy, developer tools availability is determined by the 'DeveloperToolsAvailabilityAllowlist' and 'DeveloperToolsAvailability' policies. This policy [added: applies to developer tools, direct Chrome DevTools Protocol (CDP) connections (for example, using --remote-debugging-port or --remote-debugging-pipe), and CDP connections through the chrome.debugger extension API. The 'RemoteDebuggingAllowed' (Allow remote debugging) policy controls whether remote debugging can start. When remote debugging is allowed, this policy still restricts which targets can be inspected. This policy ]supports up to 1,000 entries.[added: On Android, this policy controls inspection of targets through remote debugging. It does not enable on-device developer tools.] Example value: https://contoso.com contoso.com https://ssl.server.com contoso.com/bad_path https://server.contoso.com:8080/path .exact.hostname.com * file://*

[added: The ]unload event handlers are being deprecated. Whether they fire depends on the unload Permissions-Policy. Currently, the policy allows them by default. In the future, they [removed: move to being ][added: will be ]disallowed by default, and sites must explicitly enable them using Permissions-Policy headers. This enterprise policy can be used to opt out of this gradual deprecation by forcing the default to [removed: stay][added: remain] enabled. Pages might depend on unload event handlers to save data or to signal the end of a user session to the server. This dependency isn't recommended because it's unreliable and impacts performance by blocking use of BackForwardCache. Recommended alternatives exist, but the unload event has been used for a long time. Some applications might still rely on them. If you disable this policy or don't configure it, unload event handlers are gradually deprecated in-line with the deprecation rollout, and sites that don't set Permissions-Policy header stop firing `unload` events. If you enable this policy, the unload event handlers continue to work by default.

This policy configures Microsoft Edge to order its preferred encryption ciphers in TLS 1.3 based on algorithms approved by a specific compliance regime. Setting this policy does not guarantee that any specific algorithms will be negotiated. This policy allows server operators who support both compliant and non-compliant clients to differentiate between them, and use certain non-default algorithms with increased cryptographic strength only for clients explicitly configured to prefer them. Setting the policy to 'cnsa' configures Microsoft Edge 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 Microsoft Edge to use its default ciphers. Setting this policy isn't required for security. The default cryptography used by Microsoft Edge is strong enough to withstand a brute-force attack using the entire power of the Sun. Setting this policy will cause Microsoft Edge to be slower when accessing websites. This policy only affects TLS 1.3 and QUIC. It doesn't 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 Microsoft Edge 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. ]Policy options mapping: * CNSA (cnsa) = Prefer ciphers satisfying the requirements of CNSA 1.0 and 2.0 * Default (default) = Use Microsoft Edge's default cipher order Use the preceding information when configuring this policy. Example value: cnsa

This policy configures Microsoft Edge to prioritize certain key agreement algorithms (supported groups) in TLS 1.3 based on compliance requirements. If you set this policy to 'cnsa2', Microsoft Edge prefers the algorithms required for the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0). If you leave this policy unset or set it to 'default', the browser uses its standard key exchange order. This policy does not guarantee negotiation of a specific algorithm. It is designed to help server operators distinguish clients with compliance requirements and apply higher-strength, non-default algorithms only when appropriate. This policy applies only to TLS 1.3 and QUIC. The default cryptography used by Microsoft Edge already provides strong security, but enabling this policy may reduce performance when accessing websites. [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 Microsoft Edge 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. ]Policy options mapping: * CNSA2.0 (cnsa2) = Prefer key exchange methods satisfying the requirements of CNSA 2.0 * Default (default) = Use Microsoft Edge's default supported groups Use the preceding information when configuring this policy. Example value: cnsa2

Controls whether users can use remote debugging. If you enable or don't configure this policy, users can use remote debugging by specifying --remote-debug[added: ging]-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 you disable this policy, users aren't allowed to use remote debugging.

This policy setting lets you configure the timeout, in seconds, after which inactive background tabs are automatically put to sleep if sleeping tabs is enabled. By default, this timeout is [removed: 7,200][added: 900] seconds [removed: (2 hours).][added: (15 minutes). When energy saver is active, Microsoft Edge uses the shorter of this timeout and the energy saver timeout. The energy saver timeout is 5 minutes in maximum savings mode. In other active modes, it's 30 minutes, or 15 minutes on devices with less than 6 GB of memory.] Tabs are only put to sleep automatically when the policy 'SleepingTabsEnabled' (Configure sleeping tabs) is enabled or isn't configured, and the user has enabled the sleeping tabs setting. If you don't configure this policy, users can choose the timeout value. Policy options mapping: * 30Seconds (30) = 30 seconds of inactivity * 5Minutes (300) = 5 minutes of inactivity * 15Minutes (900) = 15 minutes of inactivity * 30Minutes (1800) = 30 minutes of inactivity * 1Hour (3600) = 1 hour of inactivity * 2Hours (7200) = 2 hours of inactivity * 3Hours (10800) = 3 hours of inactivity * 6Hours (21600) = 6 hours of inactivity * 12Hours (43200) = 12 hours of inactivity Use the preceding information when configuring this policy.

This policy setting lets you configure the timeout, in seconds, after which inactive background tabs are automatically put to sleep if sleeping tabs is enabled. By default, this timeout is [removed: 7,200][added: 900] seconds [removed: (2 hours).][added: (15 minutes). When energy saver is active, Microsoft Edge uses the shorter of this timeout and the energy saver timeout. The energy saver timeout is 5 minutes in maximum savings mode. In other active modes, it's 30 minutes, or 15 minutes on devices with less than 6 GB of memory.] Tabs are only put to sleep automatically when the policy 'SleepingTabsEnabled' (Configure sleeping tabs) is enabled or isn't configured, and the user has enabled the sleeping tabs setting. If you don't configure this policy, users can choose the timeout value. Policy options mapping: * 30Seconds (30) = 30 seconds of inactivity * 5Minutes (300) = 5 minutes of inactivity * 15Minutes (900) = 15 minutes of inactivity * 30Minutes (1800) = 30 minutes of inactivity * 1Hour (3600) = 1 hour of inactivity * 2Hours (7200) = 2 hours of inactivity * 3Hours (10800) = 3 hours of inactivity * 6Hours (21600) = 6 hours of inactivity * 12Hours (43200) = 12 hours of inactivity Use the preceding information when configuring this policy.

[added: The ]unload event handlers are being deprecated. Whether they fire depends on the unload Permissions-Policy. Currently, the policy allows them by default. In the future, they [removed: move to being ][added: will be ]disallowed by default, and sites must explicitly enable them using Permissions-Policy headers. This enterprise policy can be used to opt out of this gradual deprecation by forcing the default to [removed: stay][added: remain] enabled. Pages might depend on unload event handlers to save data or to signal the end of a user session to the server. This dependency isn't recommended because it's unreliable and impacts performance by blocking use of BackForwardCache. Recommended alternatives exist, but the unload event has been used for a long time. Some applications might still rely on them. If you disable this policy or don't configure it, unload event handlers are gradually deprecated in-line with the deprecation rollout, and sites that don't set Permissions-Policy header stop firing `unload` events. If you enable this policy, the unload event handlers continue to work by default.