Compare privacy claims vs anti-fingerprinting techniques

It's a stated goal of this proposal to provide a carrot for would-be privacy abusers, leading them toward a solution with different (and possibly better) privacy properties.

Unless I've missed something, it's taken for granted that the fingerprinting techniques will exist and these additional APIs will somehow provide a net privacy benefit. Could we get a comparison with best available anti-fingerprinting though? If the intention is really not to restrict users privacy, the baseline for comparison should be a browser configuration that focuses on privacy.

There is no privacy benefit here and almost certainly an effective worsening of privacy. Its possible the API will leak information that helps with fingerprinting in the form of the attester name, but thats not the larger concern here.

This API is about enforcing integrity of code from the viewpoint of the server. For most code nobody cares, but if that content is a bunch of malicious code (i.e. advertisements, trackers, etc...) this API ensures the integrity of that malicious code on behalf of its creator. Users who have protective addons that remove malicious javascript would now be required to disable those addons in order to view the page content, massively decreasing their safety and privacy in the process.

It doesn't help users in any way.

There are also a bunch of fake examples of "threats" in the explainer about how web client applications (browsers) are a threat to users when in reality the actual threat to users is the code hosted on web servers that this API proposal seeks to protect.

The only people who want client integrity are web "developers" who want to ensure their garbage runs unmolested by the user. If these people wanted a proposal that actually protected users we'd be talking about something like a web site/application integrity framework. Something to verify that the server is sending you code that hasn't been modified with an identity that the user can then decide to trust or not and then decide to run or not.

Almost every single new javascript API is harmful to users and this is one of the most harmful proposals in years.

If these people wanted a proposal that actually protected users we'd be talking about something like a web site/application integrity framework. Something to verify that the server is sending you code that hasn't been modified with an identity that the user can then decide to trust or not and then decide to run or not.

That is literally exactly what "these people" are talking about. See #4.

Jesus Christ, none of you even understand what you are complaining about.

Jesus Christ, none of you even understand what you are complaining about.

You could offer a more specific response than this strawman and swear.

The issue you filed and linked to is still talking about how app authors can look inside a user's system to check whether the JavaScript is running in an approved way. The issue I filed here is asking to solidify the privacy claims in this project's goals and to make comparisons against an actual privacy-respecting browser rather than Chrome.

What am I missing?

@scanlime This repo is currently being brigaded by frothing-mad zealots who do not understand the proposal and have been led to believe that their individual liberties are under attack. I wouldn't expect them to understand the proposal, though, since it's at such an early stage of development that the explainer doesn't do a great job. If you care, you could read the public AFCG minutes (https://github.com/antifraudcg/meetings) where you would see that not only is this not a secret plot by Google to oppress you, but that there are many privacy advocates there representing the public interest. But now instead of working on this proposal and expanding the explainer, we'll need to spend time cleaning the mess you all have made all over our repo.

Yeah so I'm not missing any context it sounds like. Nice work demonizing anyone who objects though. I'm trying to get to the bottom of the privacy claims in this ticket specifically, and I don't see how anyone could assume good faith from Google given the extremely flimsy veneer they've put over plainly anticompetitive ideas.

@michaelficarra Let me tell the story from South Korea.

