Mechanisms to "disable" a feature about webappsec-permissions-policy HOT 6 CLOSED

If API access is mediated by Permission API, should we prefer the Permission denied route? We have many existing examples of this. Intuitively, I think it makes sense to developers: the result of a user declining access request is the same, we should trigger same (existing) code paths.

Thinking about this particular pattern some more, a couple of issues:

1. It's possible for a feature to be "enabled" but have the user deny permission and/or modify their previous decision.
2. An origin may want to "disable" a feature for "self" but allow its use for an embedder -- e.g. for security reasons I want to drop Geolocation API on my origin (i.e. allowed but disabled), but I do want to enable it for the embedded maps widget provider / suborigin (allowed and enabled).

The second case, in particular, hints that Permission state of a feature should be (?) independent of whether the feature is enabled or disabled for particular context. More concretely:

• Permission API reflects user decision about whether they are willing to allow a particular powerful feature for current origin.
• Enable/disable policies determine whether particular feature or interface is available to the context, subject to origin policies.

As such, perhaps we should rule out (3) for enforcing feature policies?

Going down this path would allow us to support the following Geolocation scenario:

200 OK
Feature-Policy: {disable: ['geolocation']}

<iframe src='foo.com' enable='geolocation'>

The page disables Geolocation API against "self" (via response header) but enables it for foo.com (see #9). The permission state is completely independent; the page can request user permission regardless whether feature is enabled or disabled, and delegate it to foo.com by enabling said feature.

from webappsec-permissions-policy.

Doing a bit more digging on (4)...

From Original Trials design doc:

The [OriginTrialEnabled] IDL attribute works similarly to the existing [RuntimeEnabled] attribute. The [OriginTrialEnabled] attribute is intended as a drop-in replacement for the [RuntimeEnabled] attribute, including using the same runtime feature flag name.

From Blink Runtime Enabled Feature:

Runtime flags enable Blink developers the ability to control access Chromium users have to new features they implement. Features that are hidden behind a runtime flag are known as Runtime Enabled Features.

• You can guard the entire interface
• You can guard individual definition members
• You can use overloading and guard arguments

Warning: you will not be able to change the enabled state of these at runtime as the V8 object templates definitions are created during start up and will not be updated during runtime.

If you squint enough... One could imagine "disabling" features ~via:

[RuntimeEnabled=FeaturePolicyGeolocation] interface NavigatorGeolocation {
   readonly attribute Geolocation geolocation;
 };

interface Document {
    [RuntimeEnabled=FeaturePolicyCookie] attribute DOMString cookie;
    [RuntimeEnabled=FeaturePolicyDocWrite] void write();
};

• Pro: we don't have to monkey patch each spec and method.
• Pro: much easier to reason about policies like "disable webrtc", which consist of many different API's and interfaces that need to be disabled.
• Con: If we go down this route, I don't think we can do reporting... at least, not easily. That said, if the developers attempts to call one of the disabled API's, they can catch the exception via window.onerror and decide if they want to log it themselves.

Hmm? Should we prefer this route to other strategies? Even if we can make it work in Blink, would other UA's be able to support this?

from webappsec-permissions-policy.

I think I agree that a feature disabled by Feature-Policy should be more "gone" than one that's just been "denied" permission. Specifically:

1. If a feature is disabled by Feature-Policy, there's no way for it to become enabled again within the same global object, so we can do drastic things like remove methods. We can't do that for something that's been denied permission because the user can dynamically re-enable it.
2. As you said, permission can be revoked, but we can't take back objects we've already handed out, so there has to be some way other than missing-methods to express denied permissions, usually exceptions.

Similarly, you're right that we'll need some extra state in order to spec both Permission Delegation and Feature Policy: The Permission Delegation spec is something like "if the feature is "denied" in the top-level frame, or the chain of permission='name' attributes on the iframe elements is broken, then it's "denied" in the target frame." If Feature Policy disables the feature on the top-level frame but allows it on the child frame, and we express that by making the state "denied" on the top-level frame, then there's no way to request it in the child.

That said, we could make that extra state a second-level thing: permission-using APIs could continue to check the state, and only Permission Delegation would need to distinguish the user's expressed intent toward an origin vs the frame's Feature Policy value. If navigator.geolocation continues to exist in a Feature-Policy: {"disable":["geolocation"]} resource, it could return PERMISSION_DENIED instead of a new value.

from webappsec-permissions-policy.

@jyasskin hmm, not sure if I'm parsing your last paragraph correctly.. Here's where I'm at:

Conceptually, I see Permissions API as completely separate from whether the interface is available. Meaning, it's possible to request and query navigator.permissions for "geolocation" even if there is an enforced disable (Feature-Policy: {"disable":["geolocation"]}) policy and all the interfaces are missing. In this way, it's possible for the document to "disable" a feature but still request and delegate permission. The same document could then <iframe enable=geolocation src=other.foo.com> to enable (and delegate said permission) the feature in a nested context... Is that coherent?

from webappsec-permissions-policy.

I'm still trying to wrap my head around the various IDL bits... first and very rough sketch:

partial interface Navigator {
  [Feature=geolocation] readonly attribute Geolocation geolocation;
};

partial interface NavigatorUserMedia {
  [Feature=webrtc] void getUserMedia(
                      MediaStreamConstraints constraints,
                      NavigatorUserMediaSuccessCallback successCallback,
                      NavigatorUserMediaErrorCallback errorCallback);
};

[Feature=webrtc] interface RTCPeerConnection {
 ...
}

If the [Feature] extended attribute appears on an interface, partial interface, or an individual interface member, it indicates that the interface or interface member is subject to Feature Policy associated with the ECMAScript global environment's global object, rather than being exposed by default.

The [Feature] extended attribute must take an identifier, which must be a global name.

Whether a construct that the [Feature] extended attribute can be specified on is allowed by feature policy is defined as follows:

• If the [Feature] extended attribute is specified on the construct, then it is allowed by feature policy if the "is feature disabled for global?" algorithm returns "Enabled" when executed upon the extended attribute's argument and the ECMAScript global environment's global object.
• If the [Feature] extended attribute does not appear on a construct, then it is allowed by feature policy implicitly, depending on the type of construct:
  • interface: the interface or dictionary is "Enabled" by feature policy.
  • partial interface: the partial interface is allowed by feature policy if and only if the original interface definition is.
• interface member: the interface member is allowed by feature policy if and only if the interface or partial interface the member is declared on is.

... ~ish?

• Permission delegation: embedded contexts would default to "disable" for unless an explicit "enable" policy is present?
• Origin trials: the "is feature disabled for global?" can provide a hook that other specs can extend -e.g. if we don't recognize the feature name we allow other hooks to run and return "Enable / Disable"?

References:

• https://heycam.github.io/webidl/#dfn-available-only-in-secure-contexts
• https://heycam.github.io/webidl/#dfn-xattr-identifier

from webappsec-permissions-policy.

Closing, let's continue in #33.

from webappsec-permissions-policy.