We've added this as a WIP document in the repository: https://github.com/WICG/trust-token-api/blob/main/REGISTRATION.md.
While the WICG repo won't be the final resting place for the policy/registration hopefully that works as an interim until we've got the final repo/policy published. On Wed, Apr 26, 2023 at 3:51 PM Rick Byers <[email protected]> wrote: > Thanks Steven, sorry I missed that. +1 to getting it on GitHub and links > updated. > > Rick > > On Wed, Apr 26, 2023 at 3:09 PM Mike Taylor <[email protected]> > wrote: > >> On 4/26/23 12:07 PM, Steven Valdez wrote: >> >> From higher in the thread: >> >> The WIP registration document is at >> https://docs.google.com/document/d/1oB_YdRMvQWWAsqXsvxMr4FJCngcSBj2rLJzW15l8a_A/edit?usp=sharing >> . >> >> We're planning on hosting it on a Github repo and using that as the >> source of truth for issuer registrations. >> >> We have a slightly chicken and egg problem where setting up the Github >> repo is reliant on the launch process for this feature. >> >> Even if the feature isn't shipping yet, having the docs/process on GitHub >> (even with a disclaimer as the first line that can be deleted as soon as >> you get approvals) seems like a better immediate outcome than having the >> info in a google doc which doesn't seem to be linked from >> https://github.com/WICG/trust-token-api, >> https://wicg.github.io/trust-token-api/, or >> https://developer.chrome.com/en/docs/privacy-sandbox/trust-tokens/. >> >> Would that be possible? >> >> -Steven >> >> On Wed, Apr 26, 2023 at 11:57 AM Rick Byers <[email protected]> wrote: >> >>> Hey folks, >>> Thanks for driving these improvements and taking Mozilla's feedback >>> seriously. This seems almost ready to ship a V1 to me, modulo >>> Yoav's last comment. >>> >>> Are there current docs somewhere for issuer registration? The >>> chromestatus entry points to this google doc >>> <https://docs.google.com/document/d/1cvUdAmcstH6khLL7OrLde4TnaPaMF1qPp3i-2XR46kU/edit#heading=h.4jz5ms3xrpq1> >>> that >>> says it's obsolete and will be updated. I went through the developer >>> docs >>> <https://developer.chrome.com/en/docs/privacy-sandbox/trust-tokens/>, >>> but couldn't find anything explaining how someone might act as an issuer. >>> >>> Thanks, >>> Rick >>> >>> On Tue, Apr 25, 2023 at 8:31 AM Yoav Weiss <[email protected]> >>> wrote: >>> >>>> Thanks Eric! >>>> >>>> A couple of issues Martin Thomson filed and I don't think were >>>> addressed are #232 <https://github.com/WICG/trust-token-api/issues/232> >>>> and #230 <https://github.com/WICG/trust-token-api/issues/230>. It'd be >>>> good to address them in some way. >>>> I also noticed that a bunch of issues were addressed, but not closed. >>>> It might make it easier to review if the settled discussions were marked as >>>> such :) >>>> >>>> >>>> On Fri, Apr 21, 2023 at 4:31 PM eric trouton <[email protected]> >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> We wanted to provide an update after reviewing Mozilla’s feedback and >>>>> a few rounds of good discussion in the threads. We are making several >>>>> small but significant changes based on the suggestions, after which we’d >>>>> like to launch Private State Tokens in order to support some anti-fraud >>>>> use >>>>> cases that are currently using 3rd party cookies, so developers don't turn >>>>> to fingerprinting as a replacement. This will also let us benefit from >>>>> additional feedback in the wild before making final decisions on some of >>>>> the other suggested changes. We believe we'll be able to migrate the >>>>> ecosystem to whichever option we settle on in the final standard (issue >>>>> #235 <https://github.com/WICG/trust-token-api/issues/235> explains >>>>> our rationale and approach for how we’re triaging the feedback and >>>>> managing >>>>> potential migrations). >>>>> >>>>> We have several specification improvements in flight, which will >>>>> hopefully address all of the spec concerns raised, and we plan to make the >>>>> following code changes: >>>>> >>>>> - >>>>> >>>>> Removal Private Metadata Bit from web API (we still intend to keep >>>>> the Chromium implementation around to support non-web-visible >>>>> features; but >>>>> it will no longer be available via the Private State Token API) until >>>>> the >>>>> crypto can be standardized. >>>>> - >>>>> >>>>> Update to the current VOPRF version. >>>>> - >>>>> >>>>> Add permissions policy for token issuance to match the existing >>>>> policy for token redemption. >>>>> - >>>>> >>>>> Remove 'type' from the API. >>>>> >>>>> >>>>> We are targeting these changes to land in M114. >>>>> >>>>> Thanks, >>>>> >>>>> Eric & PST team >>>>> >>>>> >>>>> On Wed, Apr 12, 2023 at 2:53 PM Mike Taylor <[email protected]> >>>>> wrote: >>>>> >>>>>> Whoops, that happened in >>>>>> https://github.com/w3ctag/design-reviews/issues/780#issuecomment-1422995031 >>>>>> - please ignore. :) >>>>>> On 4/12/23 2:37 PM, Mike Taylor wrote: >>>>>> >>>>>> One other comment, in >>>>>> https://github.com/w3ctag/design-reviews/issues/414#issuecomment-975743619 >>>>>> - the TAG requested that y'all ping the thread when the spec was more >>>>>> concrete (or open a new issue). Probably a good time to do so now. >>>>>> On 4/6/23 11:18 AM, Mike Taylor wrote: >>>>>> >>>>>> Thanks for the response, appreciated. >>>>>> On 4/6/23 10:02 AM, Steven Valdez wrote: >>>>>> >>>>>> Re: Supporting multiple crypto versions, there's no real utility >>>>>> beyond compatibility because particular UAs will only select one of the >>>>>> versions (based on their preferences), rather than trying to negotiate >>>>>> the >>>>>> crypto version. >>>>>> >>>>>> There's some discussion on standardizing to a RFC version of >>>>>> privacypass, however for the actual API surface, the PAT API is >>>>>> primarily triggered via HTTP-Authentication and they haven't seen a >>>>>> strong >>>>>> need for a JS API to trigger issuance, while for PST we see the other >>>>>> direction where the JS API is the primary way of triggering it (since its >>>>>> harder for origins to make server-side changes to their header/challenge >>>>>> via HTTP auth compared to adding new JS API calls). >>>>>> >>>>>> On Wed, Apr 5, 2023 at 6:33 PM Mike Taylor <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Thanks for linking to >>>>>>> https://github.com/WICG/trust-token-api/blob/main/PST_VS_PAT.md - >>>>>>> it's a really useful doc that I missed on my first read of this Intent. >>>>>>> >>>>>>> The API OWNERs (Yoav, Alex, Daniel, Philip, myself) were discussing >>>>>>> this intent today and had some questions that are partially answered by >>>>>>> the >>>>>>> PST_VS_PAT doc. Another question - have there been any discussions with >>>>>>> Apple on a possible convergence of these APIs? The doc hints at a future >>>>>>> unification to create a shared API surface for token >>>>>>> issuance/redemption. >>>>>>> On 4/5/23 10:03 AM, 'Steven Valdez' via blink-dev wrote: >>>>>>> >>>>>>> Private Access Tokens is roughly based on the Rate Limited >>>>>>> privacy pass specification ( >>>>>>> https://github.com/ietf-wg-privacypass/draft-ietf-privacypass-rate-limit-tokens/ >>>>>>> ). >>>>>>> >>>>>>> It is primarily triggered via HTTP-Authentication headers and >>>>>>> doesn't have a way of exposing that via a JS API. Developers are >>>>>>> expected >>>>>>> to have endpoints that provide HTTP-Authentication challenges that >>>>>>> trigger >>>>>>> the OS to issue/redeem tokens. >>>>>>> >>>>>>> There's a bit of a discussion of the similarities/differences >>>>>>> between the APIs at >>>>>>> https://github.com/WICG/trust-token-api/blob/main/PST_VS_PAT.md. >>>>>>> >>>>>>> There's some overlap between the use cases, but for the CAPTCHA use >>>>>>> case, while the platform-level signal is useful, anti-fraud providers >>>>>>> tend >>>>>>> to want to use additional signals to feed into their decision whether to >>>>>>> present something like a CAPTCHA, and being able to store the result of >>>>>>> their distillation of the decision in tokens they issue can be useful. >>>>>>> >>>>>>> On Wed, Apr 5, 2023 at 3:53 AM Yoav Weiss <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Mar 17, 2023 at 5:35 PM Steven Valdez <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Contact emails >>>>>>>>> >>>>>>>>> [email protected], [email protected], [email protected] >>>>>>>>> >>>>>>>>> Explainer >>>>>>>>> >>>>>>>>> https://github.com/WICG/trust-token-api >>>>>>>>> >>>>>>>>> NB: We'll rename the repository to private-state-token-api when >>>>>>>>> it's adopted by the antifraud CG. >>>>>>>>> >>>>>>>>> Specification >>>>>>>>> >>>>>>>>> https://wicg.github.io/trust-token-api >>>>>>>>> >>>>>>>>> Design docs >>>>>>>>> >>>>>>>>> >>>>>>>>> https://docs.google.com/document/d/1TNnya6B8pyomDK2F1R9CL3dY10OAmqWlnCxsWyOBDVQ/edit >>>>>>>>> >>>>>>>>> Summary >>>>>>>>> >>>>>>>>> The Private State Token API is a new API for propagating user >>>>>>>>> signals across sites, without using cross-site persistent identifiers >>>>>>>>> like >>>>>>>>> third party cookies for anti-fraud purposes. Anti-fraud methods that >>>>>>>>> rely >>>>>>>>> on third party cookies will not work once third party cookies are >>>>>>>>> deprecated. The motivation of this API is to provide a means to fight >>>>>>>>> fraud >>>>>>>>> in a world with no third party cookies. The API prevents cross-site >>>>>>>>> identification by limiting the amount of information stored in a >>>>>>>>> token. >>>>>>>>> Blind signatures prevent the issuer from linking a token redemption >>>>>>>>> to the >>>>>>>>> identity of the user in the issuance context. >>>>>>>>> >>>>>>>>> Private State Token API does not generate or define anti-fraud >>>>>>>>> signals. This is up to the corresponding first party and the token >>>>>>>>> issuers. >>>>>>>>> The API enforces limits on the information transferred in these >>>>>>>>> signals for >>>>>>>>> privacy concerns. Private State Token API is based on the Privacy >>>>>>>>> Pass protocol from the IETF working group >>>>>>>>> <https://datatracker.ietf.org/wg/privacypass/about/>. It can be >>>>>>>>> considered as a web-exposed form of the Privacy Pass protocols. >>>>>>>>> >>>>>>>>> The Private State Token API was formerly known as the Trust Token >>>>>>>>> API. It is renamed to more accurately reflect its functionality. >>>>>>>>> >>>>>>>>> Blink component >>>>>>>>> >>>>>>>>> Internals>Network>TrustTokens >>>>>>>>> >>>>>>>>> NB: As a part of the process of renaming the Trust Token API to >>>>>>>>> the Private State Token API, the blink component will also be renamed. >>>>>>>>> >>>>>>>>> >>>>>>>>> TAG review >>>>>>>>> >>>>>>>>> https://github.com/w3ctag/design-reviews/issues/414 >>>>>>>>> https://github.com/w3ctag/design-reviews/issues/780 >>>>>>>>> >>>>>>>>> TAG review status >>>>>>>>> >>>>>>>>> No concerns, aside from lack of clear interest from other browsers >>>>>>>>> >>>>>>>>> Risks >>>>>>>>> >>>>>>>>> Interoperability and Compatibility >>>>>>>>> >>>>>>>>> We intend to update the underlying cryptographic and token >>>>>>>>> issuance protocols to align with the eventual Privacy Pass standard. >>>>>>>>> This >>>>>>>>> will affect compatibility with the small number of token issuers. >>>>>>>>> Private >>>>>>>>> State Token API fetch requests include a token type and version >>>>>>>>> field that enables backward compatibility while allowing possible >>>>>>>>> extensions for future token types and versions. While we will >>>>>>>>> have a standard deprecation path of supporting multiple versions, we >>>>>>>>> expect >>>>>>>>> this to be easier with this API as each issuer using this API will >>>>>>>>> need to >>>>>>>>> register to become an issuer and will provide contact information as >>>>>>>>> part >>>>>>>>> of that process. >>>>>>>>> >>>>>>>>> >>>>>>>>> Gecko: Defer >>>>>>>>> <https://mozilla.github.io/standards-positions/#trust-token> >>>>>>>>> >>>>>>>>> WebKit: Pending ( >>>>>>>>> https://github.com/WebKit/standards-positions/issues/72), already >>>>>>>>> shipping similar technology >>>>>>>>> https://developer.apple.com/news/?id=huqjyh7k (see PST vs. PAT >>>>>>>>> <https://github.com/WICG/trust-token-api/blob/main/PST_VS_PAT.md> >>>>>>>>> for more information about the differences in the technologies). >>>>>>>>> >>>>>>>> >>>>>>>> Not on you, but do Private-Access-Tokens have something resembling >>>>>>>> a specification or an explainer, other than marketing material? >>>>>>>> Do I understand correctly that they are strictly based on >>>>>>>> protocol-level negotiation, without a JS API? How are developers >>>>>>>> supposed >>>>>>>> to interact with them? >>>>>>>> >>>>>>>> Is there overlap between the use-cases? (e.g. I would naively think >>>>>>>> that CAPTCHA avoidance can rely on either/both OS-level and anti-fraud >>>>>>>> provider attestation) >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Web developers: Positive >>>>>>>>> >>>>>>>>> A limited set of developers provided feedback on Private State >>>>>>>>> Tokens, indicating that the tool was valuable for anti-fraud >>>>>>>>> capabilities >>>>>>>>> while also acknowledging some utility challenges (1). Other >>>>>>>>> developers also >>>>>>>>> found that Private State Tokens provided ability for authentication >>>>>>>>> purposes (as illustrated by its use in the Privacy Sandbox k-Anonymity >>>>>>>>> Server) (2). >>>>>>>>> >>>>>>>>> 1: >>>>>>>>> https://github.com/antifraudcg/meetings/blob/main/2022/yahoo-trust-token.pdf >>>>>>>>> >>>>>>>>> 2: >>>>>>>>> https://github.com/WICG/turtledove/blob/main/FLEDGE_k_anonymity_server.md#abuse-and-invalid-traffic >>>>>>>>> >>>>>>>>> >>>>>>>>> Other signals: >>>>>>>>> >>>>>>>>> Ergonomics >>>>>>>>> >>>>>>>>> N/A >>>>>>>>> >>>>>>>>> >>>>>>>>> Activation >>>>>>>>> >>>>>>>>> Using this feature requires spinning up a (or partner with an >>>>>>>>> existing) Private State Token issuer that can issue and verify trust >>>>>>>>> tokens, which is non-trivial. Verifying properties of the Signed >>>>>>>>> Redemption >>>>>>>>> Record or the client signature requires additional cryptographic >>>>>>>>> operations. It would be beneficial to have server-side libraries that >>>>>>>>> developers can use to help make using this API easier. Sample code >>>>>>>>> can be >>>>>>>>> found at https://github.com/google/libtrusttoken. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Security >>>>>>>>> >>>>>>>>> N/A >>>>>>>>> >>>>>>>>> >>>>>>>>> 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? >>>>>>>>> >>>>>>>>> As this feature does not deprecate or change behavior of existing >>>>>>>>> APIs, we don't anticipate any risk to WebView-based applications. >>>>>>>>> >>>>>>>>> >>>>>>>>> Debuggability >>>>>>>>> >>>>>>>>> This API is debuggable via the DevTools Application Data panel and >>>>>>>>> the operations are exposed in the Network panel. >>>>>>>>> >>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>>>>>> >>>>>>>>> Yes >>>>>>>>> >>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>> ? >>>>>>>>> >>>>>>>>> Yes >>>>>>>>> <https://wpt.fyi/results/trust-tokens?label=experimental&label=master&aligned>*, >>>>>>>>> some of the tests are currently failing as renaming/API changes in >>>>>>>>> preparation for shipping these feature haven't propagated to those >>>>>>>>> tests >>>>>>>>> yet. Additionally, due to the requirements of having a server-side >>>>>>>>> issuer >>>>>>>>> (with bespoke crypto) to fully test the API, a majority of the >>>>>>>>> testing is >>>>>>>>> done in wpt_internal with a bespoke python implementation of a PST >>>>>>>>> issuer. >>>>>>>>> >>>>>>>>> Flag name >>>>>>>>> >>>>>>>>> TrustTokens (in the process of being renamed to PrivateStateTokens) >>>>>>>>> Requires code in //chrome? >>>>>>>>> >>>>>>>>> False >>>>>>>>> >>>>>>>>> Non-OSS dependencies >>>>>>>>> >>>>>>>>> Does the feature depend on any code or APIs outside the Chromium >>>>>>>>> open source repository and its open-source dependencies to function? >>>>>>>>> >>>>>>>>> Yes. Token operations are dependent on having the key commitment >>>>>>>>> information configured. Chrome (and Chromium implementations that >>>>>>>>> consume >>>>>>>>> components from component updater) supports this via a component, >>>>>>>>> other >>>>>>>>> clients will need to consume the component or come up with their own >>>>>>>>> method >>>>>>>>> of shipping the key commitment information to the client. >>>>>>>>> >>>>>>>>> Estimated milestones >>>>>>>>> >>>>>>>>> Chrome for desktop: 113 >>>>>>>>> >>>>>>>>> Chrome for Android: 113 >>>>>>>>> >>>>>>>>> Android Webview: 113 >>>>>>>>> >>>>>>>>> Anticipated spec changes >>>>>>>>> >>>>>>>>> Open questions about a feature may be a source of future web >>>>>>>>> compat or interop issues. Please list open issues (e.g. links to known >>>>>>>>> github issues in the project for the feature specification) whose >>>>>>>>> resolution may introduce web compat/interop risk (e.g., changing to >>>>>>>>> naming >>>>>>>>> or structure of the API in a non-backward-compatible way). >>>>>>>>> >>>>>>>>> The major feature changes we expect are likely to be around the >>>>>>>>> versions of tokens we support, as other use cases may need differing >>>>>>>>> properties from those provided with the initial API and other >>>>>>>>> format/API >>>>>>>>> changes to align better with standardization and interop (see the >>>>>>>>> Interoperability >>>>>>>>> and Combatibility section up above). Most potentially >>>>>>>>> web-observable changes in our open issues ( >>>>>>>>> https://github.com/WICG/trust-token-api/issues) are around >>>>>>>>> ergonomics of using the APIs and ways to use the API in more >>>>>>>>> locations/manners which should pose minimal compatibility risk to >>>>>>>>> existing >>>>>>>>> users of the API. >>>>>>>>> >>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>> >>>>>>>>> https://chromestatus.com/feature/5078049450098688 >>>>>>>>> >>>>>>>>> Links to previous Intent discussions >>>>>>>>> >>>>>>>>> Intent to prototype: >>>>>>>>> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/X9sF2uLe9rA >>>>>>>>> >>>>>>>>> Intent to experiment: >>>>>>>>> >>>>>>>>> >>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/UIvia1WwIhk/m/stu7iXTWBwAJ >>>>>>>>> >>>>>>>>> Intent to extend origin trial: >>>>>>>>> >>>>>>>>> >>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/fpfbKgJF8Vc/m/aC8HJfGdDwAJ >>>>>>>>> >>>>>>>>> >>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>> <https://chromestatus.com/>. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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 [email protected]. >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxCC8T5D9WSrvo0yq7Tu7hdAj-YXLwuOyu2DqqkTRoHQRg%40mail.gmail.com >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxCC8T5D9WSrvo0yq7Tu7hdAj-YXLwuOyu2DqqkTRoHQRg%40mail.gmail.com?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 [email protected]. >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUOedJX%2BHs1kHDRGByLPaTV23nDHUCxzbRqDz81hbO0Jw%40mail.gmail.com >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUOedJX%2BHs1kHDRGByLPaTV23nDHUCxzbRqDz81hbO0Jw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Steven Valdez | Chrome Privacy Sandbox | [email protected] | >>>>>>> Cambridge, >>>>>>> MA >>>>>>> -- >>>>>>> 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 [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxBRmxhQ4e_LTK_fDG7e9VKyNCe1EUOmmkkUXmDc02Md_A%40mail.gmail.com >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxBRmxhQ4e_LTK_fDG7e9VKyNCe1EUOmmkkUXmDc02Md_A%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Steven Valdez | Chrome Privacy Sandbox | [email protected] | >>>>>> Cambridge, >>>>>> MA >>>>>> >>>>>> -- >>>>>> 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 [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0c07740f-e250-772d-5c4b-a2726dc86e81%40chromium.org >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0c07740f-e250-772d-5c4b-a2726dc86e81%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 [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXEtEOujuvyMNjZNc5xZpGhxTadtnt1asO_CQJ3629M%3DA%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXEtEOujuvyMNjZNc5xZpGhxTadtnt1asO_CQJ3629M%3DA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> >> >> -- >> >> Steven Valdez | Chrome Privacy Sandbox | [email protected] | Cambridge, >> MA >> >> -- Steven Valdez | Chrome Privacy Sandbox | [email protected] | Cambridge, MA -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANduzxC46jOnFPCXchayA-DYfL4BtEiyL0ZA308WtUCRJSJUhw%40mail.gmail.com.
