Defaults aren't clear to me

[benfredwells]

In particular for embedded contexts, it's not clear to me if features are enabled or disabled by default.

From the examples:

SecureCorp Inc. wants to disable use of Geolocation API within all browsing contexts whose origin is "https://example.com". It can do so by delivering the following HTTP response header to define a feature policy:

Feature-Policy: {"disable":["geolocation"], "target":["https://example.com"]}
The target is a list of one or more origins, which can include the applications origin and any third-party origin.

SecureCorp Inc. is hosting an application on "https://example.com" and wants to disable WebRTC on its origin but enable it for a whitelisted embedee ("https://other.com"). It can do so by delivering the following HTTP response header to define a feature policy:

Feature-Policy: {"disable":["webrtc"], "target":["https://example.com"]},
{"enable":["webrtc"], "target":["https://other.com"]}
Some features are disabled by default in embedded contexts. The enable policy allows the application to selectively enable such features for whitelisted origins.

The first example implies that geolocation is enabled by default in frames. The second implies that it depends on the feature. Maybe this is covered elsewhere in the spec and I just didn't see it?

[clelland]

The first example implies that geolocation is enabled by default in frames. The second implies that it depends on the feature.

I think both of these statements can be true -- Whether a feature is enabled by default in embedded contexts depends on the feature, and for geolocation, the default is enabled.

The first example shows how a default-enabled feature can be disabled for an origin (and all embedded content). The second example shows how a default-enabled features can be disabled for an origin, but then re-enabled for a specific embedded third-party.

None of the examples shows a default-disabled feature. Actually, I don't think that we've actually defined one -- just left space in the spec for such a feature to be defined in the future. Those last two sentences should probably be moved somewhere else, since they don't really apply to that example.

[benfredwells]

Oh .. so if a policy is in the disable policy section, it is default-enabled, and if it is in the enable policy section, it is default-disabled?

Can a feature have a different default based on whether it is in an embedded context?

For permissions delegation to be effective it is important that all permissions are disabled by default in embedded contexts.

[raymeskhoury]

+1

We need to decide which permissions/features we want to disable by default in embedded contexts for v1 and add that somewhere.

[igrigorik]

Iterating on this in #33 -- please chime in there.