Jagadeesha, can you also take a look at the proposal in: https://github.com/privacycg/storage-access/issues/102
And comment there if you think that would help with your use case? On Mon, Jul 24, 2023 at 1:42 PM Kyra Seevers <[email protected]> wrote: > > Would this be the alternatives for the deprecation trial? > Yes, the enterprise policy `DefaultThirdPartyStoragePartitioningSetting` > is another method of achieving unpartitioned storage. It would require the > standard enterprise management setup: > https://chromium.googlesource.com/chromium/src/+/HEAD/docs/enterprise/policies.md > . > > > does the same expiry (*Chrome 127 on September 3, 2024)* is applicable > for these policies as well? > Yes, the deprecation trial and the enterprise policy have the same expiry > date (Chrome 127 on September 3, 2024). > > Thanks, > Kyra > > On Mon, Jul 24, 2023 at 1:18 PM Jagadeesha B Y <[email protected]> wrote: > >> Apologies if this is being addressed already. I see that chrome has >> enterprise policies for the same. >> https://chromeenterprise.google/policies/#DefaultThirdPartyStoragePartitioningSetting >> >> Would this be the alternatives for the deprecation trial? does the same >> expiry (*Chrome 127 on September 3, 2024)* is applicable for these >> policies as well? >> >> Context: I'm about to publish a recommendation for our customers on how >> to continue using our SAAS APP which relies on Shared worker and it would >> otherwise impact the critical call handling features. Unfortunately our >> customers doesn't have any choice except disabling it for now. so trying >> to evaluate the quickest options. >> >> On Monday, July 24, 2023 at 7:18:26 AM UTC-7 [email protected] wrote: >> >>> Hi there, >>> >>> Thank you for your email - as of today (Monday 7/24/23), the feature is >>> not rolled-out to stable. >>> >>> However, I can confirm that the rollout schedule for this feature begins >>> in M115 at Stable 1% (once M115 is served to 100% of users). M115 is >>> currently served to 12.5% of users - you can track the status at >>> https://chromiumdash.appspot.com/releases?platform=Windows. Two weeks >>> after that, we'll go to 10%, assuming no large stability or compatibility >>> regressions. Then 50 and 100% at additional 2 week increments. >>> >>> >>> In the meantime, we have a deprecation trial ( >>> https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/#participate-in-the-deprecation-trials) >>> running in M115+ that allows sites who opt-in to maintain unpartitioned >>> storage for a few milestones while they develop a >>> storage-partitioning-compatible solution. >>> >>> Thanks, >>> >>> Kyra >>> >>> On Sun, Jul 23, 2023 at 7:05 PM Jagadeesha B Y <[email protected]> >>> wrote: >>> >>>> >>>> I see that Chrome 115 release notes - >>>> https://chromestatus.com/feature/5723617717387264 mentioning about >>>> storage partition being enabled by default. Could someone confirm how >>>> gradual this rollout is? do we know if storage partition is rolled out >>>> fully? >>>> >>>> Our SASS product has a heavy reliance on Shared worker and this would >>>> break our customer use cases. We use shared worker to co-ordinate Web RTC >>>> signalling and websocket management which is critical for the app. >>>> On Wednesday, May 31, 2023 at 8:42:15 AM UTC-7 [email protected] >>>> wrote: >>>> >>>>> LGTM3 with all the caveats about careful rollout discussed above. >>>>> >>>>> -mike >>>>> >>>>> >>>>> On Tue, May 30, 2023 at 5:39 PM Mike Taylor <[email protected]> >>>>> wrote: >>>>> >>>>>> OK - let's consider this I2S officially revived. Looking for a 3rd >>>>>> LGTM to begin shipping in M115. >>>>>> >>>>>> We have implemented 3rd party deprecation trial support for M115+ >>>>>> (see >>>>>> https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/#participate-in-the-deprecation-trials), >>>>>> and extended the deprecation trial's expiration date accordingly to >>>>>> account >>>>>> for the delay. And we have the Enterprise policy ready to go. >>>>>> >>>>>> The rollout schedule will look something like the following, pending >>>>>> metrics and compatibility stability: >>>>>> >>>>>> July 25th: 1% of Stable population (approximately 1 week after M115 >>>>>> is released) >>>>>> Aug 8th: 10% >>>>>> Aug 22nd: 50% >>>>>> Sep 5: 100% >>>>>> >>>>>> As always, if we discover significant user-facing breakage we'll >>>>>> explore pausing or rolling back to address. >>>>>> >>>>>> thanks, >>>>>> Mike >>>>>> On 5/1/23 10:43 AM, Mike Taylor wrote: >>>>>> >>>>>> Thanks Rick and Yoav. >>>>>> >>>>>> We learned from two partners (one internal, one external) late last >>>>>> week that a 3P deprecation trial would be needed for them to preserve >>>>>> widely-used functionality while they work on a migration strategy. >>>>>> >>>>>> We're tracking the work in crbug.com/1441411 and hope to have that >>>>>> ready by M115. Once we land the fix, I'll circle back and look for a 3rd >>>>>> LGTM and have an updated rollout schedule. :) >>>>>> On 5/1/23 12:21 AM, Yoav Weiss wrote: >>>>>> >>>>>> LGTM2 >>>>>> >>>>>> On Thu, Apr 27, 2023, 16:23 Rick Byers <[email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Apr 26, 2023 at 2:02 PM Mike Taylor <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> On 4/26/23 9:36 AM, Mike Taylor wrote: >>>>>>>> >>>>>>>> > On 4/25/23 12:00 PM, Rick Byers wrote: >>>>>>>> > >>>>>>>> >> In terms of the standards / process piece, it looks as if the >>>>>>>> spec >>>>>>>> >> PRs have all stalled for several months. What do you think is >>>>>>>> >> necessary to get these unblocked and landed? As the last engine >>>>>>>> to >>>>>>>> >> implement this behavior, perhaps we shouldn't feel too compelled >>>>>>>> to >>>>>>>> >> block shipping on PRs landing? >>>>>>>> >>>>>>>> I was gently reminded offline that I didn't answer this part of >>>>>>>> your >>>>>>>> question - oops. >>>>>>>> >>>>>>>> Right now it seems to me that the costs of landing these spec PRs >>>>>>>> is >>>>>>>> higher than we're willing to block on, given the requested >>>>>>>> refactoring >>>>>>>> (and yes, it's unfortunate that 3 engines would be shipping >>>>>>>> essentially >>>>>>>> unspecced behavior, but that's where we're at). That said, I'm >>>>>>>> happy to >>>>>>>> devote my few IC hours to pushing these along as a personal project >>>>>>>> over >>>>>>>> the coming months. >>>>>>>> >>>>>>> >>>>>>> Thanks Mike. I trust your and wanderview@'s judgement here - I know >>>>>>> how hard y'all have been willing to work in the past to get the right >>>>>>> thing >>>>>>> done in specs. Thanks for being willing to keep pushing in parallel. But >>>>>>> given two other implementations have already shipped this, it was >>>>>>> clearly >>>>>>> already a spec bug that the spec didn't reflect reality. I agree that we >>>>>>> shouldn't block shipping a 3rd implementation on spec refactoring work. >>>>>>> >>>>>>> LGTM1 to ship from my perspective. Obviously this will need a very >>>>>>> thoughtful and careful roll-out. But I trust Mike and his team to engage >>>>>>> with impacted folks to make sure it goes smoothly, as they did with UA >>>>>>> reduction. >>>>>>> >>>>>> -- >>>>>> >>>>> 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 [email protected]. >>>>>> >>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bc52292b-9142-adad-d126-b93231468ed0%40chromium.org >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bc52292b-9142-adad-d126-b93231468ed0%40chromium.org?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>> 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 [email protected]. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0e6d131f-f6c7-4bbb-ad3e-bd68cd63ec0dn%40chromium.org >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0e6d131f-f6c7-4bbb-ad3e-bd68cd63ec0dn%40chromium.org?utm_medium=email&utm_source=footer> >>>> . >>>> >>> >>> >>> -- >>> >>> Kyra Seevers (she/her) | Software Engineer | [email protected] | >>> 859-537-9917 <(859)%20537-9917> >>> >> > > -- > > Kyra Seevers (she/her) | Software Engineer | [email protected] | > 859-537-9917 > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMi-sqGSW-aL9KYD5OwBqtOGSCTMn2DH0aEzEvVMH0j4ow%40mail.gmail.com.
