Assuming a mechanism exists that changes the universe from being singly connected to multiply connected (i.e., wormholes exist), it is possible to have wormholes permitting faster-than-light travel without time paradoxes, though some additional restrictions may apply.

We have already shown that wormholes connect across both space and time, so that a trip between star systems could take you hundreds of years into the future, and the return trip takes you hundreds of years back in time. And this is even before we throw in how time slips between planets when considering relativistic time dilation due to different speeds and gravitational potentials.

Fortunately, all the weirdness of different time rates and going backward and forward in time can be ignored by the average person. This is because you never need to go from one world to another, or back, across the vast gulfs of interstellar space. You just take the wormhole between them. All you ever need to worry about is the coordinate frame that goes across the wormhole. When considering this reference frame, you’re not hopping all over the place in time. If it takes ten minutes to cross the wormhole between the two planets, when you get to your destination world the clocks will read ten minutes later than they did when you left your departure world. By coordinating their time-keeping across the wormhole network, all of the worlds of the network can agree on a common time to coordinate their activities. This is all travelers ever need to worry about, and they can then ignore all the relativistic weirdness. Your network engineers will still need to keep track of relative time drift and how close a given configuration is getting to a time loop. But unless your protagonist is a network engineer, they can just ignore all that stuff. And, as an author, so can you! Assume your engineers are competent, you have good regulatory bodies and standards institutions, and don’t worry about any of this “time travel” that doesn’t actually let you cause paradoxes.

source: Galactic Library

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.

There is no central location to donate to open source software in general. Most open source projects include donation details on their website or in their code repositories.

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.

I assume that trolls try to provoke erratic and disproportionate reactions from others, becoming a part of their own miniature sitcom for their own entertainment. It could be because of a sense of victory upon watching others break down (assuming a zero sum point of view). It could be the viewpoint that trolls are at their own higher level compared to others and understand each other while making fun of the lower levels (a false sense of superiority). Maybe it’s a [case of] holding onto their own beliefs and assuming that they needn’t change themselves if they disrupt all conversations that may cause harm to their own beliefs. It might be attention seeking or an escape mechanism. It could also be a desire to avoid fitting in with everyone else and remaining separate.

(edit: grammar)

There are some generic observations you can use to identify whether a story was AI generated or written by a human. However, there are no definitive criteria for identifying AI generated text except for text directed at the LLM user such as “certainly, here is a story that fits your criteria,” or “as a large language model, I cannot…”

There are some signs that can be used to identify AI generated text though they might not always be accurate. For instance, the observation that AI tends to be superficial. It often puts undue emphasis on emotions that most humans would not focus on. It tends to be somewhat more ambiguous and abstract compared to humans.

A large language model often uses poetic language instead of factual (e.g., saying that something insignificant has “profound beauty”). It tends to focus too much on the overarching themes in the background even when not required (e.g., “this highlights the significance of xyz in revolutionizing the field of …”).

There are some grammatical traits that can be used to identify AI but they are even more ambiguous than judging the quality of the content, especially because someone might not be a native English speaker or they might be a native speaker whose natural grammar sounds like AI.

The only good methods of judging whether text was AI generated are judging the quality of the content (which one should do regardless of whether they want to use content quality to identify AI generated text) and looking for text directed at the AI user.

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?

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.

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.