All that data sharing and sh.itjust.works mods and admins still haven’t removed the links to CSAM websites that I reported and messaged them about several months ago. They aren’t directly hosting CSAM, but the fact that they ignored the requests to take down the links in question is not particularly pleasing. (not sharing details publicly for obvious reasons)

Edit (1778443722): I messaged them on Matrix. The report was through the default reporting interface.

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.

The link mentions nuclear energy.

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.

Planners do a lot of preparatory work before laying cables, but based on the few articles and studies I could find online, it appears they rarely share their findings with the public.

Sabotage can also be carried out without submarines. For example, a ship could drag its anchor along the seabed (whether in the Baltic Sea or the Taiwan Strait) near known locations of internet cables.

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.

The DKTB is a personal app. It is therefore assumed, that the User will not share it with other people, and that only the User can access and control their personal DKTB. Ultimately, this means that all attestations in a DKTB are expected to pertain to and only be presented by the same User. This is enforced by requiring the user to authenticate using biometry or PIN-code when using the app and only allowing the DKTB application to be installed on one device per user. (from the PDF)

This is a false assumption: PIN codes can be bypassed by sharing them with others. Devices can be faked unless using hardware attestation, which prohibits any modifications to the device which may be undertaken by those interested in rooting or installing a custom OS.

Users can initially acquire a DKTB on their smartphone or tablet via Google Play or the Apple App store. (from the PDF)

This method requires the use of a vanilla, unmodified device, effectively prohibiting modifications to devices that one might wish to alter.