Re: Request for comments: Permission Delegation to Iframes

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.

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