1697151 - Remove feature policy and permission delegation prefs

Status: RESOLVED FIXED

(Core :: DOM: Security, task, P3)

Description

[Emma Zühlcke [:emz]]

We've enabled feature policy and permission delegation since the 74 release (Bug 1617219).

Permission delegation simplifies permission UI complexity for enabled permissions, since we no longer need to present and handle the frame permission state. If we want to start removing special handling for frame permissions in our frontend site permission code we need to remove the prefs to avoid breakage.

Prefs to be removed:

dom.security.featurePolicy.enabled
permissions.delegation.enabled

Comment 1

[Thorin [:thorin]]

Hi Paul

I understand the overhead/complexity should you wish to rip it out, but is it possible to leave permissions.delegation.enabled in, as toggling this allows the user to see the real third partyness of the request. For non-technical users, not having scary 3rd parties named is great. But for technical and privacy-minded folks, showing the real party is important. Thanks :)

Comment 2

[Johann Hofmann [:johannh]]

Hey Simon, to add a bit of context here:

The reason why ripping out the pref is necessary is because we are now (and will be in the future) adding code that relies on permission delegation being enabled. In the concrete example that prompted us to file the bug, we add a temporary allow permission for WebRTC access on the browser object when a media stream ends. This temporary permission should very much follow delegation rules to be consistent and secure.

Supporting a non-delegation option doesn't just mean displaying the third-party origin in the permission prompt. It affects how permission are handled across the browser, and puts a burden on our teams. I'm not going to force developers to support disabled code paths, so sooner or later we're going to have a security bug that affects all users that have permission delegation disabled. I'd like to avoid that :)

for technical and privacy-minded folks, showing the real party is important.

So, I think this aspect is a bit overrated from a strict threat model point of view. Since you need to trust the first party enough not to postMessage the third party your data (then you might as well trust it not to set the "allow" attribute), this only works when you say "I would trust frame.com embedded in top-level.com to handle my data but not top-level.com itself". This kind of case might exist somewhere, but generally it's probably fair to say that you should not be using this first party anyway then, given the vast power it has as a first party to try to manipulate you.

Comment 3

[Thorin [:thorin]]

Thanks Johann for the info. That's cool. Sorry for the noise... just one a couple of quick q's

My concern was that if you go to firstparty and it prompts to allow camera+mic as firstparty (but it's really from good3rdparty) and you permanently allow it, then what happens the next time when you go to that site and it auto allows, but now the 3rd party is actually evil3rdparty? Or site using awesomeprivatemaps (no logs, no tracking) changes to using makemoneymaps (the opposite). It doesn't have to be malicious per se. Is there something else going on here behind the scenes re origin attributes that prevents this? FS isn't an issue IMO, but the other delegation permissions (geo/camera+mic - that's all of them right?) have privacy/fingerprinting concerns.

Feel free to email me rather than make more noise here :) TIA

Comment 4

[Johann Hofmann [:johannh]]

Yeah, I see your point about permanent permissions there (and there's another one around "what if one of the parties is compromised"). There is no protection for this case, in the same way that we can't protect you from the "good" third party streaming your camera data to some other evil third party when it has permission.

This is really a question of whether you personally prefer to trust the first party or the third party, and the answer to that will always differ case-by-case. In your scenario, it's not clear why firstparty should be the one mishandling your data but not good3rdparty. You decided to trust someone there, but how did you come to make that decision? We have found that generally it's much easier for regular users to make this decision based on the first party rather than the third party (and it's also the web that we want to build for all users, power or not, where they don't need to think about the concept of third parties).

And you might agree with me that without permission isolation (which is just hard because the UI would be incredibly complex) you'll also not be sure whether good3rdparty should really have access to your devices all around the web, wherever it might be embedded (see also https://lists.mozilla.org/pipermail/dev-platform/2019-December/025050.html).

However, I don't think there's any point in discussing FP/PD now, we have decided in favor of it and are now at the point where adding new code might add security bugs to the old code path and thus would like to remove that :)

Comment 5

[Gregory Pappas [:gregp]]

Attachment: Bug 1697151 - Remove permissions.delegation.enabled pref r?pbz!

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/51f4e647256d
Remove permissions.delegation.enabled pref r=pbz

Comment 7

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/51f4e647256d