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/CAFUtAY_KUrMQ-aXSF_OD%2B716mT7WJrrOSaY%3D5SJkRaspGAZB0A%40mail.gmail.com.
