Subject: questions on same-site cookies algorithm (draft-west-first-party-cookies)

From: [email-masked]
Date: Fri, 17 Jun 2016 12:51:44 -0600

Hi,

I have some questions about the below section of the latest version (-07) of..

  https://tools.ietf.org/html/draft-west-first-party-cookies

..perhaps I'm confused, hopefully you can enlighten me.

> 2.1.1.  Document-based requests
>
>    The URI displayed in a user agent's address bar is the only security
>    context directly exposed to users, and therefore the only signal
>    users can reasonably rely upon to determine whether or not they trust
>    a particular website.  The registrable domain of that URI's origin
>    represents the context in which a user most likely believes
>    themselves to be interacting.  We'll label this domain the "top-level
>    site".
>
>    For a document displayed in a top-level browsing context, we can stop
>    here: the document's "site for cookies" is the top-level site.
>
>    For documents which are displayed in nested browsing contexts, we
>    need to audit the origins of each of a document's ancestor browsing
>    contexts' active documents in order to account for the "multiple-
>    nested scenarios" described in Section 4 of [RFC7034].  These
>    document's "site for cookies" is the top-level site if and only if
>    the document and each of its ancestor documents' origins have the
>    same registrable domain as the top-level site.  Otherwise its "site
>    for cookies" is the empty string.
>
>    Given a Document ("document"), the following algorithm returns its
>    "site for cookies" (either a registrable domain, or the empty
>    string):
>
>    1.  Let "top-document" be the active document in "document"'s
>        browsing context's top-level browsing context.
>
>    2.  Let "top-origin" be the origin of "top-document"'s URI if "top-
>        document"'s sandboxed origin browsing context flag is set, and
>        "top-document"'s origin otherwise.

these..

  https://html.spec.whatwg.org/#origin
  https://html.spec.whatwg.org/#concept-origin-opaque

..indicate that a document, that has its `sandboxed origin browsing
context flag` set, has only a `unique opaque origin` whose ASCII
serialization is `"null"`, and does not have an associated URI
(necessarily?)

Yet, in step 4.1 below...

>    3.  Let "documents" be a list containing "document" and each of
>        "document"'s ancestor browsing contexts' active documents.
>
>    4.  For each "item" in "documents":
>
>        1.  Let "origin" be the origin of "item"'s URI if "item"'s
>            sandboxed origin browsing context flag is set, and "item"'s
>            origin otherwise.

..this step is relying on there being a URI from which an origin can be
extracted when the item's sandboxed origin browsing context flag is set, but
according to the HTML spec (links above) it has only a `unique opaque origin`
-- I'm not sure how this will work?

should "set" actually be "not set" ?  or am I missing something?

>
>        2.  If "origin"'s host's registrable domain is not an exact match
>            for "top-origin"'s host's registrable domain, return the
>            empty string.
>
>    5.  Return "top-site".

thanks,

=JeffH

---

From: Mike West <[email-masked]>
Date: Tue, 21 Jun 2016 13:35:50 +0200

Thanks for the feedback, Jeff!

On Fri, Jun 17, 2016 at 8:51 PM, <[email-masked]> wrote:

> >    ...

All documents have a URL distinct from their origin:
https://dom.spec.whatwg.org/#concept-document-url. The URL might be
something like `about:blank`, in which case this algorithm would still
result in an opaque origin as the document's site for cookies, but that
seems like enough of an edge case to not worry about.

(An alternative would be to simplify the algorithm by treating sandboxed
documents as completely distinct from the origin from which they were
served. That's not what Safari, Chrome, or Firefox do today with regard to
so-called "third-party cookie blocking", but it's a reasonable alternative
proposal.)

-mike