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).
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.
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.
