Thanks for your response Mike; I do appreciate that OTs shouldn't be used as soft launches, and it's nice to hear that TAG reviews technically aren't blocking.
Rick, thanks for providing that context. You are absolutely correct; that partner is still running an experiment and may have feedback for us, so we'd like to not interrupt their study. (My earlier email was definitely incorrect, I was thinking too hard about things I need to do for the I2S.) Re: shipping, yes; we're preparing to ship a conservative behavior, but would still like to support the partner as they'recollecting metrics to evaluate that behavior. On Thursday, September 12, 2024 at 3:40:44 PM UTC-4 Rick Byers wrote: > On Wed, Sep 11, 2024 at 3:04 PM Mike Taylor <miketa...@chromium.org> > wrote: > >> Hey Chris, >> >> A few thoughts: >> >> We do not block shipping features if TAG is slow with their responses. >> But that said, I see the TAG review was requested just 20 hours ago - we do >> like to give them a reasonable amount of time to respond (this is usually >> on the order of a few weeks, maybe longer if there's an active dialog >> happening) before approving an I2S. If you were to send an I2S today, that >> would probably be the case[1]. >> >> We also don't like using OTs/experiments as "soft launches". The first >> two points of the "contract" that a site agrees to when registering for an >> OT are: >> >> 1. "I understand that this feature is experimental and may at any >> point become unavailable, and may never be enabled beyond this >> experiment, >> and even if Chrome decides to enable the feature after this trial, it >> will >> be unavailable for some time." >> 2. "I understand that this feature may change throughout the course >> of the trial." >> >> 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 until an I2S is sent and approved (in short >> order, it sounds like). >> > I'm involved with FedCM and have a different perspective in trying to > represent a partner's interests here so I'll recuse myself as an API owner > on this one. > > As I understand it, we have a major partner who is currently experimenting > with SAA autogrant with a small fraction of their traffic. They are > evaluating some properties of the design with that experiment which may > influence future versions of our design. While we are expecting to I2S > before they conclude their experiment, it would be harmful to their > experimentation if we caused a gap in it - causing a delay in their own > work for at least a month, or possibly even resetting their work more than > that. Does that all match your understanding Chris? When you said "It's not > exactly for experimentation", did you mean that we (Chrome / Privacy > Sandbox) are now confident in our design and are preparing to ship even > though we have a partner who is still experimenting themselves and not yet > ready to go to 100% of their traffic? > > Also note this OT was approved for 2 milestones and renewed once for 2. If > Chris had just requested the max of 6 milestones at the start (or max of 3 > for the first 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] FWIW, I've noticed that TAG has recently reduced their latency in >> responding to and engaging with reviews, which is great to see. >> On 9/11/24 12:54 PM, Chris Fredrickson wrote: >> >> It's not exactly for experimentation, technically. My understanding is >> that we need to have a verdict from the TAG review before we send an I2S, >> but I don't think it's realistic to expect one before M130 branch cut >> (9/16/23). (I also need to go through I2S pre-review and launch bug >> approval before I can actually enable this feature by default, which will >> take some time.) >> >> I'm trying to avoid creating a gap between the OT and when the feature >> ships in Chrome, since that would be a bad experience for OT participants. >> (I have seen the technical note about "gapless" OTs >> <https://www.chromium.org/blink/launching-features/#origin-trials>, but >> I'm not 100% clear on what that means, since it seems to imply that OT >> extension requests are irrelevant from a technical perspective.) >> >> On Wednesday, September 11, 2024 at 11:23:17 AM UTC-4 Chris Harrelson >> 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 <cfred...@chromium.org> >>> wrote: >>> >>>> Hello again - we'd like to request another OT extension, through M130 >>>> inclusive. As a demonstration of progress, we have: >>>> >>>> - Opened a spec PR >>>> <https://github.com/privacycg/storage-access/pull/206> >>>> - Requested formal position signals from Firefox >>>> <https://github.com/mozilla/standards-positions/issues/1065> and >>>> WebKit <https://github.com/WebKit/standards-positions/issues/390> >>>> - Written WPTs >>>> <https://github.com/web-platform-tests/wpt/pull/47728> >>>> - Requested TAG review >>>> <https://github.com/w3ctag/design-reviews/issues/992> >>>> >>>> >>>> On Wednesday, 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 inclusive. :) >>>>> >>>>> Re: the OT dashboard, I've already requested an OT extension through >>>>> the chromestatus entry; I believe the OT dashboard will be updated to >>>>> reflect that once the OT team approves that request. >>>>> >>>>> Great - I think the OT team typically chases down LGTMs - so you >>>>> should be set now. >>>>> >>>>> >>>>> Chris >>>>> >>>>> On Wednesday, July 24, 2024 at 1:52:53 PM UTC-4 Mike Taylor wrote: >>>>> >>>>>> Hey Chris, >>>>>> >>>>>> Per the process, you'll need to formally request an extension, rather >>>>>> than treat this as an FYI. >>>>>> >>>>>> (Also, I just double checked and >>>>>> https://developer.chrome.com/origintrials/#/register_trial/4008766618313162753 >>>>>> >>>>>> is only available until M127. Note there's a 2 month "grace period" >>>>>> where >>>>>> it will continue to work for users on 126 or 127 that haven't upgraded >>>>>> to >>>>>> M128 or higher - but it should not work in 128 or 129.) >>>>>> >>>>>> thanks, >>>>>> Mike >>>>>> On 7/24/24 4:03 PM, Chris Fredrickson wrote: >>>>>> >>>>>> 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 Fredrickson wrote: >>>>>>> >>>>>>> Contact emails >>>>>>> >>>>>>> joha...@chromium.org, cfre...@chromium.org, yi...@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 automatically approve a storage access request. >>>>>>> >>>>>>> When a user grants permission for using their identity with a 3rd >>>>>>> party Identity Provider (IdP) on a Relying Party (RP), many IdPs >>>>>>> require >>>>>>> third-party cookies to function correctly and securely. This proposal >>>>>>> aims >>>>>>> to satisfy that requirement in a private and secure manner by updating >>>>>>> the >>>>>>> Storage Access API (SAA) permission checks to not only accept the >>>>>>> permission grant that is given by a storage access prompt, but also the >>>>>>> permission grant that is given by a FedCM prompt. >>>>>>> >>>>>>> A key property of this mechanism is limiting the grant to cases >>>>>>> explicitly allowed by the RP via the FedCM permissions policy, >>>>>>> enforcing a >>>>>>> per-frame control for the RP and preventing passive surveillance by the >>>>>>> IdP >>>>>>> beyond the capabilities that FedCM already grants, as outlined in the >>>>>>> Privacy >>>>>>> Considerations >>>>>>> <https://github.com/explainers-by-googlers/storage-access-for-fedcm?tab=readme-ov-file#privacy-considerations> >>>>>>> . >>>>>>> >>>>>>> >>>>>>> Blink component >>>>>>> >>>>>>> Blink>StorageAccessAPI >>>>>>> >>>>>>> TAG review >>>>>>> >>>>>>> None >>>>>>> >>>>>>> TAG review status >>>>>>> >>>>>>> N/A >>>>>>> >>>>>>> Risks >>>>>>> >>>>>>> >>>>>>> Interoperability and Compatibility >>>>>>> >>>>>>> None >>>>>>> >>>>>>> >>>>>>> >>>>>>> Gecko: No public signals, positive initial signals >>>>>>> <https://docs.google.com/document/d/1jxqW4kvGdclIWsOlWMXWLGpwu1wOorST2Ol6vJKAjDE/edit#heading=h.y0ecc5cfr86n>. >>>>>>> >>>>>>> We will request a formal position. >>>>>>> >>>>>>> WebKit: No signal. We will request a formal position. >>>>>>> >>>>>>> Web developers: Positive >>>>>>> <https://github.com/fedidcg/FedCM/issues/467> >>>>>>> >>>>>>> Other signals: >>>>>>> >>>>>>> WebView application risks >>>>>>> >>>>>>> Does this intent deprecate or change behavior of existing APIs, such >>>>>>> that it has potentially high risk for Android WebView-based >>>>>>> applications? >>>>>>> >>>>>>> N/A, not shipping on Android WebView. >>>>>>> >>>>>>> Goals for experimentation >>>>>>> >>>>>>> Evaluate the implementation, and the usability of the feature to >>>>>>> ensure it adequately solves the problem. >>>>>>> >>>>>>> Ongoing technical constraints >>>>>>> >>>>>>> None >>>>>>> >>>>>>> Debuggability >>>>>>> >>>>>>> None >>>>>>> >>>>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>>>> Mac, Linux, ChromeOS, Android, and Android WebView)? >>>>>>> >>>>>>> No. It will not be supported in Android WebView. >>>>>>> >>>>>>> Is this feature fully tested by web-platform-tests? >>>>>>> >>>>>>> No. The implementation is primarily in permissions code in //chrome, >>>>>>> which cannot be tested in WPTs since WPTs use a fake permission >>>>>>> manager >>>>>>> <https://crsrc.org/c/content/web_test/browser/web_test_permission_manager.h;drc=33b441e83b1f70381158fcafb0ecde9168b79524;l=28> >>>>>>> >>>>>>> in Chromium. >>>>>>> >>>>>>> Flag name on chrome://flags >>>>>>> >>>>>>> #fedcm-with-storage-access-api >>>>>>> >>>>>>> Finch feature name >>>>>>> >>>>>>> FedCmWithStorageAccessAPI >>>>>>> >>>>>>> Non-finch justification >>>>>>> >>>>>>> None >>>>>>> >>>>>>> Requires code in //chrome? >>>>>>> >>>>>>> True >>>>>>> >>>>>>> Estimated milestones >>>>>>> >>>>>>> M126 through M127 (inclusive). >>>>>>> >>>>>>> >>>>>>> Link to entry on the Chrome Platform Status >>>>>>> >>>>>>> https://chromestatus.com/feature/5116478702747648 >>>>>>> >>>>>>> Links to previous Intent discussions >>>>>>> >>>>>>> Intent to prototype: >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4iogs7O60r0YcVnDB5aCvs9WUYjWFcuHqcFi5bXLRBOig%40mail.gmail.com >>>>>>> >>>>>>> This intent message was generated by Chrome Platform Status. >>>>>>> >>>>>>> -- >>>>>>> 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/9a75fe74-ca55-4ddc-93d7-120adfdee49en%40chromium.org >>>>>>> >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9a75fe74-ca55-4ddc-93d7-120adfdee49en%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+unsubscr...@chromium.org. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b4effd10-8b45-478a-8d73-ba0a766688efn%40chromium.org >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b4effd10-8b45-478a-8d73-ba0a766688efn%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+unsubscr...@chromium.org. >> > To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b229db03-df87-4751-9436-6f719f0c4789%40chromium.org >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b229db03-df87-4751-9436-6f719f0c4789%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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c45d39a8-d7a0-4b2d-8cd8-20a8aa8471f3n%40chromium.org.
