Skip to content

allow disabled-by-default features #513

@fergald

Description

@fergald

Motivation:

This would be a tool to use in deprecating and removing a feature. Our current motivator for this is the deprecation of unload but it could apply to any other feature.

Deprecating is hard and we want to provide a period where a feature is still usable but opt-in. The plan for unload is more complicated than just flipping to this state but this is the desired state.

Currently the available defaults for a feature are self and *. It is not possible to have a policy that disables a feature by default.

Proposal

Add an allowed default value of none. This would mean that by default, the feature is not available. To make the feature available in a given frame, that frame would have to declare it via the header and every ancestor of that frame would also have to declare it via the header and delegate it via the allow attribute on the iframe element.

This

  • fits with the existing PP model
  • achieve goal of allowing opt-back-in
  • opt-in requires action on by allow frames in the ancestry chain

The unfortunate side-effect of forcing the feature to be enabled in a the ancestor frames even if they do not want it could be avoided by also implementing not-self .

Alternative outcomes

There are some different outcomes one could imaging trying to achieve.

require action only by the subframe itself

  • by subframes can enable feature
  • ancestors can epxlicitly prevent this

This would make it easier to opt back in while still giving containers utlimate control. It does not seem to sit with the existing inheritance model of PP and would require changes to the decision algorithm, not just the available defaults.

require action only by the containing frames

  • subframes don't need to explicitly enable the feature
  • ancestors enable the feature

This would allow sites to restore unload functionality to 3rd party frames even without the cooperation of the 3rd party. It seems like 3rd parties have an incentive to enable the features they use, so this is of questionable benefit vs the proposed outcome.

@clelland

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions