Re: Request for comments: Permission Delegation to Iframes

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

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:
<iframeid="embedee"src="https://maps.example.com/"can-prompt-for-permissions="yes"></iframe> 

* If a user grants a permission for a top level site that is later 
embedded, the embedded site will still have the permission.

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