Sorry for the slow follow-up here.

On Friday, July 28, 2023 at 10:26:25 PM UTC-7 Lauren N. Liberda wrote:

>I have encouraged the team working on this to ignore feedback in any forum 
in which something like Chromium's code of conduct 
<https://chromium.googlesource.com/chromium/src/+/HEAD/CODE_OF_CONDUCT.md#:~:text=Be%20respectful%20and%20constructive.,condescension%2C%20whether%20blatant%20or%20subtle.>
 
is not being maintained as anything else would be creating an unsafe 
working environment. It's somewhat ironic to me that some folks arguing 
passionately for the openness of the web (something I and many of the 
proposal contributors are also passionate about) are relying on physical 
threats and other forms of abuse, which of course means we must limit the 
engagement on this topic such that their voices are ignored completely (the 
antithesis of the openness they are advocating for). 

I'm gonna say this as politely as I can. Google has got into hugely 
dominant positions with Chromium and Android. 

Chromium is forkable, and we (Microsoft) participate in this project with a 
big community of folks who are investing to improve the codebase. Google 
pays most of those bills, and as a result, enjoys the most influence. 
That's how OSS is *supposed* to work. Android is a different question (MADA 
is...not great), and to the extent that what we're talking about here is 
inflicting some of the closed properties of the Android ecosystem onto a 
much more open, standards-based userland, we can differentiate those 
interests and influences.

Simply saying "there's a lot of influence from Google in Chromium" attempts 
to prove far too much.

I don't think I have to explain here how much these 2 projects dominate the 
web and mobile spaces. They are both under Google's governance, and treated 
by Google as its backyard. Chromium comes up with whatever Chromium wants 
to implement, and can ignore everyone else. Android keeps getting moved 
from AOSP to Google Play Services. Nobody can stop this. Nobody can stand 
up against this.

This, in a direct consequence, means whatever Google does with these 
projects *will* be watched closely and with little trust, like a government 
is. If this is a problem for you, maybe suggest to the more important 
people to stop that. I don't know, turn them into independent non-profit 
projects, separate from Chrome and Google Play? Request Firefox is shipped 
by OEMs on some Android phones instead of Chrome? Send some bigger one-time 
donations for Servo and Ladybird development, with no requests made? I'm 
not getting paid to give you advice.

WEI is also an especial, highly flammable combo, because it touches (risks 
of) all of: anti-end user practices, setting Google as an authority to 
trust with decisions about user's faith, reinforcing user reliance on 
Chrome specifically and Google Play Services, fight on ad blockers, 
scraping, and unofficial clients. If I continue with the government 
analogy, Google is here an unelected official whose death would start 
street parties. I know, I know, this is just "an experiment", "not a goal", 
and actually "for privacy".

Currently, as I'm on Android, my banking apps will refuse to enable some 
features, Snapchat will refuse to log in, and the McDonald's app will 
refuse to launch if I don't get Google to sign some magic string these apps 
get from a server. I'm, according to the Play Integrity API documentation, 
supposed to not get it signed, because I have access to my own device's 
root user. I want to update apps from my F-Droid as easily as those from 
Google Play, stop traffic to some domains by editing /etc/hosts, and have a 
possibility to backup some of my installed apps with their data, but I 
guess that's too much freedom to have a McDonald's equivalent of a loyalty 
card. Maybe I'll self-report here now that I also have access as an 
Administrator to my Windows machine.

The current proposal is to extend this to the web. 


That's a statement of intent that isn't exactly clear from the original 
explainer that was published. We should absolutely be asking for much more 
clarity around the goals and concrete use-cases. Obviously, this is what 
Apple is *already* doing, and it's very directly what you're worried about:

    https://httptoolkit.com/blog/apple-private-access-tokens-attestation/
 
The opportunity here, if we can avoid asserting malintent, is to seek 
clarification on the user and developer needs and make sure the design 
meets them with the minimum of risks and downsides.

So let's collectively interrogate needs and goals, assuming good faith.

Best,

Alex

