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
<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
<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
<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%2By7gDGdiWTKR832P7m2hH0p1VtxXqvnBxwYnAZ0AQjo4jQ%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-uykBNk1Vpd85sEzRXrKTroxcy5wowspF0hmSkugX4dEw_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>.
