Re: Request for comments: Permission Delegation to Iframes

On Fri, Mar 18, 2016 at 6:18 PM, Raymes Khoury <raymes@google.com> wrote:

> Hey Tanvi and RIchard, thanks for the replies! I think there’s a few main
> issues being discussed here, I’ll try to address them:
>
> 1. With respect to the question of how an embedded frame would request
> permissions: I think we’ve made this really unclear in the draft. But the
> original idea was that if an embedder delegates a permission to an embedee,
> but the embedder does not yet have access itself, then a request from the
> embedee would trigger a prompt on behalf of the embedder. As you mentioned
> Richard, the request would always be presented in terms of the top-level
> context. This is exactly for the reason you suggest: so that developers
> don’t have to invent protocols to request permission.
>
> We also considered the alternative of firing events in the embedder when
> permissions are requested from an embedee. This would give an embedder the
> opportunity to handle the event or if the event bubbles to the top, it
> could automatically trigger a request as in the above paragraph. We felt
> this would add too much complexity for such a large change already and that
> we could consider adding this later.
>

Yeah, that's basically what I was imagining as well.  My preference would
be to just let the embeddee ask directly, and patch things up at the UX
layer.  Of course, the delegation statement should then act as a filter --
if the permission isn't delegated, then the embeddee shouldn't be able to
request it.

--Richard


