Re: Request for comments: Permission Delegation to Iframes

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.


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


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


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


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