Re: Request for comments: Permission Delegation to Iframes

> On 18 Mar 2016, at 20:55, Tanvi Vyas <tanvi@mozilla.com> wrote:
> 
> Yes it is true that if the top level page has a permission, it can delegate it.


The embedded content can also pass the information up to the top-level page with:

parent.postMessage()



With the Google Maps example, as a user, if I want directions from my current location to the displayed location, either the top-level page, or the embedded page, can ask for the geolocation permission.

For most users, they are thinking about giving that permission to the top-level page (who can easily delegate it anyway), as that is the website they have chosen to view.

I would like for the user to say "no" if the top-level page wanted to pass it onto the third party (some people don't trust Google with their data), but this already happens, where the top-level website asks for the location on page 1, then passes that information onto the third party on page 2 (aka the results page).

And the same can happen in reverse, where the third party may already have the permission, and immediately pass it back up to the top-level page via postMessage(), even though the user may not want that top-level page to have access to this information.

So in summary, I like the proposal where the permission is based on the top-level domain, as seen/requested by the user, irrespective of where that information is passed to later (and maybe some of these top-level websites may then start acting a little more responsibly with this data).

Craig



> On 18 Mar 2016, at 20: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/" 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
>