Initial draft of outlining the larger problem space

README.md

@@ -7,7 +7,7 @@ The space is full of challenges which have not been comprehensively tackled: mos
 * avoiding user-visible side effects and annoyances from running script on the destination site; and
 * fulfilling the privacy objectives of the user and the referring site.
 
-This repository contains a set of explainers and (eventually) specifications which, combined, give a rigorous model for performing such prerendering and prefetching of content, in an interoperably-implementable way.
+This repository contains a set of explainers and (eventually) specifications which, combined, give a rigorous model for performing such prerendering of content, in an interoperably-implementable way. Each piece is designed to be composable and reusable; for example, [some contribute to prefetching](#prefetching), independent of prerendering, and the [opt-in](./opt-in.md) is designed to be usable by other types of alternate loading modes, such as [fenced frames](https://github.com/shivanigithub/fenced-frame/).
 
 ## Pieces of the solution
 
@@ -23,7 +23,7 @@ We envision prerendering having several related pieces:
 
 * [**Prerendering fetching modes**](./fetch.md), which modify the way in which cross-origin documents and subresources are fetched in order to preserve privacy and avoid side effects.
 
-  Closely related to the previous bullet, this covers the mechanics of how a document is fetched in order to check for the opt-in, and provide it with no identifying information. The most obvious technique here is omitting credentials, but others could include using a proxy server (for IP privacy), or using a previously-fetched response in "memory cache".
+  Closely related to the previous bullet, this covers the mechanics of how a document is fetched in order to check for the opt-in, and provide it with no identifying information. The most obvious technique here is omitting credentials, but one could also consider using a proxy server (for IP privacy), or using a previously-fetched response in "memory cache".
 
 * [**Prerendering browsing contexts**](./browsing-context.md), which are special browsing contexts that are not displayed to the user, and within which content is constrained to not perform disruptive or side-effecting operations.
 
@@ -54,11 +54,11 @@ Here's a summary:
 
 _Aside: it's probably safe to also allow same-origin prerendering with only a destination-side opt-in, as long as all of the same restrictions are applied (e.g., no credentials or storage access). But, this complicates the model a good deal, for both implementers and web developers. For now, we're concentrating on the model described above._
 
-Finally, we'll note that browser-initiated prerenders fall somewhere in between these cases. In particular, the user typing `https://example.com/` in the URL bar, even before they press <kbd>Enter</kbd>, might serve as a reasonable prerender trigger, and perhaps even the prerendering could be done with credentials. The need to prevent user annoyance is still present, so the prerendering browsing context concept is important. But, what if the user types `https://example.com/logout`? Our thinking is still evolving in this area.
+Finally, we'll note that browser UI-initiated prerenders fall somewhere in between these cases. In particular, the user typing `https://example.com/` in the URL bar, even before they press <kbd>Enter</kbd>, might serve as a reasonable prerender trigger, and perhaps even the prerendering could be done with credentials. The need to prevent user annoyance is still present, so the prerendering browsing context concept is important. But, what if the user types `https://example.com/logout`? Our thinking is still evolving in this area.
 
 ## Prefetching
 
-Although these explainers focus largely on prerendering, we expect some of the work they produce to be useful for _prefetching_ as well. Prefetching currently exists in [`<link rel="prefetch">`](https://w3c.github.io/resource-hints/#dfn-prefetch), but as with prerendering, it is underspecified, and its current implementations have potential privacy issues which will require some work to address.
+Although these explainers focus largely on prerendering, we expect some of the work they produce to be useful for _prefetching_ as well. Prefetching currently exists in [`<link rel="prefetch">`](https://w3c.github.io/resource-hints/#dfn-prefetch), but as with prerendering, it is underspecified, and its current implementations have potential privacy issues for cross-origin prefetching, which will require some work to address.
 
 In particular, the [triggers](./triggers.md) and [opt-in](./opt-in.md) can be designed in a generic way, so that they can also be used to trigger and opt-in to prefetching (of documents, in particular). Similarly, the [prerendering fetching infrastructure](./fetch.md) will likely be used for modernized prefetching.
 
@@ -125,15 +125,15 @@ or the HTML `<meta>` element
       content="uncredentialed-prerender">
 ```
 
-As in the last example, based on its heuristics or informed by prerender triggers, the browser can attempt to prerender these linked-to news articles. Since they are cross-origin, however, the process is more restricted. The initial fetch, as well as any subresource fetches, are performed without credentials. If the response that comes back does not have the opt-in, then the result is discarded.
+As in the last example, based on its heuristics or informed by prerender triggers, the browser can attempt to prerender these linked-to news articles. Since they are cross-origin, however, the process is more restricted. The initial fetch, as well as any subresource fetches, are performed without credentials. This means that the target site may get uncredentialed requests even when there are credentials stored in UA. If the initial response that comes back does not have the opt-in, then the result is discarded (without performing any subresource fetches).
 
 If the opt-in is present, then the resulting document is loaded into a cross-origin prerendering browsing context. Content there is restricted more heavily; not only are disruptive APIs prevented from working, but also storage access is initially not available. If the news site intends to personalize itself, e.g. to reflect subscriber status, then it would use code such as the following:
 
 ```js
 function afterPrerendering() {
   // grab user data from cookies/IndexedDB
   // update the UI
-  // maybe ask for camera access
+  // maybe ask for notifications access
 }
 
 if (!document.loadingMode || document.loadingMode.type === 'default') {
@@ -172,6 +172,6 @@ newsArticleLink.onclick = async e => {
 
   e.preventDefault();
   await animateToFullViewport(newsArticlePortal);
-  newsArticlePortal.activate()
+  newsArticlePortal.activate();
 };
 ```

browsing-context.md

@@ -25,4 +25,4 @@ if (!document.loadingMode || document.loadingMode.type === 'default') {
 }
 ```
 
-Script can also observe this by using APIs particular to the behavior they are interested in. For instance, the [`document.hasStorageAccess()`][storage-access] can be used in supporting browsers to observe whether unpartitioned storage is available.
+Script can also observe this by using APIs particular to the behavior they are interested in. For instance, the [`document.hasStorageAccess()`][https://github.com/privacycg/storage-access] API can be used in supporting browsers to observe whether unpartitioned storage is available.

opt-in.md

@@ -4,7 +4,7 @@ Because [prerendering fetching modes](./fetch.md) intentionally obscure the user
 
 Similarly, [prerendering browsing contexts](./browsing-context.md) allow HTML parsing, subresource fetching, and script execution, but such actions are restricted to avoid identifying the user or causing user-visible annoyance.
 
-Pages designed with these restrictions in mind can "upgrade" themseles 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.)
+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.)
 
 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.