WIP: Proposal "Allow to change permissions behavior on extension's update"

[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_on_update," to the manifest to alter the newly added "permissions" behavior during the extension's update. When set to "defer," newly added permissions on update won't be granted by default; they will behave like optional permissions and must be explicitly requested by the extension. Also, the default browser behavior will NOT be applied (warning, turn off, stop further updates, etc.).

The new behavior isn't applicable during install time or for permission that doesn't trigger a warning.

Extension manifest file example:

{
  "permissions_behavior_on_update": "defer"
}

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.