In the early 2000, NSA was extremely picky about crypto export. The 40-bit crypto era. It leads to the ActiveX plugin development after the pwnage demo (I don't remember that exactly -- it happened when I was too young)

Problem solved? Definitely not!

They now want to verify the client machine is not infected by any malwares which taints the banking page. Exactly what this proposal wants to achieve.

They started to add integrity check using plugins. Taint the kernel to "check integrity of systems" while making more holes to be exploited in the process (if you are interested, see this awesome article by WPalant: https://palant.info/2023/01/09/touchen-nxkey-the-keylogging-anti-keylogger-solution/ ). That's how South Korean online banking and government websites literally screwed up. Rarely works on non-MSWindows box (they also decided to screw up the Mac and Linux with very same plugins, but they cannot taint the kernel in there), open a lot of holes for the bad actors, etc.

Your people have two choices

Follow the exact Korean way to screw up the whole internet. Let the browser run in the Kernel, dissolve the security barrier, let the new era of explpitation begin.

Make the world in the typical cyberpunk-style dystopia. Shady Megacorp (Yes, you Google, Apple!) decides what you run on your machine, lock out the systems from the owner, make the systems betray the owner, bring the dystopia in the world.

I think Google wants to solve the problem in the second way. What do you think?

By the way, my choice will be

Scrap this proposal and save the web.

If these people wanted a proposal that actually protected users we'd be talking about something like a web site/application integrity framework. Something to verify that the server is sending you code that hasn't been modified with an identity that the user can then decide to trust or not and then decide to run or not.

That is literally exactly what "these people" are talking about. See #4.

Jesus Christ, none of you even understand what you are complaining about.

At first I thought you just didn't understand the proposal, but it looks like the company you work for bills itself as being able to protect from bots so you're just being disingenuous. I can totally understand how the idea of client attestation must sound incredibly valuable to you. Forcing the client to do whatever you want regardless of user will must make you salivate at the mouth.

This is not code integrity in any way that would be beneficial to the user (i.e. code signing), this is client side enforcement of security demands by the server with the goal being that a server can be guaranteed that the code they sent is the code that's being run regardless of if the user wants to run it. Its trash and will overwhelmingly be used by bad actors (such as yourself) to make the web even worse than it is today.

@scanlime This repo is currently being brigaded by frothing-mad zealots who do not understand the proposal and have been led to believe that their individual liberties are under attack. I wouldn't expect them to understand the proposal, though, since it's at such an early stage of development that the explainer doesn't do a great job. If you care, you could read the public AFCG minutes (https://github.com/antifraudcg/meetings) where you would see that not only is this not a secret plot by Google to oppress you, but that there are many privacy advocates there representing the public interest. But now instead of working on this proposal and expanding the explainer, we'll need to spend time cleaning the mess you all have made all over our repo.

The explainer does a poor job because the uses cases are all nonsense. They're presenting this as beneficial to users which is a total lie. If they presented it truthfully (its a way to enforce server demands on a client regardless of user preference) then it would be even more transparently bad than it already is.

@scanlime This repo is currently being brigaded by frothing-mad zealots who do not understand the proposal and have been led to believe that their individual liberties are under attack. I wouldn't expect them to understand the proposal, though, since it's at such an early stage of development that the explainer doesn't do a great job. If you care, you could read the public AFCG minutes (https://github.com/antifraudcg/meetings) where you would see that not only is this not a secret plot by Google to oppress you, but that there are many privacy advocates there representing the public interest. But now instead of working on this proposal and expanding the explainer, we'll need to spend time cleaning the mess you all have made all over our repo.

I'm pretty sure that my individual liberties includes running any number of automated browsers in non-destructive manner, without indicating this fact to anybody, intercepting and modifying any kind of request my browser does, and modifying any script it runs in any way I feel acceptable to me.

Everyone understands that this proposal would not replace fingerprinting, but instead will become yet another data point in such fingerprinting.

If these people wanted a proposal that actually protected users we'd be talking about something like a web site/application integrity framework. Something to verify that the server is sending you code that hasn't been modified with an identity that the user can then decide to trust or not and then decide to run or not.

That is literally exactly what "these people" are talking about. See #4.

Jesus Christ, none of you even understand what you are complaining about.

This repo is currently being brigaded by frothing-mad zealots who do not understand the proposal and have been led to believe that their individual liberties are under attack.

@michaelficarra I've read the explainer, proposal, some recent meeting minutes, and your linked issue there. In https://github.com/antifraudcg/meetings/blob/ecce38b1ce1e280e2e26bccbcd66b3ae05d68ea4/2023/07-07-wei-side-meeting.md, there's discussion of device integrity and trusted execution environments:

Vinod: We cannot keep the ecosystem closed where only certain attesters are able to participate. Like what the FIDO alliance does for trusted computing hardware. Can we create criteria that are independently verifiable?

Philipp: Great question - lots of different ways to solve. FIDO alliance is one way. Another way is that within the feedback loop, there’s a way to origins to have some idea of attester quality. Feedback can help color the attester reputation

Brian: Attesters have a privileged relationship with device users. We would like to enable new issuers to come online. Allow clients to sign up with different issuers?

Philipp: We’ve thought about how to empower issuers, but a lot tdb. Can attester run in a trusted environment like a TEE? Maybe TEE + multiparty. Really you should just be proxying things between two parties.

If an attester for Web Environment Integrity is in a privileged relationship with me because of my device, I would like to have explained what privileges they'd be reasonably expected to exercise in the attestation process. The current web environment, an environment without WEI, only requires the user agent and the root TLS certificate authorities to have a privileged relationship with the user. Any proposal requiring that web users enter into additional privileged relationships should be scrutinized.

I would also like an explanation for why an attester should run in a trusted execution environment on my device. I get that you all are early in the drafting & discussion process, but trusted execution environments are also not to be required lightly, even if only some attesters would require TEEs. By requiring execution of code in a TEE, a user's freedom to execute code from the web however they desire (via the user agent of their choice) is restricted. This restriction deserves justification.

Now, quoting from that linked issue:

We don't have a specific request for what to include (or not include) in the attestation. Instead, our goal is to be able to bootstrap trust in other browser APIs. For example, we would like it to be hard for an attested environment to be under control of automation without that being indicated by the navigator.webdriver property. If the attestation can guarantee to us that the browser built-ins are original and being faithfully evaluated, it would allow the set of actual attested values to be small and remain stable over time – two very desirable properties. Anything else that needs to be trusted could be added through regular browser APIs without continually extending the APIs added by this proposal.

All users of the web currently have freedom of choice between user agents and their underlying platforms / devices, excluding cases like the South Korean banking system brought up earlier by @perillamint. What you're proposing here is that WEI should be usable to restrict a user's choice of user agents—user agents that allow browser built-ins to be mocked or otherwise evaluate outside of WHATWG standards in an environment should attest differently from browsers with built-ins evaluating to a level of WHATWG standards compliance in an environment. For this attestation to be practical, users must also be restricted from choosing user agents that manage to somehow evaluate built-ins in non-conformant ways but that also still manage to attest like browsers that are equivalent save for evaluating built-ins in conformant ways. If I have misunderstood anything here, please correct my misunderstandings.

However, if I have understood your feature request, you propose that user agents must restrict their technical capabilities in order to reliably interact with the full web. An automated user agent is still a valid user agent, and users currently have the freedom to automate their user agents as they please without that basic act condemning them to a subset of the web. Sites may currently try to detect automation through various means, successfully or unsuccessfully, but they do so currently via systems in user agents not designed for the purpose—systems that could potentially be redesigned in ways that prevent detection of automation while not preventing service of their core functionalities to users. Web Environment Integrity with your desired functionality, however, could not be redesigned in the same way to prevent detection of automation, because detection of automation would be one of the points. A user agent implementing WEI with script integrity functionality would serve the user sometimes by preventing the user from reliably automating their browser for certain tasks. WEI would not require that web sites prevent the user from doing anything, as WEI would only report the facts, but sites would also have the freedom to deny their functionality when attestation data reports potential automation. Additionally, a user's automation could sometimes succeed if holdback is included in WEI, their user agent decides to holdback, and the web site does not deny functionality in holdback conditions, but I also have to state that holdback is a continual rolling brownout for WEI over a subset of user agents. If sites accept temporary holdback conditions, and if WEI is successful in not leaking identifying information, then a user agent could be implemented to permanently holdback and this would be undetectable by sites. I would personally be very happy if WEI was designed so that it can be completely disabled if the user wishes with no loss in functionality across the web, but if that's the case, I would like an explanation for why WEI should ship at all.

As an example, say that Firefox implements WEI but in a way where it operates in perpetual holdback. Some web sites could then be reasonably expected to restrict functionality to user agents in WEI holdback, to apply pressure to Firefox to properly implement WEI, especially if, down the line, unintended tracking & detection methods in other web APIs are patched up. WEI would at this point become mandatory for a subset of the web. I would also like to know why the general user base of the web should be expected to believe that a subset of sites won't fail user agents practicing WEI holdback as soon as WEI attestations become available to them. There's a well documented history of overuse of attestation on Android. I would also like to quote RFC 8890: The Internet is for End Users, an RFC brought up by @rektide in #13:

4.4. Handling Conflicting End-User Needs

When the needs of different end users conflict (for example, two sets of end users both have reasonable desires), we again should try to minimize negative impact.

For example, when a decision improves the Internet for end users in one jurisdiction, but at the cost of potential harm to others elsewhere, that is not a good trade-off. As such, we design the Internet for the pessimal environment; if a user can be harmed, they probably will be, somewhere.

There may be cases where genuine technical need requires compromise. However, such trade-offs are carefully examined and avoided when there are alternate means of achieving the desired goals. If they cannot be, these choices and reasoning ought to be thoroughly documented.

I would like explained why WEI minimizes negative impact to all users of the web in the pessimal environment.

Thank you for your time.

@scanlime This repo is currently being brigaded by frothing-mad zealots who do not understand the proposal and have been led to believe that their individual liberties are under attack. I wouldn't expect them to understand the proposal, though, since it's at such an early stage of development that the explainer doesn't do a great job. If you care, you could read the public AFCG minutes (https://github.com/antifraudcg/meetings) where you would see that not only is this not a secret plot by Google to oppress you, but that there are many privacy advocates there representing the public interest. But now instead of working on this proposal and expanding the explainer, we'll need to spend time cleaning the mess you all have made all over our repo.

I work for a website that regularly deals with card testing attacks and processes millions of dollars in transactions a year for nonprofits

Pardon the expression, but this is batshit insane. I'd rather deal with card testing attacks daily than check the "integrity" of my user's browsers.

If these people wanted a proposal that actually protected users we'd be talking about something like a web site/application integrity framework. Something to verify that the server is sending you code that hasn't been modified with an identity that the user can then decide to trust or not and then decide to run or not.

Isn't that just TLS?

@scanlime This repo is currently being brigaded by frothing-mad zealots who do not understand the proposal and have been led to believe that their individual liberties are under attack. I wouldn't expect them to understand the proposal, though, since it's at such an early stage of development that the explainer doesn't do a great job. If you care, you could read the public AFCG minutes (https://github.com/antifraudcg/meetings) where you would see that not only is this not a secret plot by Google to oppress you, but that there are many privacy advocates there representing the public interest. But now instead of working on this proposal and expanding the explainer, we'll need to spend time cleaning the mess you all have made all over our repo.

You have offered nothing of substance here other than ad hominems. Perhaps this is an opportunity to stop and reflect on what you're doing, and your methods of communication. Because if you're trying to change people's minds, this is not the way to do it.

There's a glaring issue here that you seem almost willfully blind to: Google has absolutely blown their credibility in the area of user trust and safety. They can swear up and down that they're operating in good faith, but almost nobody believes them. And people have a good reason to not trust google, we've all seen google lie about this exact stuff before.

Berating and denigrating people who distrust google as "zealots" and idiots does nothing to accomplish your goals, and only spends down your reputation in the process.

explainers-by-googlers / Web-Environment-Integrity

Compare privacy claims vs anti-fingerprinting techniques #36