LGTM3 On Wed, Nov 6, 2024 at 11:05 AM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote:
> LGTM2 > > At the API owner meeting, Jeffrey explained to me that the issuers are > controlled by the top-level, so I'm comfortable with the model (and the > fact that ad providers won't fight for the 2 slots in ways that the site > owner can't control). > > On Wednesday, November 6, 2024 at 4:15:09 PM UTC+1 Yoav Weiss wrote: > >> How likely are we to get multiple 3Ps on the page with each using its own >> issuer? >> >> On Wednesday, November 6, 2024 at 1:19:49 AM UTC+1 Chris Harrelson wrote: >> >>> LGTM1 >>> >>> On Thu, Oct 31, 2024 at 8:59 AM Ari Chivukula <aric...@chromium.org> >>> wrote: >>> >>>> >>>>> - In case of the user denies giving consent to X vendors / tech >>>>> via the CMP (Consent Management Platform), will the token be shared >>>>> cross >>>>> site if a wildcard is set anyway? The question also works with the >>>>> Global >>>>> privacy control >>>>> >>>>> I think this is unrelated to the work here as that's a question about >>>> how any permissions policy would work with CMP/GPC, and not this specific >>>> change. >>>> >>>> >>>>> - Is there a way to prevent any adtech to redeem the token to >>>>> display an ads anywhere outside? (But I think this question is already >>>>> in >>>>> the blink discussion) >>>>> >>>>> I'm having trouble parsing the question, but if the question is >>>> whether adtech could redeem a token and then later take action based on >>>> past redemption the answer is yes as long as it's the same context storage >>>> wise (otherwise there wouldn't be a way to know a past redemption had >>>> occured). >>>> >>>> >>>>> - Not related but somehow related, if the token is considered >>>>> First party tracking (Potential risk noted in the spec >>>>> >>>>> <https://github.com/WICG/trust-token-api/blob/main/README.md#first-party-tracking-potential>) >>>>> then combined with the wildcard, you have a cross site tracking : How >>>>> to >>>>> prevent that? >>>>> >>>>> The first-party tracking potential you link to isn't about >>>> third-parties accessing data but first-parties reading the redemption >>>> records (this is only available in a top-level frame). The mitigation >>>> described in the explainer still applies as this change does not impact the >>>> availability of redemption records. >>>> >>>> ~ Ari Chivukula (Their/There/They're) >>>> >>>> >>>> On Thu, Oct 31, 2024 at 7:04 AM Alexandre Nderagakura < >>>> nderale...@gmail.com> wrote: >>>> >>>>> Trying to understand this discussion, the Issue 990 design revue in >>>>> w3ctag <https://github.com/w3ctag/design-reviews/issues/990> and the >>>>> privacy side (I put a comment in the Issue 306 >>>>> <https://github.com/WICG/trust-token-api/pull/306#issuecomment-2449585140> >>>>> but >>>>> perhaps talking is here is better) : >>>>> >>>>> - In case of the user denies giving consent to X vendors / tech >>>>> via the CMP (Consent Management Platform), will the token be shared >>>>> cross >>>>> site if a wildcard is set anyway? The question also works with the >>>>> Global >>>>> privacy control >>>>> - Is there a way to prevent any adtech to redeem the token to >>>>> display an ads anywhere outside? (But I think this question is already >>>>> in >>>>> the blink discussion) >>>>> - Not related but somehow related, if the token is considered >>>>> First party tracking (Potential risk noted in the spec >>>>> >>>>> <https://github.com/WICG/trust-token-api/blob/main/README.md#first-party-tracking-potential>) >>>>> then combined with the wildcard, you have a cross site tracking : How >>>>> to >>>>> prevent that? >>>>> >>>>> >>>>> On Wednesday, October 23, 2024 at 1:41:52 AM UTC+2 Jeffrey Yasskin >>>>> wrote: >>>>> >>>>>> This all makes sense to me. I don't personally have a good sense of >>>>>> the privacy implications of calling this, but that's a question for the >>>>>> privacy reviewers, not me. :) I'm torn on the question of when to make it >>>>>> easier for sites to pick their issuers. The overall TAG sense >>>>>> <https://github.com/w3ctag/design-reviews/issues/990> was that >>>>>> because this makes the risk worse, you should add the easier mitigation >>>>>> before shipping this change. But you have more experience with the >>>>>> particular users of this API, so it could be that you're right to want to >>>>>> wait for those users to complain. Is there a good issue for them to >>>>>> comment >>>>>> on if they run into this problem, so you can notice and fix it quickly? I >>>>>> think it'd be reasonable for the API owners to let this ship given a good >>>>>> way to catch if it breaks anything. >>>>>> >>>>>> The TAG also requested that you ask the Privacy WG to review the PST >>>>>> API <https://github.com/w3ctag/design-reviews/issues/990>, to get >>>>>> some non-Google validation that there aren't any privacy reasons to avoid >>>>>> loosening the permission policy. I wouldn't expect the API owners to >>>>>> insist >>>>>> that shipping wait for the Privacy WG. >>>>>> >>>>>> For the thread's information, I also got a request to help PSTs move >>>>>> into a WG, as the launch process requires we do >>>>>> <https://www.chromium.org/blink/launching-features/#new-feature-prepare-to-ship:~:text=If%20your%20specification%20is%20still%20in%20an%20incubation%20venue%20and%20not%20a%20working%20group%2C%20propose%20that%20the%20feature%20migrate%20to%20a%20working%20group.>, >>>>>> and we're figuring out what shape that should take. >>>>>> >>>>>> Jeffrey >>>>>> >>>>>> On Thu, Oct 3, 2024 at 11:37 AM Ari Chivukula <ari...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> Divided Jeffrey's email to separate questions verbatim (italic >>>>>>> font). Our responses are below the question (bold font). >>>>>>> >>>>>>> >>>>>>> 1. https://github.com/WICG/trust-token-api/issues/106 says that >>>>>>> adtech services want to redeem tokens without needing to get changes >>>>>>> made >>>>>>> on the top-level site. The request seems to say that it's the adtech >>>>>>> origin >>>>>>> that's directly called from the top-level site, but I think this change >>>>>>> would allow redemptions anywhere down the tree of ad-related frames? >>>>>>> >>>>>>> Yes, this change would allow redemptions anywhere down the tree of >>>>>>> frames regardless of origin unless explicit >>>>>>> Permissions-Policies/allow-attributes block them (7). >>>>>>> >>>>>>> * Is there any risk of an ad redeeming tokens to interfere with >>>>>>> other ads? >>>>>>> https://github.com/WICG/trust-token-api?tab=readme-ov-file#private-state-token-exhaustion >>>>>>> says only 1 token is redeemed per top-level page visit, which prevents >>>>>>> the >>>>>>> ad from deliberately using up the user's tokens, but it could still >>>>>>> race to >>>>>>> prevent any other ad from knowing to trust the user. >>>>>>> >>>>>>> Yes, an ad redeeming a token may interfere with other origins' >>>>>>> capabilities, as that redemption operation associates the issuer >>>>>>> with the top level origin. And this counts towards the issuer limit. At >>>>>>> most 2 issuers per top level origin is allowed. See step 4 in algorithm >>>>>>> (1). Associating an issuer with the top level origin occupies a slot. >>>>>>> Once >>>>>>> an ad redeems a token, only one issuer slot is left for all others in >>>>>>> the >>>>>>> same top level page. >>>>>>> >>>>>>> Following a successful redemption, a redemption record (3) is >>>>>>> stored, step 14 in algorithm (2). Redemption records are keyed by >>>>>>> (issuer, >>>>>>> toplevel) origin pair. Any other origin in the page trying to redeem a >>>>>>> token from the same issuer will get this cached redemption record. >>>>>>> >>>>>>> Put another way, ads can’t ‘use up’ tokens that other ads on the >>>>>>> page want to redeem, because those other ads would just re-use the same >>>>>>> redemption record. >>>>>>> >>>>>>> The explainer text is not in the best shape, created issue #307 >>>>>>> <https://github.com/WICG/trust-token-api/issues/307> to fix this. >>>>>>> >>>>>>> 2. This intent also expands which origins can _issue_ tokens, but I >>>>>>> don't see the justification for that in the issue. What circumstances >>>>>>> need >>>>>>> that? >>>>>>> >>>>>>> Yes, you are correct that the particular request cited here is >>>>>>> pertaining to redemption operations. However, we are aware that many >>>>>>> anti-fraud vendors are only embedded in 3p contexts, without necessarily >>>>>>> having script access on the top-level site. Vendors who currently rely >>>>>>> on >>>>>>> third-party cookies to establish and convey trust will need commensurate >>>>>>> permissions on both redemption and issuance sides. >>>>>>> >>>>>>> There's some privacy impact from using this API. The tight default >>>>>>> permission policy meant that top-level sites had to explicitly ask to >>>>>>> expose their users to that privacy impact. Without it, shouldn't we >>>>>>> expect >>>>>>> lots of embedded resources to try to learn whatever information they can >>>>>>> using this API? Why is that extra risk good for users overall? >>>>>>> >>>>>>> We see this is a key tradeoff that many third-party cookie >>>>>>> replacement APIs have to contend with. Given the widespread reliance on >>>>>>> third-party cookies, it may not be practical to have anti-fraud vendors >>>>>>> to >>>>>>> work with every publisher/page to update their permission policy for the >>>>>>> frames they have. Usefulness of the signal depends on its availability. >>>>>>> >>>>>>> Further, the extra risk is actually very small: it's not going to >>>>>>> affect users' privacy if anyone can learn that they've visited 2 >>>>>>> particular >>>>>>> issuers and the 6 bits those issuers want to convey about them. In fact, >>>>>>> the privacy risk is decreased by allowing 3p issuers to send that >>>>>>> information, because it limits the inference about which sites a user >>>>>>> has >>>>>>> actively visited. >>>>>>> >>>>>>> Note that the information embedded resources can learn are >>>>>>> constrained by limiting information content stored in a token (4) and >>>>>>> limiting the number of issuers per page (5). Additionally, PST issuers >>>>>>> are >>>>>>> expected to register on GitHub >>>>>>> <https://github.com/GoogleChrome/private-tokens/blob/main/PST-Registration.md> >>>>>>> with some transparency on how they’re using the tokens. >>>>>>> >>>>>>> I don't find the "the top-level origin could call hasPrivateToken up >>>>>>> to twice before any other JavaScript is included" mitigation plausible: >>>>>>> folks often don't control the order of their Javascript that closely. It >>>>>>> seems more likely that sites would just explicitly set the permission >>>>>>> policy to the origins they trust to pick their issuers: is there a >>>>>>> reason >>>>>>> that's not an adequate defense? >>>>>>> >>>>>>> Permission policy can certainly be used, but it does not prevent >>>>>>> third-party scripts embedded on the top-level context from picking their >>>>>>> own issuers. The hasPrivateToken method overcomes that issue. >>>>>>> >>>>>>> For the general case, the JS API method mitigates most cases, but we >>>>>>> have heard that folks would like a more explicit way of doing this, >>>>>>> either >>>>>>> as a meta tag or header that can be sent by the server since the JS >>>>>>> inclusion order and complexities with single page sites means that this >>>>>>> is >>>>>>> a little fragile if it's not the earliest executed JS. >>>>>>> >>>>>>> While we could add a new meta-tag/header feature to control issuance >>>>>>> origins and then change the policy to default to *, given the low usage >>>>>>> and >>>>>>> (in our estimation) the low risk of changing the policy default we would >>>>>>> prefer to pursue this change and follow up if requested by clients. >>>>>>> >>>>>>> But then you've still just switched the burden from sites that want >>>>>>> to delegate use of this API, to sites that need to defend against >>>>>>> hostile >>>>>>> use of the API. Can you share any analysis of why you think attacks >>>>>>> will be >>>>>>> much less likely than uses, or some other reason that it's good for >>>>>>> users >>>>>>> and sites to switch that burden? >>>>>>> >>>>>>> While it could be viewed as a “burden switch”, the fundamental >>>>>>> privacy properties of PSTs mentioned above are such that the vast >>>>>>> majority >>>>>>> of sites shouldn’t have cause to be concerned. For sites that are >>>>>>> looking >>>>>>> to prevent any cross site communication, the permission policy remains >>>>>>> available. >>>>>>> References >>>>>>> >>>>>>> 1. >>>>>>> https://wicg.github.io/trust-token-api/#append-private-state-token-redemption-request-headers >>>>>>> >>>>>>> 2. https://wicg.github.io/trust-token-api/#handle-a-redeem-response >>>>>>> >>>>>>> 3. https://wicg.github.io/trust-token-api/#redemption-record >>>>>>> >>>>>>> 4. https://wicg.github.io/trust-token-api/#limit-encoded-info >>>>>>> >>>>>>> 5. https://wicg.github.io/trust-token-api/#per-issuer-limits >>>>>>> >>>>>>> 6. https://github.com/WICG/trust-token-api/issues/106 >>>>>>> >>>>>>> 7. >>>>>>> https://developer.mozilla.org/en-US/docs/Web/HTTP/Permissions_Policy#allowlists >>>>>>> >>>>>>> 8. https://chromestatus.com/metrics/feature/timeline/popularity/3276 >>>>>>> >>>>>>> ~ Ari Chivukula (Their/There/They're) >>>>>>> >>>>>>> >>>>>>> On Wed, Oct 2, 2024 at 4:51 PM Ari Chivukula <ari...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> These are good questions! Sorry for the delay in replying, now that >>>>>>>> TPAC has passed we should have something soon. >>>>>>>> >>>>>>>> ~ Ari Chivukula (Their/There/They're) >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Sep 11, 2024 at 3:52 PM Jeffrey Yasskin < >>>>>>>> jyas...@chromium.org> wrote: >>>>>>>> >>>>>>>>> This Intent makes me realize that my mental model of Private State >>>>>>>>> Tokens wasn't correct. I'd been thinking of users going to a site that >>>>>>>>> trusts them, having that site issue some tokens, and then going to >>>>>>>>> another >>>>>>>>> site which would redeem a token to increase its trust. In both cases, >>>>>>>>> the >>>>>>>>> sites could rely on third-parties to handle the tokens, but the sites >>>>>>>>> have >>>>>>>>> intentional relationships with their service providers and so could >>>>>>>>> enable >>>>>>>>> them in the top-level Permission Policy. >>>>>>>>> >>>>>>>>> This Intent implies that something else is going on, maybe >>>>>>>>> multiple things. >>>>>>>>> >>>>>>>>> 1. https://github.com/WICG/trust-token-api/issues/106 says that >>>>>>>>> adtech services want to redeem tokens without needing to get changes >>>>>>>>> made >>>>>>>>> on the top-level site. The request seems to say that it's the adtech >>>>>>>>> origin >>>>>>>>> that's directly called from the top-level site, but I think this >>>>>>>>> change >>>>>>>>> would allow redemptions anywhere down the tree of ad-related frames? >>>>>>>>> * Is there any risk of an ad redeeming tokens to interfere with >>>>>>>>> other ads? >>>>>>>>> https://github.com/WICG/trust-token-api?tab=readme-ov-file#private-state-token-exhaustion >>>>>>>>> says only 1 token is redeemed per top-level page visit, which >>>>>>>>> prevents the >>>>>>>>> ad from deliberately using up the user's tokens, but it could still >>>>>>>>> race to >>>>>>>>> prevent any other ad from knowing to trust the user. >>>>>>>>> 2. This intent also expands which origins can _issue_ tokens, but >>>>>>>>> I don't see the justification for that in the issue. What >>>>>>>>> circumstances >>>>>>>>> need that? >>>>>>>>> >>>>>>>>> There's some privacy impact from using this API. The tight default >>>>>>>>> permission policy meant that top-level sites had to explicitly ask to >>>>>>>>> expose their users to that privacy impact. Without it, shouldn't we >>>>>>>>> expect >>>>>>>>> lots of embedded resources to try to learn whatever information they >>>>>>>>> can >>>>>>>>> using this API? Why is that extra risk good for users overall? >>>>>>>>> >>>>>>>>> I don't find the "the top-level origin could call hasPrivateToken >>>>>>>>> up to twice before any other JavaScript is included" mitigation >>>>>>>>> plausible: >>>>>>>>> folks often don't control the order of their Javascript that closely. >>>>>>>>> It >>>>>>>>> seems more likely that sites would just explicitly set the permission >>>>>>>>> policy to the origins they trust to pick their issuers: is there a >>>>>>>>> reason >>>>>>>>> that's not an adequate defense? >>>>>>>>> >>>>>>>>> But then you've still just switched the burden from sites that >>>>>>>>> want to delegate use of this API, to sites that need to defend against >>>>>>>>> hostile use of the API. Can you share any analysis of why you think >>>>>>>>> attacks >>>>>>>>> will be much less likely than uses, or some other reason that it's >>>>>>>>> good for >>>>>>>>> users and sites to switch that burden? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Jeffrey >>>>>>>>> >>>>>>>>> On Mon, Sep 9, 2024 at 5:58 AM Ari Chivukula <ari...@chromium.org> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Contact emails >>>>>>>>>> >>>>>>>>>> ari...@chromium.org, kaust...@chromium.org, sva...@chromium.org, >>>>>>>>>> ayk...@google.com, nic...@google.com >>>>>>>>>> >>>>>>>>>> Specification >>>>>>>>>> >>>>>>>>>> https://github.com/WICG/trust-token-api/pull/306 >>>>>>>>>> >>>>>>>>>> Summary >>>>>>>>>> >>>>>>>>>> Access to the Private State Token API >>>>>>>>>> <https://wicg.github.io/trust-token-api/> is gated by Permissions >>>>>>>>>> Policy <https://www.w3.org/TR/permissions-policy/> features. We >>>>>>>>>> proposed to update the default allowlist >>>>>>>>>> <https://w3c.github.io/webappsec-permissions-policy/#policy-controlled-feature-default-allowlist> >>>>>>>>>> for both `private-state-token-issuance >>>>>>>>>> <https://wicg.github.io/trust-token-api/#policy-controlled-feature-private-state-token-issuance>` >>>>>>>>>> and `private-state-token-redemption >>>>>>>>>> <https://wicg.github.io/trust-token-api/#policy-controlled-feature-private-state-token-redemption>` >>>>>>>>>> features from self to * (wildcard). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Blink component >>>>>>>>>> >>>>>>>>>> Blink>StorageAccessAPI >>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorageAccessAPI> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Motivation >>>>>>>>>> >>>>>>>>>> The Private State Tokens API >>>>>>>>>> <https://wicg.github.io/trust-token-api/> has received recurring >>>>>>>>>> feedback from developers >>>>>>>>>> <https://github.com/WICG/trust-token-api/issues/106> that the >>>>>>>>>> current requirement to have first-party sites opt-in to allow >>>>>>>>>> third-parties >>>>>>>>>> to invoke token issuance and redemption operations is not practical. >>>>>>>>>> This >>>>>>>>>> is especially true for use cases where embeds don’t have first-party >>>>>>>>>> script >>>>>>>>>> access to either execute the operations directly in first-party >>>>>>>>>> context, or >>>>>>>>>> to enable the permission policies on the relevant frames. Current >>>>>>>>>> default >>>>>>>>>> requires every site to update permission policy for iframes that >>>>>>>>>> embed >>>>>>>>>> invalid traffic (IVT) detection scripts.Since scale and coverage are >>>>>>>>>> of >>>>>>>>>> essence for IVT detection that rely on identifying outlier patterns; >>>>>>>>>> the >>>>>>>>>> need for coordination with first-parties places a high cost for >>>>>>>>>> successful >>>>>>>>>> adoption. >>>>>>>>>> >>>>>>>>>> TAG review >>>>>>>>>> >>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/990 >>>>>>>>>> >>>>>>>>>> Compatibility >>>>>>>>>> >>>>>>>>>> This will not break any existing Private State Token API usage as >>>>>>>>>> it only increases permissiveness. As usage increases, sites may need >>>>>>>>>> to >>>>>>>>>> consider the need to mitigate issuer exhaustion >>>>>>>>>> <https://wicg.github.io/trust-token-api/#issuer-exhaustion>. >>>>>>>>>> >>>>>>>>>> Competing scripts might race to call hasPrivateToken to ensure >>>>>>>>>> their preferred issuer enters the issuerAssociations >>>>>>>>>> <https://wicg.github.io/trust-token-api/#issuerassociations> map >>>>>>>>>> <https://infra.spec.whatwg.org/#ordered-map> before the issuer >>>>>>>>>> of others given a limit of two per top-level origin >>>>>>>>>> <https://html.spec.whatwg.org/multipage/webappapis.html#concept-environment-top-level-origin>. >>>>>>>>>> To control this process, the top-level origin >>>>>>>>>> <https://html.spec.whatwg.org/multipage/webappapis.html#concept-environment-top-level-origin> >>>>>>>>>> could call hasPrivateToken up to twice before any other JavaScript is >>>>>>>>>> included to ensure their preferred issuers are available. >>>>>>>>>> >>>>>>>>>> Few enough websites >>>>>>>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/3277> >>>>>>>>>> are using the API that we believe we can broaden the default >>>>>>>>>> permission set >>>>>>>>>> and not open any concerning new avenues of attack. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Interoperability >>>>>>>>>> >>>>>>>>>> Gecko: Position Requested >>>>>>>>>> <https://github.com/mozilla/standards-positions/issues/1066> >>>>>>>>>> >>>>>>>>>> WebKit: Position Requested >>>>>>>>>> <https://github.com/WebKit/standards-positions/issues/391> >>>>>>>>>> >>>>>>>>>> Web developers: Positive >>>>>>>>>> <https://github.com/WICG/trust-token-api/issues/106> >>>>>>>>>> >>>>>>>>>> Debuggability >>>>>>>>>> >>>>>>>>>> Storage written can be examined in devtools. >>>>>>>>>> >>>>>>>>>> Is this feature fully tested by web-platform-tests? >>>>>>>>>> >>>>>>>>>> Yes >>>>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/trust-tokens/> >>>>>>>>>> >>>>>>>>>> Tracking bug >>>>>>>>>> >>>>>>>>>> https://issues.chromium.org/353738486 >>>>>>>>>> >>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>> >>>>>>>>>> https://chromestatus.com/feature/5205548434456576 >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>> Google Groups "blink-dev" group. >>>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>>> send an email to blink-dev+...@chromium.org. >>>>>>>>>> To view this discussion on the web visit >>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DL2enC2Q1vYBb%2BKA-O3aYW-a3bcvpWnU12NdAvQT6eUcg%40mail.gmail.com >>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DL2enC2Q1vYBb%2BKA-O3aYW-a3bcvpWnU12NdAvQT6eUcg%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 blink-dev+unsubscr...@chromium.org. >>>> >>> To view this discussion visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DKLGRyeE9SCYuxyRG0DSLvzzX9qT4%3Dz3MtXW37Ki_9JsA%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DKLGRyeE9SCYuxyRG0DSLvzzX9qT4%3Dz3MtXW37Ki_9JsA%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 blink-dev+unsubscr...@chromium.org. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/99634aa5-7264-44b3-9eaa-8b1506853126n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/99634aa5-7264-44b3-9eaa-8b1506853126n%40chromium.org?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2MysJNH%2Bea%2BvX5DDPHCY0Fv7V85wHCwsJQOoj_HZdk99Q%40mail.gmail.com.
