Thanks Chris and Rick for the clarifications. I'm happy to approve an
extension given that partners are actively experimenting.
LGTM to extend to M130 or 131 inclusive - whichever is more useful
(either way, you're still within the default 6 milestone limit for
experiments).
On 9/12/24 6:49 PM, Chris Fredrickson wrote:
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
<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
<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
<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
<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
<mailto: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
<mailto: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/44c40874-acaa-4204-beb9-19f44b681db7%40chromium.org.
