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
<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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
<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
<mailto: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>.
