Address redirect privacy in more detail

prefetch.bs

@@ -768,3 +768,11 @@ The following parameters are defined for the "`prefetch`" token:
 
     This specification conforms to this advice; the [=prefetch=] algorithm does not emit non-boolean values.
   </div>
+
+<h2 id="security-considerations">Security considerations</h2>
+
+See <a href="speculation-rules.html#security-considerations">Security considerations (Speculation Rules)</a>.
+
+<h2 id="privacy-considerations">Privacy considerations</h2>
+
+See <a href="speculation-rules.html#privacy-considerations">Privacy considerations (Speculation Rules)</a>.

speculation-rules.bs

@@ -828,7 +828,16 @@ While efforts have been made to minimize the privacy impact of prefetching, some
 
 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>
+The <a href="prefetch.html">prefetch specification</a> allows issuing HTTP requests which behave consistently with the partitioning scheme. If a navigation using its response would load a document in the same partition (approximately, the top-level site would not change), then partitioned state (e.g., cookies) can be sent, as they can with subresource requests and scripted fetches. If it would load a document in another partition, it would be inconsistent with the partitioning scheme to use partitioned state for the destination partition (since this would cross the boundary between partitions without a top-level navigation) and also inconsistent to use partitioned state within the originating partition (since this would result in the user seeing a document with different state than a non-prefetched navigation). Instead, a third, initially empty, partition is used for such requests. These requests therefore contain no partitioned state from either partition (though it may still be possible to fingerprint the user agent by other means).
+
+However, the response to a prefetch request in an empty partition can only be used if:
+
+1. the response declares that the resource can be used even if an ordinary navigation would have sent credentials; or
+1. the destination partition contains no credentials which would have been included
+
+Checking the latter requires examining the destination partition's state. To avoid this being a workaround for the partitioning scheme, the prefetch must continue <em>even if the existence of conflicting partitioned state will preclude it being used for navigation</em>.
+
+Redirects are possible between these two types of requests. A redirect from a same- to cross-partition URL could contain information derived from partitioned state in the originating partition; however, this is equivalent to the originating document fetching the same-partition URL itself and then issuing a request for the cross-partition URL. A redirect from a cross- to same-origin URL could carry state from the isolated partition, but since this partition has no prior state this does not enable tracking based on the user's prior browsing activity on that site, and the document could construct the same state by issuing uncredentialed requests itself.
 
 <h3 id="privacy-identity-joining">Identity joining</h3>