From 16570ff808267383a393064ff951b764911be78f Mon Sep 17 00:00:00 2001
From: Domenic Denicola <d@domenic.me>
Date: Thu, 1 Sep 2022 23:38:21 -0400
Subject: [PATCH] Support same-site cross-origin prerendering

This includes our first formal spec for Supports-Loading-Mode, and an update to its explainer to reflect what we're most immediately looking to ship.
---
 README.md                                     |   6 +-
 opt-in.md                                     | 155 +++++++++---------
 ...ss-origin.md => prerendering-cross-site.md |  16 +-
 ...ame-origin.md => prerendering-same-site.md |  50 ++++--
 prerendering-state.md                         |   2 +-
 prerendering.bs                               |  42 ++++-
 same-origin-chrome-origin-trial.md            |   2 +-
 same-origin-security-privacy-questionnaire.md |  10 +-
 speculation-rules.bs                          |   2 +-
 9 files changed, 175 insertions(+), 110 deletions(-)
 rename prerendering-cross-origin.md => prerendering-cross-site.md (86%)
 rename prerendering-same-origin.md => prerendering-same-site.md (81%)

diff --git a/README.md b/README.md
index ff94728..b86c851 100644
--- a/README.md
+++ b/README.md
@@ -21,20 +21,20 @@ See [the full explainer](./triggers.md) for more.
 
 Prerendering is more complex than prefetching, as it involves running the target page's scripts and loading its subresources. We've produced a couple of relevant explainers:
 
-* [Same-origin prerendering](./prerendering-same-origin.md), discusses what we believe to be solid so far: user agent-triggered and same-origin-triggered prerendering.
+* [Same-site prerendering](./prerendering-same-site.md), discusses what we believe to be solid so far: user agent-triggered and same-site-triggered prerendering.
 * [Prerendering state APIs](./prerendering-state.md), discussing the new `document.prerendering` API and its associated event in more detail.
 
 ## Cross-origin and cross-site concerns
 
 Much of the complexity of preloading comes in when dealing with site that is cross-origin or cross-site. Origins are the web's security boundary, and sites are its privacy boundary, so any preloading across these boundaries needs to preserve the relevant properties.
 
