Preparing for Big Changes to Chrome App Ecosystem

As I’ve been catching up on the changes Simeon Vincent, (Developer Advocate @ Google) announces in his talk, I’ve been asked what these changes will mean to extension developers and Product Managers. This is my humble attempt at providing a written summary on how we can be better prepared.

Although there are 2 changes coming up:

  1. Host Permission Changes
  2. Manifest V3

This summary only focusses on #1. For more on Manifest V3, checkout this Google reference.

To confirm this summary is relevant to you, let’s start with a definition of host permissions (more details here)

Host Permission: a chrome extension requesting access to inject custom javascript when the user is on specific websites. This surfaces to users in the form of the following message seen when users download the extension:
Read and change all your data on the websites you visit

If you never intend on requesting host permissions from your extension, this article may be more academic than useful for you.

Why the Change?

User privacy and safety is of highest importance, and unfortunately not all extensions are well-intentioned. Malicious extensions abuse host permissions to gain access to user’s web data to do whatever they want with it.

In the fewest words, not all extensions are well-intentioned, and malicious extensions abuse host permissions to gain access to your web data to do whatever they want with it.

Host Permission Changes

Let me break this down by doing a comparison of the current state, to the proposed future state. But before that, a quick definition of host permissions (more details here)

Current State

Current install screen for extension requesting host permissions
  1. When downloading a new extension, a user either accepts all the extension permissions (including host permissions) by clicking “Add Extension”, or cancels the installation process by clicking “Cancel”.
  2. Users must go into extension settings after downloading to limit which scenarios allow the extension to have host permissions:
    - allow extension to access all sites
    - allow extension to access specific sites — user can enter allowed URLs in a text box
    - allow access to the site “On Click” (same as “Invoking the App”)

Invoking the app: Open the app by doing one of the following:
1. Click on the browser action menu
2. Call the app from a context menu (right-click on the page to see an extension option)
3. Keyboard shortcut

3. Due to #1 and the slightly more buried nature of updating settings as described in #2, it is generally safe to assume that once a user has installed an extension, the extension will have access to the hosts it requests (as defined in the manifest.json file)

Future State

WIP by Google: Proposed install screen for extension requesting host permissions
  1. When downloading an extension, the default selection when accepting host permissions will be “On extension activation” (or similar). “On extension activation” means the same as “Invoking the app” above. With this selection, the user must first “invoke the app”, and reload the page. The extension now has host access as long as the user continues to use that site on that tab. The same site on a different tab or different site on the same tab will require the user to “Invoke the app” and reload again.
  2. The user can still go to the extension setting to change permission behaviour like before. No change to current state.
  3. Due to #1 and #2, it is unwise to assume that your extension will have host permissions post install (as defined in manifest.json). For this reason, Google advises us to embrace the “Runtime Permission Model”.

Runtime Permission Model: Rather than expect that you will receive all of the permissions that you request, embrace the idea that you will gain and lose permissions at runtime, based on the users choices.

When are these changes expected to go live?

Google has yet to announce an official date. We can expect to see these changes in Chrome Canary well before it rolls out in production.

Tips For Continued Success:

The video provides some great ways to be better prepared for these changes and offers a few strategies to better embrace the “Runtime Permission Model”.

If your app is one that revolves around user engagement by first “invoking the app”, consider using the activeTab permission instead.

activeTab: Gives an extension temporary access to the currently active tab when the user invokes the extension

Using the above, you no longer need to worry about whether the user has provided host access or not, you can be sure that as soon as the user “invokes the app” you can access the host site (without the user needing to reload).

The onboarding flow is a great time to convey your extension’s value propositions to the user. You can offer the user a button on this page to re-request host permissions, now that you have explained what functionalities the user can unlock by doing so.

Google is considering more options that can help the development community adapt to the changes, some of which include:

  • Declarative Net Request API: Allows users to block or modify network requests without needing access to site data. Allows content blockers to continue to function without having to give them any host permissions
  • Dynamic Content Scripts: Greater flexibility of script injection on defined hosts allowing to run when and where the user wants
  • New Contextual Entry Points: For example, declarative badging will allow extensions to badge content on a site with an icon to let the user know they can use your extension.


A push for a more secure browsing experience is in the collective interest of Google, extension developers and extension users. As such, extension developers should accept the “Runtime Permission Model”, as this will minimize the impact on extension usage, while keeping user security top-of-mind.



Founder (in stealth) — helping people become more productive