[blink-dev] Intent to Ship: Storage Access API with Prompts

Contact emails cfred...@chromium.org, johann...@chromium.org, shuu...@chromium.org Explainer https://github.com/privacycg/storage-access/blob/main/README.md https://github.com/cfredric/chrome-storage-access-api/blob/main/README.md Specification https://privacycg.github.io/storage-access Summ

Re: [blink-dev] Intent to Ship: Storage Access API with Prompts

://github.com/privacycg/storage-access/issues/113> for security reasons; Firefox is planning <https://bugzilla.mozilla.org/show_bug.cgi?id=1837648> to incorporate the recent changes.) Chris On Wednesday, August 2, 2023 at 5:02:35 PM UTC-4 Mike Taylor wrote: > &

Re: [blink-dev] Intent to Ship: Storage Access API with Prompts

h > the TAG? > > Best, > > Alex > > > > On Monday, August 7, 2023 at 11:47:45 AM UTC-7 Chris Fredrickson wrote: > >> Hi Mike, >> >> Sure. MDN has a section >> <https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API#browser_st

Re: [blink-dev] Intent to Ship: Storage Access API with Prompts

t; cross-vendor feedback, isn't worth changing after shipping, then it's not >>> worth changing most APIs that Blink ships first either. >>> >>> Jeffrey >>> >>> On Wed, Aug 16, 2023 at 8:52 AM Alex Russell >>> wrote: >>> >>

Re: [blink-dev] Intent to Ship: First-party sets

rome announced a change in the size limit for the associated subset; it is now 5 (increased from 3). The increased limit will roll out to Chrome clients over the next week or two. On Wednesday, June 28, 2023 at 1:34:57 PM UTC-4 Chris Fredrickson wrote: > Hi all, > > Our metrics analysis

Re: [blink-dev] Intent to Ship: Storage Access API with Prompts

We're now rolling this feature out to 100% on Chrome Stable (M117 and later). On Tuesday, September 26, 2023 at 11:20:29 AM UTC-4 Chris Fredrickson wrote: > Belatedly updating this thread in case folks are monitoring it -- we've > enabled this feature on 1% of Chrome Stabl

[blink-dev] PSA: Storage Access API & dedicated workers

Hello all, Just wanted to give an FYI that I will be submitting a change that makes dedicated workers "inherit" 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

Re: [blink-dev] Intent to Ship: requestStorageAccessFor (for First-Party Sets)

Hi Elijah, The specification 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 was just hypothetical, to explo

[blink-dev] Re: Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

Hi Eli, If I can chime in on a few points from the First-Party Sets perspective: 1. Do you plan to use First-Party Sets to put your consent management site in the same FPS as your customers' sites? (Note that you would have to work around the FPS disjointness requirement

[blink-dev] Re: Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

). Regards, Eli On Monday, April 10, 2023 at 10:45:09 AM UTC-7 Chris Fredrickson wrote: Hi Eli, If I can chime in on a few points from the First-Party Sets perspective: 1. Do you plan to use First-Party Sets to put your consent management site in the same FPS as your customers' site

[blink-dev] Re: Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

en we will of course need to require customers to configure > their own sync coordination domains (manually hosted or CNAME-backed). > > Does that plan mesh well with the FPS registry or are there any other > gotchas that we might be forgetting? > > On Monday, April 24, 2023 at 9:12:

Re: [blink-dev] Intent to Ship: First-party sets

Thanks all. Just an update - we're rolling First-Party Sets out to 1% on Chrome M113 Stable now, and plan to ramp up to 100% over the next few weeks (barring metrics regressions). On Friday, April 7, 2023 at 12:45:41 PM UTC-4 Mike Taylor wrote: > After re-reading the spec, explainer, related d

Re: [blink-dev] Intent to Ship: First-party sets

within the next week or so -- if all continues to go well). On Tuesday, May 30, 2023 at 8:57:20 AM UTC-4 Andrey Lipattsev wrote: > How far along is this now? Are we at 100%? > > On Wednesday, 17 May 2023 at 21:11:35 UTC+2 Chris Fredrickson wrote: > >> Thanks all. Just an updat

Re: [blink-dev] Intent to Ship: First-party sets

