While such a "feature" would be great marketing for Firefox, I still think it should be opposed.

This API offers nothing to the end user, and can only be used to restrict the user. It is not in users' interests to implement it.

Furthermore, this specification is vague and the underlying mechanism is unclear.

Mozilla opposes this proposal because it contradicts our principles and vision for the Web.

Any browser, server, or publisher that implements common standards is automatically part of the Web:

Standards themselves aim to avoid assumptions about the underlying hardware or software that might restrict where they can be deployed. This means that no single party decides which form-factors, devices, operating systems, and browsers may access the Web. It gives people more choices, and thus more avenues to overcome personal obstacles to access. Choices in assistive technology, localization, form-factor, and price, combined with thoughtful design of the standards themselves, all permit a wildly diverse group of people to reach the same Web.

Mechanisms that attempt to restrict these choices are harmful to the openness of the Web ecosystem and are not good for users.

Additionally, the use cases listed depend on the ability to “detect non-human traffic” which as described would likely obstruct many existing uses of the Web such as assistive technologies, automatic testing, and archiving & search engine spiders. These depend on tools being able to receive content intended for humans, and then transform, test, index, and summarize that content for humans. The safeguards in the proposal (e.g., “holdback”, or randomly failing to produce an attestation) are unlikely to be effective, and are inadequate to address these concerns.

Detecting fraud and invalid traffic is a challenging problem that we're interested in helping address. However this proposal does not explain how it will make practical progress on the listed use cases, and there are clear downsides to adopting it.

Thanks @bgrins for this summary write-up. Per this analysis I’m going to label our position on this proposal as negative.

Since this is a proposal in a personal GitHub repo, and not standards track work nor in any open incubation group, there is no need for a dashboard entry. Closing accordingly.

(Originally published at: https://tantek.com/2023/205/t1/)

The API proposal mentions the "user" a lot. Has anyone actually asked real users and collected any statistics?

I actually am a user and I don't want this nor do I find it useful. They shouldn't try to deceive me saying that this is "for me", when it actually isn't.

So they actually borrow ideas from Decentralized Identifiers / Verifiable Credentials and want to force adoption by building this tech into the browser. Obviously Google's intent is to monopolize & profit, and less about "privacy", "user security", etc, which are just facade words.

Mozilla opposes this proposal because it contradicts our principles and vision for the Web.

Any browser, server, or publisher that implements common standards is automatically part of the Web:

Standards themselves aim to avoid assumptions about the underlying hardware or software that might restrict where they can be deployed. This means that no single party decides which form-factors, devices, operating systems, and browsers may access the Web. It gives people more choices, and thus more avenues to overcome personal obstacles to access. Choices in assistive technology, localization, form-factor, and price, combined with thoughtful design of the standards themselves, all permit a wildly diverse group of people to reach the same Web.

Mechanisms that attempt to restrict these choices are harmful to the openness of the Web ecosystem and are not good for users.

Additionally, the use cases listed depend on the ability to “detect non-human traffic” which as described would likely obstruct many existing uses of the Web such as assistive technologies, automatic testing, and archiving & search engine spiders. These depend on tools being able to receive content intended for humans, and then transform, test, index, and summarize that content for humans. The safeguards in the proposal (e.g., “holdback”, or randomly failing to produce an attestation) are unlikely to be effective, and are inadequate to address these concerns.

Detecting fraud and invalid traffic is a challenging problem that we're interested in helping address. However this proposal does not explain how it will make practical progress on the listed use cases, and there are clear downsides to adopting it.

I guess, even if " it contradicts our principles and vision for the Web.", it might happen just like the past:

@abdul It might. Yet please let's fight. Every epoch is unique. And a fight not fought is automatically lost.

Though I've disagreed with Mozilla's decisions or directions in the past, today I am very grateful for Mozilla's objection towards "Integrity API". I couldn't imagine the future of web if proposal like this getting accepted and implemented.

Just donated $100 to Mozilla.

Thanks for your contributions everyone, but I think we're straying a little bit off topic.