requestStorageAccess currently provides no way to directly control any
surfaces with first-party SameSite=Strict cookies. If the handle returned
allowed you to access first-party SharedWorkers, those workers would have
access to SameSite=Strict cookies. Chrome's decision at this juncture is to
not provide that as it would the assurances around what party was making
the request the cookies were included in.
Chrome could provide some independent pool of SharedWorkers accessible via
requestStorageAccess in a third-party context that did not have access to
SameSite=Strict cookies, but where otherwise essentially first-party
workers. Chrome could even make these workers accessible from a first-party
context via some additional argument (e.g., SharedWorker(...,
{enableThirdPartyAccessWithoutSameSiteStrictCookies: true}). That might
meet some use cases, but not others. Chrome would want to see more
developer interest before considering that.
As for two separate frames on different origins messaging each other, if
one frame opens the other in a way that allows access via window.opener,
then the two frames can use postMessage cross-origin. Otherwise there isn't
a way to message between frames without some sort of extension mediating
the process AFAIK.
~ Ari Chivukula (Their/There/They're)
On Wed, Nov 29, 2023 at 4:34 PM Jesper van den Ende <jesperthe...@gmail.com>
wrote:
> Ah that's too bad.
> I don't think using object urls would be performant. The data in the
> ArrayBuffer is still accessible after creating the object url, so that does
> not seem like it is getting transferred.
>
> Is there any chance an api could be exposed in the future that would allow
> two separate origins to share the same SharedWorker?
> Being able to access requestStorageAccess() from within a SharedWorker
> wouldn't work for my use case, since at that point the two separate workers
> have already been created.
> I need some way to request storage access before creating the SharedWorker.
>
> Maybe I'm misunderstanding the issue of SameSite=Strict cookies being
> accessible within SharedWorkers, but what if you could only gain access to
> `handle.SharedWorker` when you requested storageAccess with {all: true}?
> Wouldn't that mean you explicitly requested storage access for everything,
> thus allowing access to any existing SharedWorkers that may have been
> created?
> On Wednesday, November 29, 2023 at 12:05:04 AM UTC+1 Ari Chivukula wrote:
>
>> Testing locally, event.source seems always to be null when using
>> Broadcast Channel. This seems to align with the spec which doesn't mention
>> setting source at all for the MessageEvent:
>> https://html.spec.whatwg.org/multipage/web-messaging.html#broadcasting-to-other-browsing-contexts
>> and the chrome code which doesn't set it:
>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/broadcastchannel/broadcast_channel.cc;drc=8e78783dc1f7007bad46d657c9f332614e240fd8;l=173
>>
>> It looks like storing the ArrayBuffer as a Blob (
>> https://developer.mozilla.org/en-US/docs/Web/API/URL/createObjectURL_static)
>> and sharing the resulting URL via BroadcastChannel or other means may work,
>> but I'm unsure about the efficiency of such an approach.
>>
>> ~ Ari Chivukula (Their/There/They're)
>>
>>
>> On Tue, Nov 28, 2023 at 5:35 PM Jesper van den Ende <jesper...@gmail.com>
>> wrote:
>>
>>> Awesome, thanks for the info!
>>>
>>> A broadcast channel doesn't work for my use case unfortunately.
>>> I'd like to create a MessageChannel
>>> <https://developer.mozilla.org/en-US/docs/Web/API/MessageChannel> and
>>> then transfer the two MessagePorts to both tabs.
>>> Since a broadcast channel doesn't allow transferring objects
>>> <https://github.com/whatwg/html/issues/7088#issuecomment-922529073>,
>>> there's no way for me to send messages to both tabs without it also being
>>> sent to all other tabs.
>>> And with no way to transfer things such as ArrayBuffers, I reckon this
>>> would also be pretty inefficient for some operations.
>>> But maybe I'm missing something? One thing that comes to mind is using
>>> the MessageEvent.source to get access to the window of another tab and then
>>> send a message to it directly. But I'm not sure if that would work.
>>>
>>
>>> On Tuesday, November 28, 2023 at 10:44:54 PM UTC+1 Ari Chivukula wrote:
>>>
>>>> Thanks for letting us know about your use case. Yes, Chrome has decided
>>>> not to pursue Shared Worker access via the handle returned by
>>>> requestStorageAccess given it would allow access to SameSite=Strict cookies
>>>> to a third-party iframe via that shared worker. We are examining an
>>>> alternate option where requestStorageAccess will be available in workers:
>>>> https://github.com/privacycg/storage-access/issues/157
>>>>
>>>> Either way, this change will probably require switching from using a
>>>> (shared) Shared Worker for tab discovery to something like Broadcast
>>>> Channel
>>>> <https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API>which
>>>> would allow for cross-tab messaging without the need to be online.
>>>>
>>>> ~ Ari Chivukula (Their/There/They're)
>>>>
>>>>
>>>> On Tue, Nov 28, 2023 at 4:35 PM Jesper van den Ende <
>>>> jesper...@gmail.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I noticed the TODOs for shared workers were removed.
>>>>> My application relies on cross origin shared workers and to be honest
>>>>> this was the main part of the proposal I was looking forward to haha.
>>>>> I'm currently relying on the origin trial for disabling third party
>>>>> storage partitioning.
>>>>> Are there any plans for the shared worker use case? I'm not sure what
>>>>> to do once the origin trial expires. And as far as I can tell there is no
>>>>> good alternative for what I'm trying to achieve.
>>>>> Specifically, I'd like to be able to discover other tabs (that are
>>>>> also broadcasting their existence using the same shared worker) and then
>>>>> initiate a connection to them.
>>>>> One alternative I could think of was using WebRTC for this, but
>>>>> ideally I'd like this to work while the user is offline, which is not
>>>>> possible with WebRTC.
>>>>>
>>>>> Is there any discussion about the plan to remove shared workers from
>>>>> the proposal? I couldn't find anything about SameSite=Strict cookies
>>>>> anywhere other than the commit that removed the TODOs.
>>>>>
>>>>> Cheers,
>>>>> Jesper
>>>>>
>>>> On Monday, October 2, 2023 at 3:44:05 PM UTC+2 Ari Chivukula wrote:
>>>>>
>>>>>> Contact emails
>>>>>>
>>>>>> ari...@chromium.org, wande...@chromium.org, joha...@chromium.org,
>>>>>> hel...@google.com
>>>>>>
>>>>>> Specification
>>>>>>
>>>>>> https://arichiv.github.io/saa-non-cookie-storage/
>>>>>>
>>>>>> Summary
>>>>>>
>>>>>> We propose an extension of the Storage Access API
>>>>>> <https://webkit.org/blog/8124/introducing-storage-access-api/>
>>>>>> (backwards compatible) to allow access to unpartitioned (cookie and
>>>>>> non-cookie) storage in a third-party context, and imagine the API
>>>>>> mechanics
>>>>>> to be roughly like this (JS running in an embedded iframe):
>>>>>>
>>>>>>
>>>>>> // Request a new storage handle via rSA (this should prompt the user)
>>>>>>
>>>>>> let handle = await document.requestStorageAccess({all: true});
>>>>>>
>>>>>> // Write some cross-site localstorage
>>>>>>
>>>>>> handle.localStorage.setItem("userid", "1234");
>>>>>>
>>>>>> // Open or create an indexedDB that is shared with the 1P context
>>>>>>
>>>>>> let messageDB = handle.defaultBucket.indexedDB.open("messages");
>>>>>>
>>>>>>
>>>>>> The same flow would be used by iframes to get a storage handle when
>>>>>> their top-level ancestor successfully called rSAFor
>>>>>> <https://github.com/privacycg/requestStorageAccessFor>, just that in
>>>>>> this case the storage-access permission was already granted and thus the
>>>>>> rSA call would not require a user gesture or show a prompt, allowing for
>>>>>> “hidden” iframes accessing storage.
>>>>>>
>>>>>>
>>>>>> Browsers currently shipping the Storage Access API apply varying
>>>>>> methods of when or how to ask the user for permission to grant 3p cookie
>>>>>> access to a site. Given that this proposal involves extending the
>>>>>> existing
>>>>>> Storage Access API, while maintaining largely the same implications
>>>>>> (from a
>>>>>> privacy/security perspective) to the user, a consistent prompt for cookie
>>>>>> and non-cookie access is preferred. No prompt is needed when the origins
>>>>>> are RWS (Related Website Sets, the new name for First Party Sets).
>>>>>>
>>>>>>
>>>>>> Blink component
>>>>>>
>>>>>> Blink>Storage
>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorage>
>>>>>>
>>>>>>
>>>>>> Motivation
>>>>>>
>>>>>> There has been increasing developer
>>>>>> <https://github.com/GoogleChromeLabs/privacy-sandbox-dev-support/issues/124>
>>>>>> and implementer
>>>>>> <https://github.com/privacycg/storage-access/issues/102> interest in
>>>>>> first-party DOM Storage
>>>>>> <https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API>
>>>>>> and Quota Managed Storage
>>>>>> <https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API>
>>>>>> being available in third-party contexts the same way that Cookies
>>>>>> already can be <https://github.com/privacycg/storage-access>. In the
>>>>>> absence of such a solution, we would in effect be pushing developers to
>>>>>> migrate to Cookies from other storage mechanisms. There are significant
>>>>>> tradeoffs between Cookie and non-Cookie storage (size, flexibility,
>>>>>> server
>>>>>> exposure, network request size, etc.) that could cause a detriment in
>>>>>> user
>>>>>> experience from a privacy, security and performance perspective. To
>>>>>> prevent
>>>>>> sub-optimal use of cookies and to preserve context, we propose a solution
>>>>>> for developers to regain 3p access to unpartitioned storage in select
>>>>>> instances 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
>>>>>> <https://caniuse.com/mdn-api_document_requeststorageaccess>, but the
>>>>>> proposed API shape would not change existing behavior without new
>>>>>> arguments
>>>>>> added.
>>>>>>
>>>>>>
>>>>>> Interoperability
>>>>>>
>>>>>> Gecko: https://github.com/mozilla/standards-positions/issues/898
>>>>>>
>>>>>> WebKit: https://github.com/WebKit/standards-positions/issues/262
>>>>>>
>>>>>> Web developers: Positive
>>>>>> <https://github.com/GoogleChromeLabs/privacy-sandbox-dev-support/issues/124>
>>>>>>
>>>>>> Debuggability
>>>>>>
>>>>>> Storage written can be examined in devtools.
>>>>>>
>>>>>> Is this feature fully tested by web-platform-tests?
>>>>>>
>>>>>> Tests will be added.
>>>>>>
>>>>>> Tracking bug
>>>>>>
>>>>>> https://crbug.com/1484966
>>>>>>
>>>>>> Link to entry on the Chrome Platform Status
>>>>>>
>>>>>> https://chromestatus.com/feature/5175585823522816
>>>>>>
>>>>>>
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DKAAQVBwfU1jbk6jVbUmfSSwAE9Q1Gf08-HJOSpR0abig%40mail.gmail.com.