-Our current proposals are focused around allowing cross-origin/site prefetching. We also have some early thoughts on cross-origin/site prerendering, but have not yet committed to them. The following explainers are relevant:
+Our current proposals are focused around allowing cross-origin/site prefetching, and cross-origin but same-site prerendering. We also have some early thoughts on cross-site prerendering, but have not yet committed to them. The following explainers are relevant:
 
 * [Cross-site preloading fetching modes](./fetch.md), discussing how to perform the fetch of the main content and any subresources while doing cross-site preloading.
 * [`Supports-Loading-Mode`](./opt-in.md), a new header which allows target pages to opt in to being loaded in an uncredentialed mode, with the understanding that they will upgrade their content later upon activation.
 * [`<meta http-equiv="supports-loading-mode">`](https://github.com/WICG/nav-speculation/blob/main/meta-processing.md), an extension to the header definition that uses a HTML preparsing pass to allow it to appear in-document.
 * [Client IP anonymization](./anonymous-client-ip.md), an extension to prefetching (and maybe one day prerendering?) to require using an anonymizing proxy to hide the user's IP address.
-* [Cross-origin prerendering](./cross-origin-prerendering.md), containing what we've brainstormed so far about how cross-origin prerendering could work in the future.
+* [Cross-site prerendering](./cross-site-prerendering.md), containing what we've brainstormed so far about how cross-site prerendering could work in the future.
 
 ## Portals
 
diff --git a/opt-in.md b/opt-in.md
index 79e440a..6109ff0 100644
--- a/opt-in.md
+++ b/opt-in.md
@@ -1,84 +1,103 @@
-# Prerendering opt-in
+# Loading mode support
 
-Because [prerendering fetching modes](./fetch.md) intentionally obscure the user's identity, the response document cannot be personalized for the user. If it is used when the user navigates, the user will notice that they are not logged in (even if they should be), and other surprising behavior.
+Several subtypes of preloading introduce novel ways of loading content, which the destination site might not be prepared for. In such cases, we require that the response signal that they support the given loading mode, via the `Supports-Loading-Mode` header proposed here.
 
-Similarly, prerendering browsing contexts allow HTML parsing, subresource fetching, and script execution, but such actions are restricted to avoid identifying the user or causing user-visible annoyance.
+<!-- START doctoc generated TOC please keep comment here to allow auto update -->
+<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
+## Table of contents
 
-Pages designed with these restrictions in mind can "upgrade" themselves when they load, by personalizing based on data in unpartitioned storage and by fetching personalized content from the server. But existing web pages are unlikely to behave well with these restrictions today. (And, it is impractical for user agents to distinguish such pages.)
+- [HTTP header declaration](#http-header-declaration)
+- [Use cases](#use-cases)
+  - [Uncredentialed preloading](#uncredentialed-preloading)
+  - [Cross-origin same-site prerendering](#cross-origin-same-site-prerendering)
+  - [Non-preloading cases](#non-preloading-cases)
+- [Future extensions](#future-extensions)
+  - [An in-markup version](#an-in-markup-version)
+  - [Application to subframes while prerendering](#application-to-subframes-while-prerendering)
+- [Redirect handling](#redirect-handling)
+- [Alternatives considered](#alternatives-considered)
+  - [No declaration](#no-declaration)
+  - [Opt-out only](#opt-out-only)
+  - [Document policy](#document-policy)
+- [Acknowledgments](#acknowledgments)
 
-As such, we propose a lightweight way for a page to declare that it is prepared for such prerendering, and will, if necessary, upgrade itself when it gains access to unpartitioned storage and other privileges.
+<!-- END doctoc generated TOC please keep comment here to allow auto update -->
 
-There has been previous discussion along these lines in [w3c/resource-hints#82](https://github.com/w3c/resource-hints/issues/82#issuecomment-536492276). (It also proposes a new `prenavigate` hint; defining triggers for these loading modes is not yet part of this proposal.)
+## HTTP header declaration
 
-## Table of contents
+```http
+Supports-Loading-Mode: uncredentialed-prefetch, uncredentialed-prerender
+```
 
-- [Declaration](#declaration)
-- [Request header](#request-header)
-- [Risks](#risks)
-- [Alternatives considered](#alternatives-considered)
+This is an [HTTP structured header][http-structured-header] which lists tokens indicating the loading modes the content is ready for. The tokens we so far envision are:
 
-## Declaration
+* `uncredentialed-prefetch`
+* `uncredentialed-prerender`
+* `credentialed-prerender`
 
-```
-// HTTP response header
-Supports-Loading-Mode: uncredentialed-prefetch, uncredentialed-prerender
+## Use cases
 
-// HTML meta tag
-<meta http-equiv="Supports-Loading-Mode"
-      content="uncredentialed-prefetch, uncredentialed-prerender">
-```
+### Uncredentialed preloading
+
+Cross-site preloads intentionally obscure the user's identity, to avoid leaking it to sites that the user has not yet affirmatively indicated an intent to visit. See the [Cross-site preloading fetching modes](./fetch.md) document for more details. Because of this, the resulting responses cannot be personalized for the user. If such responses are directly shown to the user upon activation, the user will notice that they are not logged in (even if they should be), and other surprising behavior.
+
+Pages designed with these restrictions in mind can "upgrade" themselves when they are activated, by personalizing based on data in unpartitioned storage and by fetching personalized content from the server. But existing web pages are unlikely to behave well with these restrictions today. (And, it is impractical for user agents to distinguish such pages.)
+
+To resolve this problem, user agents must only preload pages which either:
 
-This is an [HTTP structured header][http-structured-header] which lists tokens indicating the loading modes the content is ready for. They have the following proposed meaning:
+* Have no stored credentials (for prefetch) or storage of any kind (for prerender); or
+* Indicate that they are prepared to perform this sort of upgrade, by sending the appropriate `Supports-Loading-Mode` header value: either `uncredentialed-prefetch`, `uncredentialed-prerender`, or both.
 
-<dl>
-  <dt><code>default</code></dt>
-  <dd>Implied, even if not listed. Baseline standard behavior.</dd>
+_Note: these values are not currently implemented in Chromium._
 
-  <dt><code>uncredentialed-prefetch</code></dt>
-  <dd>The resource is suitable for any user who meets the cache conditions. Either it is not personalized, or it includes script to modify the document to reflect credentialed state (e.g., to show the user's logged-in state). However, access to credentials will be available when the document loads and script executes.</dd>
+### Cross-origin same-site prerendering
 
-  <dt><code>uncredentialed-prerender</code></dt>
-  <dd>Implies <code>uncredentialed-prefetch</code>. The resource can be loaded without access to its credentials and storage. Access to certain other APIs may be limited in this state. Either it is not personalized based on credentials, or it includes script to modify the document when the loading state changes to permit it.</dd>
-</dl>
+For prerendering, there is an additional complication when dealing with cross-origin destinations. Because the web's privacy boundary is site, we can send credentials and give storage access to such pages before activation. However, the web's _security_ boundary is the origin, not the site. So we need to ensure that pages cannot use prerendering to attack other origins—even same-site ones.
 
-The `<meta>` tag is processed only if it appears within the `<head>` element and no `<script>`, `<noscript>` or `<template>` tag appears before it.
-This means that the supported loading modes, if not declared in a response header, can be statically computed with use of an HTML parser without rendering or script execution.
-See [the meta processing model](meta-processing.md) for details.
+As a concrete example of what an "attack" might look like, consider an organization which provides both web hosting and document editing services. Furthermore, assume that whenever you render a document on the document editing service, the viewer's JavaScript code updates the user's list of recently-viewed documents. And finally, assume that the document editing service is not prerendering-aware, i.e. it has no code that checks [`document.prerendering`](./prerendering-state.md) to customize its behavior. Then, if we allowed `https://sites.example.com/bobs-star-wars-fan-site` to prerender `https://docs.example.com/public-list-of-best-star-wars-movies` with no opt-in, Bob's Star Wars Fan Site would be able to update the user's list of recently-viewed documents, pushing the List of Best Star Wars Movies document to the top.
 
-Blocking subframes which do not make this declaration is likely to make adoption more difficult. Ideally the author would be able to make as few declarations as possible to opt in, as long as this doesn't break too much. Fundamentally, there are three basic options here:
-* subframe load fails
-* subframe load is deferred until navigation
-* subframe load proceeds
+To resolve this problem, we need to extend the previous section as follows:
 
-And there are several different scenarios:
-* same-origin subframe, declaration present
-* same-origin subframe, declaration absent
-* cross-origin subframe, declaration present
-* cross-origin subframe, declaration absent
+* Prerendering a cross-site URL will perform the fetch, and only use the results if it contains `Supports-Loading-Mode: uncredentialed-prerender`
+* Prerendering a cross-origin same-site URL will perform the fetch, and only use the results if it contains `Supports-Loading-Mode: credentialed-prerender`
+* (Prerendering a same-origin URL does not have any restriction.)
 
-> TODO: settle on what to do in each of these cases.
+_Note: as indicated previously, the first case here is not yet implemented in Chromium; for cross-site URLs, we instead just ignore the prerendering request._
 
-## Request header
+With this framework in place, by default, Bob's Star Wars Fan Site's attempt to prerender the List of Best Star Wars Movies document will fail and have no effect. And eventually, `https://docs.example.com/` might update their code to be prerendering aware, by not modifying the user's list of recently-viewed documents while prerendering. Once they've made such updates, `https://docs.example.com/` can add the `Supports-Loading-Mode: credentialed-prerender` header, and now the prerendering will work—giving a fast navigation from Bob's Star Wars Fan Site, with no unintended side effects.
 
-If an alternate loading mode is used, the user agent will send a `Sec-Loading-Mode` request header indicating the mode. The server may respond with an error status code (400-599), in which case prefetching/prerendering will be considered to have failed, regardless of the response body.
+### Non-preloading cases
 
-A server could defer non-idempotent behavior such as impression counting,  or it could reject prerender requests altogether without needing to do the full work to generate a response (since it need only inspect the request headers).
+There are other contexts on the web platform where novel loading modes are introduced. One of these is [fenced frames](https://github.com/WICG/fenced-frame), which also will use the `Supports-Loading-Mode` opt-in.
 
-> TODO: Should we also/instead send `Sec-Purpose`? Should `Sec-Fetch-Mode` differ?
+## Future extensions
 
-## Risks
+### An in-markup version
 
-__Credentialed requests__ allow fetching the right resource for the user, but the web is increasingly moving toward a model whereby an origin cannot trigger credentialed requests to another origin except as part of a committed action (i.e., a navigation). Forward-looking prerendering should prefer to use uncredentialed requests to reduce the risk of identifying the user when doing so is undesirable, and should also deny access to unpartitioned storage under those circumstances.
+We believe it would also be possible to have a `<meta>` version of this opt-in, within the response body:
 
-Requests originating from the same __source IP address__ or otherwise implicitly detectable as the same user (e.g. fingerprinting approaches) may sometimes allow identification of the user even when credentials like cookies are not available. Forward-looking prerendering should allow the user agent to mitigate these risks, for example by obscuring the source IP (with a proxy server or [CDN][ip-blindness] that does not disclose it to the origin server, or by taking advantage of network capabilities to use [multiple IP addresses][ipv6-privacy]) and by making less fingerprintable data available to content during prerendering, if possible.
+```html
+<meta http-equiv="Supports-Loading-Mode"
+      content="uncredentialed-prefetch, uncredentialed-prerender">
+```
+
+This would be processed only if it appears within the `<head>` element and no `<script>`, `<noscript>` or `<template>` tag appears before it. This means that the supported loading modes, if not declared in a response header, can be statically computed with use of an HTML parser without rendering or script execution. See [the meta processing model](./meta-processing.md) for details.
+
+The main advantage here is that this may be easier to adopt. In order to make as much content as possible available for uncredentialed preloading, we would like to make it as easy as possible for authors to mark eligible content. We have heard from developers that many of them find it much easier to deploy changes that only affect content than changes which also require server behavior changes, even relatively straightforward ones. For example, these may be managed by different teams or not be possible at all. One example here is that GitHub Pages doesn't allow users to set response headers.
+
+### Application to subframes while prerendering
+
+Currently while prerendering, the loading of all cross-origin subframes are delayed. This prevents attacks similar to those described [above](#cross-origin-same-site-prerender). But of course, it has the cost that some of the benefits of prerendering are absent for such pages.
 
-If approaches which restrict access to credentials and storage are used, __existing content may be broken__ if prefetched or prerendered in this way. This could be mitigated by user agent heuristics to only load content believed to work correctly (e.g. via reporting from past visitors to that site or from a robot indexer) or by an author declaration whether the resource will function correctly with this modified behavior. This document proposes the latter.
+We could use `Supports-Loading-Mode` to allow subframes to indicate they are OK with being prerendered, using either the `credentialed-prerender` or `uncredentialed-prerender` variants.
 
-Server behavior in response to a GET request __may not be idempotent__. Thus issuing a request early may lead to changes in server state, such as modifying data or recording an ad impression. Unauthenticated requests to servers on the public Internet are believed to be at somewhat lower risk, because the lack of credential likely does not convey significant authority to make destructive changes and because such servers already contend with web crawlers which issue such requests. In the same-origin case, an express signal from the author that the user agent should prerender is also an indication that the request is likely to be idempotent. An alternative future direction for exploration is a capability for an origin to declare that certain URLs can be accessed idempotently, for example by responding to OPTIONS requests or by serving a manifest from a well-known URL, but this suggests a higher barrier to entry.
+It's not 100% clear this is necessary, because after [storage partitioning](https://github.com/privacycg/storage-partitioning/), the "attacks" on these cross-origin subframes would actually be on the subframe origin's partition within the top-level prerendered origin. Arguably, the top-level prerendered origin could be the one making decisions on behalf of its sub-partitions. If we want to start un-delaying cross-origin subframes in the future, we'll need to consider this question more carefully, and discuss it with the storage partitioning community.
 
-There is a risk that loading the resource may be __resource-intensive__. This is largely out of scope of this document. User agents may cancel prerendering if it has become too resource-intensive and may apply a variety of heuristics to make an educated decision about whether prerendering is likely to be lightweight.
+## Redirect handling
 
-Finally, there is the risk that any proposal is __too arduous for adoption__. Unless the effect on author incentives is extremely strong it will be very difficult to convince them to deploy a complex solution. The simpler and easier to adopt, the more likely adoption will become widespread.
+This header only needs to be supplied by the final response in any redirect chain. For example, for the `credentialed-prerender` case, `https://example.com/` → `https://a.example.com/` without the header → `https://b.example.com/` with the header succeeds.
+
+This is because checking the intermediate redirects does not gain anything. Once the request has been issued, any server-side behavior has already happened, and we will not process any client-side behavior for redirect responses.
 
 ## Alternatives considered
 
@@ -86,11 +105,11 @@ Finally, there is the risk that any proposal is __too arduous for adoption__. Un
 
 Why is a declaration needed at all? Why can't the document be fetched and loaded normally, just without credentials?
 
-The origin may already have data in its unpartitioned storage, but from the above, our goal is to provide for prerendering which does not grant access to it until the user actually navigates to the destination site. However, this may cause the content to load and behave differently than it would have with access to its unpartitioned storage. Then, when the prerendered document is preseneted, the user will observe any such differences as brokenness.
+The origin may already have data in its unpartitioned storage, but from the above, our goal is to provide for preloading which does not grant access to it until the user actually navigates to the destination site. However, this may cause the content to load and behave differently than it would have with access to its unpartitioned storage. Then, when the prerendered document is preseneted, the user will observe any such differences as brokenness.
 
 For example, an authenticated user or subscriber will observe that on navigation, that state is not reflected (they appear logged out or encounter a paywall). The user is likely to __blame the innocent destination site for this brokenness__. (Naturally, this is unlikely to be an issue if the origin has no existing cookies or other storage.)
 
-The user agent could reload the page on navigation, but this would defeat the point of prerendering.
+The user agent could reload the page on navigation, but this would defeat the point of preloading.
 
 If the user agent could detect brokenness, it could avoid this. However, this seems impossible to do in general, because:
 
@@ -105,37 +124,21 @@ Could an opt-out suffice? It would seem to make it easier to increase coverage.
 
 In principle, yes. However, this would mean that content may become broken (as described above) and require authors to roll out an opt-out to simply restore the previous level of functionality. This seems problematic, especially since we anticipate a large fraction of the web would be affected.
 
-### HTTP header exchange only
-
-An opt-in solely based on HTTP request and response headers is appealing. It allows the fetch to be terminated before processing the response body, and doesn't require HTML parsing or other complicated logic to handle.
-
-The largest drawback here is one of adoption. In order to make as much content as possible available for uncredentialed prerendering, we would like to make it as easy as possible for authors to mark eligible content. We have heard from developers that many of them find it much easier to deploy changes that only affect content than changes which also require server behavior changes, even relatively straightforward ones. For example, these may be managed by different teams or not be possible at all. One key example here is that GitHub Pages doesn't allow users to set response headers.
-
-This strongly indicates an opt-in in the HTML document, such as a `<meta>` tag, attribute of the `<html>` element, or other affordance entirely within the HTML response body.
+Note that there is some precedent for opting out of a novel loading mode in `X-Frame-Options`, which lets content opt out of being loaded inside a frame. However, this model is widely seen as a mistake, and it would have been better to have been designed as an opt-in.
 
 ### Document policy
 
-[Document policy][document-policy] provides a related mechanism, which allows a document to provide a set of behavior changes and restrictions it wishes to apply to itself in an HTTP response header, `Document-Policy`. The request may contain a `Sec-Required-Document-Policy` header, which indicates the minimum level of strictness for each policy that is required -- otherwise the load will fail.
+[Document policy][] provides a related mechanism, which allows a document to provide a set of behavior changes and restrictions it wishes to apply to itself in an HTTP response header, `Document-Policy`. The request may contain a `Sec-Required-Document-Policy` header, which indicates the minimum level of strictness for each policy that is required—otherwise the load will fail.
 
-Document policy does not support a mechanism for setting policy inside the response body, which we believe to be important to ease of deployment by authors. It might be possible to extend document policy to also support this, but there would be significant added complexity in document policy, such as algorithms for combining policy declarations in both places and deferring loads in contexts with a required document policy until it can be determined that the merged policy is suitable. These problems are somewhat similar in the special case this proposal discusses than in the general case of document policy.
-
-`Sec-Required-Document-Policy` would not replace the need for a [request header](#request-header), since this is settable by content that is not genuinely prerendering, e.g. via `<iframe policy>`.
-
-Document policy also defines a strict mechanism for inheritance of strict document policy (always inherited by subframes, declaration is required or load fails), but this is not flexible enough for the preferred behavior above. In particular the option of deferral wouldn't ordinarily make sense for document policy (since required policy and policy both cannot change), but do make sense for prerendering, where the user may eventually navigate.
+Document policy also defines a strict mechanism for inheritance of strict document policy (always inherited by subframes, declaration is required or load fails), but this is not flexible enough for the preferred behavior above. In particular the option of deferral wouldn't ordinarily make sense for document policy (since required policy and policy both cannot change), but do make sense for preloading, where the user may eventually navigate.
 
 Document policy is also immutable, so either we would have to introduce a notion of mutable required policy and mutable policy, or we would have to define a policy named something like `initial-unpartitioned-storage` that doesn't change, but which only controls unpartitioned storage "initially". This is somewhat awkward and could lead to an explosion of "initial" vs "always" policies.
 
-We do, however, intend to use common integration points with permissions policy such as the HTML [allowed to use][allowed-to-use] algorithm to minimize the collatoral complexity imposed on other specifications, where possible.
-
 ## Acknowledgments
 
-@jeremyroman is the primary author of this explainer.
+@jeremyroman and @domenic are the primary authors of this explainer.
 
-Thanks to @domenic, @kinu, @yoavweiss, @clelland, and others, for their thoughts which contributed to this proposal.
+Thanks to @kinu, @yoavweiss, @clelland, and others, for their thoughts which contributed to this proposal.
 
-[allowed-to-use]: https://html.spec.whatwg.org/#allowed-to-use
-[document-policy]: https://github.com/w3c/webappsec-permissions-policy/blob/master/document-policy-explainer.md
+[document policy]: https://github.com/w3c/webappsec-permissions-policy/blob/master/document-policy-explainer.md
 [http-structured-header]: https://httpwg.org/http-extensions/draft-ietf-httpbis-header-structure.html
-[ip-blindness]: https://github.com/bslassey/ip-blindness
-[ipv6-privacy]: https://tools.ietf.org/html/rfc4941
-[storage-access]: https://github.com/privacycg/storage-access
diff --git a/prerendering-cross-origin.md b/prerendering-cross-site.md
similarity index 86%
rename from prerendering-cross-origin.md
rename to prerendering-cross-site.md
index d7f96e1..71200dc 100644
--- a/prerendering-cross-origin.md
+++ b/prerendering-cross-site.md
@@ -1,6 +1,6 @@
-# Cross-origin prerendering
+# Cross-site prerendering
 
-Building on our vision for [same-origin prerendering](./prerendering-same-origin.md), we would eventually like to enable prerendering of cross-origin content.
+Building on our vision for [same-site prerendering](./prerendering-same-site.md), we would eventually like to enable prerendering of cross-site content.
 
 None of this is implemented or specified in detail yet. But, we've spent some time thinking about it, and wanted to capture that process publicly.
 
@@ -18,11 +18,11 @@ None of this is implemented or specified in detail yet. But, we've spent some ti
 
 ## Privacy-based restrictions
 
-In addition to the [restrictions for same-origin prerendering](./prerendering-same-origin.md#restrictions), cross-origin prerendering has more privacy-based restrictions. In particular, prerendering is intended to comply with the [W3C Target Privacy Threat Model](https://w3cping.github.io/privacy-threat-model/). This section discusses the aspects of that threat model that are particularly relevant to the browsing context part of the story, and how the design satisfies them.
+In addition to the [restrictions for same-site prerendering](./prerendering-same-site.md#restrictions), cross-site prerendering has more privacy-based restrictions. In particular, prerendering is intended to comply with the [W3C Target Privacy Threat Model](https://w3cping.github.io/privacy-threat-model/). This section discusses the aspects of that threat model that are particularly relevant to the browsing context part of the story, and how the design satisfies them.
 
 A prerendering browsing context can contain either a same-site or cross-site resource. Same-site prerendered content don't present any privacy risks, but cross-site resources risk enabling [cross-site recognition](https://w3cping.github.io/privacy-threat-model/#model-cross-site-recognition) by creating a messaging channel across otherwise-partitioned domains. For simplicity, when a cross-site channel needs to be blocked, we also block it for same-site cross-origin content. In some cases we even block it for same-origin content.
 
-Because prerendered browsing contexts can be activated, they (eventually) live in the first-party [storage shelf](https://storage.spec.whatwg.org/#storage-shelf) of their origin. This means that the usual plan of [storage partitioning](https://github.com/privacycg/storage-partitioning) does not suffice for prerendering browsing contexts as it does for nested browsing contexts (i.e. iframes). Instead, we take the following measures to restrict cross-origin prerendered content:
+Because prerendered browsing contexts can be activated, they (eventually) live in the first-party [storage shelf](https://storage.spec.whatwg.org/#storage-shelf) of their origin. This means that the usual plan of [storage partitioning](https://github.com/privacycg/storage-partitioning) does not suffice for prerendering browsing contexts as it does for nested browsing contexts (i.e. iframes). Instead, we take the following measures to restrict cross-site prerendered content:
 
 - Prevent communication with the referring document, to the same extent we prevent it with a cross-site link opened in a new tab.
 - Block all storage access while content is prerendered.
@@ -35,11 +35,11 @@ The below subsections explore the implementation of these restrictions in more d
 
 ### Storage access blocking
 
-Prerendered pages that are cross-origin to their referring site will have no access to storage.
+Prerendered pages that are cross-site to their referring site will have no access to storage.
 
 We could attempt to address the threat by providing partitioned or ephemeral storage access, but then it is unclear how to transition to _unpartitioned_ storage upon activation. It would likely require some kind of web-developer-written merging logic. Completely blocking storage access is thus deemed simpler; prerendered pages should not be doing anything which requires persistent storage before activation.
 
-This means that most existing content will appear "broken" when prerendered by a cross-origin referrer. This necessitates an explicit opt-in to allow cross-origin content to be prerendered, [discussed elsewhere](./opt-in.md). Such content might optionally "upgrade" itself to a credentialed view upon activation, as shown in the [example](#example) above.
+This means that most existing content will appear "broken" when prerendered by a cross-site referrer. This necessitates an explicit opt-in to allow cross-site content to be prerendered, [discussed elsewhere](./opt-in.md). Such content might optionally "upgrade" itself to a credentialed view upon activation, as shown in the [example](#example) above.
 
 For a more concrete example, consider `https://aggregator.example/` which wants to prerender this GitHub repository. To make this work, GitHub would need to add the opt-in to allow the page to be prerendered. Additionally, GitHub should add code to adapt their UI to show the logged-in view upon activation, by removing the "Join GitHub today" banner, and retrieving the user's credentials from storage and using them to replace the signed-out header with the signed-in header. Without such adapter code, activating the prerendering browsing context would show the user a logged-out view of GitHub in the top-level tab that the prerendering browsing context has been activated into. This would be a bad and confusing user experience, since the user is logged in to GitHub in all of their other top-level tabs.
 
@@ -56,8 +56,8 @@ As for the exact mechanism of this blocking:
 - `SharedWorker` construction is delayed in prerendering browsing contexts. In particular, while the `new SharedWorker()` constructor returns immediately, no worker is started or connected to until after activation. Any messages sent to the `SharedWorker` pre-activation are buffered up and delivered upon activation. (And, since the `SharedWorker` is not connected to an actual shared worker pre-activation, no message can be received on it pre-activation.)
 - Web locks APIs will return promises which wait to settle (and wait to do any lock-related work) until activation.
 - TODO `ServiceWorker`?
-- Fetches within cross-origin prerendering browsing contexts, including the initial request for the page, do not use credentials. Credentialed fetches could be used for cross-site recognition, for example by:
-  - Using the sequence of loads. The referring page could encode a user ID into the order in which a sequence of URLs are prerendered. To prevent the target from correlating this ID with its own user ID without a navigation, a document loaded into a cross-origin prerendering browsing context is fetched without credentials and doesn't have access to storage, as described above.
+- Fetches within cross-site prerendering browsing contexts, including the initial request for the page, do not use credentials. Credentialed fetches could be used for cross-site recognition, for example by:
+  - Using the sequence of loads. The referring page could encode a user ID into the order in which a sequence of URLs are prerendered. To prevent the target from correlating this ID with its own user ID without a navigation, a document loaded into a cross-site prerendering browsing context is fetched without credentials and doesn't have access to storage, as described above.
   - The host creates a prerendering browsing context, and the prerendered site decides between a 204 and a real response based on the user's ID. Or the prerendered site delays the response by an amount of time that depends on the user's ID. Because the prerendering load is done without credentials, the prerendered site can't get its user ID in order to make this sort of decision.
 - Sizing side channels: prerendering browsing contexts always perform layout based on the initial size of their referring browsing context, as its most likely that upon activation, they'll end up with that same size. However, further resizes to the referring browsing context are not used to update the size of the prerendering browsing context, as this could be used to communicate a user ID. For simplicity, we apply this sizing model to same-origin prerendered content as well.
 
diff --git a/prerendering-same-origin.md b/prerendering-same-site.md
similarity index 81%
rename from prerendering-same-origin.md
rename to prerendering-same-site.md
index d331d4d..4bc61b1 100644
--- a/prerendering-same-origin.md
+++ b/prerendering-same-site.md
@@ -1,4 +1,4 @@
-# Same-origin prerendering
+# Same-site prerendering
 
 [Read the spec](https://wicg.github.io/nav-speculation/prerendering.html)
 
@@ -6,7 +6,7 @@ Prerendering allows user-agents to preemptively load content into an invisible s
 
 Prerendering can potentially be triggered by another referrer document, or by the [user agent](https://wicg.github.io/nav-speculation/prerendering.html#start-user-agent-initiated-prerendering), for example from browser UI such as the URL bar.
 
-Our current specification, and the Chromium implementation, only allow same-origin referrer documents. Allowing cross-origin referrer documents requires additional security and privacy considerations, which we have many ideas for but have not yet proven out. As such, this explainer is scoped to same-origin-document- and user-agent-initiated prerendering, often abbreviated to "same-origin prerendering".
+Our current specification, and the Chromium implementation, only allow same-site referrer documents. Allowing cross-site referrer documents requires additional security and privacy considerations, which we have many ideas for but have not yet proven out. As such, this explainer is scoped to same-site-document- and user-agent-initiated prerendering, often abbreviated to "same-site prerendering".
 
 <!-- START doctoc generated TOC please keep comment here to allow auto update -->
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
@@ -18,7 +18,8 @@ Our current specification, and the Chromium implementation, only allow same-orig
   - [Page-initiated prerendering](#page-initiated-prerendering)
 - [Opting out](#opting-out)
 - [Restrictions](#restrictions)
-  - [No cross-origin navigations](#no-cross-origin-navigations)
+  - [No cross-site navigations](#no-cross-site-navigations)
+  - [Cross-origin same-site navigations require opt-in](#cross-origin-same-site-navigations-require-opt-in)
   - [Restrictions on the basis of being hidden](#restrictions-on-the-basis-of-being-hidden)
   - [Restrictions on loaded content](#restrictions-on-loaded-content)
   - [Purpose-specific APIs](#purpose-specific-apis)
@@ -31,6 +32,7 @@ Our current specification, and the Chromium implementation, only allow same-orig
 - [Session history](#session-history)
 - [Rendering-related behavior](#rendering-related-behavior)
 - [CSP integration](#csp-integration)
+- [More details on cross-origin same-site](#more-details-on-cross-origin-same-site)
 - [Considered alternatives](#considered-alternatives)
   - [Main-document prefetching](#main-document-prefetching)
   - [Prefetching with subresources](#prefetching-with-subresources)
@@ -76,7 +78,7 @@ This completes the journey to a fully-rendered view of `https://b.example/`, in
 
 ### Page-initiated prerendering
 
-The [speculation rules API](./triggers.md) can be used to trigger a prerender to any same-origin page. For example:
+The [speculation rules API](./triggers.md) can be used to trigger a prerender to any same-site page. For example:
 
 ```html
 <script type="speculationrules">
@@ -90,7 +92,7 @@ The [speculation rules API](./triggers.md) can be used to trigger a prerender to
 <a href="https://a.test/foo">Click me!</a>
 ```
 
-The `<script type="speculationrules">` block here hints to prerender `https://a.test/foo`. As in the previous section, such prerendering includes sending the `Sec-Purpose` header.
+The `<script type="speculationrules">` block here hints to prerender `https://a.test/foo`. As in the previous section, such prerendering includes sending the `Sec-Purpose` header. If the prerendered URL is cross-site, then prerendering will fail. If it is same-site but cross-origin, then the destination needs the opt-in [`Supports-Loading-Mode: credentialed-prerender` header](./opt-in.md#cross-origin-same-site-prerendering). See [below](#more-details-on-cross-origin-same-site) for more details on the same-site cross-origin case.
 
 Note that the user agent remains in control of exactly when this prerendering is done; it could do it immediately upon script insertion, or it could do it in idle time, or it could do it as the user starts clicking on the link, or it could do it never. But if it does prerender that URL, then any navigation there will activate the prerendering browsing context, with the resulting desired instant navigation.
 
@@ -108,11 +110,19 @@ The recommended response codes for opting out of prerendering are [204 No Conten
 
 For an API-by-API analysis of the restrictions in prerendering browsing contexts, see [this section of the spec](https://wicg.github.io/nav-speculation/prerendering.html#intrusive-behaviors). The following section outlines the reasoning behind the proposed restrictions.
 
-### No cross-origin navigations
+### No cross-site navigations
 
-If the prerendering browsing context navigates to a different origin, then it will be immediately discarded before a request to that other origin is sent. As such, it will no longer be used for any future activation.
+If the prerendering browsing context navigates to a different site, then it will be immediately discarded before a request to that other site is sent. As such, it will no longer be used for any future activation.
 
-This includes both cases where the initial request redirects to a different origin through the `Location` header, or cases where the navigation occurs after the initial document is loaded, via mechanisms like the `location.href` setter or the `<meta http-equiv="refresh">` element.
+This includes both cases where the initial request redirects to a different site through the `Location` header, or cases where the navigation occurs after the initial document is loaded, via mechanisms like the `location.href` setter or the `<meta http-equiv="refresh">` element.
+
+### Cross-origin same-site navigations require opt-in
+
+If the prerendering browsing context navigates to a different origin that is still same-site, then (unlike the cross-site case) the request will be made. However, the response will immediately be checked for the `Supports-Loading-Mode: credentialed-prerender` header; if it is not present, then the response will be discarded and the prerender will fail.
+
+Again, this includes both cases where the initial request redirects to a different origin through the `Location` header, or cases where the navigation occurs after the initial document is loaded, via mechanisms like the `location.href` setter or the `<meta http-equiv="refresh">` element.
+
+For more analysis on cross-origin same-site prerendering, see [our dedicated section below](#more-details-on-cross-origin-same-site).
 
 ### Restrictions on the basis of being hidden
 
@@ -151,7 +161,7 @@ The removal of the script-visible `about:blank` in prerendering browsing context
 
 If a prerendering browsing context navigates itself to a non-HTTP(S) URL, e.g. via `window.location = "data:text/plain,foo"`, then the prerendering browsing context will be immediately discarded, and no longer be used by the user agent for anything.
 
-Iframes inside of a prerendering browsing context are restricted in a slightly different way: we delay loading the contents of any cross-origin iframe while prerendering, until activation occurs. This is done to avoid breakage caused by loading a cross-origin site that is unaware of prerendering, and to avoid the complexities around what credentials and storage to expose to these frames.
+Iframes inside of a prerendering browsing context are restricted in a slightly different way: we delay loading the contents of any cross-origin iframe while prerendering, until activation occurs. This is done to avoid breakage caused by loading a cross-origin page that is unaware of prerendering, and to avoid the complexities around what credentials and storage to expose to these frames.
 
 ### Purpose-specific APIs
 
@@ -175,7 +185,7 @@ Note that service workers that are already registered would handle fetches from
 
 ## Storage and cookies
 
-For same-origin prerendering, the prerendered page has the same access to storage and cookies as a normal page. In particular, the prerendered request includes cookies, and the `Set-Cookie` response header modifies cookies. Storage APIs such as Indexed DB and `localStorage` also function in a prerendered page.
+For same-site prerendering, the prerendered page has the same access to storage and cookies as a normal page. In particular, the prerendered request includes cookies, and the `Set-Cookie` response header modifies cookies. Storage APIs such as Indexed DB and `localStorage` also function in a prerendered page.
 
 ### `sessionStorage`
 
@@ -254,13 +264,29 @@ A prerendered `Document` can apply CSP to itself as normal. Being in a prerender
 
 Prerendered content will be affected by [`prefetch-src`](https://w3c.github.io/webappsec-csp/#directive-prefetch-src) on the referring page, which provides a way of preventing prefetching in addition to the [triggers](./triggers.md).
 
+## More details on cross-origin same-site
+
+Recall that the web's privacy boundary is the site, whereas its security boundary is an origin. So although it's obviously safe to allow same-origin prerendering, cross-origin same-site prerendering requires some additional analysis, to ensure that we are not introducing any security issues.
+
+Here is what we've found after doing such analysis:
+
+- Side effects from prerendering are the biggest potential attack.
+  - Side effects from simply issuing credentialed requests to the target URL, e.g. triggering non-idempotent GETs, are not a concern. These are already possible today via `<iframe>`s, `<img>`s, etc.
+  - Thus, the main worry is side effects from actually prerendering the page, e.g. running its JavaScript. To prevent these, we require the [`Supports-Loading-Mode: credentialed-prerender`](./opt-in.md#cross-origin-same-site-prerendering) header.
+
+- Preventing side channel attacks such as [Spectre](https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)) requires respecting the [cross-origin isolation](https://web.dev/coop-coep/) settings of both the referrer and destination. In particular, we must treat prerendered pages like we treat popups, such that they go into agent clusters segregated by cross-origin isolation status, and thus in implementations they go into different processes when appropriate. Thankfully, this is fairly automatic in the relevant spec infrastructure.
+
+- One might be concerned about cross-origin information leakage via [`activationStart`](#timing), since normally timing APIs are carefully guarded to make sure they don't leak information across origins. However, this particular piece of timing information is not an issue: it is just the time that the prerender was activated, and represents something about the prerendered page, not information about the referrer page.
+
+- The default referrer policy on the web is `"strict-origin-when-cross-origin"`. This means that if `https://a.example.com/1.html` prerenders `https://a.example.com/2.html`, the full referrer will be sent. But if the same referrer document prerenders `https://b.example.com/2.html`, only the origin (`https://a.example.com/`) will be sent, losing the `1.html` path. This is fine and working as expected; it's just something for developers to be aware of.
+
 ## Considered alternatives
 
 ### Main-document prefetching
 
 Prefetching the main response for an upcoming navigation, without prefetching any subresources or actually creating the document and running any of its JavaScript, is a technique we also believe is important. It has its [own specification](https://wicg.github.io/nav-speculation/prefetch.html) in this repository.
 
-Main-document prefetching has an advantage over prerendering in its simplicity. Because no JavaScript runs, there are many fewer considerations. And because only one resource is fetched, it's possible to come up with reasonable cross-origin semantics, at least in the case where the target has no existing HTTP state (credentials and cache).
+Main-document prefetching has an advantage over prerendering in its simplicity. Because no JavaScript runs, there are many fewer considerations. And because only one resource is fetched, it's possible to come up with reasonable cross-site semantics, at least in the case where the target has no existing HTTP state (credentials and cache).
 
 However, it is not necessarily going to lead to instant navigations, like prerendering can.
 
@@ -268,7 +294,7 @@ However, it is not necessarily going to lead to instant navigations, like preren
 
 Chromium previously supported prerendering, but replaced it with "[NoState Prefetch](https://developers.google.com/web/updates/2018/07/nostate-prefetch)". No State Prefetch prefetches a page and scans its markup for resources that are also fetched. A less Chromium-specific name for this technology would then be "prefetching with subresources".
 
-This is another point on the spectrum between main-document prefetching, and prerendering. It avoids the complexities of running JavaScript, so it is simpler than prerendering; but it does fetch more than one resource, so it is not as straightforward what to do in the cross-origin case compared to main-document prefetching.
+This is another point on the spectrum between main-document prefetching, and prerendering. It avoids the complexities of running JavaScript, so it is simpler than prerendering; but it does fetch more than one resource, so it is not as straightforward what to do in the cross-site case compared to main-document prefetching.
 
 Based on some initial performance testing, Chromium found that prefetching with subresources was a bad middle ground for our users: it would result in significantly more resource consumption, but only slightly faster loads, compared to main-document prefetching. As such, we're currently investing in main-document prefetching and in prerendering instead. We may revisit prefetching with subresources at some point in the future.
 
diff --git a/prerendering-state.md b/prerendering-state.md
index 765e4f5..cb377f6 100644
--- a/prerendering-state.md
+++ b/prerendering-state.md
@@ -10,7 +10,7 @@ doc](https://docs.google.com/document/d/1Xzw0k8DgltI2ohapuDKmjRZLv7NVrRFGusW8IBt
 
 ## Background
 
-Pages need to know when they're being rendered inside a [prerendering browsing context](./prerendering-same-origin.md).
+Pages need to know when they're being rendered inside a [prerendering browsing context](https://wicg.github.io/nav-speculation/prerendering.html#prerendering-browsing-context).
 Some examples of divergent behavior:
 
 * Avoid fetching large video resources
diff --git a/prerendering.bs b/prerendering.bs
index 19e9c0e..0b3d74a 100644
--- a/prerendering.bs
+++ b/prerendering.bs
@@ -200,6 +200,12 @@ spec: nav-speculation; urlPrefix: prefetch.html
   type: dfn
     text: supports prefetch; url: supports-prefetch
     text: list of sufficiently-strict speculative navigation referrer policies
+spec: RFC8941; urlPrefix: https://www.rfc-editor.org/rfc/rfc8941.html
+  type: dfn
+    text: structured header; url: #section-1
+    for: structured header
+      text: list; url: name-lists
+      text: token; url: name-tokens
 </pre>
 <pre class="biblio">
 {
@@ -358,9 +364,9 @@ Every {{Document}} has an <dfn for="Document">activation start time</dfn>, which
 
      <p class="note">This avoids having to deal with any potential opener relationship between the prerendering browsing context and |referrerDoc|'s [=Document/browsing context=]'s [=opener browsing context=].
 
-  1. If |referrerDoc|'s [=Document/origin=] is not [=/same origin=] with |startingURL|'s [=url/origin=], then return.
+  1. If |referrerDoc|'s [=Document/origin=] is not [=/same site=] with |startingURL|'s [=url/origin=], then return.
 
-     <p class="note">Currently, cross-origin prerendering is not specified or implemented, although we have various ideas about how it could work in this repository's explainers.
+     <p class="note">Currently, cross-site prerendering is not specified or implemented, although we have various ideas about how it could work in this repository's explainers.
 
   1. If |referrerDoc|'s [=Document/prerendering browsing contexts map=][|startingURL|] [=map/exists=], then return.
 
@@ -528,11 +534,23 @@ Navigation redirects can also [=prerendering browsing context/activate=] [=prere
 
     1. Return.
 
-  1. If |browsingContext| is a [=prerendering browsing context=]  and <var ignore>currentURL</var>'s [=url/origin=] is not [=same origin=] with <var ignore>incumbentNavigationOrigin</var>, then:
+  1. If |browsingContext| is a [=prerendering browsing context=]  and <var ignore>currentURL</var>'s [=url/origin=] is not [=/same site=] with |incumbentNavigationOrigin|, then:
 
     1. Run the [=environment discarding steps=] for <var ignore>navigationParams</var>'s [=navigation params/reserved environment=].
 
     1. Return.
+
+  Additionally, append the following steps toward the end of the algorithm, after the steps which check <var ignore>locationURL</var>:
+
+  1. If |browsingContext| is a prerendering browsing context, and <var ignore>responseOrigin</var> is not [=same origin=] with |incumbentNavigationOrigin|, then:
+
+    1. Let |loadingModes| be the result of [=getting the supported loading modes=] for |response|.
+
+    1. If |loadingModes| does not [=list/contain=] \`<code><a for="Supports-Loading-Mode">credentialed-prerender</a></code>\`, then set |response| to a [=network error=].
+
+       <p class="note">This will cause the prerender to fail in the following steps of the algorithm.
+
+       <p class="note">In the future we could possibly also allow the `uncredentialed-prerender` token to work here. However, since that is primarily intended for the cross site case, which isn't specified or implemented yet, we don't want to encourage its use in the wild, so for now we specify that prerendering fails if only the `uncredentialed-prerender` token is found.
 </div>
 
 <div algorithm="process a navigate response patch">
@@ -640,6 +658,24 @@ The <dfn attribute for="PerformanceNavigationTiming">activationStart</dfn> gette
 
 1. Return a {{DOMHighResTimeStamp}} with a time value equal to the [=current document=]'s [=Document/activation start time=].
 
+<h2 id="supports-loading-mode">The \`<dfn http-header><code>Supports-Loading-Mode</code></dfn>\` HTTP response header</h2>
+
+<em>The following section would be added as a sub-section of [[HTML]]'s <a href="https://html.spec.whatwg.org/multipage/browsers.html#browsers">Loading web pages</a> section.</em>
+
+In some cases, cross-origin web pages might not be prepared to be loaded in a novel context. To allow them to opt in to being loaded in such ways, the \`<a http-header><code>Supports-Loading-Mode</code></a>\` HTTP response header can be used. This header is a [=structured header=]; if present its value must be the single [=structured header/token=] \`<code><a for="Supports-Loading-Mode">credentialed-prerender</a></code>\`.
+
+<p class="note">The parsing is actually done as a [=structured header/list=] of [=structured header/tokens=], and unknown tokens will be ignored. However, authors are best off avoiding any form except the single-token one, for future compatibility.
+
+The \`<code><dfn for="Supports-Loading-Mode">credentialed-prerender</dfn></code>\` token indicates that the response can be used to create a [=prerendering browsing context=], despite the prerendering being initiated by a cross-origin same-site referrer. Without this opt-in, such prerenders will fail, as outlined in [[#navigate-fetch-patch]].
+
+To <dfn>get the supported loading modes</dfn> for a [=response=] |response|:
+
+1. If |response| is a [=network error=], then return an empty list.
+
+1. Let |slmHeader| be the result of [=header list/getting a structured field value=] given \`<a http-header><code>Supports-Loading-Mode</code></a>\` and "`list`" from |response|'s [=response/header list=].
+
+1. Return a [=list=] containing all elements of |slmHeader| that are [=structured header/tokens=].
+
 <h2 id="nonsense-behaviors">Preventing nonsensical behaviors</h2>
 
 Some behaviors might make sense in most [=top-level browsing contexts=], but do not make sense in [=prerendering browsing contexts=]. This section enumerates specification patches to enforce such restrictions.
diff --git a/same-origin-chrome-origin-trial.md b/same-origin-chrome-origin-trial.md
index e307e99..77c4816 100644
--- a/same-origin-chrome-origin-trial.md
+++ b/same-origin-chrome-origin-trial.md
@@ -1,6 +1,6 @@
 # Chrome Origin Trial for same-origin prerendering
 
-Google Chrome offered an [origin trial](https://github.com/GoogleChrome/OriginTrials/blob/gh-pages/developer-guide.md) of [same-origin prerendering](./prerendering-same-origin.md) triggered by the [Speculation Rules API](./triggers.md), from Chrome 94 through 102.
+Google Chrome offered an [origin trial](https://github.com/GoogleChrome/OriginTrials/blob/gh-pages/developer-guide.md) of [same-origin prerendering](./prerendering-same-site.md) triggered by the [Speculation Rules API](./triggers.md), from Chrome 94 through 102.
 
 However, the trial is now concluded, and this feature is launched!
 
diff --git a/same-origin-security-privacy-questionnaire.md b/same-origin-security-privacy-questionnaire.md
index aaeb381..f027e29 100644
--- a/same-origin-security-privacy-questionnaire.md
+++ b/same-origin-security-privacy-questionnaire.md
@@ -1,14 +1,14 @@
-# Security & Privacy Questionnaire (same-origin prerendering)
+# Security & Privacy Questionnaire (same-site prerendering)
 
-Covers the specific case of [same-origin prerendering](./prerendering-same-origin.md) triggered by [speculation rules](./triggers.md). Based on the [W3C TAG Self-Review Questionnaire: Security and Privacy](https://w3ctag.github.io/security-questionnaire/).
+Covers the specific case of [same-site prerendering](./prerendering-same-site.md) triggered by [speculation rules](./triggers.md). Based on the [W3C TAG Self-Review Questionnaire: Security and Privacy](https://w3ctag.github.io/security-questionnaire/).
 
 For general [speculation rules](triggers.md) including cross-origin cases, see that [questionnaire](speculation-rules-security-privacy-questionnaire.md). Some answers below are inspired by that document.
 
 ### What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?
 
-At its core, this feature does not expose any additional information because it is restricted to same-origin triggers. The origin cannot do anything it cannot already do with an iframe.
+At its core, this feature does not expose any additional information because it is restricted to same-site triggers. The page cannot do anything it cannot already do with an iframe.
 
-However, the user agent chooses whether to act upon the origin's hint to prerender a URL at its own discretion. If the user agent uses heuristics such as the user's engagement with the origin to make that decision, the origin can potentially glean information based on whether the user agent acts upon the hint or not.
+However, the user agent chooses whether to act upon the page's hint to prerender a URL at its own discretion. If the user agent uses heuristics such as the user's engagement with the origin to make that decision, the origin can potentially glean information based on whether the user agent acts upon the hint or not.
 
 ### Do features in your specification expose the minimum amount of information necessary to enable their intended uses?
 
@@ -20,7 +20,7 @@ This is similar to the previous responses. User agents should avoid basing heuri
 
 ### How do the features in your specification deal with sensitive information?
 
-This is similar to the previous responses. There is no additional information that can be communicated from the origin to itself that it cannot already do via an iframe. But the user agent's heuristics deciding whether to honor a prerender hint can potentially leak information.
+This is similar to the previous responses. There is no additional information that can be communicated from the site to itself that it cannot already do via an iframe. But the user agent's heuristics deciding whether to honor a prerender hint can potentially leak information.
 
 ### Do the features in your specification introduce new state for an origin that persists across browsing sessions?
 
diff --git a/speculation-rules.bs b/speculation-rules.bs
index d4dc33c..7478c1c 100644
--- a/speculation-rules.bs
+++ b/speculation-rules.bs
@@ -365,7 +365,7 @@ While efforts have been made to minimize the privacy impact of prefetching, some
 
 <h3 id="privacy-partitioning">Partitioning</h3>
 
-Some user agents <a href="https://privacycg.github.io/storage-partitioning/">partition storage</a> according to the site or origin of the top-level document. In order for prefetching and prerendering to be useful, it is therefore essential that prefetching or prerendering of a document either occur in the partition in which the navigation would occur (e.g., for a same-origin URL) or in an isolated partition, so as to ensure that prefetching does not become a mechanism for bypassing the partitioning scheme.
+Some user agents <a href="https://privacycg.github.io/storage-partitioning/">partition storage</a> according to the site or origin of the top-level document. In order for prefetching and prerendering to be useful, it is therefore essential that prefetching or prerendering of a document either occur in the partition in which the navigation would occur (e.g., for a same-site URL) or in an isolated partition, so as to ensure that prefetching does not become a mechanism for bypassing the partitioning scheme.
 
 <div class="issue">Expand this section once more detail on prefetch and prerender partitioning mechanism is specified.</div>