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

Jump to bottom

Let HTML handle the "same site" definition #457

Merged
merged 4 commits into from
Nov 20, 2019
Merged

Let HTML handle the "same site" definition #457

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
7f9b4aa
Let HTML handle the "same site" definition
domenic Nov 11, 2019
0a1177b
Add an ID
domenic Nov 18, 2019
00ca217
Same origin-domain is unreasonable
domenic Nov 19, 2019
51f8e2f
Add temporary link-defaults block
domenic Nov 20, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
54 changes: 11 additions & 43 deletions url.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,11 @@ Abstract: The URL Standard defines URLs, domains, IP addresses, the <code>applic
Translation: ja https://triple-underscore.github.io/URL-ja.html
</pre>

<!-- TODO: remove after Bikeshed database updates itself to no longer have url version -->
<pre class=link-defaults>
spec:html; type:dfn; text:same site
</pre>


<h2 id=goals class=no-num>Goals</h2>

Expand Down Expand Up @@ -346,49 +351,12 @@ obtain <var>host</var>'s <a for=host>registrable domain</a>, run these steps:
</table>
</div>

<p>Two <a for=/>hosts</a>, <var>A</var> and <var>B</var> are said to be
<dfn for=host export>same site</dfn> with each other if either of the following statements are true:

<ul class=brief>
<li><p><var>A</var> <a for=host>equals</a> <var>B</var> and <var>A</var>'s
<a for=host>registrable domain</a> is non-null.

<li><p><var>A</var>'s <a for=host>registrable domain</a> is <var>B</var>'s
<a for=host>registrable domain</a> and is non-null.
</ul>

<div class=example id=example-same-site>
<p>Assuming that <code>suffix.example</code> is a <a for=host>public suffix</a> and that
<code>example.com</code> is not:

<ul>
<li><p><code>example.com</code>, <code>sub.example.com</code>, <code>other.example.com</code>,
<code>sub.sub.example.com</code>, and <code>sub.other.example.com</code> are all <a>same site</a>
with each other (and themselves), as their <a for=host>registrable domains</a> are
<code>example.com</code>.

<li><p><code>registrable.suffix.example</code>, <code>sub.registrable.suffix.example</code>,
<code>other.registrable.suffix.example</code>, <code>sub.sub.registrable.suffix.example</code>,
and <code>sub.other.registrable.suffix.example</code> are all <a>same site</a> with each other
(and themselves), as their <a for=host>registrable domains</a> are
<code>registrable.suffix.example</code>.

<li><p><code>example.com</code> and <code>registrable.suffix.example</code> are not
<a>same site</a> with each other, as their <a for=host>registrable domains</a> differ.

<li><p><code>suffix.example</code> is not <a>same site</a> with <code>suffix.example</code>, as
it is a <a for=host>public suffix</a>, and therefore has a null
<a for=host>registrable domain</a>.
</ul>
</div>

<p class=warning>Specifications should prefer the <a for=/>origin</a> concept for security
decisions. The notion of "<a for=host>public suffix</a>", "<a for=host>registrable domain</a>",
and "<a>same site</a>" cannot be relied-upon to provide a hard security boundary, as the public
suffix list will diverge from client to client. Specifications which ignore this advice are
encouraged to carefully consider whether URLs' schemes ought to be incorporated into any decision
made based upon whether or not two <a for=/>hosts</a> are <a>same site</a>. HTML's <a>same
origin-domain</a> concept is a reasonable example of this consideration in practice.
<p class=warning id=warning-avoid-psl>Specifications should prefer the <a for=/>origin</a> concept
for security decisions. The notion of "<a for=host>public suffix</a>" and
"<a for=host>registrable domain</a>" cannot be relied-upon to provide a hard security boundary, as
the public suffix list will diverge from client to client. Specifications which ignore this advice
are encouraged to carefully consider whether URLs' schemes ought to be incorporated into any
decisions made, i.e. whether to use the <a>same site</a> or <a>schemelessly same site</a> concepts.


<h3 id=idna>IDNA</h3>
Expand Down