Re: [blink-dev] Re: Intent to Ship: Extending Storage Access API (SAA) to non-cookie storage

[Ari Chivukula]

Noting this here for future discoverability: one of the APIs that was
launched as part of this was a new name for hasStorageAccess

: hasUnpartitionedCookieAccess
.
This was documented in the linked explainer

and spec
,
but failed to make the text of the I2E/S as it probably should have.

This was included to make the meaning of the boolean returned by the
function clearer, as hasStorageAccess

does
*not* indicate if access to non-cookie storage via requestStorageAccess

was
granted, it *only* indicates if unpartitioned cookies are available in the
given context (which may have been granted via a requestStorageAccess

 call).

hasUnpartitionedCookieAccess

is
effectively an alias for hasStorageAccess
,
and there are no plans to remove hasStorageAccess
 as
far as I'm aware.

For example:
// In a cross-site iframe with third-party cookies disabled
let access1 = await document.hasStorageAccess();
let access2 = await document.hasUnpartitionedCookieAccess();
// access1 equals access2 equals false.

// Request access only to unpartitioned localStorage
let handle = await document.requestStorageAccess({localStorage: true});
access1 = await document.hasStorageAccess();
access2 = await document.hasUnpartitionedCookieAccess();
// access1 equals access2 equals false.

// Request access to unpartitioned cookies as well
await document.requestStorageAccess();
// the above is similar to calling requestStorageAccess({cookies: true})
access1 = await document.hasStorageAccess();
access2 = await document.hasUnpartitionedCookieAccess();
// access1 equals access2 equals true.

