Re: Request for comments: Permission Delegation to Iframes

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 
> <mailto: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 <http://yelp.com>, yellowpages.com
>     <http://yellowpages.com>, and tripadvisor.com
>     <http://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:
>     <iframeid="embedee"src="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
>
>