>> >> On Wednesday, May 31, 2023 at 4:02:25 PM UTC+2 Andrey Lipattsev wrote: >> >>> Sweet, thanks Chris! >>> >>> On Tuesday, 30 May 2023 at 16:36:34 UTC+2 Chris Fredrickson wrote: >>> >>>> Hi Andrey, >>>> >>&g

Re: [blink-dev] Intent to Ship: First-party sets

olling out more broadly. We will keep this thread updated with future changes - thanks. On Wednesday, June 21, 2023 at 5:15:51 PM UTC-4 Chris Fredrickson wrote: > Hugo: no, we are still examining metrics and evaluating. I will post to > this thread when I have updates. > >

[blink-dev] Intent to Experiment: FedCM as a trust signal for the Storage Access API

Contact emails johann...@chromium.org, cfred...@chromium.org, y...@chromium.org Explainer https://github.com/explainers-by-googlers/storage-access-for-fedcm Specification None (TBD) Summary Reconciles the FedCM and Storage Access APIs by making a prior FedCM grant a valid reason to automa

Re: [blink-dev] Intent to Experiment: FedCM as a trust signal for the Storage Access API

03 AM UTC-4 Mike Taylor wrote: > >> LGTM to experiment from 126 to 127 inclusive. >> On 5/7/24 10:52 AM, Chris Fredrickson wrote: >> >> Contact emails >> >> joha...@chromium.org, cfre...@chromium.org, yi...@chromium.org >> >> Explainer >> &g

Re: [blink-dev] Intent to Experiment: FedCM as a trust signal for the Storage Access API

, July 24, 2024 at 2:39:32 PM UTC-4 Mike Taylor wrote: > On 7/24/24 8:06 PM, Chris Fredrickson wrote: > > My apologies, I misunderstood the process here. I hereby formally request > an extension for this OT, through M129 :) > > Thanks, I formally LGTM the request to M129

Re: [blink-dev] Intent to Experiment: FedCM as a trust signal for the Storage Access API

elson wrote: > Hi Chris, > > Sounds like good progress, thanks. Could you also tell us the reasons you > need to continue experimenting? > > On Wed, Sep 11, 2024 at 6:43 AM Chris Fredrickson > wrote: > >> Hello again - we'd like to request another OT ex

Re: [blink-dev] Intent to Experiment: FedCM as a trust signal for the Storage Access API

t renewal), we wouldn't even need any extension approval for > the 5 milestones we ultimately expect the trial to run I believe. To what > extent do we think this should have a bearing on how API owners reason > about extensions? > > later, >> Mike >> >> [1]

[blink-dev] Ready for Trial: First-Party Sets

Contact emails kaustub...@google.com, johann...@google.com, cfred...@google.com Explainer https://github.com/WICG/first-party-sets Specification TBD. Summary First-Party Sets (FPS) is a web platform mechanism, proposed within the context of browser efforts to phase out support for third-par

Re: [blink-dev] Intent to Deprecate and Remove: Persistent Quota

any API not work anymore, rather we're slightly changing the >>>>>>>>>> behavior >>>>>>>>>> of some of the legacy methods. A hypothetical website that somehow >>>>>>>>>> relies >>>&

Re: [blink-dev] Intent to Deprecate and Remove: Persistent Quota

lt and let that change propagate through the channels. On Thursday, August 12, 2021 at 3:34:32 PM UTC-4 Alex Russell wrote: > Thanks for letting us know. Please ping back here when you want to revive > this intent. > > On Wednesday, August 11, 2021 at 2:25:20 PM UTC-7 Chris Fredrickson

Re: [blink-dev] Intent to Ship: FedCM as a trust signal for the Storage Access API

ad an Origin Trial. Did you get any results > you are able to share from the trial? > > On Thu, Oct 3, 2024 at 2:48 AM Chris Fredrickson > wrote: > >> Contact emails >> >> johann...@chromium.org, cfred...@chromium.org, y...@chromium.org >> >> Explain

[blink-dev] Intent to Ship: FedCM as a trust signal for the Storage Access API

Contact emails johann...@chromium.org, cfred...@chromium.org, y...@chromium.org Explainer https://github.com/explainers-by-googlers/storage-access-for-fedcm Specification https://github.com/privacycg/storage-access/pull/206 Summary Reconciles the FedCM and Storage Access APIs by making a pri

Re: [blink-dev] Intent to Ship: Storage Access Headers