~ Ari Chivukula (Their/There/They're)


On Wed, Apr 3, 2024 at 11:57 AM Rick Byers  wrote:

> LGTM3
>
> On Wed, Apr 3, 2024 at 11:30 AM Daniel Bratell 
> wrote:
>
>> LGTM2
>>
>> /Daniel
>> On 2024-03-20 16:14, Yoav Weiss (@Shopify) wrote:
>>
>> LGTM1
>>
>> The signals from other vendors and the CG discussion seem encouraging and
>> I agree that the future risk from an "all" value is probably outweighed by
>> its developer-facing benefits.
>>
>> On Wed, Mar 20, 2024 at 12:56 PM Ari Chivukula 
>> wrote:
>>
>>> I'd guess that, in the future, the semantics around 'all' may change in
>>> one of two ways:
>>>
>>> (A) If storage methods included are deprecated, (1) we would start
>>> warning developers via a DevTools issue when they use 'all', (2) we would
>>> start requiring the deprecated method was specifically included in the call
>>> to rSA rather than it being automatically included in all, (3) the storage
>>> method would be removed from rSA. The timeline for this would likely be
>>> rather long (alongside the timeline for the deprecation of the storage
>>> method itself).
>>>
>>> (B) If a new storage method were proposed, (1) we would allow developers
>>> to use it if explicitly included in rSA (but not add it via all) and then
>>> (2) add it under 'all' once it had fully launched.
>>>
>>> The chances of a new storage method being added we (1) do want in rSA
>>> but (2) wouldn't ever want under 'all' is low I think. All of the
>>> storage/communication mechanisms besides local/session storage either have
>>> async APIs or don't expose events to monitor changes that would require
>>> full loading of data simply because the handle/constructor was made
>>> available. I agree there is a potential for a footgun here, but given the
>>> direction these APIs seem to be heading I don't think the risk is high.
>>> What are the chances vendors decide to add new storage mechanisms that are
>>> loaded at document initialization with all data synchronously available?
>>>
>>> ~ Ari Chivukula (Their/There/They're)
>>>
>>>
>>> On Wed, Mar 20, 2024 at 7:48 AM Yoav Weiss (@Shopify) <
>>> yoavwe...@chromium.org> wrote:
>>>


 On Wed, Mar 20, 2024 at 12:40 PM Ari Chivukula 
 wrote:

> I think the last place it came up was in this thread:
> https://github.com/mozilla/standards-positions/issues/898#issuecomment-1745688352
>
> I think it came up at TPAC, but I might me missing the right line:
> https://github.com/privacycg/meetings/blob/a27d3ee4c596efb5aec7d16feda2708fbd60eacf/2023/tpac/minutes.md?plain=1#L302
>
> 

Re: [blink-dev] Re: Intent to Ship: Extending Storage Access API (SAA) to non-cookie storage

[Rick Byers]

LGTM3

On Wed, Apr 3, 2024 at 11:30 AM Daniel Bratell  wrote:

> LGTM2
>
> /Daniel
> On 2024-03-20 16:14, Yoav Weiss (@Shopify) wrote:
>
> LGTM1
>
> The signals from other vendors and the CG discussion seem encouraging and
> I agree that the future risk from an "all" value is probably outweighed by
> its developer-facing benefits.
>
> On Wed, Mar 20, 2024 at 12:56 PM Ari Chivukula 
> wrote:
>
>> I'd guess that, in the future, the semantics around 'all' may change in
>> one of two ways:
>>
>> (A) If storage methods included are deprecated, (1) we would start
>> warning developers via a DevTools issue when they use 'all', (2) we would
>> start requiring the deprecated method was specifically included in the call
>> to rSA rather than it being automatically included in all, (3) the storage
>> method would be removed from rSA. The timeline for this would likely be
>> rather long (alongside the timeline for the deprecation of the storage
>> method itself).
>>
>> (B) If a new storage method were proposed, (1) we would allow developers
>> to use it if explicitly included in rSA (but not add it via all) and then
>> (2) add it under 'all' once it had fully launched.
>>
>> The chances of a new storage method being added we (1) do want in rSA but
>> (2) wouldn't ever want under 'all' is low I think. All of the
>> storage/communication mechanisms besides local/session storage either have
>> async APIs or don't expose events to monitor changes that would require
>> full loading of data simply because the handle/constructor was made
>> available. I agree there is a potential for a footgun here, but given the
>> direction these APIs seem to be heading I don't think the risk is high.
>> What are the chances vendors decide to add new storage mechanisms that are
>> loaded at document initialization with all data synchronously available?
>>
>> ~ Ari Chivukula (Their/There/They're)
>>
>>
>> On Wed, Mar 20, 2024 at 7:48 AM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>>
>>>
>>> On Wed, Mar 20, 2024 at 12:40 PM Ari Chivukula 
>>> wrote:
>>>
 I think the last place it came up was in this thread:
 https://github.com/mozilla/standards-positions/issues/898#issuecomment-1745688352

 I think it came up at TPAC, but I might me missing the right line:
 https://github.com/privacycg/meetings/blob/a27d3ee4c596efb5aec7d16feda2708fbd60eacf/2023/tpac/minutes.md?plain=1#L302

 Either way, there hasn't been further concern raised recently so we
 moved forward with 'all' since the function is async (the delay from
 loading local/session storage isn't high, and it was often already loaded
 given the requirement to have interacted with the iframe's site in a
 top-level context in the past).

>>>
>>> The only concern I may have on the "all" front is related to changing
>>> semantics. How likely are we to add future storage mechanisms that users
>>> would not want to expose along with current ones?
>>>
>>>

 ~ Ari Chivukula (Their/There/They're)


 On Wed, Mar 20, 2024 at 7:29 AM Yoav Weiss (@Shopify) <
 yoavwe...@chromium.org> wrote:

>
>
> On Thursday, March 14, 2024 at 2:27:20 PM UTC+1 Ari Chivukula wrote:
>
> Contact emails
>
> aric...@chromium.org, wanderv...@chromium.org, johann...@chromium.org,
> rosh...@google.com
>
> Specification
>
> https://privacycg.github.io/saa-non-cookie-storage/
>
> Design Doc
>
> https://docs.google.com/document/d/19qCGb4qwOcGiNrQM3ptWvRmB4Jtpa
> TFgFVlWLXNOQ6c/edit
>
> Feedback
>
> https://github.com/privacycg/saa-non-cookie-storage/issues
>
>
> Intent to Prototype
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/inRN8tI49O0
>
> Intent to Experiment
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/SEL7N-xIE5s
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/AjH7tGxuVuw
>
> Summary
>
> This launches the proposed extension of the Storage Access API
> 
> (backwards compatible and currently in OT) to allow access to 
> unpartitioned
> cookie and non-cookie storage in a third-party context. The current API
> only provides access to cookies, which have different use-cases than
> non-cookie storage (discussed more in the Motivation section). The API can
> be used as follows (JS running in an embedded iframe):
>
>
> // Request a new storage handle via rSA (this may prompt the user)
>
> let handle = await document.requestStorageAccess({all: true});
>
> // Write some 1P context sessionstorage
>
> handle.sessionStorage.setItem("userid", "1234");
>
> // Write some 1P context localstorage
>
> handle.localStorage.setItem("preference", "A");
>
> // Open or create an indexedDB that is shared with the 1P context
>

Re: [blink-dev] Re: Intent to Ship: Extending Storage Access API (SAA) to non-cookie storage

[Daniel Bratell]

LGTM2

/Daniel

On 2024-03-20 16:14, Yoav Weiss (@Shopify) wrote:

LGTM1

The signals from other vendors and the CG discussion seem encouraging 
and I agree that the future risk from an "all" value is probably 
outweighed by its developer-facing benefits.


On Wed, Mar 20, 2024 at 12:56 PM Ari Chivukula  
wrote:


I'd guess that, in the future, the semantics around 'all' may
change in one of two ways:

(A) If storage methods included are deprecated, (1) we would start
warning developers via a DevTools issue when they use 'all', (2)
we would start requiring the deprecated method was specifically
included in the call to rSA rather than it being automatically
included in all, (3) the storage method would be removed from rSA.
The timeline for this would likely be rather long (alongside the
timeline for the deprecation of the storage method itself).

(B) If a new storage method were proposed, (1) we would allow
developers to use it if explicitly included in rSA (but not add it
via all) and then (2) add it under 'all' once it had fully launched.

The chances of a new storage method being added we (1) do want in
rSA but (2) wouldn't ever want under 'all' is low I think. All of
the storage/communication mechanisms besides local/session storage
either have async APIs or don't expose events to monitor changes
that would require full loading of data simply because the
handle/constructor was made available. I agree there is a
potential for a footgun here, but given the direction these APIs
seem to be heading I don't think the risk is high. What are the
chances vendors decide to add new storage mechanisms that are
loaded at document initialization with all data synchronously
available?

~ Ari Chivukula (Their/There/They're)


On Wed, Mar 20, 2024 at 7:48 AM Yoav Weiss (@Shopify)
 wrote:



On Wed, Mar 20, 2024 at 12:40 PM Ari Chivukula
 wrote:

I think the last place it came up was in this thread:

https://github.com/mozilla/standards-positions/issues/898#issuecomment-1745688352


I think it came up at TPAC, but I might me missing the
right line:

https://github.com/privacycg/meetings/blob/a27d3ee4c596efb5aec7d16feda2708fbd60eacf/2023/tpac/minutes.md?plain=1#L302

Either way, there hasn't been further concern raised
recently so we moved forward with 'all' since the function
is async (the delay from loading local/session storage
isn't high, and it was often already loaded given the
requirement to have interacted with the iframe's site in a
top-level context in the past).


The only concern I may have on the "all" front is related to
changing semantics. How likely are we to add future storage
mechanisms that users would not want to expose along with
current ones?


~ Ari Chivukula (Their/There/They're)


On Wed, Mar 20, 2024 at 7:29 AM Yoav Weiss (@Shopify)
 wrote:



On Thursday, March 14, 2024 at 2:27:20 PM UTC+1 Ari
Chivukula wrote:

Contact emails

aric...@chromium.org
,
wanderv...@chromium.org
,
johann...@chromium.org
,
rosh...@google.com 


Specification

https://privacycg.github.io/saa-non-cookie-storage/



Design Doc


https://docs.google.com/document/d/19qCGb4qwOcGiNrQM3ptWvRmB4JtpaTFgFVlWLXNOQ6c/edit




Feedback

https://github.com/privacycg/saa-non-cookie-storage/issues



Intent to Prototype


https://groups.google.com/a/chromium.org/g/blink-dev/c/inRN8tI49O0




Intent to Experiment


https://groups.google.com/a/chromium.org/g/blink-dev/c/SEL7N-xIE5s




https://groups.google.com/a/chromium.org/g/blink-dev/c/AjH7tGxuVuw




Summary

This launches the proposed extension of the
Storage Access API

[blink-dev] Re: Intent to Ship: Extending Storage Access API (SAA) to non-cookie storage

[Yoav Weiss (@Shopify)]

LGTM1

The signals from other vendors and the CG discussion seem encouraging and I
agree that the future risk from an "all" value is probably outweighed by
its developer-facing benefits.

On Wed, Mar 20, 2024 at 12:56 PM Ari Chivukula  wrote:

> I'd guess that, in the future, the semantics around 'all' may change in
> one of two ways:
>
> (A) If storage methods included are deprecated, (1) we would start warning
> developers via a DevTools issue when they use 'all', (2) we would start
> requiring the deprecated method was specifically included in the call to
> rSA rather than it being automatically included in all, (3) the storage
> method would be removed from rSA. The timeline for this would likely be
> rather long (alongside the timeline for the deprecation of the storage
> method itself).
>
> (B) If a new storage method were proposed, (1) we would allow developers
> to use it if explicitly included in rSA (but not add it via all) and then
> (2) add it under 'all' once it had fully launched.
>
> The chances of a new storage method being added we (1) do want in rSA but
> (2) wouldn't ever want under 'all' is low I think. All of the
> storage/communication mechanisms besides local/session storage either have
> async APIs or don't expose events to monitor changes that would require
> full loading of data simply because the handle/constructor was made
> available. I agree there is a potential for a footgun here, but given the
> direction these APIs seem to be heading I don't think the risk is high.
> What are the chances vendors decide to add new storage mechanisms that are
> loaded at document initialization with all data synchronously available?
>
> ~ Ari Chivukula (Their/There/They're)
>
>
> On Wed, Mar 20, 2024 at 7:48 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>>
>>
>> On Wed, Mar 20, 2024 at 12:40 PM Ari Chivukula 
>> wrote:
>>
>>> I think the last place it came up was in this thread:
>>> https://github.com/mozilla/standards-positions/issues/898#issuecomment-1745688352
>>>
>>> I think it came up at TPAC, but I might me missing the right line:
>>> https://github.com/privacycg/meetings/blob/a27d3ee4c596efb5aec7d16feda2708fbd60eacf/2023/tpac/minutes.md?plain=1#L302
>>>
>>> Either way, there hasn't been further concern raised recently so we
>>> moved forward with 'all' since the function is async (the delay from
>>> loading local/session storage isn't high, and it was often already loaded
>>> given the requirement to have interacted with the iframe's site in a
>>> top-level context in the past).
>>>
>>
>> The only concern I may have on the "all" front is related to changing
>> semantics. How likely are we to add future storage mechanisms that users
>> would not want to expose along with current ones?
>>
>>
>>>
>>> ~ Ari Chivukula (Their/There/They're)
>>>
>>>
>>> On Wed, Mar 20, 2024 at 7:29 AM Yoav Weiss (@Shopify) <
>>> yoavwe...@chromium.org> wrote:
>>>


 On Thursday, March 14, 2024 at 2:27:20 PM UTC+1 Ari Chivukula wrote:

 Contact emails

 aric...@chromium.org, wanderv...@chromium.org, johann...@chromium.org,
 rosh...@google.com

 Specification

 https://privacycg.github.io/saa-non-cookie-storage/

 Design Doc

 https://docs.google.com/document/d/19qCGb4qwOcGiNrQM3ptWvRmB4Jtpa
 TFgFVlWLXNOQ6c/edit

 Feedback

 https://github.com/privacycg/saa-non-cookie-storage/issues


 Intent to Prototype

 https://groups.google.com/a/chromium.org/g/blink-dev/c/inRN8tI49O0

 Intent to Experiment

 https://groups.google.com/a/chromium.org/g/blink-dev/c/SEL7N-xIE5s

 https://groups.google.com/a/chromium.org/g/blink-dev/c/AjH7tGxuVuw

 Summary

 This launches the proposed extension of the Storage Access API
 
 (backwards compatible and currently in OT) to allow access to unpartitioned
 cookie and non-cookie storage in a third-party context. The current API
 only provides access to cookies, which have different use-cases than
 non-cookie storage (discussed more in the Motivation section). The API can
 be used as follows (JS running in an embedded iframe):


 // Request a new storage handle via rSA (this may prompt the user)

 let handle = await document.requestStorageAccess({all: true});

 // Write some 1P context sessionstorage

 handle.sessionStorage.setItem("userid", "1234");

 // Write some 1P context localstorage

 handle.localStorage.setItem("preference", "A");

 // Open or create an indexedDB that is shared with the 1P context

 let messageDB = handle.indexedDB.open("messages");

 // Use locks shared with the 1P context

 await handle.locks.request(“example”, …);


 The same flow would be used by iframes to get a storage handle when
 their top-level ancestor 

[blink-dev] Re: Intent to Ship: Extending Storage Access API (SAA) to non-cookie storage

[Ari Chivukula]

I'd guess that, in the future, the semantics around 'all' may change in one
of two ways:

(A) If storage methods included are deprecated, (1) we would start warning
developers via a DevTools issue when they use 'all', (2) we would start
requiring the deprecated method was specifically included in the call to
rSA rather than it being automatically included in all, (3) the storage
method would be removed from rSA. The timeline for this would likely be
rather long (alongside the timeline for the deprecation of the storage
method itself).

(B) If a new storage method were proposed, (1) we would allow developers to
use it if explicitly included in rSA (but not add it via all) and then (2)
add it under 'all' once it had fully launched.

The chances of a new storage method being added we (1) do want in rSA but
(2) wouldn't ever want under 'all' is low I think. All of the
storage/communication mechanisms besides local/session storage either have
async APIs or don't expose events to monitor changes that would require
full loading of data simply because the handle/constructor was made
available. I agree there is a potential for a footgun here, but given the
direction these APIs seem to be heading I don't think the risk is high.
What are the chances vendors decide to add new storage mechanisms that are
loaded at document initialization with all data synchronously available?

~ Ari Chivukula (Their/There/They're)


On Wed, Mar 20, 2024 at 7:48 AM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

>
>
> On Wed, Mar 20, 2024 at 12:40 PM Ari Chivukula 
> wrote:
>
>> I think the last place it came up was in this thread:
>> https://github.com/mozilla/standards-positions/issues/898#issuecomment-1745688352
>>
>> I think it came up at TPAC, but I might me missing the right line:
>> https://github.com/privacycg/meetings/blob/a27d3ee4c596efb5aec7d16feda2708fbd60eacf/2023/tpac/minutes.md?plain=1#L302
>>
>> Either way, there hasn't been further concern raised recently so we moved
>> forward with 'all' since the function is async (the delay from loading
>> local/session storage isn't high, and it was often already loaded given the
>> requirement to have interacted with the iframe's site in a top-level
>> context in the past).
>>
>
> The only concern I may have on the "all" front is related to changing
> semantics. How likely are we to add future storage mechanisms that users
> would not want to expose along with current ones?
>
>
>>
>> ~ Ari Chivukula (Their/There/They're)
>>
>>
>> On Wed, Mar 20, 2024 at 7:29 AM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>>
>>>
>>> On Thursday, March 14, 2024 at 2:27:20 PM UTC+1 Ari Chivukula wrote:
>>>
>>> Contact emails
>>>
>>> aric...@chromium.org, wanderv...@chromium.org, johann...@chromium.org,
>>> rosh...@google.com
>>>
>>> Specification
>>>
>>> https://privacycg.github.io/saa-non-cookie-storage/
>>>
>>> Design Doc
>>>
>>> https://docs.google.com/document/d/19qCGb4qwOcGiNrQM3ptWvRmB4Jtpa
>>> TFgFVlWLXNOQ6c/edit
>>>
>>> Feedback
>>>
>>> https://github.com/privacycg/saa-non-cookie-storage/issues
>>>
>>>
>>> Intent to Prototype
>>>
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/inRN8tI49O0
>>>
>>> Intent to Experiment
>>>
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/SEL7N-xIE5s
>>>
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/AjH7tGxuVuw
>>>
>>> Summary
>>>
>>> This launches the proposed extension of the Storage Access API
>>> 
>>> (backwards compatible and currently in OT) to allow access to unpartitioned
>>> cookie and non-cookie storage in a third-party context. The current API
>>> only provides access to cookies, which have different use-cases than
>>> non-cookie storage (discussed more in the Motivation section). The API can
>>> be used as follows (JS running in an embedded iframe):
>>>
>>>
>>> // Request a new storage handle via rSA (this may prompt the user)
>>>
>>> let handle = await document.requestStorageAccess({all: true});
>>>
>>> // Write some 1P context sessionstorage
>>>
>>> handle.sessionStorage.setItem("userid", "1234");
>>>
>>> // Write some 1P context localstorage
>>>
>>> handle.localStorage.setItem("preference", "A");
>>>
>>> // Open or create an indexedDB that is shared with the 1P context
>>>
>>> let messageDB = handle.indexedDB.open("messages");
>>>
>>> // Use locks shared with the 1P context
>>>
>>> await handle.locks.request(“example”, …);
>>>
>>>
>>> The same flow would be used by iframes to get a storage handle when
>>> their top-level ancestor successfully called requestStorageAccessFor
>>> , just that in
>>> this case the storage-access permission was already granted and thus the
>>> requestStorageAccess call would not require a user gesture or show a
>>> prompt, allowing for “hidden” iframes accessing storage.
>>>
>>>
>>> Beyond calling this additional extension, access to non-cookie 

[blink-dev] Re: Intent to Ship: Extending Storage Access API (SAA) to non-cookie storage

[Yoav Weiss (@Shopify)]

On Wed, Mar 20, 2024 at 12:40 PM Ari Chivukula  wrote:

> I think the last place it came up was in this thread:
> https://github.com/mozilla/standards-positions/issues/898#issuecomment-1745688352
>
> I think it came up at TPAC, but I might me missing the right line:
> https://github.com/privacycg/meetings/blob/a27d3ee4c596efb5aec7d16feda2708fbd60eacf/2023/tpac/minutes.md?plain=1#L302
>
> Either way, there hasn't been further concern raised recently so we moved
> forward with 'all' since the function is async (the delay from loading
> local/session storage isn't high, and it was often already loaded given the
> requirement to have interacted with the iframe's site in a top-level
> context in the past).
>

The only concern I may have on the "all" front is related to changing
semantics. How likely are we to add future storage mechanisms that users
would not want to expose along with current ones?


>
> ~ Ari Chivukula (Their/There/They're)
>
>
> On Wed, Mar 20, 2024 at 7:29 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>>
>>
>> On Thursday, March 14, 2024 at 2:27:20 PM UTC+1 Ari Chivukula wrote:
>>
>> Contact emails
>>
>> aric...@chromium.org, wanderv...@chromium.org, johann...@chromium.org,
>> rosh...@google.com
>>
>> Specification
>>
>> https://privacycg.github.io/saa-non-cookie-storage/
>>
>> Design Doc
>>
>> https://docs.google.com/document/d/19qCGb4qwOcGiNrQM3ptWvRmB4Jtpa
>> TFgFVlWLXNOQ6c/edit
>>
>> Feedback
>>
>> https://github.com/privacycg/saa-non-cookie-storage/issues
>>
>>
>> Intent to Prototype
>>
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/inRN8tI49O0
>>
>> Intent to Experiment
>>
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/SEL7N-xIE5s
>>
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/AjH7tGxuVuw
>>
>> Summary
>>
>> This launches the proposed extension of the Storage Access API
>> 
>> (backwards compatible and currently in OT) to allow access to unpartitioned
>> cookie and non-cookie storage in a third-party context. The current API
>> only provides access to cookies, which have different use-cases than
>> non-cookie storage (discussed more in the Motivation section). The API can
>> be used as follows (JS running in an embedded iframe):
>>
>>
>> // Request a new storage handle via rSA (this may prompt the user)
>>
>> let handle = await document.requestStorageAccess({all: true});
>>
>> // Write some 1P context sessionstorage
>>
>> handle.sessionStorage.setItem("userid", "1234");
>>
>> // Write some 1P context localstorage
>>
>> handle.localStorage.setItem("preference", "A");
>>
>> // Open or create an indexedDB that is shared with the 1P context
>>
>> let messageDB = handle.indexedDB.open("messages");
>>
>> // Use locks shared with the 1P context
>>
>> await handle.locks.request(“example”, …);
>>
>>
>> The same flow would be used by iframes to get a storage handle when their
>> top-level ancestor successfully called requestStorageAccessFor
>> , just that in
>> this case the storage-access permission was already granted and thus the
>> requestStorageAccess call would not require a user gesture or show a
>> prompt, allowing for “hidden” iframes accessing storage.
>>
>>
>> Beyond calling this additional extension, access to non-cookie storage
>> would match the current requirements for cookie access through the Storage
>> Access API.
>>
>>
>> DOM Storage (session and local storage), Indexed DB, Web Locks, Cache
>> Storage, Origin Private File System, Quota, Blob Storage, Broadcast
>> Channel, and SharedWorkers will be available.
>>
>>
>> Blink component
>>
>> Blink>StorageAccessAPI
>> 
>>
>>
>> Motivation
>>
>> There has been increasing developer
>> 
>> and implementer 
>> interest in first-party DOM Storage
>>  and Quota
>> Managed Storage
>>  being
>> available in third-party contexts the same way that cookies can be today
>> . In the absence of such a
>> solution, browsers would in effect be pushing developers to migrate to
>> cookies from other storage mechanisms. There are tradeoffs between cookie
>> and non-cookie storage (size, flexibility, server exposure, network request
>> size, etc.) that could impact user experience from a privacy, security and
>> performance perspective (e.g., cookies are included in HTTP requests and
>> not just available via JavaScript). To prevent sub-optimal use of cookies
>> and to preserve context, we propose a solution for developers to regain 3p
>> access to unpartitioned storage to avoid user-facing 

[blink-dev] Re: Intent to Ship: Extending Storage Access API (SAA) to non-cookie storage

[Ari Chivukula]

I think the last place it came up was in this thread:
https://github.com/mozilla/standards-positions/issues/898#issuecomment-1745688352

I think it came up at TPAC, but I might me missing the right line:
https://github.com/privacycg/meetings/blob/a27d3ee4c596efb5aec7d16feda2708fbd60eacf/2023/tpac/minutes.md?plain=1#L302

Either way, there hasn't been further concern raised recently so we moved
forward with 'all' since the function is async (the delay from loading
local/session storage isn't high, and it was often already loaded given the
requirement to have interacted with the iframe's site in a top-level
context in the past).

~ Ari Chivukula (Their/There/They're)


On Wed, Mar 20, 2024 at 7:29 AM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

>
>
> On Thursday, March 14, 2024 at 2:27:20 PM UTC+1 Ari Chivukula wrote:
>
> Contact emails
>
> aric...@chromium.org, wanderv...@chromium.org, johann...@chromium.org,
> rosh...@google.com
>
> Specification
>
> https://privacycg.github.io/saa-non-cookie-storage/
>
> Design Doc
>
> https://docs.google.com/document/d/19qCGb4qwOcGiNrQM3ptWvRmB4Jtpa
> TFgFVlWLXNOQ6c/edit
>
> Feedback
>
> https://github.com/privacycg/saa-non-cookie-storage/issues
>
>
> Intent to Prototype
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/inRN8tI49O0
>
> Intent to Experiment
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/SEL7N-xIE5s
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/AjH7tGxuVuw
>
> Summary
>
> This launches the proposed extension of the Storage Access API
>  (backwards
> compatible and currently in OT) to allow access to unpartitioned cookie and
> non-cookie storage in a third-party context. The current API only provides
> access to cookies, which have different use-cases than non-cookie storage
> (discussed more in the Motivation section). The API can be used as follows
> (JS running in an embedded iframe):
>
>
> // Request a new storage handle via rSA (this may prompt the user)
>
> let handle = await document.requestStorageAccess({all: true});
>
> // Write some 1P context sessionstorage
>
> handle.sessionStorage.setItem("userid", "1234");
>
> // Write some 1P context localstorage
>
> handle.localStorage.setItem("preference", "A");
>
> // Open or create an indexedDB that is shared with the 1P context
>
> let messageDB = handle.indexedDB.open("messages");
>
> // Use locks shared with the 1P context
>
> await handle.locks.request(“example”, …);
>
>
> The same flow would be used by iframes to get a storage handle when their
> top-level ancestor successfully called requestStorageAccessFor
> , just that in this
> case the storage-access permission was already granted and thus the
> requestStorageAccess call would not require a user gesture or show a
> prompt, allowing for “hidden” iframes accessing storage.
>
>
> Beyond calling this additional extension, access to non-cookie storage
> would match the current requirements for cookie access through the Storage
> Access API.
>
>
> DOM Storage (session and local storage), Indexed DB, Web Locks, Cache
> Storage, Origin Private File System, Quota, Blob Storage, Broadcast
> Channel, and SharedWorkers will be available.
>
>
> Blink component
>
> Blink>StorageAccessAPI
> 
>
>
> Motivation
>
> There has been increasing developer
> 
> and implementer 
> interest in first-party DOM Storage
>  and Quota
> Managed Storage
>  being
> available in third-party contexts the same way that cookies can be today
> . In the absence of such a
> solution, browsers would in effect be pushing developers to migrate to
> cookies from other storage mechanisms. There are tradeoffs between cookie
> and non-cookie storage (size, flexibility, server exposure, network request
> size, etc.) that could impact user experience from a privacy, security and
> performance perspective (e.g., cookies are included in HTTP requests and
> not just available via JavaScript). To prevent sub-optimal use of cookies
> and to preserve context, we propose a solution for developers to regain 3p
> access to unpartitioned storage to avoid user-facing breakage in browsers
> shipping storage partitioning.
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/906
>
> Compatibility
>
> The Storage Access API is already implemented in Safari, Firefox, and
> Chrome , but
> the proposed API shape would preserve existing behavior until the web
> developer adds new arguments.
>
>

[blink-dev] Re: Intent to Ship: Extending Storage Access API (SAA) to non-cookie storage

[Yoav Weiss (@Shopify)]

On Thursday, March 14, 2024 at 2:27:20 PM UTC+1 Ari Chivukula wrote:

Contact emails

aric...@chromium.org, wanderv...@chromium.org, johann...@chromium.org, 
rosh...@google.com

Specification

https://privacycg.github.io/saa-non-cookie-storage/

Design Doc

https://docs.google.com/document/d/19qCGb4qwOcGiNrQM3ptWvRmB4Jtpa
TFgFVlWLXNOQ6c/edit

Feedback

https://github.com/privacycg/saa-non-cookie-storage/issues


Intent to Prototype

https://groups.google.com/a/chromium.org/g/blink-dev/c/inRN8tI49O0

Intent to Experiment

https://groups.google.com/a/chromium.org/g/blink-dev/c/SEL7N-xIE5s

https://groups.google.com/a/chromium.org/g/blink-dev/c/AjH7tGxuVuw

Summary

This launches the proposed extension of the Storage Access API 
 (backwards 
compatible and currently in OT) to allow access to unpartitioned cookie and 
non-cookie storage in a third-party context. The current API only provides 
access to cookies, which have different use-cases than non-cookie storage 
(discussed more in the Motivation section). The API can be used as follows 
(JS running in an embedded iframe):


// Request a new storage handle via rSA (this may prompt the user)

let handle = await document.requestStorageAccess({all: true});

// Write some 1P context sessionstorage

handle.sessionStorage.setItem("userid", "1234");

// Write some 1P context localstorage

handle.localStorage.setItem("preference", "A");

// Open or create an indexedDB that is shared with the 1P context

let messageDB = handle.indexedDB.open("messages");

// Use locks shared with the 1P context

await handle.locks.request(“example”, …);


The same flow would be used by iframes to get a storage handle when their 
top-level ancestor successfully called requestStorageAccessFor 
, just that in this 
case the storage-access permission was already granted and thus the 
requestStorageAccess call would not require a user gesture or show a 
prompt, allowing for “hidden” iframes accessing storage. 


Beyond calling this additional extension, access to non-cookie storage 
would match the current requirements for cookie access through the Storage 
Access API.


DOM Storage (session and local storage), Indexed DB, Web Locks, Cache 
Storage, Origin Private File System, Quota, Blob Storage, Broadcast 
Channel, and SharedWorkers will be available.


Blink component

Blink>StorageAccessAPI 



Motivation

There has been increasing developer 
 
and implementer  
interest in first-party DOM Storage 
 and Quota 
Managed Storage 
 being 
available in third-party contexts the same way that cookies can be today 
. In the absence of such a 
solution, browsers would in effect be pushing developers to migrate to 
cookies from other storage mechanisms. There are tradeoffs between cookie 
and non-cookie storage (size, flexibility, server exposure, network request 
size, etc.) that could impact user experience from a privacy, security and 
performance perspective (e.g., cookies are included in HTTP requests and 
not just available via JavaScript). To prevent sub-optimal use of cookies 
and to preserve context, we propose a solution for developers to regain 3p 
access to unpartitioned storage to avoid user-facing breakage in browsers 
shipping storage partitioning.

TAG review

https://github.com/w3ctag/design-reviews/issues/906

Compatibility

The Storage Access API is already implemented in Safari, Firefox, and Chrome 
, but the 
proposed API shape would preserve existing behavior until the web developer 
adds new arguments.


Interoperability

Gecko: No Position Yet https://github.com/mozilla/
standards-positions/issues/898


Despite the lack of an official position, the discussion seems encouraging. 
I sympathize with concerns around "all"'s semantics and their future compat 
impact.
Was this point discussed in the CG or elsewhere?
  

WebKit: No Position Yet https://github.com/WebKit/
standards-positions/issues/262

Web developers: Positive 


Debuggability

Storage written can be examined in devtools.

Is this feature fully tested by web-platform-tests?

Yes 


Tracking bug

https://issues.chromium.org/40282415


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5175585823522816

-- 
You received this message