Yup i have been following - https://github.com/privacycg/storage-access/issues/102 closely and it does make my use cases to work seamlessly. Hopefully we get more traction on this topic and the same solution (RSA) works for shared worker and other type of storages too.
there are the related issues i have cut to follow up on this topic - https://github.com/privacycg/storage-access/issues/175, https://github.com/cfredric/chrome-storage-access-api/issues/3, and https://github.com/WICG/first-party-sets/issues/161 and https://issuetracker.google.com/issues/288303220?pli=1 On Monday, July 24, 2023 at 11:47:44 AM UTC-7 wande...@chromium.org wrote: > 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 <kyras...@google.com> 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 <jaga...@gmail.com> 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 kyras...@google.com 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 <jaga...@gmail.com> >>>> 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 mk...@chromium.org >>>>> wrote: >>>>> >>>>>> LGTM3 with all the caveats about careful rollout discussed above. >>>>>> >>>>>> -mike >>>>>> >>>>>> >>>>>> On Tue, May 30, 2023 at 5:39 PM Mike Taylor <mike...@chromium.org> >>>>>> 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 <rby...@chromium.org> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Apr 26, 2023 at 2:02 PM Mike Taylor <mike...@chromium.org> >>>>>>>> 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 blink-dev+...@chromium.org. >>>>>>> >>>>>> 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 blink-dev+...@chromium.org. >>>>> >>>> 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 | kyras...@google.com | >>>> 859-537-9917 <(859)%20537-9917> >>>> >>> >> >> -- >> >> Kyra Seevers (she/her) | Software Engineer | kyras...@google.com | >> 859-537-9917 <(859)%20537-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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ee89ae6e-485b-4470-92dd-9b4bff081d20n%40chromium.org.