> 2. With respect to a user’s decision for a top-level frame persisting when
> that frame is embedded: we have thought about an approach like this. While
> it is convenient for users in some situations (as you mentioned Tanvi) it
> can also be surprising in others. Take the (not so imaginary) example of a
> social networking site x.com. I may grant access to my mic/camera to x.com
> in order to do some video chat. But I would generally expect that when I
> close the x.com tab, it would no longer have access to my mic/camera. The
> problem is that x.com is very popular and has comment <iframe> widgets
> embedded on sites all over the web. As soon as I incidentally navigate to
> one of those many sites, x.com can listen-in on me without prompting. I
> find this very surprising.
>
> I think the issue Tanvi mentioned about needing to re-grant permission to
> an embedded site over and over does have the potential to cause a problem
> at some point. I think a more appropriate solution is "background
> permissions" (see
> https://docs.google.com/document/d/1iaocsSuVrU11FFzZwy7EnJNOwxhAHMroWSOEERw5hO0/edit#heading=h.7zbw0q59c4id
> ). The idea being that if the user understands that a particular permission
> will be used even while the site is not visibly open in a top level frame,
> then it would not be surprising for iframes (which may have no visible UI)
> to use that permission.
>
> 3. With respect to the proposal Tanvi suggested: I think that with any
> combination-scoping approach, it only really benefits users who understand
> composability. With the proposal you suggest, the embedder has control over
> whether an iframe can request permission. I think the idea is that this
> means users don't have to really know whether a prompt is coming from the
> iframe or the top-level frame because the top-level frame has expressed
> trust in the iframe (please correct me if I'm wrong). But if the user is
> making a decision based on their trust in the top-level frame, is it so bad
> if the top-level site also gets access as a result of the user's decision?
> I see this case as basically equivalent to the delegation proposal. You’re
> right though: for users who do understand composability, there is a
> benefit: they only give access to the site that needs it. However it comes
> at the cost of a more complicated model that is still going to be exposed
> to the user at some points, causing potential confusion, e.g.:
> -What if both the top level frame and the iframe request permission? The
> user will see two prompts
> -The combination of origins must be displayed in permission management UI,
> e.g. when clicking the lock icon, etc.
>
> It is unfortunate to have to give out permission more broadly than what is
> necessary. However, we see the two things as at odds with each other: we
> either have an easy to understand model which gives less control to the
> user or a more complicated model that gives more fine grained control.
>
> Thanks!
> Raymes
>
> On Sat, 19 Mar 2016 at 07:55 Tanvi Vyas <tanvi@mozilla.com> wrote:
>
>> On 3/18/16 12:46 PM, Richard Barnes wrote:
>>
>> Tanvi, I think you're kind of off-target here.
>>
>> On Fri, Mar 18, 2016 at 2:16 AM, Tanvi Vyas < <tanvi@mozilla.com>
>> tanvi@mozilla.com> wrote:
>>
>>> I understand the motivation behind this proposal.  Particularly, in the
>>> User Research study done[1], it is clear that users don't understand the
>>> difference between a top level page and an iframe.  However, there are a
>>> couple things that I don't like about this proposal that are a result of
>>> section 5[2]:
>>> * Assume google maps is embedded in yelp.  I want to give google maps my
>>> location, but not yelp.  With this proposal, there is no easy way of doing
>>> this (as described in section 8).
>>>
>>
>> This seems naïve.  One thing I like about this proposal is that it
>> acknowledges the reality that if a top-level page has a permission, then it
>> can *already* effectively delegate that permission to embedded pages with
>> enough JS.  This fact (or rather, its mirror image) is precisely why the
>> Secure Contexts spec has all the ancestor / ServiceWorker complexity.
>>
>> Yes it is true that if the top level page has a permission, it can
>> delegate it.  So in my example, if yelp.com was granted access to a
>> users location, it could grant that access to google maps.  But, if google
>> maps is granted access to a users location, it does not have to pass this
>> information to yelp.  With the original proposal, yelp has to have access
>> in order for google maps to have access.
>>
>>
>>
>>
>>> * Assume a user grants location access to google maps.  They later visit
>>> yelp.com, yellowpages.com, and tripadvisor.com.  They will get the
>>> geolocation permission prompt 3 more times on each of these pages, when
>>> before, their one time grant was enough.
>>>
>>
>> Given that the research indicates that the one-time grant wasn't what the
>> user actually meant, this seems like a feature, not a bug.
>>
>> In my example the user grants location access to google maps while it is
>> a top level site.  We could impose an additional restriction:
>> * If a permission is granted to a top level site, the permission persists
>> when that site is embedded in any origin.
>> * If a permission is granted to an embedded site, the permission does not
>> persist when that site is embedded in another context.  The user would have
>> to re-grant the permission.
>> This way, we honor users permissions decisions for top level pages (where
>> they presumably better understand what they are granting), and essentially
>> double-key permissions granted in frames.
>>
>>
>>
>>
>>> Here is another proposal that aims to handle some of the four reasons
>>> described in section 4:
>>> * Top level website can decide whether or not frames can request
>>> permissions with a frame attribute:
>>> <iframe id="embedee" src= <https://maps.example.com/>
>>> "https://maps.example.com/" <https://maps.example.com/>
>>> can-prompt-for-permissions="yes"></iframe>
>>>
>>
>> This is clearly insufficient.  Suppose the embedder sets
>> can-prompt-for-permissoins="no" -- how does the embedded page get any
>> permissions it needs?  Can it just not access any protected APIs?
>>
>>
>> That is the whole idea behind the original proposal.  An embedee can't
>> access any permissions without the embedders consent.  Reread section 5 -
>> https://noncombatant.github.io/permission-delegation-api/#permission-restrictions-for-embedded-web-applications
>>
>>
>>
>>> * If a user grants a permission for a top level site that is later
>>> embedded, the embedded site will still have the permission.
>>>
>>
>> This seems obvious; it's how I assumed this API would work anyway.
>>
>> The original proposal clearly states that this is not how the API will
>> work (again, see section 5).  This is one of my issues with the original
>> proposal, as noted above ("Assume a user grants location access..").
>>
>>
>>
>>
>>>
>>> With this proposal
>>> * An embedder has some control over how annoying an embedee can be.  It
>>> can allow trusted frames to prompt for permissions while denying access to
>>> less trusted frames.
>>> * The user makes their decision based off their trust for the top level
>>> site.  And the top level site decides what embedded content is trustworthy
>>> enough to prompt their users.
>>> * We avoid unnecessarily prompting the user for a site that is often
>>> embedded and that they have already granted permission for.
>>> * We honor the principal of least privileges, ensuring that only the
>>> site that needs the permission gets it.
>>>
>>> I also wonder if delegation is worth doing for all permission types.
>>>
>>
>> If we're going to do this, let's do it generically.
>>
>> --Richard
>>
>>
>>
>>>   Is Chrome collecting data on the percentage of mic/camera/pointer
>>> lock/etc permissions requested by frames?  Maybe we could restrict this to
>>> a subset of permissions.  Also, 3.5% seems high for notifications; do you
>>> have any examples of when an embedee would request notification access?
>>> That seems like a decision that can be better made when the user is
>>> actually visiting the top level site.
>>>
>>> Thanks!
>>>
>>> ~Tanvi
>>>
>>> [1]
>>> https://docs.google.com/presentation/d/1suzMhtvMtA11jxPUdH1jL1oPh-82rTymCnslgR3ehEE/edit
>>> [2]
>>> https://noncombatant.github.io/permission-delegation-api/#permission-restrictions-for-embedded-web-applications
>>>
>>>
>>>
>>> On 3/15/16 5:20 PM, Raymes Khoury wrote:
>>>
>>> Hi all,
>>>
>>> We're looking for comments and feedback on a proposal aimed at making
>>> the permissions model for iframes more understandable for people. User
>>> research suggests that currently people don't have a good understanding of
>>> who they are granting access to when permission requests come from iframes.
>>> Also, the way permission decisions are scoped for iframes is inconsistent
>>> (across permissions and across UAs), making behavior hard to predict. It's
>>> also difficult to build simple UI to communicate and manage iframe
>>> permissions.
>>>
>>> The idea of the proposal is to require an embedding origin to delegate
>>> permission to an iframe in order for the iframe to get access. Sites in
>>> iframes would not be able to access permissions unless they were delegated.
>>> This means that users would only be required to make permission decisions
>>> about the top level origin, which is simpler to understand. It also allows
>>> for simpler permission management UI.
>>>
>>> We've converted our initial proposal doc [1] into a draft spec, however
>>> this is far from final and we're seeking more discussion, feedback and
>>> other contributions from those interested:
>>>
>>> https://noncombatant.github.io/permission-delegation-api/
>>>
>>> The draft includes motivations, a discussion of security considerations
>>> and risks, requirements for delegation, as well as an iframe attribute and
>>> JS API to delegate permissions.
>>>
>>> Thanks,
>>> Raymes
>>>
>>> [1]
>>> https://docs.google.com/document/d/1iaocsSuVrU11FFzZwy7EnJNOwxhAHMroWSOEERw5hO0
>>>
>>>
>>>
>>
>>