891281 - nsPermissionManager should allow distinguishing between http and https

Status: RESOLVED DUPLICATE of bug 1165263

(Core :: Permission Manager, defect)

Description

[Georg Fritzsche [:gfritzsche]]

When using nsPermissionManager to store & test permissions, we can't differentiate between permissions set for http & https.

This would e.g. be sensible in the case of click-to-play plugin permissions (see bug 887773).

Comment 1

[Benjamin Smedberg]

I think this request was for the permission manager to distinguish these all the time (by default). I'm not sure what led to the current design, though.

Comment 2

[[e-mail]]

I don't think there's been a compelling use case for it prior, which means the behavior has mirrored how cookies work and users think: if they add permissions for a page, they don't generally care whether it's http or https. Making that distinction to the user is unnecessary and confusing, in general, though I'm sure one can think of exceptions. Cookies historically also do not distinguish between http and https (other than the 'secure' extension) which was what PM was designed around originally. In other words, Keep It Simple.

I don't see any problem in principle with adding support for it to the backend, but you'll have to be very, very careful that you don't introduce confusing user-facing behavior (what happens when they add a permission for a site -- is it http, https or both? how do you surface http/https-specific permissions to them? how do they edit those? in a pageload involving mixed http/https elements, how do you make it clear to them that some elements aren't working as they expect because the http and https permissions aren't the same?) and you don't break existing contracts (e.g. with cookies). PM is used all over the place in-product and in extensions. So, yeah. Think hard and carefully.

Comment 3

[Georg Fritzsche [:gfritzsche]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #1)
> I think this request was for the permission manager to distinguish these all
> the time (by default). I'm not sure what led to the current design, though.

Jesse, can you clarify this and possibly extend on the background here?
I think i might have not fully understood your concerns.

Comment 4

[Jesse Ruderman]

When I allow something dangerous (e.g. Java) for a secure site, I don't want MITM attackers to be able to use the same permission.

Comment 5

[Georg Fritzsche [:gfritzsche]]

So this would be about per-scheme permissions for specific use-cases, not for everything, right?

Comment 6

[Jesse Ruderman]

If we're comfortable dividing "security-relevant" permissions from "pure annoyance" permissions, I guess.  Edge cases include geolocation (private for some people) and full screen (phishing).

Comment 7

[Dão Gottwald [:dao]]

How would a UI such as about:permissions handle this?

Comment 8

[:Gijs (he/him)]

Michael, didn't this get fixed in bug 1173523 for 42+ ?

Comment 9

[Nika Layzell [:nika] (ni? for response)]

Specifically this was fixed by bug 1165263, which switched the internal representation to one which can differentiate http and https.