I just raised https://github.com/WICG/trust-token-api/issues/240 based on this. I had missed that you were planning to register issuers. See the issue for more.
On Thu, Apr 27, 2023 at 6:31 AM Steven Valdez <[email protected]> wrote: > 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/CAPLxc%3DUaVmhRzdfW4qhVz6Bbrg8Ws_zoTk2X3gM1Zu%2BVihaPNw%40mail.gmail.com.
