Permission Delegation

[torgo]

This issue has come to the TAG's attention and was discussed on yesterday's teleconference. Raised by @lknik based on the announcement tweeted out by @mikewest.

[mikewest]

/cc @raymeskhoury, who's actually driving the project (and published an Intent to Implement to blink-dev@ along with an explainer doc). He's doing the hard work, I'm just a friendly supporter. :)

[torgo]

Taken up at London f2f.

[lknik]

After London F2F.

We're quite concerned with transitivity of delegations. It's somewhat a question of web security architecture.

<iframe src="https://honest.com" allow="geolocation; microphone; camera"></iframe>

If (original origin) example.com delegates permission to honest.com, can honest.com delegate this further, for example to dishonest.com? What would be the control over this transitivity of "allow" attribute?

Wondering how to address the issue of transitivity. One thing that comes to mind is a special attribute allowing transitivity. Then comes further questions, how to actually make webdevs to choose appropriately.

[annevk]

Note that should be raised against https://github.com/WICG/feature-policy/issues/new really, as that follows from Feature Policy (see also #159). And honest.com can always expose a postMessage() service to dishonest.com. allow just avoids having to write a postMessage() service, as far as I can tell.

[dbaron]

I think the flip side about transitivity is that if people are denied transitive delegation, they'll work around that denial by including cross-origin JS directly into their origin, which is a security loss.

[lknik]

...or they might choose using a special attribute for that if in need for more control, if there would be one.

[raymeskhoury]

@clelland

Thanks @lknik. As @annevk mentioned, this transitivity is a part of the Feature Policy mechanism rather than this (Permission Delegation) proposal. We thought about this issue closely when we designed Feature Policy. From a security boundary standpoint, as soon as the top level site has shared access with the embedded site, what the embedded site does with that capability is almost completely out of the hands of the top level site. We don't have any good way to force the embedded site not to share the capability. For example, if you shared location with example.com, example.com could pass on your location to other parties in any number of ways, including via a fetch/XMLHttpRequest or via postMessage.

I don't see this as problematic though. When you share your credit card with example.com, you don't have any control over what they do with it or who they share it with. You're making a trust decision to share access and as part of that trust decision you are deciding on the risk of them sharing it on to other parties. You can tell example.com not share your credit card with anyone else but that wouldn't be more than a hint that they can choose to listen to or not.

I don't see such a hint as useful in this case because it does nothing to hinder or even warn the embedded site about sharing access to the capability in the other ways mentioned above. On the contrary, an attribute actually has the potential to provide a false sense of security if developers believe that it enforces some kind of meaningful privacy constraint on the embedded site. As such, I don't think that we should consider such an attribute at the moment.

[slightlyoff]

There's a commonality between wanting to limit transitivity and limiting frame depth (e.g.). In both cases, the parent doc might want ensure that only the party it has a direct relationship with (the immediate child document) is using (or including third parties that use) a capability very intentionally. Allowing the parent to set this sort of "depth limit" seems valuable.

/cc @ojanvafai

[annevk]

How is it valuable if the child can circumvent it quite trivially and the user won't ever know either way?

[raymeskhoury]

@slightlyoff what I was trying to say above is that I don't think what you are suggesting is possible in the general case or, I would suggest, even in most cases.

Specifically,

the parent doc might want ensure that only the party it has a direct relationship with (the immediate child document) is using (or including third parties that use) a capability very intentionally

For most permissions features, they are gating access to some kind of privacy sensitive data like camera, microphone, location, personal identifiers. Once these things are given to a third party, the cat is out of the bag and the third party can pass them on to other parties in many different ways. Even bi-directional device access, such as bluetooth or USB can easily be mediated by a third-party to anyone else it chooses (e.g. via a postMessage API that it sets up or by communicating with a server).

And even in the case of frame depth - it is possible to limit a frame from embedding other frames. But it's not possible to control what the frame does with the screen real estate it has already been given, or the memory and CPU resources it has been given. There is nothing stopping it from downloading third-party code and rendering it within its container.

[lknik]

I'd say as @slightlyoff - functionality of limiting further propagation would be valuable, as per (e.g.) the future. My understanding of your point is that there is nothing to be done here effectively, because nothing can be done due to web architecture as of now.

[annevk]

In the future you'll still have the same leaks. We cannot really close them after-the-fact, that's not how the web platform works.