Apparently if I have root access on my phone, this means I must be a robot 
that shouldn't see the website that has ads (referring to the first example 
from the explainer's introduction). That's correct, I don't want to be 
human. Especially if my humanity is reduced to "advertisement watcher". The 
left-over crumbs of humanity that used to be in this body are only here to 
check the "I'm not a robot" boxes.
>Attacks and doxing make me personally MORE likely to support stronger 
safety features in chromium, as such acts increase my suspicion that there 
is significant intimidation from criminals who are afraid this feature will 
disrupt their illegal and/or unethical businesses, and I don't give in to 
criminals or bullies.

If wanting to see the news, watch some user-uploaded videos, or scroll some 
social media feed on the internet is gonna side me with criminals, then at 
this point maybe I should simply become one. This makes "unethical 
businesses" sound like they might actually be a moral choice. Torrents 
actually give me movies, not "The WidevineCdm plugin has crashed". The site 
you probably know well wants, at worst, 2,80 Euro for a thousand checked 
boxes, while I'd need half a minute to fill each myself. With mass use of 
attestation (availability on web *will* increase it on all platforms), APIs 
returning tokens signed by Google will only become a matter of the price 
per 1000, not of a fact. If the "strong safety features" mean making it 
annoying enough to cost 15 Euro instead of 1, while a genuine Huawei user 
will not be able to get any, and actual criminals already send phones to 
package lockers as a way of selling bank account access, then maybe this is 
not safety. (Just kidding. I would never do cybercrime.)

On 28/07/2023 21:08, 'Rick Byers' via blink-dev wrote:

As one of the API owners and chromium community leaders, I'd just like to 
chime in on this personally with a meta-point:  

Thank you all for the thoughtful and constructive debate in this forum. As 
I'm sure you know, this topic has gotten a lot of disrespectful, abusive 
and overly-simplified criticism in other public forums which IMHO has made 
it hard to get any useful signal from the noise there. I have encouraged 
the team working on this to ignore feedback in any forum in which something 
like Chromium's code of conduct 
<https://chromium.googlesource.com/chromium/src/+/HEAD/CODE_OF_CONDUCT.md#:~:text=Be%20respectful%20and%20constructive.,condescension%2C%20whether%20blatant%20or%20subtle.>
 
is not being maintained as anything else would be creating an unsafe 
working environment. It's somewhat ironic to me that some folks arguing 
passionately for the openness of the web (something I and many of the 
proposal contributors are also passionate about) are relying on physical 
threats and other forms of abuse, which of course means we must limit the 
engagement on this topic such that their voices are ignored completely (the 
antithesis of the openness they are advocating for). Attacks and doxing 
make me personally MORE likely to support stronger safety features in 
chromium, as such acts increase my suspicion that there is 
significant intimidation from criminals who are afraid this feature will 
disrupt their illegal and/or unethical businesses, and I don't give in to 
criminals or bullies. 

But then I'm grateful that the blink-dev community remains a place where we 
can disagree respectfully and iterate openly and publicly on difficult and 
emotionally charged topics, backing us away from thinking and acting in an 
"us-vs-them" fashion. I also want to point out that while open to anyone, 
this forum is moderated for new posters. Moderators like myself approve any 
post which is consistent with chromium's code of conduct 
<https://chromium.googlesource.com/chromium/src/+/HEAD/CODE_OF_CONDUCT.md>, 
regardless of the specific point of view being taken. The thoughtful 
comments here over the past few days have been educational and overall 
calming for me, thank you!

