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.
%20 is the URL-encoded form of a space; %25 is the URL-encoded form of the percent sign. The URL you are posting gets re-encoded and % becomes %25 (in the same way that a space becomes %20)
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.
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.
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.
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.