about:blank gets to inherit cookies, too

[annevk]

Per https://bugzilla.mozilla.org/show_bug.cgi?id=1223885 it seems that in the majority of implementations cookies cross the about:blank boundary too, just like HTTPS state, etc.

It seems this copying is not currently happening when creating a new browsing context though: https://html.spec.whatwg.org/#creating-a-new-browsing-context. Hmm.

[bzbarsky]

So what Gecko does here isn't to copy the cookies, since those can obviously change.

Instead, what Gecko does is that it has a concept of "origin URI" which is normally the same as the document URI (e.g. when a document is loaded over HTTP). When origins are inherited/aliased, the origin URI is inherited as well. Access to document.cookie uses the "origin URI", not the document URI.

I looked into what Blink does, and they have a "cookieURL" on their Document object, with the following comment:

// The cookieURL is used to query the cookie database for this document's
// cookies. For example, if the cookie URL is http://example.com, we'll
// use the non-Secure cookies for example.com when computing
// document.cookie.
//
// Q: How is the cookieURL different from the document's URL?
// A: The two URLs are the same almost all the time.  However, if one
//    document inherits the security context of another document, it
//    inherits its cookieURL but not its URL.

which sounds basically like the Gecko setup with slightly different names. WebKit has the same thing as Blink; I assume it predates the fork (not surprising).

[annevk]

Okay, so that means documents have at least three associated URLs:

1. Creation URL
2. Current URL
3. Cookie URL

I guess that's easy enough. It's still unclear whether we are inheriting all this state correctly in the first place though. E.g., it doesn't seem like HTTPS state gets inherited when creating an about:blank browsing context. @mikewest?

[mikewest]

If we're creating a new top-level browsing context, I'd suggest that we shouldn't inherit this state.

If we're creating a nested or auxiliary browsing context, inheriting the various bits of state for about:blank makes sense.

[annevk]

That makes sense. This should also happen when navigating to a non-initial about:blank right? Although in that case do you inherit from the parent or the source browsing context?

[bzbarsky]

In Gecko's case, from the source. Note that there might not be a parent at all (consider navigating a toplevel window to about:blank).

[mikewest]

I agree that inheriting from the navigation's source is the right thing to do. It's not what WebKit/Blink does, though, and it would be a pretty large effort to change that.

[bzbarsky]

That's surprising, in light of the above-cited source comments that say that cookie inheritance follows security context inheritance, because security context inheritance does come from the source, right?

[mikewest]

It does follow context inheritance, but Blink inherits the security context for about:blank from the document in which about:blank is embedded, not the document that initiated the navigation. That is, if https://example.com runs the following:

var i = document.createElement('iframe');
i.src = "https://something-cross-origin.com/";
document.body.appendChild(i);

// Assume that the document loaded into the frame contains something like
// `<script>window.location = 'about:blank';</script>`

It will result in a frame that's same-origin with https://example.com/ in Blink/WebKit, and a frame that's same-origin with https://something-cross-origin.com/ in Gecko and Edge.

[bzbarsky]

but Blink inherits the security context for about:blank from the document in which about:blank is embedded, not the document that initiated the navigation

I see. Except in the window.open() case, right? Because I'm pretty sure that initial about:blank inherits the origin of the caller of window.open() in Blink/WebKit.

In any case, it sounds like what Blink/WebKit are doing there is already not following what the spec says should happen for origin inheritance... :( What do you do for navigation of a toplevel window?

[mikewest]

I'm pretty sure that initial about:blank inherits the origin of the caller of window.open() in Blink/WebKit.

Correct. We transfer the origin from the window's opener in the same way Gecko does for window.open and <a target>.

In any case, it sounds like what Blink/WebKit are doing there is already not following what the spec says should happen for origin inheritance... :(

That's correct. Blink/WebKit have never followed the spec's recommendations on this point, though I think I agree that the specced inheritance behavior is better than what we currently implement.

What do you do for navigation of a toplevel window?

We inherit from the opener for cases where a top-level window navigates to about:blank. If the top-level window doesn't have an opener, we'll assign an opaque origin.

[anforowicz]

FWIW, the HTML spec currently says that https://html.spec.whatwg.org/#dom-document-cookie says that about:blank is associated with a cookie-averse-document-object (because the about scheme is not a network scheme - not a ftp/http/https scheme). It seems that this used to be called a "cookie-free document" and dates back to 2010 (5118883). This seems to contradict the actual behavior of browsers, which do associate about:blank documents with cookies (as outlined in the current issue) and do not throw a SecurityError exception as asked by the HTML spec for cookie-averse documents.

[annevk]

Yeah, that should probably be based on whether or not the document has an opaque origin.