This community and moderation practices represents the sort of balance 
between openness and safety which I believe the WEI proposal authors are 
striving for. At the same time, I believe it's clear to many of us that the 
tradeoffs being struck by the current proposal do not yet meet the minimum 
bar necessary to uphold chromium's values 
<https://www.chromium.org/blink/guidelines/values/>. That's OK - that's the 
whole point of designing in the open and having public debate is to find 
reasonable compromises between stakeholders with very different 
perspectives, and creating a safe place to experiment (as we expect most 
experiments to fail!). In order to start even an origin trial in Chrome, 
this proposal would need approval from API owners like myself, and the 
current state of the proposal is not something I'd personally approve due 
to many of the concerns being raised. At the same time I do think there's 
an urgent opportunity for chromium to do more to help with the problem of 
inauthentic traffic, and (like everything we do) some amount of 
experimentation seems essential to that. I believe the team working on this 
proposal is taking some time to regroup (and recover from all the stress) 
and rethink at least the framing, if not some of the core design properties 
of this feature. I'm sure we'll get an update from them when they feel 
ready and sufficiently recovered to engage in public again. In the interim, 
please keep the constructive and respectful criticism coming. Bonus points 
if you also have suggestions or data on how to actually make meaningful 
progress on the problem of inauthentic traffic in a way that's fully 
consistent with the openness of the web :-).

Cheers, and I hope you all have a stress-free weekend,
   Rick

On Fri, Jul 28, 2023 at 11:48 AM Justin Schuh <jsc...@chromium.org> wrote:

Hopefully I'm not adding to the noise, but I wanted to call out a few 
things as an independent observer with some background in the problem 
space. (My comments are beyond the process and structure things, which Alex 
already addressed.) 

First, I suggest that anyone commenting on this explainer as currently 
written should also read the initial public proposal linked in Ben's email 
<https://github.com/antifraudcg/proposals/issues/8>, which gives more 
context on the problem space. To use the terminology from that discussion, 
this proposal is about detecting/blocking IVT (invalid traffic), which 
encompasses things like fraud, spam, coordinated disinformation, etc. that 
originate from inauthentic users (e.g. bots, farms). Site operators have 
historically relied on fingerprinting and other tracking signals to 
identify IVT, but as browser makers eliminate fingerprinting/tracking 
surfaces, site operators need privacy preserving ways to detect/block IVT.

That context sort of comes across from the explainer and linked resources, 
but IMHO it really needs to lead with plainly stating this. Because the CG 
discussions show broad consensus on the nature of the problem and the 
importance of addressing it, but the explainer is written in a way that 
largely assumes understanding of all the context (which is clearly not the 
case).

The next big thing that jumps out at me is that the only solution even 
considered for IVT seems to involve wrapping device attestation APIs (e.g. 
Android Safety Net and iOS App Attest). This is a common enough approach 
for native apps dealing with IVT (it basically repurposes a DRM mechanism, 
with all the baggage that entails). However, it also seems to ignore the 
fundamentally different privacy and security considerations of the Web 
platform. Most concerningly, it tightly couples user authenticity to device 
integrity. I have my doubts that this is necessary, and I think most of the 
concerns arise from conflating these two concepts.

My recollection is that there was a lot of work done with PrivacyPass 
<https://privacypass.github.io/> to explicitly decouple user authenticity 
from other ambient state. I also see from the CG discussions that 
PrivacyPass was not considered adequate for addressing IVT. If I were in a 
position of assessing this proposal, I know that I'd need more detail in 
the explainer on specifically how PrivacyPass was lacking, and why a 
narrower extension of the protocol is insufficient.

I also see questions about holdback, but I feel like that's a bit 
backwards. I appreciate the need to detect ever evolving adversaries, but 
IVT is a problem that happens at scale. So, if more signals are needed to 
stay ahead of the threats, then a conservative sampling rate should be more 
than adequate to detect new patterns and identify coincident signals. 
Something like that could mitigate many of the concerns around sites 
misusing this sort of thing.

Perhaps these sorts of discussions took place in the CG and I just didn't 
find them. But it certainly isn't captured in the explainer, and the CG 
discussion read to me like everyone started with the assumption that the 
solution was to just wrap the Android/iOS native approach.



P.S. This may be total bikeshedding, but I really don't like the term IVT, 
since invalid traffic is too broad of a concept. The problem space here is 
concerned with inauthentic traffic at scale, so I'd suggest zeroing in a 
term that better conveys that reality.


On Tue, Jul 25, 2023 at 7:32 AM Dominic Farolino <d...@chromium.org> wrote:

