Proposal "Allow to change permissions behavior on extension updates"

[oleksiilevzhynskyi]

Context

During a recent WECG meeting ("Upgrade Permissions" section), we discussed a #711 and Proposal for "Hybrid Permissions". The group agreed that the current behavior with "warning" is suboptimal and needs to be updated. Also, the group decided that adding a new manifest key for permissions doesn't make sense. Instead, we may add a property that will suppress permissions warning behavior and fall to "optional" behavior for new permissions during the update.

Proposal Summary

Add a new property, permissions_behavior.updates, to the manifest to specify how browsers should act when extension updates introduce new permissions. When set to defer, new permissions will behave as if specified in optional_permissions for existing. They are not requested or granted on update thus must be explicitly requested by the extension. The default browser behavior will NOT be applied (warning, turn off, stop further updates, etc.).

The new behavior is not applicable during install time or for permissions that do not trigger a warning.

Extension manifest file example:

{
  "permissions_behavior": {
    "updates": "defer"
  }
}

To use the original browser's behavior, use "auto" or omit "updates" or "permissions_behavior" properties:

{
  "permissions_behavior": {
    "updates": "auto"
  }
}

or

{
  "permissions_behavior": {}
}

Open questions

• Double-check the name. Is it clear?
• What should happen when the extension is already turned off or further updates are suppressed due to a permission warning? Should new property work retroactively and "restore" extension?

[xeenon]

Thanks for the proposal — the behavior makes sense and generally aligns with what Safari does (we disable extensions on update if they cross a permission threshold, but without showing warnings).

That said, I think the property name could be more flexible. suppress_permissions_warning_on_update is a bit too UI/UX specific and doesn’t map well in all browsers.

At the Berlin meeting, an enum was suggested — I think something like this would scale better:

"permissions_behavior_on_update": "defer"

This is more future-proof and avoids locking us into a UI-specific interpretation.

I plan to have a more detailed review of the proposal soon.

[oleksiilevzhynskyi]

"permissions_behavior_on_update": "defer"

@xeenon, thank you; that's a great point! Enum permissions_behavior_on_update makes much more sense!

I've updated the proposal's name and wording to account for the new name and value.

[xeenon]

"permissions_behavior_on_update": "defer"

@xeenon, thank you; that's a great point! Enum permissions_behavior_on_update makes much more sense!

I've updated the proposal's name and wording to account for the new name and value.

@oleksiilevzhynskyi You will want to define the opposite value too. "disable", "prompt", "warn", …?

[carlosjeurissen]

Thanks for the initial proposal doc!

@xeenon would advocate for auto as well to have a neutral explicit default value.

[carlosjeurissen]

Probably disregard; however want to mention it, we could be further future-proofed by making it an object.

{
  "permissions_behavior": {
    "updates": "defer",
  }
}

allowing other types of permission behaviours we might want to introduce in the future.

[oleksiilevzhynskyi]

Hey @xeenon @carlosjeurissen. Thank you for the comments. I updated the proposal with a new "permissions_behavior" namespace and added an "auto" value that represents the current (default) permissions behaviour during update. Please take another look.

The only part of the proposal I'm unsure of is what should happen when the extension is turned off or further updates are suppressed due to a permission warning. Would the browser be able to "restore" such an extension if the next version has "defer"? This will provide a way to rescue unintended permissions updates, but this may not be feasible from the implementation side.

[oleksiilevzhynskyi]

@xeenon, thank you!

As promised, I filled in the section about rescue for extension "blocked" due to a warning. Could you check if it makes sense? 995df62

[Optional feature] What if extension was already turned off due to the permission "warning", but updates to a new version with "permissions_behavior.updates" set to "defer"

We would like to provide a way to rescue an extension blocked by unintended permission updates or the accidental removal of permissions_behavior.updates. It should be possible to restore the extension by publishing an updated version of the extension with permissions_behavior.updates set to defer.

However, we cannot confirm the timeline of such a feature in this proposal. It remains for the browser vendor to decide if it's feasible to implement and when to implement it.

[carlosjeurissen]

@oleksiilevzhynskyi alternative which would be backwards compatible is another key as discussed here:
#711 (comment)

However this can be confusing during the transition period.

[oleksiilevzhynskyi]

@oleksiilevzhynskyi alternative which would be backwards compatible is another key as discussed here: #711 (comment)

However this can be confusing during the transition period.

Agreed. The proposed change will result in a suboptimal experience for users of older browsers that do not support it.

Your comment reminded me about the "Hybrid permissions" proposal. The idea is similar to permissions_on_install from your comment and is backward compatible. The concern about it was that the new permissions key adds an ambiguity and may cause everyone to abandon the permissions key at all.

[Rob--W]

Do you anticipate more keys in permissions_behavior?

I'm wondering whether it makes more sense to specify the update_behavior instead. For this, I can see more general utility, e.g. specifying a desired minimum supported extension version. For example, a dev could use this if they know older versions to be harmfully broken (e.g. breaking websites or security issues), or simply if they want to discontinue support for ancient versions.

Example of revised object:

  "update_behavior": {
    "new_permissions_are_optional": true
  }

The following is NOT a must-have, but just for illustration why it would be useful for update_behavior to be the top-level key:

  "update_behavior": {
    "minimum_extension_version": "1.2.3",
    "new_permissions_are_optional": false
  }

The minimum_extension_version in the above example would default to "0" in Firefox (to accept any previous extension),
whereas in Chrome it could default to the new extension's version (disable older versions).

[carlosjeurissen]

Added notes on host_permissions

[carlosjeurissen]

@Rob--W one argument in favor of permissions_behavior instead of update_behavior is mentioned in:
#116 (comment)

Having the ability to change how host permissions should be prompted / if content script matches should be added to host_permissions or not.

[carlosjeurissen]

@oleksiilevzhynskyi could you follow up on some of the suggested changes?

@oliverdunk do you have some thoughts on this PR from the Chrome side?

[oleksiilevzhynskyi]

(deleted)

[oleksiilevzhynskyi]

Hey. Here is a summary of the discussion and the current status

1. permissions_behavior object provides a room for extensibility without the need to bump the manifest. The current proposal adds updates. Additionally, #116 (comment) proposes the possibility to add "content_scripts": "suppress".

"permissions_behavior": {
   "updates": "defer",
   "content_scripts": "suppress" // Not a part of this proposal
}

2. [Important] permissions_behavior isn't backward compatible, as it will only work starting from the browser version that supports it; older versions will simply ignore it.

Next steps:

• on upcoming "WebExtensions CG" agreed on"backward compatibility" concern (2).
• browser vendors to review and agree on the proposal

[carlosjeurissen]

@oleksiilevzhynskyi to give a clear alternative for the discussion, a backwards compatible way of dealing with the permissions could be a new permissions_on_install.

permissions_on_install would be an array of permissions just like other permission containers like permissions and optional_permissions.

Permissions in permissions_on_install will be prompted to the user on installation similar to the current browser behaviour for permissions. With the difference being during an update. If an extension updates with additional permissions in permissions_on_install, new permissions will not be prompted to existing users. Only to new users. This covers the initial use case of this proposal.

In addition, if permissions_on_install is present and understood by the browser. The prompting behaviour of the permissions key and match patterns in content_scripts will be suppressed. This would allow for maximum backwards compatibility while opening up for the new behaviour for new browser versions.

Since the presence of permissions_on_install would downgrade permissions to being optional. Eventually the optional_permissions key could be dropped and all permissions not in permissions_on_install be treated as optional.