From 54caceba9c0d1849e2d7db429af9d96277be3e50 Mon Sep 17 00:00:00 2001 From: Johann Hofmann Date: Thu, 5 Jan 2023 13:09:02 +0100 Subject: [PATCH] Add preliminary description of how we integrate with cookies (#145) Closes #31 Co-authored-by: Anne van Kesteren --- storage-access.bs | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/storage-access.bs b/storage-access.bs index 17e606e..2751e06 100644 --- a/storage-access.bs +++ b/storage-access.bs @@ -29,6 +29,11 @@ urlPrefix: https://tc39.github.io/ecma262/; spec: ECMASCRIPT text: agent cluster; url: #sec-agent-clusters; type: dfn urlPrefix: https://infra.spec.whatwg.org/; spec: INFRA text: implementation-defined; url: #implementation-defined; type: dfn +urlPrefix: https://fetch.spec.whatwg.org/; spec: Fetch + text: http-network-or-cache fetch; url: #concept-http-network-or-cache-fetch; type: dfn +spec: RFC6265; urlPrefix: https://tools.ietf.org/html/rfc6265 + type: dfn + text: cookie store; url: section-5.3 urlPrefix: https://w3c.github.io/webdriver/webdriver-spec.html#; spec: webdriver type: dfn text: current browsing context; url: dfn-current-browsing-context @@ -286,12 +291,18 @@ ISSUE(privacycg/storage-access#137): Add links to current entry and session hist

Changes to various client-side storage mechanisms

-ISSUE(privacycg/storage-access#4): Should this API affect client-side storage other than cookies? - -ISSUE(privacycg/storage-access#31): Write this section. For each kind of client-side storage affected, modify them to invoke [=determine if a site has storage access=] & modify their behavior based on the result. +This API only impacts HTTP cookies. A future revision of this API might impact other client-side state. [[!RFC6265]]

Cookies

+This API is intended to be used with environments and user agent configurations that block access to unpartitioned cookies in a [=third party context=]. At the time of this writing, this concept has not yet been integrated into the [=HTTP-network-or-cache fetch=] and {{Document/cookie}} algorithms. To allow for such an integration, the [=cookie store=] will need to be modified to receive information about the top-level and embedded site of the request (to determine whether to attach cross-site, partitioned, or no cookies) as well as whether the request was made for a document that has storage access, through running the [=determine if a site has storage access=] algorithm that is defined in this specification. + +Once the cookie store allows for receiving information about storage access, we would update [=HTTP-network-or-cache fetch=] and {{Document/cookie}} to run [=determine if a site has storage access=] and pass this information to the [=cookie store=] when retrieving cookies. + +When getting unpartitioned cookies from the [=cookie store=] with storage access, user agents will still follow applicable `SameSite` restrictions (i.e., not attach cookies marked `SameSite=Strict` or `SameSite=Lax` in [=third party contexts=]). + +Note: User agents could apply different default values for the `SameSite` cookie attribute. This could lead to unpartitioned cookies without a `SameSite` attribute being attached to requests in some user agents (where `SameSite=None` is the default), but not in others (where `SameSite=Lax` is the default). Web developers are encouraged to set the `SameSite` attribute on their cookies to not run into issues. +

Sandboxing storage access

A [=sandboxing flag set=] has a sandbox storage access by user activation flag. This flag prevents content from requesting storage access.