and the Storage Access API (by itself, or even in conjunction with > > FedCM). A series of heuristics > > were also put in place, which covers a lot of ground too, again optimizing

Login Status API, and allow Relying Parties (RPs) to request access to this information via a browser-mediated prompt similar to the current FedCM flow. By storing the account information

> generic Storage Access API prompt. > > One piece of feedback we got on the API was a question on > whether `navigator.credentials.preventSilentAccess()` > should

> Other API OWNERs may disagree with me (and that's OK), but I'm > not personally inclined to approve an extension here in order > to prevent a small gap in availability

the Blink API owners would >>>>>>>>>>>>> still review it carefully, but in the context of the other intents that >>>>>

Update: The feature has landed in M128 stable. The flag name associated with this feature has changed since the I2S from

CHIPS, Storage Access API, > Related Website Sets, FedCM, etc. > > Experiment Risks > > No, since this experiment allows sites to opt-in to limiting third-party >

us if storage partitioning is disabled. It just tells you if there is unpartitioned cookie access. That will always return false post-3PCD. It will also return true pre-3PCD with storage

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

cfredric/storage-access-headers/issues/7, implementing > arturjanc's proposal ("Require Activate-Storage-Access to specify not only > permission, but

googlers/storage-access-for-fedcm Specification None Summary Reconciles the Federated Credential Management (FedCM) and Storage Access APIs by making a prior permission grant

cookie-storage/ > > Feedback > > https://github.com/privacycg/saa-non-cookie-storage/issues > > Design Doc > > > https://docs.google.com/document

cookie-storage/ ~ Ari Chivukula (Their/There/They're) On Mon, Jan 29, 2024 at 1:41 PM Ari Chivukula wrote: > Please note the repo has been moved into PrivacyCG, and the new

Hi Blink API owners, >>>>> >>>>> We would like to request your approval for adding a first-party >>>>> version of this Deprecation

extension to Storage Access API (SAA) to non-cookie storage ) have been published! Explainer: Extending Storage Access API (SAA) to omit unpartitioned cookies The current Storage

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

the FedCM API, when a user is signing in to a relying party (RP) with an identity provider (IdP) in the browser for the first time, the browser will treat them as a “new” user since it didn

PaymentRequest and Storage access API effectively all follow > this policy too. 3PCD doesn't block cross-origin information sharing, it > just requires user consent

browser-api-login-status. Since WebKit > has expressed some interest in using this API in other scenarios than just > FedCM I imagine there may be a request at some point to move

" the storage-access status of their parent (whether the parent is a document, or is another worker). This behavior is not specified by the Storage Access API (SAA) spec, but is

chrome-storage-access-api#testing-instructions > > On Tuesday, August 22, 2023 at 1:26:10 PM UTC-4 Mike Taylor wrote: > >> LGTM3 >> On 8/22/23 10:49 AM,

chrome-storage-access-api https://github.com/privacycg/storage-access/blob/main/README.md Specification https://privacycg.github.io/storage-access Summary The

shipping an API that we're unhappy with (arguably the name is what we're really most unhappy about). Through our involvement we were able to go back to key design concerns (

describes the API shape and behavior. The design we're shipping is the "singular" one from the explainer. The discussion of the "plural" API in the explainer

THANK YOU ALL for the help especially Eric! Best regards, Mircea On 8. Apr 2023, at 15:25, Kaustubha Govind wrote:  Circling back on the main thread.

handle cookie access accordingly. The First-Party Sets proposal has undergone some changes since we sent the previous Intents. In particular: - We have introduced the notion of "

on the storage access repo, which I've now filed . Feedback is welcome! Thanks! On Tue, Aug 16, 2022 at 5:14 PM 'Brandon Maslen' via blink-dev < blink-dev@chromium

the Request Storage Access API instead of a cookie attribute. Ergonomics The initial implementation will support the Partitioned attribute as a way third-party servers can opt-

`, Storage Access API, etc). >>> >>> -mike >>> >>> >>> On Wed, Oct 30, 2019 at 5:34 PM Ken Buchanan wrote: >>> >>>

of this API. > > While it is true that the other implementations (Firefox/Safari) rely on > user gesture to gate the potential success of requesting storage access so >