LGTM2

On Thu, Jul 6, 2023, 11:54 AM Rick Byers <[email protected]> wrote:

> Protected audiences seems like one of the most powerful and complex
> features ever added to Chromium, and I'll admit I've struggled to
> understand it at enough depth to do a decent API owner review. I carved out
> a few more hours this morning and am now comfortable giving my LGTM1 to
> ship. My reasoning is below for those few interested.
>
> I'm impressed and inspired by the scope of investment here across the
> whole online advertising industry. Just seeing the level of investment and
> breadth of proposals that have been explored over the past 3.5 years makes
> it clear there's an important problem to be solved here. I don't feel
> qualified (not sure anyone really is) to predict whether putting such a
> critical piece of the adtech architecture into browsers will ultimately
> succeed and prove to be good for the web or not. But it does seem like we
> have to try and find out. The most obvious competing path is for ad-funded
> content to rely on either covert tracking or login walls, both of which
> will be an arms race which will be hard to win without some viable
> alternatives like protected audiences and topics. I'm particularly
> concerned with login walls being strictly worse for privacy and information
> discovery (eg. risks content being indexable only between large publishers
> and search engines via business deals). Given that the only other plausible
> alternative for Chrome is to preserve the status quo of third-party
> cookies, I personally see this as a step forward in giving users more
> choice, transparency and control over advertising and their privacy.
> Critically, shipping this now creates a path by which the
> targeted advertising tradeoff space is likely to continue to be improved
> over time.
>
> From an interop risk perspective, despite the lack of official signals,
> given the feedback we've seen from other implementers on features like
> topics, I think it's safe to assume there won't be support from other
> engines anytime soon. I'd be interested to hear what other chromium
> embedders think, but that's not technically part of our interop risk
> signals and I imagine we'll see soon enough what other chromium browsers do
> with the privacy sandbox APIs. Still, IMHO we should be open to ideas for
> things we could do to make it easier for other chromium browsers to adopt
> (or fully disable) this API. It seems clear to me that tons of work has
> gone into puting the API on a plausible path to interoperability, but it's
> also clear it's a huge effort with work still to do. Thank you Dominic,
> Paul and team for your investments here and keeping it up, guided by the
> engagement and feedback you're getting. Now that the compat-impacting spec
> issues have been resolved or have a clear plan to resolve, I'm comfortable
> saying that the minimum spec/test bar for a major new feature to chip in
> chromium has been met.
>
> I am somewhat concerned about the long-term implications on web
> performance (given the isolation requirements) but was heartened by the
> work that has gone into setting quotas and limits and exploration of
> alternate computing models like "bidding and auction services". I feel
> confident that we have lots of options (many more than with 3PCs today) for
> adjusting the tradeoff space in the future if performance proves to be a
> real problem in practice.
>
> Overall, given the ambition of what is being attempted here (and our
> options for course correcting or even backtracking if needed), it seems to
> me the feature has reached a level of maturity that it's time to ship a V1
> while continuing to iterate on the spec and larger open industry debate.
>
> Rick
>
>
> On Fri, Jun 30, 2023 at 5:50 PM Paul Jensen <[email protected]>
> wrote:
>
>>
>>
>> On Fri, Jun 30, 2023 at 5:03 PM Mike Taylor <[email protected]>
>> wrote:
>>
>>> On 7/1/23 3:09 AM, Paul Jensen wrote:
>>>
>>>
>>> On Wed, Jun 28, 2023 at 5:33 AM Yoav Weiss <[email protected]>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Jun 27, 2023 at 9:54 PM Paul Jensen <[email protected]>
>>>> wrote:
>>>>
>>>>> Yoav,
>>>>>
>>>>> Protected Audiences has been fortunate to have a ton of design
>>>>> contributions and feedback, but consequently has a lot of issues filed.  
>>>>> We
>>>>> try to respond to all issues, as you can see by the discussion comments on
>>>>> nearly all issues.  I went through and triaged all the issues recently.  I
>>>>> closed many of them, created some labels and labeled many of them.  Here’s
>>>>> where I think the open issues stand:
>>>>>
>>>>>    -
>>>>>
>>>>>    65
>>>>>    
>>>>> <https://github.com/WICG/turtledove/labels/Non-breaking%20Feature%20Request>
>>>>>    I labeled “Non-breaking Feature Request”, meaning they’re requesting 
>>>>> new
>>>>>    functionality that is unlikely to cause backwards compatibility issues.
>>>>>    -
>>>>>
>>>>>    29 <https://github.com/WICG/turtledove/labels/spec> are spec
>>>>>    related.  As Dominic said above, most of these changes are unlikely to
>>>>>    break web content.
>>>>>    -
>>>>>
>>>>>    8
>>>>>    <https://github.com/WICG/turtledove/labels/Looking%20for%20feedback>
>>>>>    are seeking feedback rather than pointing to a problem.
>>>>>    -
>>>>>
>>>>>    4 <https://github.com/WICG/turtledove/labels/compat%20concern>
>>>>>    could potentially break compatibility.  I think for all of these we’ve
>>>>>    decided to not adopt the proposed changes or we’ve decided to adopt the
>>>>>    proposed changes but as part of our longer-term plans in the future.  I
>>>>>    should note that recently we adopted many breaking changes to our API, 
>>>>> but
>>>>>    did so in a way that supports backwards compatibility, so we can wean
>>>>>    developers off of the old APIs without causing immediate significant
>>>>>    breakage.  If we chose to adopt some of these changes, I imagine we 
>>>>> could
>>>>>    do so in a similar non-breaking way.
>>>>>    -
>>>>>
>>>>>    86
>>>>>    
>>>>> <https://github.com/WICG/turtledove/issues?q=is%3Aopen+-label%3A%22Non-breaking+Feature+Request%22++-label%3Aspec+-label%3A%22Looking+for+feedback%22+-label%3A%22compat+concern%22>
>>>>>    didn’t fit well into a particular category:
>>>>>    -
>>>>>
>>>>>       Some were questions seeking to clarify details of our timeline
>>>>>       or the explainer or design.
>>>>>       -
>>>>>
>>>>>       Some were discussions that are mostly addressed but left open
>>>>>       so we don’t forget about remaining pieces.
>>>>>       -
>>>>>
>>>>>       Some are open discussions or examples.
>>>>>
>>>>> I think it’s worth noting that our usage of the issue system differs
>>>>> from those of many other folks who ship features:  We tend to use the
>>>>> issues as open forums as opposed to only leaving open issues that need to
>>>>> have decisions made.  Many of the issues predate the FLEDGE explainer and
>>>>> represent design discussions that culminated in FLEDGE’s design.
>>>>>
>>>>
>>>> Thanks for going over the issues!! To be clear, the number of issues is
>>>> not a concern in itself, and is indeed an indication of the level of
>>>> engagement this had.
>>>> This list of compat-related issues
>>>> <https://github.com/WICG/turtledove/labels/compat%20concern> is the
>>>> only relevant bit for this intent IMO. At the same time, it'd be good to
>>>> settle these issues, or at least have a clear path towards future-compat
>>>> around them, before shipping. WDYT?
>>>>
>>>
>>> I think we’ve settled on paths to addressing each of the compat issues:
>>>
>>> #444 <https://github.com/WICG/turtledove/issues/444> and #586
>>> <https://github.com/WICG/turtledove/issues/586> I think we’ve settled
>>> on not pursuing for reasons expressed in the issues.
>>>
>>> #522 <https://github.com/WICG/turtledove/issues/522> has been our long
>>> term plan but we've heard feedback that it blocks adoption and usability at
>>> this stage, especially in the long-tail of advertisers.  Providing a
>>> solution to audience stealing is an important goal of Protected Audience.
>>> Our current implementation offers opt-in protection via our
>>> Permission-Policy, and we're going to continue to look for an ergonomic
>>> solution that facilitates adoption sufficiently to offer the protection by
>>> default.
>>> #554 <https://github.com/WICG/turtledove/issues/554> is something we
>>> might do, and could do in the future while offering a temporary
>>> backward-compatible period.  It doesn’t have significant developer
>>> benefits, other than making it potentially more web-like, so I’m reluctant
>>> to adopt it.
>>>
>>> Thanks Paul. Could you close out 586 and leave comments on 522 and 554
>>> with your current thinking?
>>>
>> Done.
>>
>>>
>>> Re: 554, do you have plans to update the spec to match Chromium's
>>> implementation of setBid(), setPriority(), and setPrioritySignalsOverride()?
>>>
>> Yes, I think this makes sense, I noted this in #554.  We will make this
>> change soon.
>>
>>> Or do something else?
>>>
>>>
>>>>
>>>>> I hope the labels I added make it clearer which are future
>>>>> enhancements and not likely to break backwards compatibility.  I honestly
>>>>> think over the years before our Origin Trial and over the course of our
>>>>> lengthy Origin Trial we’ve addressed all the feedback for core
>>>>> functionality in Protected Audience and don’t anticipate breaking 
>>>>> backwards
>>>>> compatibility in significant ways.
>>>>>
>>>>> On Thu, Jun 22, 2023 at 3:56 AM Yoav Weiss <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Glancing at the open issues, I see 291 of them
>>>>>> <https://github.com/WICG/turtledove/issues?page=2&q=is%3Aopen>..
>>>>>> Would it be possible to go over the issues and label them so that it's
>>>>>> clearer which are about future enhancements, which are editorial and 
>>>>>> which
>>>>>> may have an impact on the processing model or API shape in ways that can
>>>>>> impact future compatibility?
>>>>>>
>>>>>> On Wed, Jun 21, 2023 at 8:00 PM Dominic Farolino <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> As the spec mentor for this feature I'll offer a spec maturity
>>>>>>> summary
>>>>>>> <https://www.chromium.org/blink/launching-features/#:~:text=If%20your%20specification%20isn%27t%20a%20modification%20of%20an%20existing%20specification%2C%20include%20a%20one%2Dline%20spec%20maturity%20summary%20from%20someone%20outside%20your%20team%20(like%20your%20spec%20mentor)%20who%20has%20done%20a%20review.>.
>>>>>>> @Jeffrey Yasskin <[email protected]> and I reviewed the spec in
>>>>>>> detail recently and were pleased with the improvements that the team 
>>>>>>> worked
>>>>>>> with us to make recently, especially with regards to:
>>>>>>>
>>>>>>>    -
>>>>>>>
>>>>>>>    Formalizing the interaction with times and dates
>>>>>>>    -
>>>>>>>
>>>>>>>    Adding rigor to the in parallel work (and its interaction with
>>>>>>>    the main thread and the Script Runner realms)
>>>>>>>    -
>>>>>>>
>>>>>>>    Fetch integration
>>>>>>>    -
>>>>>>>
>>>>>>>    Specifying the conversions from internal spec data to JS objects
>>>>>>>    when calling into the Script Runners
>>>>>>>    <https://wicg.github.io/turtledove/#script-runners>, mostly by
>>>>>>>    increasing the use of WebIDL
>>>>>>>
>>>>>>> In a few of these points there is still work to be done, and we've
>>>>>>> been filing bugs <https://github.com/WICG/turtledove/labels/spec>
>>>>>>> against the specification for individual tasks that the team has 
>>>>>>> committed
>>>>>>> to making progress on in the very near future. The spec overall is not
>>>>>>> yet very readable <https://github.com/WICG/turtledove/issues/646>,
>>>>>>> which means external reviewers will have to spend time to understand the
>>>>>>> flow before they can give substantive feedback. From a completeness
>>>>>>> perspective, the spec still has over a dozen "TODOs" (I expect that 
>>>>>>> they’ll
>>>>>>> be finished soon given how many have recently closed), including the 
>>>>>>> bulk
>>>>>>> of the integration with Fenced Frames
>>>>>>> <https://github.com/WICG/turtledove/pull/616>, whose completion
>>>>>>> might help other browser engines notice new interoperability issues. The
>>>>>>> team is completing these at a good pace, but this implies that in 
>>>>>>> addition
>>>>>>> to finishing pieces of the spec that document the current 
>>>>>>> implementation,
>>>>>>> there will probably be minor web-visible changes after shipping in M115.
>>>>>>> However, most of these changes are unlikely to break web content, and if
>>>>>>> anything bigger comes up, the Privacy Sandbox's general tools for 
>>>>>>> migrating
>>>>>>> their users should be effective.
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jun 20, 2023 at 4:06 PM Paul Jensen <[email protected]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> *Contact emails*
>>>>>>>>
>>>>>>>> [email protected], [email protected], [email protected]
>>>>>>>>
>>>>>>>> Explainer
>>>>>>>>
>>>>>>>> https://github.com/WICG/turtledove/blob/master/FLEDGE.m
>>>>>>>> <https://github.com/WICG/turtledove/blob/master/FLEDGE.md>d
>>>>>>>>
>>>>>>>> Specification
>>>>>>>>
>>>>>>>> https://wicg.github.io/turtledove
>>>>>>>>
>>>>>>>> Summary
>>>>>>>>
>>>>>>>> The Protected Audience API (formerly known as FLEDGE) provides a
>>>>>>>> method of interest-group advertising without having to track individual
>>>>>>>> users’ detailed browsing history as is done today with third-party 
>>>>>>>> cookies.
>>>>>>>> Additional advantages over cookies include time limits on group 
>>>>>>>> membership,
>>>>>>>> better user controls, and more user transparency.
>>>>>>>>
>>>>>>>> Blink component
>>>>>>>>
>>>>>>>> Blink>InterestGroups
>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3EInterestGroups&can=2>
>>>>>>>>
>>>>>>>> TAG review
>>>>>>>>
>>>>>>>> https://github.com/w3ctag/design-reviews/issues/723
>>>>>>>>
>>>>>>>> TAG review status
>>>>>>>>
>>>>>>>> Pending since March 2022
>>>>>>>>
>>>>>>>> Risks
>>>>>>>> Compatibility
>>>>>>>>
>>>>>>>> This is not a breaking change. To use it, sites will need to call
>>>>>>>> the Protected Audience API. There is no change to existing behavior for
>>>>>>>> sites not calling the API. It’s worth noting that the spec uses WebIDL 
>>>>>>>> to
>>>>>>>> describe the script runners
>>>>>>>> <https://wicg.github.io/turtledove/#script-runners> but the
>>>>>>>> implementation does not. There may be minor compat issues as we align 
>>>>>>>> the
>>>>>>>> implementation with the WebIDL semantics over time.
>>>>>>>>
>>>>>>>> Interoperability
>>>>>>>>
>>>>>>>> Gecko: No signal, requested March 2023
>>>>>>>> <https://github.com/mozilla/standards-positions/issues/770>
>>>>>>>>
>>>>>>>> WebKit: No signal, requested March 2023
>>>>>>>> <https://github.com/WebKit/standards-positions/issues/158>
>>>>>>>>
>>>>>>>> Edge: Edge explored interest group based advertising, namely with the
>>>>>>>> PARAKEET proposal
>>>>>>>> <https://github.com/WICG/privacy-preserving-ads/blob/main/Parakeet.md>.
>>>>>>>> PARAKEET shares much of its API with Protected Audience but as
>>>>>>>> discussed in TPAC 2022
>>>>>>>> <https://docs.google.com/presentation/d/1QQgrm4oaRRRBr1gfvKj7D8rS2EW8kRgRUHPscvR8BNo/edit#slide=id.g15545e7b627_0_173>,
>>>>>>>> involves proxying data to non-trusted servers in real-time whereas
>>>>>>>> Protected Audience does not have long term plans to do this.
>>>>>>>>
>>>>>>>> Web developers: Significant interest from many web developers.  
>>>>>>>> Significant
>>>>>>>> Origin Trial participation
>>>>>>>> <https://github.com/WICG/turtledove/blob/main/fledge-tester-list.md>.
>>>>>>>>  WICG FLEDGE calls <https://github.com/WICG/turtledove/issues/88>
>>>>>>>> are heavily attended.  Interest in Protected Audience is further 
>>>>>>>> evidenced
>>>>>>>> by the many related discussions and proposals that Protected
>>>>>>>> Audience’s design draws from, most notably:
>>>>>>>>
>>>>>>>>    -
>>>>>>>>
>>>>>>>>    The original TURTLEDOVE
>>>>>>>>    
>>>>>>>> <https://github.com/WICG/turtledove/blob/main/Original-TURTLEDOVE.md>
>>>>>>>>    from Chrome.
>>>>>>>>    -
>>>>>>>>
>>>>>>>>    SPARROW <https://github.com/WICG/sparrow> from Criteo.
>>>>>>>>    -
>>>>>>>>
>>>>>>>>    Outcome-based TURTLEDOVE
>>>>>>>>    <https://github.com/WICG/turtledove/blob/main/OUTCOME_BASED.md>
>>>>>>>>    and Product-level TURTLEDOVE
>>>>>>>>    <https://github.com/WICG/turtledove/blob/main/PRODUCT_LEVEL.md>
>>>>>>>>    from RTB House.
>>>>>>>>    -
>>>>>>>>
>>>>>>>>    Dovekey
>>>>>>>>    
>>>>>>>> <https://github.com/google/ads-privacy/tree/master/proposals/dovekey>
>>>>>>>>    from Google Ads.
>>>>>>>>    -
>>>>>>>>
>>>>>>>>    PARRROT
>>>>>>>>    
>>>>>>>> <https://github.com/prebid/identity-gatekeeper/blob/master/proposals/PARRROT.md>
>>>>>>>>    from Magnite.
>>>>>>>>    -
>>>>>>>>
>>>>>>>>    TERN <https://github.com/WICG/turtledove/blob/main/TERN.md>
>>>>>>>>    from NextRoll.
>>>>>>>>
>>>>>>>>
>>>>>>>> Demo link
>>>>>>>> https://developer.chrome.com/docs/privacy-sandbox/fledge-api/#demo
>>>>>>>> Debuggability
>>>>>>>>
>>>>>>>> To learn more about debugging Protected Audience in Chrome please
>>>>>>>> follow these links:
>>>>>>>> https://developer.chrome.com/blog/fledge-api/#debugging
>>>>>>>> https://developer.chrome.com/blog/fledge-api/#observe-fledge-events
>>>>>>>>
>>>>>>>> Will this feature be supported on all six Blink platforms (Windows,
>>>>>>>> Mac, Linux, Chrome OS, Android, and Android WebView)?
>>>>>>>>
>>>>>>>> All except WebView
>>>>>>>>
>>>>>>>> Is this feature fully tested by web-platform-tests
>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>>>>>> ?
>>>>>>>>
>>>>>>>> We've tested all of the primary functionality in WPT. This API has
>>>>>>>> a lot of surface area and so we're continuing to add platform tests 
>>>>>>>> over
>>>>>>>> time.
>>>>>>>>
>>>>>>>> https://wpt.fyi/results/?q=fledge
>>>>>>>>
>>>>>>>> Flag name
>>>>>>>>
>>>>>>>>
>>>>>>>> InterestGroupStorage,AdInterestGroupAPI,Fledge,AllowURNsInIframes,BiddingAndScoringDebugReportingAPI
>>>>>>>>
>>>>>>>> Requires code in //chrome?
>>>>>>>>
>>>>>>>> Yes, for settings UI controls and k-anonymity server communication.
>>>>>>>>
>>>>>>>> Estimated milestones
>>>>>>>>
>>>>>>>> Has been in Origin Trial since M101.  We intend to start an
>>>>>>>> incremental ramp to 100% in Stable with Chrome Release M115.
>>>>>>>>
>>>>>>>> Anticipated spec changes
>>>>>>>>
>>>>>>>>    -
>>>>>>>>
>>>>>>>>    We’re addressing some remaining TODOs and specifying some
>>>>>>>>    recently added non-breaking features (e.g. #304
>>>>>>>>    <https://github.com/WICG/turtledove/issues/304>, #305
>>>>>>>>    <https://github.com/WICG/turtledove/issues/305>, #310
>>>>>>>>    <https://github.com/WICG/turtledove/issues/310>, #166
>>>>>>>>    <https://github.com/WICG/turtledove/issues/166>).
>>>>>>>>    -
>>>>>>>>
>>>>>>>>    Moving beyond our core use cases, we anticipate the need to
>>>>>>>>    support new functionality going forward.  We don’t currently 
>>>>>>>> anticipate
>>>>>>>>    changes that would break backwards compatibility.
>>>>>>>>    -
>>>>>>>>
>>>>>>>>    Support for Bidding and Auction services
>>>>>>>>    
>>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/bGd_nPuUrUg/m/j39WQ7e2AwAJ>
>>>>>>>>    is in progress.  This is a non-breaking additional feature.
>>>>>>>>
>>>>>>>>
>>>>>>>> Link to entry on the Chrome Platform Status
>>>>>>>>
>>>>>>>> https://chromestatus.com/feature/5733583115255808
>>>>>>>>
>>>>>>>> Links to previous Intent discussions
>>>>>>>>
>>>>>>>> Intent to Prototype:
>>>>>>>>
>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/w9hm8eQCmNI
>>>>>>>>
>>>>>>>> Intent to Experiment:
>>>>>>>>
>>>>>>>>
>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/0VmMSsDWsFg/m/_0T5qleqCgAJ
>>>>>>>>
>>>>>>>> Intent to Extend Origin Trial:
>>>>>>>>
>>>>>>>>
>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/SD8Ot2gpz4g/m/A9uA-_cGAwAJ
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/gpmaOi3of_w/m/SyMclFhMAAAJ
>>>>>>>>
>>>>>>>>
>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/CBrV-2DrYFI/m/RTojC6kHAgAJ
>>>>>>>> --
>>>>>>>> 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/CABQTWrn8eM3wOtUY3RzmDrt7SVxR_y_6Fo02bJ%2BF1bzbwpFfkQ%40mail.gmail.com
>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQTWrn8eM3wOtUY3RzmDrt7SVxR_y_6Fo02bJ%2BF1bzbwpFfkQ%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/CAP-uykDhn3EzgNacgnEExhiLwrdnc%2Bf7ZV6qMf%3DHk1ns1oHdTw%40mail.gmail.com
>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-uykDhn3EzgNacgnEExhiLwrdnc%2Bf7ZV6qMf%3DHk1ns1oHdTw%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/CABQTWr%3D1ROXvBN-k6trfMvLpnE74avuc4WtmyZRrAuOHdh0zNQ%40mail.gmail.com
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQTWr%3D1ROXvBN-k6trfMvLpnE74avuc4WtmyZRrAuOHdh0zNQ%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/CABQTWrmxni_nFb60tusUdO%3D1i3ixRUWC2J86qa24u6B5e0SFpw%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQTWrmxni_nFb60tusUdO%3D1i3ixRUWC2J86qa24u6B5e0SFpw%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/CAFUtAY-EK9ZUm%3DAk1LXxi3PLK7CArEZ1EGbeLMdXKuPQdsGsQg%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-EK9ZUm%3DAk1LXxi3PLK7CArEZ1EGbeLMdXKuPQdsGsQg%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/CAOMQ%2Bw8of4RwVy9_uM%3DDW3hJwshuUSKWWmK1HPLpfjMX%3DmArJA%40mail.gmail.com.

Reply via email to