Thanks for the feedback, I've replied on Github with the reasoning and to continue the conversation. There's definitely some spec work to make the registration behavior clearer.
-Steven On Wed, Apr 26, 2023 at 9:59 PM Martin Thomson <[email protected]> wrote: > 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 >> > -- 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/CANduzxAzfvzT7Bq7JhhuZ9fTcOVAxufvnOUN_tz%3D4_rD%3DebNgA%40mail.gmail.com.
