Permission Delegation

[shhnjk]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Permission Delegation
• Specification or proposal URL: https://groups.google.com/d/msg/mozilla.dev.platform/BdFOMAuCGW8/-fqk-MWIAQAJ

Other information

Permission Delegation is not a standard or specification. But recently Firefox announced the intent to prototype Permission Delegation. I would like to know the Mozilla Position of Permission Delegation, and why would you like to do it (also why without a spec or a standard).

Most important points IMO to consider are:

1. Simplify prompts/dialogs to only contain the top-level origin (even if permission request is from cross-origin iframe).
2. No way for top-level frame to disable delegation if iframe's allow attribute is controlled and top-level frame requires that permission.

[nils-ohlmeier]

@shhnjk I think a clarification would help here: I see Permission Delegation as part of Feature Policy. We have already a position on Feature Policy her #24.

So is your question about implementing feature policy, or only about the UI part of how we are going to handle the frontend pieces of expressing this in permission prompts?

[shhnjk]

Feature Policy defines new ways to allow/restrict the access to powerful features from cross-origin iframe, and also how to restrict certain features in own origin.

But I think Feature Policy doesn't talk about:

1. How permission prompt should be displayed (including which origin).
2. Whether or not permission acquired by top frame should be delegated to cross-origin iframe if an allow attribute is present.

Those things are defined by Permission Delegation (IMO, let me know if I'm wrong), which means it's not defined in any spec or standard.

I'm asking the Mozilla Position on those things.

[shhnjk]

• Mozillians who can should provide input (optional): @mozfreddyb 😜

[annevk]

I think you're right that standards-wise there are various loose ends to tie up and we've suggested at times to merge Feature Policy into Permissions, but as far as I know Chrome ships a very similar thing.

Also, both your 1 and 2 above are very much up to the discretion of the user agent as they are defined today so what Firefox plans to ship here is well within bounds.

[shhnjk]

but as far as I know Chrome ships a very similar thing

Yes, but I'm asking about Mozilla Position😊

Also, both your 1 and 2 above are very much up to the discretion of the user agent as they are defined today so what Firefox plans to ship here is well within bounds.

So what's the Mozilla Position here? It's up to the UA, so it doesn't matter and no security consideration is required?

[annevk]

I'm not sure I understand the question in the last paragraph.

Mozilla's position on the UI to present to users is similar to that of Chrome. I think we currently differ in how we want to treat wildcards (Firefox will prompt "again" in a way that should be somewhat clear to the user), but Jan-Ivar opened an issue against Feature Policy to discuss that further.

[shhnjk]

Mozilla's position on the UI to present to users is similar to that of Chrome.

So does Mozilla think this is a good solution? By showing top-frame origin in the prompt even though request comes from cross-origin iframe, you are removing the indicator of which origin is requesting access.

I think we currently differ in how we want to treat wildcards (Firefox will prompt "again" in a way that should be somewhat clear to the user)

Could you explain more? What would happen if top-frame origin already has access to camera and it has <iframe allow="camera" src="//cross-origin.tld">? Would cross-origin iframe automatically gets permission without prompt or would that require another prompt?

[annevk]

If cross-origin.tld requests access it would not result in another prompt. We generally think this is good as it puts the blame with the top-level origin, who could already via postMessage() accomplish much the same thing.

Also, showing lots of prompts leads to dialog fatigue and showing prompts for third parties is generally confusing as they're pretty much an implementation detail of the site.

[shhnjk]

If cross-origin.tld requests access it would not result in another prompt. We generally think this is good as it puts the blame with the top-level origin, who could already via postMessage() accomplish much the same thing.

Your scenario seems to only consider about top frame being evil, but there's also a possibility that top frame is vulnerable to HTML injection. Implementing Permission Delegation would allow HTML injection to delegate all permission top frame has, to cross-origin iframe. This means no matter how strong the CSP script-src mitigation is (to mitigate potential XSS), attacker can still steal all permissions. Which is bad.

[johannhof]

Hey Jun, thanks for your input. I don't really think this is the right forum to discuss this question (this repo is for discussing our official stance on external standards/proposals, not to challenge product/engineering decisions) and I'm not sure why you're confused about our position when we've just published an intent to ship a few days ago.

I left an extensive explanation about our motivation on the dev-platform thread you also commented on https://groups.google.com/forum/#!topic/mozilla.dev.platform/BdFOMAuCGW8

It's probably a better idea to continue discussing there.

Thanks!

[dbaron]

Based on the discussion above, I think it makes sense to close this.

However, feel free to reopen (or ask us to -- not sure if you can directly) if you think an official Mozilla position on this is still needed beyond what's already been stated -- and with an explanation of why such a position is needed.