Re: Request for comments: Permission Delegation to Iframes

On Wed, Mar 16, 2016 at 8:22 PM, Raymes Khoury <raymes@google.com> wrote:

> 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.
>

Oh sure, from a UX POV, I can understand what you're saying.  I was
imagining that the prompt would just identify the top-level site as the
recipient of the permissions.  But in any case, let's set aside the
proposal for a moment and let me ramble a bit.

I'm feeling a bit better about this after reading the document some more --
Section 9.3 in particular helped clarify some things.  There are still a
couple of major things making me uneasy:

1. The permissions model needs to be much clearer here.  I like the phrase
"permissions adhere to the embedder", but you need to explain how it fits
in the overall permissions model for the web, because it's a pretty
significant update.  There are now two types of permissions that a page can
have -- ones that the web origin has for itself, and ones that flow down
from the top-level context.  It might help to frame this as an update to
the Permissions API.

2. "The embedder itself MUST access to the permission, or must request it
of the user" (must *have* access, I assume) Is this necessary?  Or can we
let embeddees do the requesting, and let the market sort out which ones are
not too annoying?  There's no issue with presenting the top-level context
as the recipient of the permission in the UX; we've already established
that the embedder is the source of all permissions.  And you could suppress
requests for non-delegated permissions.  If we do have this restriction,
then we should have a way for the embed to declare what permissions it
wants, so that developers don't have to invent a protocol for embeds to
request permissions.

--Richard




>
> 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.
>>
>