Automatically grant https: host_permissions with http:

[carlosjeurissen]

Background

Currently when an extension has host_permissions specified in the http: protocol, this causes issues when requests happen to be using / being upgraded to https:. This blocks upgrading to a secure environment and is a blocker for #303.

Solution

let http: permissions be an umbrella host permission which also includes https: permissions. Basically threat it as a synonym for *://example.com/. This assures no downgrades happen without permission warnings, yet fixes the issue above. For a user, there does not seem to be a clear disadvantage of not being able to notice protocol updates from permission warnings, only confusion.

[Rob--W]

While I mentioned this problem in the context of #303, this issue is not unique to the topic there. The same issue occurs when a website itself redirects (e.g. with HTTP Strict-Transport-Security, or a regular 3xx redirect to a secure scheme). That's why extension developers should use *://host/* instead of http://host/* to avoid the issue.

The potential solution was described in the meeting, as:

[rob] Note that we also need to consider the desired behavior when an extension has requested http:- host permissions but not https. Upgrading requests without having granted https:-permission would result in the request being blocked for the lack of permissions. Note that the permission warnings (e.g. in Chrome and Firefox) don’t even show the scheme to users, so an option is to also grant https permissions when http is specified.

[carlosjeurissen]

@Rob--W Thanks for clarifying. Updated the issue to reflect this.

[xeenon]

Safari does this currently. Granted permissions from the UI are always *://*.domain/ patterns that are formed by what the extension asks for in the manifest. I think the only exception is origins directly requested from the extension via the permissions.request() API, those are as-is currently.

[rdcronin]

I don't think this is something we'd want to support in Chromium.

There's a few concerns I have here:

• It makes the manifest harder to understand and parse for review, both by humans and automated systems.
• It makes it less clear to developers when permissions are used and in which contexts
• It makes it impossible for developers to self-restrict, say to only run on insecure contexts

While I understand that this would potentially reduce the breakage mentioned in issue 303, I don't think it's worth adding another exception and less-predictable behavior. I think we can handle the breakage from issue 303 through appropriate messaging to developers and outreach, and that would be more desirable in the long-term than supporting this going forward. Developers can always opt into this themselves (by just specifying ://example.com/ in their manifests).

(I know that the permission warnings a user sees already omit the scheme, but I still think it's valuable for developers / admins / browsers to be able to treat http://example.com and https://example.com as different from an extension permissions perspective.)

[Rob--W]

Safari does this currently. Granted permissions from the UI are always *://*.domain/ patterns that are formed by what the extension asks for in the manifest.

If a manifest only requests https (without http) and the user grants host permissions, would the extension be granted http permissions too? That behavior is what this issue is requesting.

If not, and the extension requests http and https permissions in an extension update, would the new http permission automatically be granted too?
If not, how does user approval look like? The UI cannot show the permission as off or on, because both are (partially) true.

Note that this issue is not about granting https+http when the manifest has specified both. It is entirely reasonable for an extension to receive permissions for the http(s)+ws(s) schemes when specified in the manifest AND confirmed by the user.

I agree with @rdcronin 's concerns above. Extensions with unexpected host access may behave unexpectedly. These concerns have longer-lasting impact than a one-time effort to get everyone to replace "http:" with "https:" in their extension.

If Chrome is willing to help their share of the extensions to migrate to the https: permission when needed, then I see no point in automatically treating http://xx/* as *://xx/* (= http://xx/* + https://xx/*). Firefox hasn't signed any MV3 extensions yet, so developers who build extensions should notice if anything breaks, and fix the issue by replacing http: with https: before publishing the extension.

[carlosjeurissen]

@rdcronin @Rob--W Thanks for your replies! Seems some of the responses are based on misunderstandings.

Let me comment and clarify:

(robwu) If a manifest only requests https (without http) and the user grants host permissions, would the extension be granted http permissions too? That behavior is what this issue is requesting.

This is not what this issue is about. My proposal was to ONLY do upgrades. So:
http://* and *://* would grant both http://* and https://*
While for obvious security reasons, https://* would not grant http://* (a downgrade)

(robwu) If not, and the extension requests http and https permissions in an extension update, would the new http permission automatically be granted too?

Yes. It seems to make sense to consider collapsing host permissions here. Not sure this hold true in all browsers, but requesting http://* and https://* at the same time should be treated equally to requesting *://*. In the same sense, with this proposal, requesting just http://* would be treated the same as above.

(robwu) If not, how does user approval look like? The UI cannot show the permission as off or on, because both are (partially) true.

See above.

(rdcronin) It makes the manifest harder to understand and parse for review, both by humans and automated systems.

This seems subjective. To me it is more confusing *://* grants only the http and https protocols, than it is http://* would also grant https://*.

(rdcronin) It makes it less clear to developers when permissions are used and in which contexts.

Why so? granted host_permissions specify what an extension can do, while match patterns and globs in for example content_scripts specify what an extension wants to do. The distinction seems already pretty clear.

(rdcronin) It makes it impossible for developers to self-restrict, say to only run on insecure contexts

Self-restricting is already possible by specifying only http:// in content_script matches or globs. I do not see a need to upgrade those as well. The issue is only about granting the https:// host permissions.

(rdcronin) less-predictable behavior
(robwu) Extensions with unexpected host access may behave unexpectedly.

What is this less-predictable behaviour? Not sure what negative side effects you are referring to.

(rdcronin) I think we can handle the breakage from issue 303 through appropriate messaging to developers and outreach, and that would be more desirable in the long-term than supporting this going forward. Developers can always opt into this themselves (by just specifying ://example.com/ in their manifests).

To me it seems very important we make sure not to break extensions when a relatively easy way of preventing this is available. Already many extensions exists on the stores which got broken by changes in the platform. Not every extension is actively maintained and not every author has the resources to constantly keep up with all the changes.

(rdcronin) I know that the permission warnings a user sees already omit the scheme, but I still think it's valuable for developers / admins / browsers to be able to treat http://example.com/ and https://example.com/ as different from an extension permissions perspective.

Developers / admins / browsers can already actively restrict http and https based on the CSP they define and the match patterns they use for content scripts. Can you describe what the value would be here?