At the very least, an explicit commitment to a holdback would seem to quell 
*some* of the concerns about this feature. But one thing I'm concerned 
about is if there'd be a difference in holdback between Chrome and WebView. 
Since WebView isn't always considered a "real browser" I could see this as 
an opening to try and not implement holdbacks on WebView. I'm not sure how 
API OWNERs would evaluate that, but the risks there seem pretty 
interesting, as I imagine it'd force some sites to aggressively UA-sniff to 
determine whether they're in a WebView and can interpret the absence of 
attestation as a perfect signal, vs. a possible holdback user in a browser 
where lack of attestation is "OK". Having the adoption of an API hinge on 
that kind of ugly practice seems unfortunate.

On Mon, Jul 24, 2023 at 12:10 PM Yoav Weiss <yoavwe...@chromium.org> wrote:

/* with my API OWNER hat on */

Examining this proposed change, it seems to me that the most risky part in 
the signed attestation information 
<https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md#what-information-is-in-the-signed-attestation>
 is 
the part about "application identity". Providing that information to the 
server seems to go against our past efforts to GREASE UA-CH 
<https://wicg.github.io/ua-client-hints/#grease> and will prevent Chromium 
browsers from identifying themselves as Chrome, something they are 
(unfortunately) often required to do for compatibility reasons.

On Mon, Jul 24, 2023 at 1:02 AM Dana Jansens <dan...@orodu.net> wrote:

There's been a lot of strongly worded negative feedback for this proposal 
in the Github, and I don't agree with how that feedback was delivered but I 
do agree that this proposal if followed would not be good for the web. 

The proposal talks about trust, but the server does not need to trust the 
client. Like palmer said, they can never trust the client, this doesn't 
allow them to trust the client in a way that could be considered a security 
boundary. That is a fundamental design choice of client-server with open 
user agents, in place of closed apps/walled gardens. This is an intentional 
property of the web.

But this proposal provides a mechanism for web sites to force their ideals 
and preferences onto user agents, which takes away user autonomy and 
choice, and damages the trust held by Chromium as the dominant user agent 
today. Let's push the world to be more open, to give more user control, not 
more controlled and closed.

Dana

On Thursday, July 20, 2023 at 1:41:45 PM UTC-4 Reilly Grant wrote:

Michaela, I think you are misunderstanding this proposal. This is not a 
proposal for a site to prove its integrity to the user. It is a proposal 
for the user agent to prove its integrity to the site, and that it is 
acting on behalf of a real user. These are two largely independent 
problems. I recommend looking at Isolated Web Apps 
<https://github.com/WICG/isolated-web-apps>, which attempt to solve 
exactly the problem you're discussing.

On Thu, Jul 20, 2023 at 8:18 AM 'Michaela Merz' via blink-dev <
blin...@chromium.org> wrote:

Thanks @Chris Palmer for your input. Nobody is more opposed to DRM than I 
am. Even today I refuse to load DRM extensions into the browser. I think 
that DRM is wrong and the open web is the way to go.

But providing provenance and integrity to a resource is not DRM. TLS is not 
DRM. If you hit a page with an invalid TLS certificate, you are free to 
continue. If the power to be would decide to NOT allow us to continue to 
sites without a valid TLS certificate, you'll find me on the barricades 
right along with you. 

Browsers already include a protection mechanism called "Subresource 
Integrity" (SIR) . If the provided resource doesn't match the hash, the 
browser refuses to load the resource. Together with "content security 
policy" we can already create hardened web resources. But we're missing one 
crucial element: If the web site has been modified on the server. If a 
malicious attempt to modify a web environment is successful right at the 
source, we (and our users) have no way to protect us and our users. 

That's why I think it is important to extend the SRI with a "master key" or 
certificate that can not be recreated without the knowledge of the author 
of the web site. 

We can and must discuss the details of such a mechanism of course. I am 
with you and don't want DRM through the back door. But I think it's crucial 
for the web environment's credibility to have tools that can be used to 
protect the integrity of the environment.

m.


