Skip to content

Commit

Permalink
Dropping 'a priori' in favor of 'assumed'. *sigh*
Browse files Browse the repository at this point in the history
  • Loading branch information
@mikewest
mikewest committed May 28, 2014
1 parent a170165 commit 6e9bbfa
Show file tree
Hide file tree
Showing 2 changed files with 71 additions and 82 deletions.
87 changes: 40 additions & 47 deletions specs/mixedcontent/index.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -174,46 +174,43 @@ <h3 class="heading settled heading" data-level=2.1 id=terms-defined-here><span c
</dt>
<dd>
A resource is said to be <strong>mixed content</strong> if its origin is
<a data-link-type=dfn href=#a-priori-insecure-origin title="a priori"><em>a priori</em></a> or <a data-link-type=dfn href=#a-posteriori-insecure-origin title="a posteriori insecure"><em>a posteriori</em> insecure</a>,
<strong>and</strong> the <a data-link-type=dfn href=http://www.w3.org/html/wg/drafts/html/CR/browsers.html#browsing-context title="browsing context">browsing context</a> into which it is loaded
is a <a data-link-type=dfn href=#secure-browsing-context title="secure browsing context">secure browsing context</a>.
<a data-link-type=dfn href=#assumed-insecure-origin title=assumed>assumed</a> or <a data-link-type=dfn href=#proven-insecure-origin title=proven>proven</a> to be insecure, <strong>and</strong> the
<a data-link-type=dfn href=http://www.w3.org/html/wg/drafts/html/CR/browsers.html#browsing-context title="browsing context">browsing context</a> into which it is loaded is a <a data-link-type=dfn href=#secure-browsing-context title="secure browsing context">secure browsing
context</a>.
</dd>

<dt>
<dfn data-dfn-type=dfn data-export="" id=a-priori-insecure-origin title="a priori insecure origin|a priori insecure|a priori">
<em>a priori</em> insecure origin
<a class=self-link href=#a-priori-insecure-origin></a></dfn>
<dfn data-dfn-type=dfn data-export="" id=assumed-insecure-origin title="assumed insecure origin|assumed insecure|assumed">
assumed insecure origin
<a class=self-link href=#assumed-insecure-origin></a></dfn>
</dt>
<dd>
An origin is said to be <strong><em>a priori</em> insecure</strong> if
the user agent can determine that resources loaded from that origin will
not be <a data-link-type=dfn href=#tls-protected title=tls-protected>TLS-protected</a> before actually requesting the resource. For
example, <a data-link-type=dfn href=#origin title=origins>origins</a> whose scheme component is "HTTP" or "WS" fall
into this category.
An <a data-link-type=dfn href=#origin title=origin>origin</a> is said to be <strong>assumed insecure</strong> if the
user agent can determine that resources loaded from that origin will not
be <a data-link-type=dfn href=#tls-protected title=tls-protected>TLS-protected</a> before actually requesting the resource. For
example, origins whose scheme component is "HTTP" or "WS" fall into this
category.

<p class=note>Note: The mixed content checks will take place <em>after</em> Strict
Transport Security is applied to resource URLs, which should simplify
<em>a priori</em> determination of insecurity. <a data-biblio-type=informative data-link-type=biblio href=#biblio-rfc6797 title=biblio-rfc6797>[RFC6797]</a></p>
assumptions of insecurity. <a data-biblio-type=informative data-link-type=biblio href=#biblio-rfc6797 title=biblio-rfc6797>[RFC6797]</a></p>
</dd>

<dt>
<dfn data-dfn-type=dfn data-export="" id=a-posteriori-insecure-origin title="a posteriori insecure origin|a posteriori insecure|a posteriori">
<em>a posteriori</em> insecure origin
<a class=self-link href=#a-posteriori-insecure-origin></a></dfn>
<dfn data-dfn-type=dfn data-export="" id=proven-insecure-origin title="proven insecure origin|proven insecure|proven">
proven insecure origin
<a class=self-link href=#proven-insecure-origin></a></dfn>
</dt>
<dd>
An origin is said to be <strong><em>a posteriori</em> insecure</strong>
if the user agent can determine that resources loaded from that origin
will not be <a data-link-type=dfn href=#tls-protected title=tls-protected>TLS-protected</a> only after sending a request out over
the network. For example, an <a data-link-type=dfn href=#origin title=origin>origin</a> whose scheme component is
"HTTPS", but whose server presents an invalid certificate, or negotiates
an ineffective encryption algorithm.
An origin is said to be <strong>proven insecure</strong> if the user
agent determines that resources loaded from that origin are not
<a data-link-type=dfn href=#tls-protected title=tls-protected>TLS-protected</a> only after sending a request out over the network.
For example, this would include an <a data-link-type=dfn href=#origin title=origin>origin</a> whose scheme component
is "HTTPS", but whose server presents an invalid certificate, or
negotiates an ineffective encryption algorithm.
</dd>
</dl>

