Feature-Policy ∪ Permission Delegation ∪ Origin Trials

[igrigorik]

From: https://noncombatant.github.io/permission-delegation-api/

We recommend that UAs only allow permissions to be granted to embedded applications via explicit delegation from the embedding application.
...
A permission, generally, is an affordance in the UA to allow, deny, throttle, or otherwise regulate access to a powerful feature that the user, through the UA, may grant to the web origin. Examples of powerful features include [geolocation-API] and the getUserMedia API from [webrtc].
...
An embedder can delegate permissions it holds to its embedee(s), thus allowing the embedee to use the powerful feature to which the permission grants access. Similarly, an embedder can undelegate (revoke) a permission from an embedee.

The recommendation is to make powerful features mediated by Permissions API (i.e. features that require user permission) disabled by default in nested context's, and require the parent context to explicitly delegate permission to each embedee to (a) enable access to said feature, and (b) pass along the permission held by the embedder to the embedee.

Functional requirement: some features are off by default in nested contexts and the parent context should have a mechanism to selectively enable access to such features.

---

Enable Policy

The enable policy allows a developer to turn on certain features for a Document or Worker. The policy may be set and communicated via the Feature-Policy HTTP Header Field, or via a declarative API.

Example A: Site A wants to enable Geolocation for all embedees.

200 OK
Feature-Policy: {enable: ["geolocation"], mode: "cascade"}

Example B: Site B wants to enable a "trials" feature for its origin.

200 OK
Feature-Policy: {enable: ["opaque-token"]}

Example C: Site A wants to also enable notifications for particular embedee.
<iframe enable="notifications" src="foo.com"></iframe>

foo.com has access to geolocation (via Example A) and notifications.

Extensions to the iframe element

partial interface HTMLIFrameElement {
  [PutForwards=value] readonly attribute DOMTokenList enable;
};

The enable attribute, when specified, enables specified features for the embedee running in the iframe. Its value must be an unordered set of unique space-separated tokens that are ASCII case-insensitive, and is processed by the "parse enable response policy from value" algorithm.

Parse enable response policy from value

Note: this would be called from "process response policy" which processes Feature-Policy header, and "process attribute policy".

Given a list of ASCII case-insensitive tokens, this algorithm returns a list of valid enable features... Rough sketch:

1. Let enable policy be an empty list.
2. For each item in list:
   • If item is one of valid PermissionName enum values:
     • If item was defined via enable attribute:
       • Set target to iframe element's src attribute value.
     • Otherwise, set target to target mode's value if present, and self if missing.
     • Set mode to enforce.
     • Set report to to null.
   • Otherwise, if the <insert ref to Origin Trials token processing algorithm> algorithm returns "Enabled" when executed upon item and the document's global object:
     • Set target to self.
     • Set mode to enforce.
     • Set report to to null.
   • Otherwise, go to the next item in list.
   • Append tuple to enable policy.
3. Return enable policy.

---

There is a bunch more to work through here, but I think the above would, more or less, allow us to merge Permission Delegation and Origin Trials into a single "enable" mechanism?

• The processing logic for "trials" would live in the Origin Trials spec; we treat it as opaque token.
• The Permission Delegation spec can drop the mechanism for defining which features are enabled and instead inspect the "Feature Policy List" and define the desired behavior(s).

[ojanvafai]

I like it. I think we should flip the default for cascading though. cascade should be opt-out.

Also, we need a disable attribute on iframe as well?

[igrigorik]

I like it. I think we should flip the default for cascading though. cascade should be opt-out.

Yep, that's what we have currently: http://igrigorik.github.io/feature-policy/#the-target-member

Also, we need a disable attribute on iframe as well?

Yep, see: #11

[igrigorik]

Had an offline chat with @jpchase @clelland @mkruisselbrink today. Quick summary:

1. The rough integration sketch in Mechanisms to "disable" a feature #10 (comment) sounds reasonable.
   • One concern is lack of <meta> support, opened: Should we support <meta http-equiv> mechanism to set the policy? #15.
   • The algorithm that processes tokens probably shouldn't call out to Origin Trials specifically, instead just provide an extension point for other specs to hook into.
2. We talked about pro's and con's of hiding interfaces/methods vs throwing exceptions. Agreed that it probably makes sense to hide interfaces for cases like "disable webrtc", less clear on "disable document.cookie" and similar... Need to think about it some more.

Overall though, I think we agreed that it makes sense to explore this further.

Next step: convert #10 (comment) into a concrete proposal.

p.s. @jpchase @clelland @mkruisselbrink please chime in if I'm forgetting anything.

[raymeskhoury]

Hmm would safer defaults be for enable features not to cascade but disabled features to cascade?

[igrigorik]

Closing this; we broke out the various pieces of #9 (comment) into separate threads.