Re: Request for comments: Permission Delegation to Iframes

Thanks Richard!

> Do we even need an API here?  It seems like you could achieve the same
> effect with less back-and-forth / code changes by stipulating that
> permissions requested from iframe are only valid in the scope of the
> top-level page.

I'm assuming you mean scoping the permission to the combination of
top-level and requesting origin? I don't think that achieves the same
effect as this proposal. We already use that model for several permissions
in Chrome and it's problematic. One of the main problems we're trying to
address is that users don't understand composability very well. They don't
know what it means for an embedded origin to request permission: they don't
understand who they are giving access to and it's unclear how that decision
will persist. When that decision is persisted, we have to expose it in the
UI ("granted geolocation to x.com embedded in y.com"). That is hard for
people to understand too. These are some of the problems we're trying to
address which are inherent to combination scoping.

With this proposal, people would only have to grant/manage permissions for
the top-level origin. This is a model people have a better chance of
understanding. The responsibility for sharing permission with an iframe is
given to the embedder of the iframe. This is why a delegation API is
necessary.

Cheers,
Raymes

On Thu, 17 Mar 2016 at 08:53 Chris Palmer <palmer@google.com> wrote:

> On Wed, Mar 16, 2016 at 1:02 PM, Richard Barnes <rbarnes@mozilla.com>
> wrote:
>
>
>> This seems like something for the market to sort out (i.e., don't use
>> annoying embeds), rather than a compelling reason to build an API.
>>
>
> Well, say an embedder wanted to find out if any of its embedees were being
> annoying. Wouldn't it be great to be able to install handlers for "embedee
> requested permission X"? (A previous draft included that; we could add it
> back.)
>
> And, sites that want to find out the hard way ;) if their embedders could
> delegate all permissions always — it could be as free-wheeling as it is
> today. (A previous draft also had a "*" pseudo-permission, to grant all.
> Again, if there is interest, we could add that back.
>
> It's hard for me to see that giving embedders knowledge and control is a
> bad thing, especially given the observed problem that people who use web
> apps are not generally aware that web apps are composed from pieces from
> different origins. And, it's hard for me to see how we could do that
> without an API.
>
> And it's not clear to me that the proposed API does much for this
>> problem.  It seems like you would have to say that using permission="..."
>> would disable prompts for permissions not on that list, i.e., that you
>> can't mix and match delegated with traditional permissions.  Which of
>> course also has its own transition issues.
>>
>
> Right, without explicit delegation the embedee would not even be able to
> ask. And, yes, there would be transition issues, but as mentioned, the
> deployed base is small... for now.
>
> One can imagine that an embedder might install an event handler to capture
> "embedee tried to ask for Foo permission", and then the embedder could have
> logic to decide if they want to let the request go through. Again, we could
> add event handlers to the draft for that, if people are interested.
>