<p class=issue id=issue-96ecbc9a><a class=self-link href=#issue-96ecbc9a></a>Is using both <em>a priori</em> and <em>a posteriori</em> in the same
specification too Kantian? I say never! Others may disagree.</p>

<h3 class="heading settled heading" data-level=2.2 id=terms-defined-by-reference><span class=secno>2.2 </span><span class=content>Terms defined by reference</span><a class=self-link href=#terms-defined-by-reference></a></h3>
<dl>
<dt><dfn data-dfn-type=dfn data-noexport="" id=plugin>plugin<a class=self-link href=#plugin></a></dfn></dt>
Expand Down Expand Up @@ -510,16 +507,16 @@ <h3 class="heading settled heading" data-level=4.1 id=requirements-fetching><spa
<ol>
<li>
<a data-link-type=dfn href=#request title=requests>Requests</a> for <a data-link-type=dfn href=#active-content title=active>active</a> resources and <a data-link-type=dfn href=#blockable-passive-content title="blockable passive">blockable passive</a>
resources from an <a data-link-type=dfn href=#a-priori-insecure-origin title="a priori insecure origin"><em>a priori</em> insecure origin</a> MUST not
generate network traffic, and MUST instead return a synthetically
generated <a data-link-type=dfn href=#network-error title="network error">network error</a> response.
resources from an <a data-link-type=dfn href=#assumed-insecure-origin title="assumed insecure origin">assumed insecure origin</a> MUST not generate
network traffic, and MUST instead return a synthetically generated
<a data-link-type=dfn href=#network-error title="network error">network error</a> response.
</li>

<li>
<a data-link-type=dfn href=#request title=requests>Requests</a> for <a data-link-type=dfn href=#active-content title=active>active</a> resources and <a data-link-type=dfn href=#blockable-passive-content title="blockable passive">blockable passive</a>
resources from an <a data-link-type=dfn href=#a-posteriori-insecure-origin title="a posteriori insecure origin"><em>a posteriori</em> insecure origin</a> MUST not
be delivered to the requesting <a class=idl-code data-link-type=interface href=http://www.w3.org/html/wg/drafts/html/CR/infrastructure.html#dom-document title=document>Document</a>, but instead
MUST return a synthetically generated <a data-link-type=dfn href=#network-error title="network error">network error</a> response.
resources from an <a data-link-type=dfn href=#proven-insecure-origin title="proven insecure origin">proven insecure origin</a> MUST not be delivered to
the requesting <a class=idl-code data-link-type=interface href=http://www.w3.org/html/wg/drafts/html/CR/infrastructure.html#dom-document title=document>Document</a>, but instead MUST return a
synthetically generated <a data-link-type=dfn href=#network-error title="network error">network error</a> response.
</li>

<li>
Expand Down Expand Up @@ -654,7 +651,7 @@ <h3 class="heading settled heading" data-level=5.2 id=should-block-fetch><span c
<p>User agents should entirely block requests to <a data-link-type=dfn href=#active-content title=active>active</a> mixed content;
the Fetch specification will hook into this algorithm to determine whether a
request should be entirely blocked (e.g. because the request would be used
as <a data-link-type=dfn href=#active-content title="active content">active content</a>, and we know <em>a priori</em> that it won’t be
as <a data-link-type=dfn href=#active-content title="active content">active content</a>, and we can <em>assume</em> that it won’t be
loaded over a secure connection).</p>