On Thu, Jul 20, 2023 at 7:05 AM Chris Palmer <pal...@chromium.org> wrote:

Speaking as a recent former Chromie who wants you to succeed: retract this 
proposal. 

* The web is *the* open, mainstream application platform. The world really, 
really needs it to stay that way.

* Whatever goals publishers might think this serves (although it doesn't), 
extensions and Dev Tools (and other debuggers) neutralize it. Extensions 
and Dev Tools are incalculably valuable and not really negotiable. So if 
something has to give, it's DRM.

* The document claims WEI won't directly break content blockers, 
accessibility aids, et c. But: (a) this will be used as part of an argument 
to not bring extensions to Chrome for Android; and (b) assume/realize that 
publishers will start rejecting clients that support extensions. Chrome for 
mobile platforms already doesn't support extensions, and mobile is the 
largest platform class. So publishers might even have a decent chance of 
getting away with such a restriction.

* DRM will always be cracked and worked around, but that doesn't mean that 
implementing this will be harmless. DRM still shuts out legitimate use 
cases (accessibility comes foremost to mind, but not solely), even when it 
is broken. Everybody loses.

* DRM misaligns incentives: the customer is now the adversary. This is a 
losing move, both from a business perspective and from a technical security 
engineering perspective. (Do you want an adversarial relationship with 
security researchers? No, you do not.) WEI enables publishers to play a 
losing game, not a winning one.

* In ideal circumstances, WEI would be at best a marginal, probabilistic, 
lossy 'security' mechanism. (Defenders must always assume that any given 
client is perfectly 'legitimate' but 'malicious'. For example, Amazon 
Mechanical Turk is cheap.) Holdbacks nullify even that marginal benefit, 
while still not effectively stopping the lockout of particular UAs and yet 
not effectively upholding any IP-maximal goals.

* Chromium has a lot of credibility in safety engineering circles. Don't 
spend it on this.

On Monday, May 8, 2023 at 8:30:30 AM UTC-7 bew...@google.com wrote:

Contact emails 

serg...@chromium.org, pb...@chromium.org, ryan...@google.com, 
b...@chromium.org, erict...@chromium.org
Explainer 

https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/
main/explainer.md
Specification 

We do not have a specification yet, however we expect to publish in the 
near future both the considered implementation options for the web layer in 
an initial spec, which we suspect are not very controversial, and an 
explanation of our approach for issuing tokens, which we expect will spark 
more public discussion, but is not directly a web platform component. We 
are gathering community feedback through the explainer before we actively 
develop the specification.
TAG Review 

Not filed yet.
Blink component 

Blink>Identity 
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EIdentity>
Summary 

This is a new JavaScript API that lets web developers retrieve a token to 
attest to the integrity of the web environment. This can be sent to 
websites’ web servers to verify that the environment the web page is 
running on is trusted by the attester. The web server can use asymmetric 
cryptography to verify that the token has not been tampered with. This 
feature relies on platform level attesters (in most cases from the 
operating system).

This project was discussed in the W3C Anti-Fraud Community Group on April 
28th, and we look forward to more conversations in W3C forums in the 
future. In the meantime, we welcome feedback on the explainer 
<https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md>
.
Motivation 

This is beneficial for anti-fraud measures. Websites commonly use 
fingerprinting techniques to try to verify that a real human is using a 
real device. We intend to introduce this feature to offer an adversarially 
robust and long-term sustainable anti-abuse solution while still protecting 
users’ privacy.
Initial public proposal 

https://github.com/antifraudcg/proposals/issues/8
Risks 

Interoperability and Compatibility

We are currently working on the explainer and specification and are working 
with the Anti-Fraud Community Group to work towards consensus across the 
web community. The “attester” is platform specific so this feature needs to 
be included on a per platform basis. We are initially targeting mobile 
Chrome and WebView.

Ergonomics

See “How can I use web environment integrity? 
<https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md#how-can-i-use-web-environment-integrity>”
 
in the explainer. Note that we are actively looking for input from the 
anti-fraud community and may update the API shape based on this. We also 
expect developers to use this API through aggregated analysis of the 
attestation signals.

Security

See the “Challenges and threats to address 
<https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md#challenges-and-threats-to-address>”
 
section of the explainer to see our current considerations.

Will this feature be supported on all six Blink platforms (Windows, Mac, 
Linux, ChromeOS, Android, and Android WebView)?

We initially support this only for Android platforms (Android, and Android 
WebView). This feature requires an attester backed by the target platform 
so it will require active integration per platform.

Is this feature fully tested by web-platform-tests 
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%2F%2B%2Fmaster%2Fdocs%2Ftesting%2Fweb_platform_tests.md&data=04%7C01%7CAmanda.Baker%40microsoft.com%7C84c5e8a01bc1471e348f08d7c6b940f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637196371372857279%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C-1&sdata=M79bBRPkECK4YmZwW1JAdcqHCofWo6qpz3TFFwnvqB8%3D&reserved=0>
?

Web platform tests will be added as part of this work as part of the 
prototyping. We will then feed those tests back into the specification.

Requires code in //chrome?

True

Feature flag (until launch)

--enable-features=WebEnvironmentIntegrity

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5796524191121408

-- 
You received this message because you are subscribed to a topic in the 
Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/
chromium.org/d/topic/blink-dev/Ux5h_kGO22g/unsubscribe.
To unsubscribe from this group and all its topics, 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/28a637ff-682c-4a38-b3a9-
f2bfa2b48c44n%40chromium.org 
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/28a637ff-682c-4a38-b3a9-f2bfa2b48c44n%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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/
chromium.org/d/msgid/blink-dev/CAKDb%2By7gDGdiWTKR832P7m2hH0p1VtxXq
vnBxwYnAZ0AQjo4jQ%40mail.gmail.com 
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKDb%2By7gDGdiWTKR832P7m2hH0p1VtxXqvnBxwYnAZ0AQjo4jQ%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 on the web visit https://groups.google.com/a/
chromium.org/d/msgid/blink-dev/b5f5a252-a0fc-4c37-8ae8-
9a460d20373an%40chromium.org 
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b5f5a252-a0fc-4c37-8ae8-9a460d20373an%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 on the web visit https://groups.google.com/a/
chromium.org/d/msgid/blink-dev/CAL5BFfW0ztZ-R%2BA995PSVB6vh7tzszw8%2B%2BxE-
6%2Bfnt_CLmHN%3DQ%40mail.gmail.com 
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfW0ztZ-R%2BA995PSVB6vh7tzszw8%2B%2BxE-6%2Bfnt_CLmHN%3DQ%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 on the web visit https://groups.google.com/a/
chromium.org/d/msgid/blink-dev/CAP-uykBNk1Vpd85sEzRXrKTroxcy5wows
pF0hmSkugX4dEw_qg%40mail.gmail.com 
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-uykBNk1Vpd85sEzRXrKTroxcy5wowspF0hmSkugX4dEw_qg%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 on the web visit https://groups.google.com/a/
chromium.org/d/msgid/blink-dev/CA%2BYmkXcj1eb5tbwrWNi_Y9pZ%
2BcHn1CiBYZM9b8Nnpze5bWnOGQ%40mail.gmail.com 
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BYmkXcj1eb5tbwrWNi_Y9pZ%2BcHn1CiBYZM9b8Nnpze5bWnOGQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
.

-- 
You received this message because you are subscribed to a topic in the 
Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/
chromium.org/d/topic/blink-dev/Ux5h_kGO22g/unsubscribe.

To unsubscribe from this group and all its topics, send an email to 
blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/
chromium.org/d/msgid/blink-dev/CAFUtAY-p5%3DG7fpjWVFA_
5Z2saAUWdZcfjqG1CJJ6s9yUYsHRZA%40mail.gmail.com 
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-p5%3DG7fpjWVFA_5Z2saAUWdZcfjqG1CJJ6s9yUYsHRZA%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 on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3d2d63de-f82c-4b54-b7df-52a6ff26a142n%40chromium.org.

Reply via email to