Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update section on 'Other and related mechanisms' #82

Open
wants to merge 1 commit into
base: gh-pages
Choose a base branch
from
+121 −52
Open

Update section on 'Other and related mechanisms' #82

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
80 changes: 58 additions & 22 deletions index.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -96,30 +96,66 @@ spec:fetch; type:dfn; text:value
</section>
<section>
<h2 id="other-and-related-mechanisms">Other and related mechanisms</h2>
<p>[[HTML5]] defines a <{iframe/sandbox}> attribute for <{iframe}> elements
that allows developers to reduce the risk of including potentially untrusted
content by imposing restrictions on content's abilities - e.g. prevent it
from submitting forms, running scripts and plugins, and more. The
[=sandbox=] directive defined by [[CSP2]] extends this capability to any
resource, framed or not, to ask for the same set of restrictions - e.g. via an
HTTP response header (<code>Content-Security-Policy: sandbox</code>). These
mechanisms enable the developer to:</p>
<i>This section is non-normative</i>
<p>Several other specifications also define ways in which specific web
platform features are enabled and disabled. These include (among others):</p>
<ul>
<li>Set and customize a sandbox policy on any resource via CSP.</li>
<li>Set and customize individual sandbox policies on each
<code>iframe</code> element within their application.</li>
<li>Content Security Policy</li>
<li>Sandbox</li>
<li>Fullscreen</li>
<li>PaymentRequest</li>
<li>WebRTC</li>
</ul>
<p>However, there are several limitations to the above mechanism: the
developer cannot automatically apply a policy across all contexts, which
makes it hard or impossible to enforce consistently in some cases (e.g. due
to third-party content injecting frames, which the developer does not
control); there is no mechanism to selectively enable features that may be
off by default; the sandbox mechanism uses a whietlist approach which is
impossible to extend without compatibility risk.</p>
<p>Feature Policy is intended to be used in combination with the sandbox
mechanism (i.e. it does not duplicate feature controls already covered by
sandbox), and provides an extensible mechanism that addresses the above
limitations.</p>
<p>Feature Policy intends to become a uniform mechanism for enabling and
disabling features on the web, including features which are currently defined
by those specifications. Feature policy is designed to be extensible, such
that other APIs can adopt it by declaring new features and specifying their
behavior.</p>
<p>Doing so automatically grants web developers the ability to craft policies
for their sites, and for the pages which their sites embed, which enable and
disable these features in a consistent way.</p>
<h3>Relationship with Content Security Policy</h3>
<p>Content Security Policy is mostly independent of Feature Policy, as it
is mostly concerned with resource loading, and not with API availability.
The one exception to this is the 'sandbox' directive defined by CSP2, which
can be used to disable the same set of features as the <{iframe/sandbox}>
attribute. (See below)</p>
<h3>Relationship with Sandbox</h3>
<p>[[HTML5]] defines a <{iframe/sandbox}> attribute for <{iframe}> elements
that allows developers to reduce the risk of including potentially untrusted
content by imposing restrictions on content's abilities - e.g. prevent it
from submitting forms, running scripts and plugins, and more.</p>
<p>Iframe sandboxing currently provides two distinct behaviours: it isolates
frames from their embedding page by enforcing an opaque origin; and it
restricts which APIs are available in the sandboxed frames (disabling all of
them by default, but allowing a developer to enable APIs selectively
per-frame).</p>
<p>Feature Policy does not currently control any of the features which
sandboxing restricts, but it is designed such that they could easily be
redefined as policy-controlled features, in which case developers would be
able to control them independently of sandboxing. In such a world,
sandboxing would still be used to provide an origin boundary between frames,
but Feature Policy would be the mechanism to control, in any frame, features
such as:</p>
<ul>
<li>Top-frame navigation</li>
<li>Form submission</li>
<li>Script execution</li>
<li>Popups</li>
<li>Pointer lock</li>
<li>Modal dialogs</li>
<li>Orientation lock</li>
<li>Presentation API</li>
</ul>
<p>Feature Policy is also intended to address some of the limitations of the
sandbox attribute's approach to disabling features: Sandbox does not allow
sites any way to automatically apply a policy to all nested browsing
contexts (or all contexts at a given origin), and it uses a whitelist
approach which is impossible to extend without compatibility risk. Feature
policy provides an HTTP header, to declare a policy at the document level
for all embedded content, and is designed to be extensible, such that new
features can be added without requiring all developers to update their sites
to take them into account.</p>
</section>
<section>
<h2 id="framwork">Framework</h2>
Expand Down
93 changes: 63 additions & 30 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1425,7 +1425,7 @@
<div class="head">
<p data-fill-with="logo"></p>
<h1 class="p-name no-ref" id="title">Feature Policy</h1>
<h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Draft Community Group Report, <time class="dt-updated" datetime="2017-06-12">12 June 2017</time></span></h2>
<h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Draft Community Group Report, <time class="dt-updated" datetime="2017-08-18">18 August 2017</time></span></h2>
<div data-fill-with="spec-metadata">
<dl>
<dt>This version:
Expand Down Expand Up @@ -1463,7 +1463,12 @@ <h2 class="no-num no-toc no-ref" id="contents">Table of Contents</h2>
<ol class="toc" role="directory">
<li><a href="#introduction"><span class="secno">1</span> <span class="content">Introduction</span></a>
<li><a href="#examples"><span class="secno">2</span> <span class="content">Examples</span></a>
<li><a href="#other-and-related-mechanisms"><span class="secno">3</span> <span class="content">Other and related mechanisms</span></a>
<li>
<a href="#other-and-related-mechanisms"><span class="secno">3</span> <span class="content">Other and related mechanisms</span></a>
<ol class="toc">
<li><a href="#relationship-with-content-security-policy"><span class="secno">3.1</span> <span class="content">Relationship with Content Security Policy</span></a>
<li><a href="#relationship-with-sandbox"><span class="secno">3.2</span> <span class="content">Relationship with Sandbox</span></a>
</ol>
<li>
<a href="#framwork"><span class="secno">4</span> <span class="content">Framework</span></a>
<ol class="toc">
Expand Down Expand Up @@ -1613,28 +1618,65 @@ <h2 class="heading settled" data-level="2" id="examples"><span class="secno">2.
</section>
<section>
<h2 class="heading settled" data-level="3" id="other-and-related-mechanisms"><span class="secno">3. </span><span class="content">Other and related mechanisms</span><a class="self-link" href="#other-and-related-mechanisms"></a></h2>
<i>This section is non-normative</i>
<p>Several other specifications also define ways in which specific web
platform features are enabled and disabled. These include (among others):</p>
<ul>
<li>Content Security Policy
<li>Sandbox
<li>Fullscreen
<li>PaymentRequest
<li>WebRTC
</ul>
<p>Feature Policy intends to become a uniform mechanism for enabling and
disabling features on the web, including features which are currently defined
by those specifications. Feature policy is designed to be extensible, such
that other APIs can adopt it by declaring new features and specifying their
behavior.</p>
<p>Doing so automatically grants web developers the ability to craft policies
for their sites, and for the pages which their sites embed, which enable and
disable these features in a consistent way.</p>
<h3 class="heading settled" data-level="3.1" id="relationship-with-content-security-policy"><span class="secno">3.1. </span><span class="content">Relationship with Content Security Policy</span><a class="self-link" href="#relationship-with-content-security-policy"></a></h3>
<p>Content Security Policy is mostly independent of Feature Policy, as it
is mostly concerned with resource loading, and not with API availability.
The one exception to this is the 'sandbox' directive defined by CSP2, which
can be used to disable the same set of features as the <code><a data-link-type="element-sub" href="https://html.spec.whatwg.org/multipage/embedded-content.html#attr-iframe-sandbox">sandbox</a></code> attribute. (See below)</p>
<h3 class="heading settled" data-level="3.2" id="relationship-with-sandbox"><span class="secno">3.2. </span><span class="content">Relationship with Sandbox</span><a class="self-link" href="#relationship-with-sandbox"></a></h3>
<p><a data-link-type="biblio" href="#biblio-html5">[HTML5]</a> defines a <code><a data-link-type="element-sub" href="https://html.spec.whatwg.org/multipage/embedded-content.html#attr-iframe-sandbox">sandbox</a></code> attribute for <code><a data-link-type="element" href="https://html.spec.whatwg.org/multipage/embedded-content.html#the-iframe-element">iframe</a></code> elements
that allows developers to reduce the risk of including potentially untrusted
content by imposing restrictions on content’s abilities - e.g. prevent it
from submitting forms, running scripts and plugins, and more. The <a data-link-type="dfn" href="https://w3c.github.io/webappsec-csp/#sandbox">sandbox</a> directive defined by <a data-link-type="biblio" href="#biblio-csp2">[CSP2]</a> extends this capability to any
resource, framed or not, to ask for the same set of restrictions - e.g. via an
HTTP response header (<code>Content-Security-Policy: sandbox</code>). These
mechanisms enable the developer to:</p>
that allows developers to reduce the risk of including potentially untrusted
content by imposing restrictions on content’s abilities - e.g. prevent it
from submitting forms, running scripts and plugins, and more.</p>
<p>Iframe sandboxing currently provides two distinct behaviours: it isolates
frames from their embedding page by enforcing an opaque origin; and it
restricts which APIs are available in the sandboxed frames (disabling all of
them by default, but allowing a developer to enable APIs selectively
per-frame).</p>
<p>Feature Policy does not currently control any of the features which
sandboxing restricts, but it is designed such that they could easily be
redefined as policy-controlled features, in which case developers would be
able to control them independently of sandboxing. In such a world,
sandboxing would still be used to provide an origin boundary between frames,
but Feature Policy would be the mechanism to control, in any frame, features
such as:</p>
<ul>
<li>Set and customize a sandbox policy on any resource via CSP.
<li>Set and customize individual sandbox policies on each <code>iframe</code> element within their application.
<li>Top-frame navigation
<li>Form submission
<li>Script execution
<li>Popups
<li>Pointer lock
<li>Modal dialogs
<li>Orientation lock
<li>Presentation API
</ul>
<p>However, there are several limitations to the above mechanism: the
developer cannot automatically apply a policy across all contexts, which
makes it hard or impossible to enforce consistently in some cases (e.g. due
to third-party content injecting frames, which the developer does not
control); there is no mechanism to selectively enable features that may be
off by default; the sandbox mechanism uses a whietlist approach which is
impossible to extend without compatibility risk.</p>
<p>Feature Policy is intended to be used in combination with the sandbox
mechanism (i.e. it does not duplicate feature controls already covered by
sandbox), and provides an extensible mechanism that addresses the above
limitations.</p>
<p>Feature Policy is also intended to address some of the limitations of the
sandbox attribute’s approach to disabling features: Sandbox does not allow
sites any way to automatically apply a policy to all nested browsing
contexts (or all contexts at a given origin), and it uses a whitelist
approach which is impossible to extend without compatibility risk. Feature
policy provides an HTTP header, to declare a policy at the document level
for all embedded content, and is designed to be extensible, such that new
features can be added without requiring all developers to update their sites
to take them into account.</p>
</section>
<section>
<h2 class="heading settled" data-level="4" id="framwork"><span class="secno">4. </span><span class="content">Framework</span><a class="self-link" href="#framwork"></a></h2>
Expand Down Expand Up @@ -2555,11 +2597,6 @@ <h3 class="no-num no-ref heading settled" id="index-defined-here"><span class="c
</ul>
<h3 class="no-num no-ref heading settled" id="index-defined-elsewhere"><span class="content">Terms defined by reference</span><a class="self-link" href="#index-defined-elsewhere"></a></h3>
<ul class="index">
<li>
<a data-link-type="biblio">[CSP3]</a> defines the following terms:
<ul>
<li><a href="https://w3c.github.io/webappsec-csp/#sandbox">sandbox</a>
</ul>
<li>
<a data-link-type="biblio">[WHATWG-DOM]</a> defines the following terms:
<ul>
Expand Down Expand Up @@ -2607,8 +2644,6 @@ <h3 class="no-num no-ref heading settled" id="index-defined-elsewhere"><span cla
<h2 class="no-num no-ref heading settled" id="references"><span class="content">References</span><a class="self-link" href="#references"></a></h2>
<h3 class="no-num no-ref heading settled" id="normative"><span class="content">Normative References</span><a class="self-link" href="#normative"></a></h3>
<dl>
<dt id="biblio-csp3">[CSP3]
<dd>Mike West. <a href="https://w3c.github.io/webappsec-csp/">Content Security Policy Level 3</a>. URL: <a href="https://w3c.github.io/webappsec-csp/">https://w3c.github.io/webappsec-csp/</a>
<dt id="biblio-fetch">[FETCH]
<dd>Anne van Kesteren. <a href="https://fetch.spec.whatwg.org/">Fetch Standard</a>. Living Standard. URL: <a href="https://fetch.spec.whatwg.org/">https://fetch.spec.whatwg.org/</a>
<dt id="biblio-html">[HTML]
Expand All @@ -2628,8 +2663,6 @@ <h3 class="no-num no-ref heading settled" id="normative"><span class="content">N
</dl>
<h3 class="no-num no-ref heading settled" id="informative"><span class="content">Informative References</span><a class="self-link" href="#informative"></a></h3>
<dl>
<dt id="biblio-csp2">[CSP2]
<dd>Mike West; Adam Barth; Daniel Veditz. <a href="https://w3c.github.io/webappsec-csp/">Content Security Policy Level 2</a>. URL: <a href="https://w3c.github.io/webappsec-csp/">https://w3c.github.io/webappsec-csp/</a>
<dt id="biblio-html5">[HTML5]
<dd>Ian Hickson; et al. <a href="https://www.w3.org/html/wg/drafts/html/master/">HTML5</a>. URL: <a href="https://www.w3.org/html/wg/drafts/html/master/">https://www.w3.org/html/wg/drafts/html/master/</a>
</dl>
Expand Down