<p>Given a request’s URL <var>url</var>, <a data-link-type=dfn href=#request-context title="request context">request context</a>
Expand Down Expand Up @@ -708,7 +705,7 @@ <h3 class="heading settled heading" data-level=5.3 id=should-block-response><spa
<p><a href=#should-block-fetch>If a request proceeds</a>, we still might want
to block the response based on the state of the connection that generated
the response (e.g. because the response would be used as <a data-link-type=dfn href=#active-content title="active content">active
content</a>, but the server is <a data-link-type=dfn href=#a-posteriori-insecure-origin title="a posteriori insecure"><em>a posteriori</em> insecure</a>).</p>
content</a>, but the server is <a data-link-type=dfn href=#proven-insecure-origin title="proven insecure">proven insecure</a>).</p>

<p>Given a <a data-link-type=dfn href=#response title=response>response</a> <var>response</var>, and <a data-link-type=dfn href=#request-client title="request client">request client</a>
<var>client</var>, the user agent can determine what response should be
Expand Down Expand Up @@ -778,9 +775,8 @@ <h2 class="heading settled heading" data-level=6 id=fetch-integration><span clas

<p>When fetching resources, the mixed content checks described in the algorithms
above should be inserted at the top of the Fetch algorithm to block network
traffic to <a data-link-type=dfn href=#a-priori-insecure-origin title="a priori insecure origins"><em>a priori</em> insecure origins</a>, and at the bottom of
the algorithm, to block responses from <a data-link-type=dfn href=#a-posteriori-insecure-origin title="a posteriori insecure origins"><em>a posteriori</em> insecure
origins</a>.</p>
traffic to <a data-link-type=dfn href=#assumed-insecure-origin title="assumed insecure origins">assumed insecure origins</a>, and at the bottom of the
algorithm, to block responses from <a data-link-type=dfn href=#proven-insecure-origin title="proven insecure origins">proven insecure origins</a>.</p>

<p>The Fetch algorithm MUST be updated as follows: <a data-biblio-type=normative data-link-type=biblio href=#biblio-fetch title=biblio-fetch>[FETCH]</a></p>

Expand Down Expand Up @@ -833,8 +829,8 @@ <h2 class="heading settled heading" data-level=6 id=fetch-integration><span clas

<p class=note>Note: This hook is necessary to detect resources modified or
synthesized by a ServiceWorker, as well as to determine whether a
resource is <a data-link-type=dfn href=#a-posteriori-insecure-origin title="a posteriori insecure">a posteriori insecure</a> See steps 4.1 and 4.2 of
the <a data-section="" href=#should-block-response>
resource is <a data-link-type=dfn href=#proven-insecure-origin title="proven insecure">proven insecure</a> See steps 4.1 and 4.2 of the
<a data-section="" href=#should-block-response>
Should response for client be blocked as mixed
content?
</a> algorithm for detail.</p>
Expand Down Expand Up @@ -934,12 +930,9 @@ <h2 class="no-num no-ref heading settled heading" id=index><span class=content>
<li>active, <a href=#active-content title="section 3.1">3.1</a>
<li>active content, <a href=#active-content title="section 3.1">3.1</a>
<li>active request contexts, <a href=#active-request-contexts title="section 3.1">3.1</a>
<li>a posteriori, <a href=#a-posteriori-insecure-origin title="section 2.1">2.1</a>
<li>a posteriori insecure, <a href=#a-posteriori-insecure-origin title="section 2.1">2.1</a>
<li>a posteriori insecure origin, <a href=#a-posteriori-insecure-origin title="section 2.1">2.1</a>
<li>a priori, <a href=#a-priori-insecure-origin title="section 2.1">2.1</a>
<li>a priori insecure, <a href=#a-priori-insecure-origin title="section 2.1">2.1</a>
<li>a priori insecure origin, <a href=#a-priori-insecure-origin title="section 2.1">2.1</a>
<li>assumed, <a href=#assumed-insecure-origin title="section 2.1">2.1</a>
<li>assumed insecure, <a href=#assumed-insecure-origin title="section 2.1">2.1</a>
<li>assumed insecure origin, <a href=#assumed-insecure-origin title="section 2.1">2.1</a>
<li>blockable, <a href=#blockable-passive-content title="section 3.2.2">3.2.2</a>
<li>blockable passive, <a href=#blockable-passive-content title="section 3.2.2">3.2.2</a>
<li>blockable passive content, <a href=#blockable-passive-content title="section 3.2.2">3.2.2</a>
Expand All @@ -960,6 +953,9 @@ <h2 class="no-num no-ref heading settled heading" id=index><span class=content>
<li>passive, <a href=#passive-content title="section 3.2">3.2</a>
<li>passive content, <a href=#passive-content title="section 3.2">3.2</a>
<li>plugin, <a href=#plugin title="section 2.2">2.2</a>
<li>proven, <a href=#proven-insecure-origin title="section 2.1">2.1</a>
<li>proven insecure, <a href=#proven-insecure-origin title="section 2.1">2.1</a>
<li>proven insecure origin, <a href=#proven-insecure-origin title="section 2.1">2.1</a>
<li>request, <a href=#request title="section 2.2">2.2</a>
<li>request client, <a href=#request-client title="section 2.2">2.2</a>
<li>request context, <a href=#request-context title="section 2.2">2.2</a>
Expand All @@ -974,10 +970,7 @@ <h2 class="no-num no-ref heading settled heading" id=property-index><span class=
<div data-fill-with=property-index><p>No properties defined.</div>


<h2 class="no-num heading settled" id=issues-index><span class=content>Issues Index</span><a class=self-link href=#issues-index></a></h2><div style="counter-reset: issue"><div class=issue>Is using both <em>a priori</em> and <em>a posteriori</em> in the same
specification too Kantian? I say never! Others may disagree.<a href=#issue-96ecbc9a> ↵ </a></div>

<div class=issue>Are these reasonable definitions that we want to run with?<a href=#issue-3c75cc41> ↵ </a></div>
<h2 class="no-num heading settled" id=issues-index><span class=content>Issues Index</span><a class=self-link href=#issues-index></a></h2><div style="counter-reset: issue"><div class=issue>Are these reasonable definitions that we want to run with?<a href=#issue-3c75cc41> ↵ </a></div>
<div class=issue>This doesn’t currently process resources loaded via
<code>&lt;link rel="subresource" ...&gt;</code> or
<code>Link: ...; prefetch</code>. Perhaps we should?<a href=#issue-9a86d6f9> ↵ </a></div>
Expand Down
Loading

0 comments on commit 6e9bbfa

Please sign in to comment.