specify prerender processing model

[jakearchibald]

Both same-site cookies and From-Origin mitigate against HEIST at the root by preventing the requesting origin from getting timing data from a credentialed request to another origin.

Both proposals (optionally in same-site cookies) allow the credentialed cross-origin response if it's part of a top-level navigation.

As it's currently specced, it isn't clear where prerender fits into that, as it may or may not be top level. Its fetching and matching needs to be specified.

Options:

• Downgrade prerender to preconnect for cross-origin resources (prefetch doesn't make sense as a fallback here)
• Allow the as attribute, which can be something like "top-level" or "auxiliary" - this would indicate how same-site/from-origin should be applied, and when the prerendered document can be matched to a navigation
  • Load events must never be fired for "top-level" prerenders as this leaks timing data that may otherwise be prevented

[jakearchibald]

I'm similarly concerned about prefetch, as it isn't clear if the prefetched resource can be used in a cross-origin navigation. It's fine if the prefetch cache is just the HTTP cache, but that isn't clear either.

[igrigorik]

The problem you're describing extends beyond prerender. Before we talk about prerender specific mitigations, let's sort out the general case - see my comment in w3c/resource-timing#64 (comment).

[jakearchibald]

We still need to solve this case, as auxiliary vs top-level matters for secure contexts and .opener.

[igrigorik]

(note: updated the issue title, since what we're discussing here extends beyond HEIST)

The Chrome policy is as follows:

If prerendering is requested, whether by Chrome or by a site or app, the preloaded site is allowed to set and read its own cookies just as if you had visited it (even if you don’t end up visiting the prerendered page). Website-initiated preloading is disabled if you disallow third party cookies, to prevent cookies from being set from pages that you did not visit. -- source

I don't know how/if that aligns with implementations of other browser vendors. Also, Chrome does not fire onload/onerror events for the element. /cc @toddreifsteck @mcmanus

Downgrade prerender to preconnect for cross-origin resources

That would break one of the primary motivating use cases.. e.g. a search engine prerendering a high confidence hit for the user.

[jakearchibald]

Sounds like we need an attribute & matching algorithm so the origin can hint if lax same-site cookies should be used.

Related: httpwg/http-extensions#226

Chrome does not fire onload/onerror events for the element

I think this should be in the spec for cross-origin prerenders.

[igrigorik]

Sounds like we need an attribute & matching algorithm so the origin can hint if lax same-site cookies should be used.

Which origin? The one initiating the prerender? I don't see what that wins you or how the initiator would even know what to set it as.

[jakearchibald]

I, the initiator, know if I'm going to display the site in an iframe, or in a popup, vs a top-level navigation. Therefore I know how I'd like the page prerendered.

[igrigorik]

As far as I can tell, Chrome will only use prerender for top-level navigation. iframed / popup content doesn't leverage prerender. I'm not sure about other browsers. Quick test:

• Open chrome://net-internals/#prerender
• Go to http://output.jsbin.com/gijiyawuvi/9/quiet
  • You should see the active prerender in net-internals but it won't be logged as used for iframe or window.open.

[annevk]

Hmm, those kind of limitations should really be defined as part of the standard...

[yoavweiss]

https://wicg.github.io/nav-speculation/prerendering.html seems like a decent take on this issue.

[clelland]

Closing this; prerender has moved to https://wicg.github.io/nav-speculation/, and didn't follow this spec's move into HTML.