The only thing you can do is to introduce a new kind of architecture and hope folks start using it. E.g., https://www.w3.org/TR/COWL/ had some very interesting properties, but it never really went anywhere.

[slightlyoff]

Sorry for the slow reply.

I'm confused about the sub-frame point. Limiting depth here could be conjoined to delegation. That is, if you choose to delegate permissions, you don't get the ability to create new iframes from there. That creates a direct trade: if you want access to the new thing, then you have to accept new limits. The web platform frequently adopts trades like this (e.g., ES6 modules or classes opting you into strict mode)

[dbaron]

Or to put it another way, I think a "delegate to A but don't allow further delegation" is probably only really effective when combined with the inability to create further nested iframes (and maybe also a restriction on cross-origin script?).

[torgo]

Discussed at tokyo f2f. Would a potential target of this discussion be opening up an appropriately worded issue in feature-policy?

[raymeskhoury]

Or to put it another way, I think a "delegate to A but don't allow further delegation" is probably only really effective when combined with the inability to create further nested iframes (and maybe also a restriction on cross-origin script?).

I agree that this could be implemented but I still see it as only a speedhump from a security standpoint and not a guarantee of any kind. What are we really trying to stop? Once I give someone my SSN on the street, they can pass it on to whomever they want. Once you give location to x.com, they can share it back to their servers via XHR and then send it on to any other server. Unless you completely isolate a frame from the network it will always be able to do this type of thing.

@slightlyoff if this still isn't coming through clearly let's meet and try to iron things out :)

[dbaron]

Yeah, I'm skeptical about restricting transitive delegation, though others seem to be arguing that it could be useful.

[annevk]

Unless we actually put in place something like COWL I'd rather not add a false sense of security.

[slightlyoff]

@raymeskhoury: sorry for the slow reply. Runtime capabilities aren't analogous to SSN's; they are capabilities to perform actions, not portable context-free identifiers. Yes, collusion between origins is always possible (particularly on the backend), but the ability for origins to abuse users at a business level is no reason for us to pervasively enable it at runtime.

More to the point, one-time location recording is (again) not analogous to the continuous ability to read one's location. We create UI and mediate relationships between users and origins with browser UI based on exactly these API contracts.

[lknik]

I'm for the restrictions indeed on sub-iframing. This would be a good way forward.

[annevk]

It's still not clear to me how that helps. Could you elaborate on your rationale?

[dbaron]

On a different topic related to this specification:

Currently the permissions API doesn't describe permissions that are granted entirely by the act of making some other selection. For example, anything involving a filepicker is really a permission grant, but the permission grant happens implicitly when the user chooses a file. Likewise, Screen Capture can involve permission grants that are implicit results of choosing a window to screenshare. (From a UI perspective, these implicitly-granted permissions are often better since it's clearer to the user what's being granted.)

If permissions are thought of only as a thing that is requested and its state queried, then it's understandable that they're not in the permissions API. But it seems like once we're talking about delegating permissions, then we do need to think of these things as permissions, and think about whether a document delegates them to its subframes or not.

That, in turn, leads me to think they should be described somewhere and given names... but where?

[torgo]

@lknik to help us progress this issue on 5-29 call - otherwise we will close.

[dbaron]

I filed w3c/permissions#178 on #225 (comment).

[travisleithead]

I ran the issue of transitivity of permission delegation by a few of our security folks on the Edge team, just to get a second opinion. They were enthusiastic about the concept of permission delegation, but like me, didn't see that restricting transitivity actually helps anything, given the ease of working around the restriction (as has been mentioned above), and that it breaks iframe component encapsulation:

For example, top-level pages would need to know whether delegation is needed only one level deep or many levels, and from an encapsulation perspective, that knowledge shouldn’t be required. In practice, I think that if such a restriction on transitivity is provided, the restriction won’t be used because one cannot (or should not) know to what extent the permission needs to be further delegated, and the path of least resistance is just to enable transitivity by default "just in case" it is necessary.

[lknik]

Thank you for the input. I agree that in the current architecture there would be obstacles. But it's all based on use cases. If you need transitivity, think about it on the design phase. I'm not sure if the argument "nobody will use this, just to make sure things work" is a point of not having it.

[torgo]

Agree to close this for now and examine what comes out of the pending permissions workshop - link tba.

[annevk]

@lknik as I pointed out, if you want something like that, you'd need to invest in something like https://www.w3.org/TR/2015/WD-COWL-20151015/.