deleted by creator

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.

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.

Yes, it is visible when a new trusted device is added. The QR code you scan to link a device contains a one-time public key for that device (ECC is used partly to fit the public key more easily into a QR code). Signal on the phone then sends a lot of information, including the identity keys, to the new device. The new device uses these identity keys to communicate. Note that the transfer of identity keys is fully encrypted, with encryption and decryption taking place on the clients. This can, of course, be bypassed if someone you’re talking to has their security key compromised, but the same risk exists if the recipient takes a screenshot or photographs their device’s screen.

Edit: The security key refers to the one-time key pair generated to initiate the transfer of identity keys and chat history. It can be compromised if someone accidentally scans a QR code and transfers their identity keys to an untrusted device.

I assumed that not only the entire app but also the entire client device had been audited. This was a client-side attack, not Meta momentarily adding itself to the trusted-device list. I’m confident it was a client-side attack because it would be impossible to hide even a momentary change in keys from the client without modifying the client app to conceal such a change.

Even in an “insecure” app without air-gapped systems or manual encryption, creating a backdoor to access plaintext messages is still very difficult if the app is well audited, open source, and encrypts messages with the recipient’s public key or a symmetric key before sending ciphertext to a third-party server.

If you trust the client-side implementation and the mathematics behind the symmetric and asymmetric algorithms, messages remains secure even if the centralized server is compromised. The client-side implementation can be verified by inspecting the source code if the app is open source and the device is trusted (for example, there is no ring-zero vulnerability).

The key exchange itself remains somewhat vulnerable if there is no other secure channel to verify that the correct public keys were exchanged. However, once the public keys have been correctly exchanged, the communication is secure.

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.

If I understand the model you proposed correctly, it basically consists of making a payment to someone (whether an instance or a central authority), obtaining tokens in exchange, giving tokens to a content creator, and the content creator exchanging them to get their money back.

Having a central authority wouldn’t work because it goes against the principles of the Fediverse and most users would prefer that there not be a single point of failure. Having an instance exchange money for tokens wouldn’t work because there is no scarcity of tokens and no guarantee that an instance honours a request.

This method could instead be replaced by content creators adding links to receive payments with people giving money to them directly.

The problem is that there is nothing meaningful you can exchange this currency for. The Fediverse is fundamentally designed to allow anyone to start a server. There is no meaningful way to reward someone with anything of value except the satisfaction of having helped grow the instance they are supporting. There is no good way to boost someone without manipulating the vote count or changing the protocol itself. Many apps already offer customizability while simultaneously being free as in free beer and free as in free speech. The main reason many people move to the Fediverse is to escape an internet where everything is “enshittified,” and most Fediverse users wouldn’t want to shift to a proprietary model.

Is there a specific “undress” button? I tried looking for proof that it exists but couldn’t find any (my searching skills clearly need work). Could you please share a screenshot or point me to a place where I can confirm that it exists?

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.

That data might be easily accessible, but that was a choice Root made. I think that it is a safe assumption that Root knew most vigilantes keep their identity secret and, assuming a German background, had read Section 202 of the StGB and other relevant laws and court rulings. As such, Root most likely did this despite knowing their identity is at risk. It is likely they did this publicly specifically to inspire others, though I haven’t looked at all the details and there might be a different reason.

Nothing in this comment constitutes legal advice.

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)