Jan 3, 2025 at 4:58 PM Chris Fredrickson wrote: On Thursday, January 2, 2025 at 10:53:50 PM UTC-5 Yoav Weiss wrote: On Thu, Jan 2, 2025 at 7:36 PM Chris Fredrickson wrote: Contact emails sled...@google.com, johann...@chromium.org, cfred...@chromium.org Explainer https://github.com/pri

Re: [blink-dev] Intent to Ship: Storage Access Headers

eiss wrote: > > LGTM1 > > This seems like a reasonable optimization, and I like plans to optimize > this further. The immediate compat risk does indeed seem tiny. (but please > keep the flag around just in case) > > On Fri, Jan 3, 2025 at 4:58 PM Chris Fredrickson > w

Re: [blink-dev] Intent to Extend Experiment: Storage Access Headers

Following up on this - we'd like to amend this I2EE to request an extension for another *3* milestones, to M135, to give ourselves more buffer to resolve any issues. (We understand that a feature may run an origin trial for up to 6 milestones. The first release with this OT was M130.) We still

Re: [blink-dev] Intent to Ship: Storage Access Headers

On Thursday, January 2, 2025 at 10:53:50 PM UTC-5 Yoav Weiss wrote: On Thu, Jan 2, 2025 at 7:36 PM Chris Fredrickson wrote: Contact emails sled...@google.com, johann...@chromium.org, cfred...@chromium.org Explainer https://github.com/privacycg/storage-access-headers Do I understand

Re: [blink-dev] Intent to Ship: Storage Access Headers

v Weiss (@Shopify) wrote: >> >> >> >> On Tue, Jan 7, 2025 at 10:31 PM Chris Fredrickson >> wrote: >> >>> Minor updates: >>> >>> Mike Taylor previously noted >>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/5-SQmyp

[blink-dev] Intent to Ship: Storage Access Headers

Contact emails sled...@google.com, johann...@chromium.org, cfred...@chromium.org Explainer https://github.com/privacycg/storage-access-headers Specification https://privacycg.github.io/storage-access-headers Summary Storage Access Headers offer an alternate way for authenticated embeds to o

[blink-dev] Re: I2P&S: Strict Same Origin Policy for Storage Access API

Mozilla standards position request: https://github.com/mozilla/standards-positions/issues/1200 WebKit standards position request: https://github.com/WebKit/standards-positions/issues/476 On Wednesday, March 19, 2025 at 4:40:17 PM UTC-4 Chris Fredrickson wrote: > Sorry for the delay, for s

[blink-dev] Re: I2P&S: Strict Same Origin Policy for Storage Access API

Do you have a sense for what fraction of Storage Access API use (yes, I >> know it's low) will be impacted by this change? Is there a way to tell? >> >> Best, >> >> Alex >> >> On Wednesday, March 12, 2025 at 9:04:37 AM UTC-7 Chris Fredrickson wro

[blink-dev] I2P&S: Strict Same Origin Policy for Storage Access API

Contact emails cfred...@chromium.org Explainer None Specification https://github.com/privacycg/storage-access/pull/213 Summary Adjusts the Storage Access API semantics to strictly follow the Same Origin Policy, w.r.t. security. I.e., using document.requestStorageAccess() in a frame only at

[blink-dev] Re: I2P&S: Strict Same Origin Policy for Storage Access API

known-affected sites (or adding > UKM to detect them), to finch'd rollout. We'd like to understand if any of > these make sense for this case to reduce the risk profile here. > > WDYT? > > Best, > > Alex > > On Friday, March 21, 2025 at 12:39:14 PM UTC-7 Chr

[blink-dev] Re: I2P&S: Strict Same Origin Policy for Storage Access API

:37 PM UTC-4 Chris Fredrickson wrote: > Thanks Alex (and Vlad), those concerns make sense. > > Re: next steps, I've improved <https://crrev.com/c/6373548> the existing > UMA, but more importantly, I added <https://crrev.com/c/6397807> a > UKM-based UseCounter th

Re: [blink-dev] Intent to Experiment: FedCM as a trust signal for the Storage Access API

FYI, we're going to extend this OT another 2 milestones, to 129 inclusive. (Existing OT tokens will still work, they won't expire IIUC.) On Tuesday, May 7, 2024 at 11:02:03 AM UTC-4 Mike Taylor wrote: > LGTM to experiment from 126 to 127 inclusive. > On 5/7/24 10:52 AM, Chris F