See https://coveryourtracks.eff.org/ with Tor set to the Safest setting. The user share for Tor might be very small. However, because all Tor users have the same configuration, it doesn’t matter whether a fingerprint differs from Chrome. Among the x% of Tor traffic, x% traffic shares the same fingerprint. Chrome might account for y% of the traffic where each user has a unique fingerprint. But as long as x is not negligible, the fact that you’re using Tor provides very few bits of information (as an example, about 8 bits of identifying information) compared to a unique fingerprint (which provides much more information). I agree that Tor is not without its flaws, but saying that Tor deanonymizes you because of its user share is wrong. Also, please note that the EFF link I shared may be biased in the data it collects.

A Layer-3 (network-layer) blacklist risks cutting off innocent CGNAT and cloud users. What you’re proposing is similar to mechanisms that already exist (e.g., access control lists at the ISP level work by asking computer B which requests it wants to reject and rejecting those that originate from computer A). However, implementing any large-scale blocking effort beyond the endpoint (i.e. telling an unrelated computer C to blackhole all requests from computer A to computer B) would be too computationally expensive for a use case as wide and as precise as “every computer on the Internet”.

Also, in your post you mentioned, “A host would need to have a way to identify itself as authoritative, responsible for the IP address in question.” This already happens in the form of BGP though it doesn’t provide cryptographic proof of ownership unless additional mechanisms are in use (RPKI/ROA).

If you mean an anonymous account from an email service trusted by other online service providers, it’s not possible to get one for free. Even among paid email providers, very few accept anonymous payment methods such as cash or XMR.

Could the app be using cell tower data to bypass mock location settings? The Github repository says it identifies a user’s location using cell tower data.

It’s most likely an error with the nozzle height. The PEI plate not heating up enough shouldn’t cause the adhesion in the photo above (and this is not a first layer problem, as the error is not at a uniform height). Additionally, a few lines are very faintly visible on the plate where they shouldn’t be, indicating nozzle height. Make sure that it is easy to move a piece of paper between the nozzle and the PEI plate when adjusting the height, feeling only a very small amount of pressure as you do so.

TL;DR: not possible with random cookies, too much work for too little gain with already-verified cookies

There is no such add-on because random cookies will not work. Whenever someone has been authenticated, Google decides the cookie the browser should send out with any subsequent requests. Google can either choose to assign and store a session id on the browser and store data on servers or choose to store the client browser fingerprint and other data in a single cookie and sign this data.

Additionally, even with a verified session, if you change your browser fingerprint, it may trigger a CAPTCHA, despite using a verified cookie. In the case of a session token, this will occur because of the server storing the fingerprint associated with the previous request. On the other hand, if using a stateless method, the fingerprint will not match the signed data stored inside the cookie.

However, this could work with authenticated cookies wherein users contribute their cookies to a database and the database further distributes these cookies based on Proof of Work. This approach, too, has numerous flaws. For instance, this would require trusting the database, this is a very over engineered solution, Google doesn’t mind asking verified users to verify again making this pointless, it would be more efficient to simply hire a team of people or use automated systems to solve CAPTCHAS, this approach also leaks a lot of data depending on your threat model, etc.

Orca works great on Debian 13 for me (I installed it as a Flatpak)