Published: November 19, 2024
At Google I/O 2024, we shared some early designs for upcoming changes to the extensions menu, which give users more control over the sites extensions can access. We're going to start testing these changes soon, beginning with a small percentage of users in Canary and with the hope to roll them out more widely in the future.
When talking to developers about this change in the past, we often heard concerns about the impact of changing the way extensions are able to request host permissions at install time. The new menu does not impact any default behavior. Extensions will continue to be granted access to all requested hosts at install time. The goal of these changes is to make it easier for users to discover controls that are already available.
This post gives an overview of what to expect and how you can prepare your extensions with a new API to handle cases where access to a page has been withheld by the user.
What's changing?
To give users more control, we will introduce a new extensions menu. Extensions will continue to be granted access to all requested hosts at install time, but users will now have an easier way to control access per extension.
The new menu (pictured with the current design which may change) more clearly shows which extensions can run on a page, and gives users the ability to change access if chosen. A user can also prevent all extensions from running on a specific site. As mentioned, none of the available settings or defaults are changing–we are focused on making what we already have easier for users to discover.
Add a site access request
We have designed a new API to complement these changes, with significant input from other browsers and developers in the WebExtensions Community Group.
If a user has withheld access to a page, extensions can now request access using the new permissions.addSiteAccessRequest API. When an extension does this, the user will see an "Allow" message alongside the extension puzzle piece in the toolbar. Here's one design we are exploring:
When a user clicks "Allow" within the extensions menu, the extension is granted persistent access to the host. The user can withhold it again in the future by accessing the extensions menu or on the chrome://extensions page. Clicking "Allow 1?" within the toolbar provides a faster way to grant immediate access.
Extensions can call permissions.addSiteAccessRequest with a tabId to show a permission request for that tab. You can use feature detection to safely begin using it in your extension today. The API won't do anything for users without the new menu, but adopting it will benefit users with the new menu as it is gradually rolled out.
chrome.tabs.onUpdated.addListener(async (tabId, changes) => {
if (typeof changes.url !== 'string') return;
const url = new URL(changes.url);
// If we are on the /checkout page of example.com.
if (url.origin === 'https://example.com' && url.pathname === '/checkout') {
const hasPermission = await chrome.permissions.contains({
origins: ['https://example.com/*']
});
// We already have host permissions.
if (hasPermission) {
return;
}
// Add a site access request if the API is available.
if (chrome.permissions.addSiteAccessRequest) {
chrome.permissions.addSiteAccessRequest({ tabId });
}
}
});
In this example, we only add a request if the user is on the /checkout page. You can see the full code in our chrome-extensions-samples repository.
Extensions should be mindful about when to ask users for access. Users are more likely to ignore noisy requests and Chrome might throttle excessive requests. A user can also choose to turn off the ability for an extension to show requests. As a result, you should only request access in specific situations, when you have high confidence the user will want to engage with your extension.
Requests are bound to a specific tab and are automatically cleared when a user navigates to a different origin. A corresponding removeSiteAccessRequest method is available to clear a request explicitly (such as if a request is bound to a particular path).
Since this API is linked with the new extensions menu, calls will be ignored if the new menu is not enabled. However, we encourage you to try the API today, and consider adopting it in your extension. You'll provide a great user experience as the new menu changes gradually show for more users.
To learn more about working with optional permissions, check out the permissions documentation.
Try it out
The API is enabled by default in Chrome 133.0.6838.0 and higher (currently in Chrome Canary). To enable the new menu, at chrome://flags, enable the "Extensions Menu Access Control" flag.
As a reminder, this is still work in progress and may continue to evolve and change. We recommend testing in Chrome Canary to see the most up to date experience.
You can leave feedback on the new design in the chromium-extensions mailing list which we'll be keeping in mind as we continue work on the new menu.