Add Privacy and Security Considerations

Hopefully this represents a good first draft. Aiming to resolve privacycg#115.

storage-access.bs

@@ -310,17 +310,47 @@ The Storage Access API defines a [=policy-controlled feature=] identified by the
 
 <h2 id="privacy">Privacy considerations</h2>
 
-ISSUE: Write this section.
+The Storage Access API is meant able to enable the process of third-party cookie deprecation. Specifically, it enables the authenticated embed use case to continue to work, albeit under further constraints. When evaluating the privacy properties of the Storage Access API it is important to consider the pre-deprecation world of third-party cookies as the baseline. However, we aim to provide strong anti-tracking protections to users, as to not undermine the gains of third-party cookie deprecation.
+
+Importantly, we do not degrade privacy properties when compared to pre-deprecation of third-party cookies. This follows from a lack of platform-specific information used in the spec to prevent stateless tracking and the only state added being a permission scoped to the [=Site|Sites=] of the embedding and embedded [=Document=].
+
+Our privacy considerations are more challenging where default third-party cookies are already deprecated. The challenge is to decide when and how to permit the Storage Access API to be used to revert a cookie-less (or cookie-partitioned) iframe to a pre-deprecation state, giving it access to its [=unpartitioned data=].
+
+In an ideal case, an iframe would only be able to gain access to its [=unpartitioned data=] if:
+
+1. the user interacts with the iframe, giving it [=transient activation=]
+2. the iframe is permitted by the embedder to use the API
+3. the iframe is a [=secure context=]
+4. the user grants express, pairwise permission to the embeddee to use its cookies in the embedder
+5. the user is not inundated by requests for the "<a permission><code>storage-access</code></a>" permission so their express permission is not undermined by fatigue
+
+This specification requires the first three of implementers. This provides guarantees that the user is aware of the content of the iframe, the embedder has not opted out of the iframe's authentication, and the third-party cookies are not disclosed to network attackers, respectively.
+
+The last two points are in tension. In an ideal world, we would show a prompt to the user in every call to {{Document/requestStorageAccess()}}. But, this would allow pages to prompt the user so frequently as to put the last point at the discretion of the page– a state we find unacceptable.
 
 <figure id=example-prompt>
 <img src=images/storage-access-prompt.png
      alt="A modal dialog box which states 'Do you want to allow “video.example” to use cookies and website data while browsing “news.example”? This will allow “video.example” to track your activity.' and which has two buttons, “Don’t Allow” and “Allow”.">
 <figcaption>An example prompt which could be shown to the user when a site calls `document.`{{Document/requestStorageAccess()}}.</figcaption>
 </figure>
 
+Thus, the last two points represent a key point of compromise. We permit [=implementation-defined=] behavior on when to grant or deny requests for [=unpartitioned data=] without requiring user choice so long as they meet all other requirements. This compromise weakens the privacy guarantees of this proposal, specifically point 4, to a degree under the control of the implementer and gives the implementer the power to render it impossible to get storage access with this API. However, this has proven necessary to enable condition 5 to be possible given our implementers' differing stances on the compromise between these two points.
+
+An important avenue for improvement is the removal of the [=implementation-defined=] silent grants and denies. This would improve the developer experience using the API across platforms.
+
+Another tension in the design of the API is what to use to key the "<a permission><code>storage-access</code></a>" permission: [=origins/origin=] or [=sites/site=]. We chose [=sites/site=] because we believe them to be acceptable boundaries for privacy while enabling existing uses of [=same site=] and cross-origin iframes on the same page with only one user prompt.
+
 <h2 id="security">Security considerations</h2>
 
-ISSUE: Write this section.
+It is important that this spec not degrade security properties of the web platform, even when compared to post-deprecation of third-party cookies. Third-party cookie deprecation has potential benefits for security, specifically in mitigating attacks that rely upon authenticated requests, e.g. CSRF. We do not wish the Storage Access API to be a foothold for such attacks to leverage.
+
+To this end, we limit the impact of a "<a permission><code>storage-access</code></a>" permission grant to only give access to [=unpartitioned data=] to the iframe that called {{Document/requestStorageAccess()}} and only until the iframe navigates across an [=origin=] boundary. This ensures that only [=origins/origin=] with a page that call {{Document/requestStorageAccess()}} will be making credentialed requests, and moreover the embedee page can control which embedder it permits via the Content Security Policy `frame-ancestors` directive. This retains an [=origins/origin=]-scoped control for security purposes by the embedee.
+
+This also is effective at preventing another attack: one on the embedee's reputation. We consider any third-party authenticated request to have potential reputational harm as consumers become more privacy conscious. Therefore a first-party or sibling third-party causing an embedded resource to be requested with the user's authentication cookies would constitute an attack on the reputation of that third-party's owner. This is also a reason we require this API to be used in a [=secure context=]: so a network adversary cannot induce an embedee to use this API.
+
+The embedder has control over which iframes have the ability to become authenticated, or even display a permission request to the user via the Permission Policy and iframe sandboxing.
+
+We also consider notification abuse permitted by the embedder to be in-scope. Specifically, we require user interaction in the iframe and consume that rejection on a denial to restrict the conditions a permission prompt will be shown to the user. This attacks such as re-requesting a permission immediately after the user denies it.
 
 <h2 id="automation">Automation</h2>