Chrome browser changes
3P profile enrollment migrates to OIDC auth code flow
Chrome 135 migrates the landing page for profile registration from the marketing website to a dynamic website. This update also migrates the OpenID Connect (OIDC) implicit flow to an auth code flow. This aims to improve both the security and the user experience for third party (3P) managed profiles.
Chrome 135 on Windows
Auto-deletion of downloads for Chrome on iOS
Users of Chrome browser on iOS can now choose to automatically delete their browser downloads on a scheduled basis.
This feature is likely to both improve device performance related to storage capacity, and to improve privacy by automating the deletion of files that users might otherwise forget to on their own.
Chrome 135 on iOS
Initial experiment at 1% in 135 for Chrome for iOS only. No planned rollout for other platforms.
Initial experiment at 1% in 135 for Chrome for iOS only. No planned rollout for other platforms.
Better password form detection with ML
Chrome 135 introduces a new client-side Machine Learning (ML) model to better parse password forms on the web to increase detection and filling accuracy. You can control this feature using the PasswordManagerEnabled policy.
Chrome 135 on Android, iOS, ChromeOS, Linux, macOS, Windows
Client’s LLM assistance in mitigating scams
Users on the web are facing significant amounts and varieties of scams on a daily basis. To combat these scams, Chrome 135 uses on-device Large Language Models (LLMs) to identify scam websites for Enhanced protection users. Chrome sends the page content to an on-device LLM to infer security-related signals for that page.Chrome then sends these signals to Safe Browsing server side for a final verdict. When turned on, Chrome might consume more bandwidth to download the LLM.
Chrome 134 on Linux, macOS, Windows
Gather the brand name and intent summary of the page that requested keyboard lock API to identify scam websites.
Chrome 135 on Linux, macOS, Windows
Show the warnings to the user based on the server verdict which uses the brand and intent summary of the page that requested keyboard lock API.
Deprecate mutation events
Synchronous mutation events, including DOMSubtreeModified, DOMNodeInserted, DOMNodeRemoved, DOMNodeRemovedFromDocument, DOMNodeInsertedIntoDocument, and DOMCharacterDataModified, negatively affect page performance, and also significantly increase the complexity of adding new features to the Web. These APIs were deprecated from the spec in 2011, and were replaced (in 2012) by the much better-behaved Mutation Observer API. Usage of the obsolete mutation events must be removed or migrated to Mutation Observer.
Since Chrome 124, a temporary enterprise policy, MutationEventsEnabled, is available to re-enable deprecated or removed mutation events. To read more, see this Chrome for Developers blog post. If you encounter any issues, you can file a Chromium bug.
Mutation event support is disabled by default, since Chrome 127, or around July 30, 2024. Code should have been migrated before that date to avoid site breakage. If more time is needed, there are a few options:
The Mutation Events Deprecation Trial can be used to re-enable the feature for a limited time on a given site. This can be used up until Chrome 135, ending March 25, 2025.
A MutationEventsEnabled enterprise policy can also be used for the same purpose, also through Chrome 135.
Chrome 135 on Android, Linux, macOS, Windows: The MutationEventsEnabled enterprise policy will be deprecated.
Download file type extension-based warnings - documentation correction
Google updated the policy documentation for ExemptDomainFileTypePairsFromFileTypeDownloadWarnings to correctly reflect its interaction with the DownloadRestrictions policy. The behavior in Chrome has not changed.
The behavior is: ExemptDomainFileTypePairsFromFileTypeDownloadWarnings can specify exemptions that override DownloadRestrictions settings for blocking dangerous file types. Other types of security measures specified by DownloadRestrictions, such as blocking malicious downloads, cannot be overridden by ExemptDomainFileTypePairsFromFileTypeDownloadWarnings.
Chrome 135 on ChromeOS, Linux, macOS, Windows
No Chrome changes - documentation change only.
Extensions improvements on Chrome Desktop
On Chrome 135 on Desktop, some users who sign in to Chrome when installing a new extension can now use and save extensions in their Google Account.
Relevant enterprise policies controlling extensions, as well as BrowserSignin, SyncDisabled or SyncTypesListDisabled, continue to work as before, so admins can configure whether users can use and save items in their Google Account.
For more information about how to use extensions on any computer, see Install and manage extensions in the Chrome Web Store Help Center.
Note: This change is a follow-up to the launch of the new identity model on Chrome Desktop. For more details, see Sign in and sync in Chrome.
Chrome 135 on Linux, macOS, Windows
Generic Device Trust Connector
Integrations created through the Device Trust Connector allow customers to implement granular controls for authentication into enterprise resources, for example, SaaS apps or your corporation intranet, based on the properties of the end user’s device and browser instance sent by Chrome. For more details, see Manage Chrome Enterprise device trust connectors.
Chrome 135 on Windows
Remove Private Network Access enterprise policies
Private Network Access (PNA 1.0) is an unshipped security feature designed to limit website access to local networks. Due to deployability concerns, PNA 1.0 was never able to ship by default, as it was incompatible with too many existing devices.
PNA 1.0 required changes to devices on local networks. Instead, Chrome is implementing an updated proposal, Private Network Access 2.0 (PNA 2.0). PNA 2.0 only requires changes to sites that need to access the local network, rather than requiring changes to devices on the local network. Sites are much easier to update than devices, and so this approach should be much more straightforward to roll out.
The only way to enforce PNA 1.0 is via enterprise policy. To avoid regressing security for enterprise customers opting-in to PNA 1.0 prior to shipping PNA 2.0, Google will maintain the PrivateNetworkAccessRestrictionsEnabled policy, which causes Chrome to send special preflight messages, until such time that it becomes incompatible with PNA 2.0.
Chrome 135 removes the InsecurePrivateNetworkRequestsAllowedForUrls and InsecurePrivateNetworkRequestsAllowed policies, which loosen PNA 1.0 restrictions. These policies currently have no effect, since PNA 1.0 is not shipped, and they will have no meaning once PNA 1.0 is removed.
PNA 2.0 is described in this explainer on GitHub.
Chrome 135 on Android, ChromeOS, Linux, macOS, Windows, Fuchsia
Removal of InsecurePrivateNetworkRequestsAllowedForUrls and InsecurePrivateNetworkRequestsAllowed policies.
Chrome 137 on Android, ChromeOS, Linux, macOS, Windows, Fuchsia
Removal of PrivateNetworkAccessRestrictionsEnabled.
Remove ThirdPartyBlockingEnabled policy
Due to unexpected issues, Google plan to remove the ThirdPartyBlockingEnabled policy in Chrome 135. If you have feedback about this removal, you can file a Chromium bug.
Chrome 132 on Windows
Deprecation of ThirdPartyBlockingEnabled policy
Chrome 135 on Windows
Removal of ThirdPartyBlockingEnabled policy
Settings, site shortcuts, and themes improvements on Chrome Desktop
On Chrome 135 on Desktop, for users who newly sign in to Chrome or who have Sync enabled, settings, site shortcuts and themes synced to their Google Account will now be kept separate from the local ones, that is, settings from when they’re signed out or when Sync is turned off.
This allows for strictly less data sharing than previously: local settings don’t get automatically uploaded when signing in or turning on Sync, and no settings from the account are left behind on the device when Sync is turned off.
Existing enterprise policies SyncDisabled and SyncTypesListDisabled will continue to apply so admins can restrict or disable the Sync feature if they want to. For more details, see Manage who can sync browser settings.
Note: This change is a follow-up to the launch of the new identity model on Chrome Desktop.
Chrome 135 on Linux, macOS, Windows
Sunsetting the legacy Password Manager in Chrome on Android
Users with old versions of Google Play Services will lose Password Manager functionality in Chrome. This is a step towards sunsetting the legacy Password Manager in Chrome on Android. These users can download a CSV file with their passwords from Chrome Settings and import it to their preferred Password Manager. The new Google Password Manager is available on devices with a recent version of Google Play Services.
Chrome 135 on Android
Third-party cookies always blocked in Incognito mode
Starting in Chrome 135, users have third-party cookies blocked in Incognito mode with no way to globally re-enable them. Site-level controls for allowing third-party cookies will not be changed.
With this launch, the BlockThirdPartyCookies policy applies to regular mode only when set to false, not Incognito mode. There are no changes when the policy is true or unset. There are also no changes to the CookieAllowedForUrls policy, which continues to apply in both regular and Incognito modes, as it applies at the site level and not globally.
Chrome 135 on Android, ChromeOS, Linux, macOS, Windows
Create service worker client and inherit service worker controller for srcdoc iframe
Srcdoc context documents were previously not service worker clients and were not covered by their parent page’s service worker. This resulted in some discrepancies (for example, Resource Timing reports the URLs that these documents load, but the service worker doesn’t intercept them).
To fix these discrepancies, Chrome 135 creates service worker clients for srcdoc iframes and makes them inherit the parent page's service worker controller.
Chrome 135 on Windows, macOS, Linux, Android
HSTS tracking prevention
HTTP Strict Transport Security (HSTS) allows sites to declare themselves accessible through secure connections only.
In Chrome 135, HSTS tracking prevention mitigates user tracking by third-parties using the HSTS cache. It only allows HSTS upgrades for top-level navigations and blocks HSTS upgrades for sub-resource requests. This prevents third-party sites using the HSTS cache to track users across the web. For more information, see this HSTS Tracking Prevention explainer on Github.
Chrome 135 on Windows, macOS, Linux, Android
Remove deprecated navigator.xr.supportsSession method
Chrome 135 removes the navigator.xr.supportsSession method, which was replaced in the WebXR spec by the navigator.xr.isSessionSupported method in September of 2019 after receiving feedback on the API shape from the TAG. It has been marked as deprecated in Chromium since then, producing a console warning redirecting developers to the updated API.
Usage of the call is very low, as shown by Chrome Status usage metrics. Additionally, all major frameworks that are used to build WebXR content have been confirmed to have been updated to use the newer call.
Chrome 135 on Windows, macOS, Linux, Android
New policies in Chrome browser
Policy - Description
- DownloadRestrictions - Blocks malicious downloads and dangerous file types
- PartitionedBlobUrlUsage - Choose whether Blob URLs are partitioned during fetching and navigations
- ExtensibleEnterpriseSSOBlocklist - Blocklist of identity providers that cannot use Extensible Enterprise SSO for the browser
- EnterpriseSearchAggregatorSettings - Enterprise search aggregator settings (Beta)
- ProfilePickerOnStartupAvailability - Profile picker availability on startup
Removed policies in Chrome browser
Policy - Description
- ThirdPartyBlockingEnabled - Enable third party software injection blocking
- KeyboardFocusableScrollersEnabled - Enable keyboard focusable scrollers
Source: Google
Comments
Post a Comment