diff --git a/content/posts/knowledge/Messengers.md b/content/posts/knowledge/Messengers.md
new file mode 100644
index 000000000..6d90ebb29
--- /dev/null
+++ b/content/posts/knowledge/Messengers.md
@@ -0,0 +1,61 @@
+---
+title: "Messengers"
+date: 2022-03-06
+tags: ['Knowledge base', 'Privacy', 'Security']
+author: madaidan
+---
+
+## Telegram
+
+[Telegram](https://telegram.org/) is [not end-to-end encrypted by default](https://telegram.org/faq#q-why-not-just-make-all-chats-secret), which allows the Telegram server to see all of your messages unless you use a "Secret Chat". Telegram uses [custom, unaudited encryption](https://core.telegram.org/mtproto), and the first version of MTProto had [severe security issues](https://eprint.iacr.org/2015/1177.pdf), although these were fixed with MTProto 2.0. However, Telegram still uses strange cryptographic primitives, such as AES-IGE, for "performance", although they use it in a way that they [aren't affected by its known security issues](https://core.telegram.org/techfaq#q-do-you-use-ige-ige-is-broken). Telegram has also been criticized by well-known cryptographers, such as [Moxie Marlinspike](https://news.ycombinator.com/item?id=6913456), [Matthew Green](https://x.com/matthew_d_green/status/726428912968982529)and [Filippo Valsorda](https://buttondown.email/cryptography-dispatches/archive/cryptography-dispatches-the-most-backdoor-looking/).
+
+Telegram has [held crypto cracking contests](https://telegram.org/crypto_contest), but these [were](https://www.schneier.com/crypto-gram/archives/1998/1215.html#contests) [rigged](https://archive.vn/SIl9M). Although the [clients are open source](https://telegram.org/apps#source-code), the server is not, so self-hosting is not a possibility. The creators of Telegram [have also spread unfounded misinformation](https://x.com/durov/status/872891017418113024) about competing apps before.
+
+Telegram, along with most other messengers, leak significant [metadata](https://en.wikipedia.org/wiki/Metadata) about your messages, even if the message itself was end-to-end encrypted.
+
+## Wire
+
+[Wire](https://wire.com/en/) [stores all metadata unencrypted on their servers](https://www.vice.com/en_us/article/gvzw5x/secure-messaging-app-wire-stores-everyone-youve-ever-contacted-in-plain-text), and [plans to correct this have not been acted on for several years](https://github.com/wireapp/wire/issues/214). Unlike Telegram, however, [Wire has been audited](https://wire.com/en/security/#audits), and its server code is [fully open source](https://github.com/wireapp/wire-server), allowing it to be self-hosted.
+
+Previously, Wire's privacy policy stated [they would only share user data when required by law](https://web.archive.org/web/20180324221043/https://wire.com/en/legal/#privacy-7), but they have quietly changed it to say that they will share data when "necessary". The ambiguity of this raises some red flags.
+
+## Threema
+
+Threema is a paid service that [claims to be more private and secure than Signal](https://web.archive.org/web/20211103081337/https://threema.ch/en/messenger-comparison).
+
+They have [downplayed security audits](https://arstechnica.com/information-technology/2023/01/messenger-billed-as-better-than-signal-is-riddled-with-vulnerabilities/) by saying that those audits refer to an older protocol and provide outdated advice. This fails to mention that this is because the researchers behind the audit revealed the vulnerabilities to Threema, and Threema then fixed them. Threema has also been [criticized](https://soatok.blog/2021/11/05/threema-three-strikes-youre-out/#summary-of-results) by the cryptographer Soatok.
+
+## XMPP
+
+[XMPP](https://xmpp.org/) is a federated protocol that allows encryption through OMENO. It has been [criticized by Soatok](https://soatok.blog/2024/08/04/against-xmppomemo/). He highlights how XMPP clients have outdated protocol implementations, how OMENO has vague design choices, and how the popular XMPP client [Conversations](https://conversations.im/) has security issues.
+
+## Matrix
+
+[Matrix](https://matrix.org) is another federated protocol that primarily features the [Element](https://element.io/)/Element X client. Soatok's [criticisms of Matrix](https://soatok.blog/2024/08/14/security-issues-in-matrixs-olm-library/) include lack of forward secrecy and vulnerabilities in Matrix's Olm library that he found easy to find. He also criticizes unsatisfactory attitudes by Matrix developers, who failed to address vulnerabilities that they knew for years.
+
+# Better Messengers
+
+These messengers have forward secrecy, post-compromise secrecy, and general security practices that make them stand out among the rest. However, as you'll see below, they are not perfect.
+
+## Signal
+
+[Signal](https://www.signal.org/) uses [audited and solid encryption](https://www.signal.org/docs/), conceals some metadata with [Sealed Sender](https://signal.org/blog/sealed-sender), has [private groups](https://signal.org/blog/signal-private-group-system), [has a better track record than most](https://signal.org/bigbrother/eastern-virginia-grand-jury/), and is recommended by several experts.
+
+To hide your phone number, you can use Signal usernames and change the Who Can See Your Phone Number setting to Nobody.
+
+Note that Signal [stores the encryption key in a plaintext file on macOS](https://github.com/signalapp/Signal-Desktop/issues/1017), and [has no plans to fix this](https://mastodon.world/@Mer__edith/112756436049179443). Signal [doesn't sandbox media or RTC](https://x.com/GrapheneOS/status/1905405000810889540#m), they haven't resolved [issues relating to outdated TLS proxies](/proxies/update-your-signal-tls-proxy/), and they haven't addressed a very severe and near-untraceable potential attack called [Careless Whisper](https://arxiv.org/pdf/2411.11194).
+
+# Molly
+
+Molly is an alternative Signal client for Android which allows you to encrypt the local database with a passphrase at rest, to have unused RAM data securely shredded, use SOCKS proxies to route your connection via Tor as an alternative to TLS proxies, and more. It also has usability improvements including scheduled backups, automatic locking, the ability to use your Android phone as a linked device instead of the primary device for a Signal account, and support for [UnifiedPush](https://unifiedpush.org/) through a [MollySocket](https://github.com/mollyim/mollysocket) instance. UnifiedPush can be especially useful with the Molly-FOSS client, which lacks proprietary code allowing support for battery-efficient notifications using Google Play Services.
+
+Note that Molly currently cannot address Signal's media and RTC sandboxing issues, and Molly is also vulnerable to Careless Whisper.
+
+## SimpleX
+
+SimpleX is a messenger that does not require user IDs to sign up. Some metadata leakage is mitigated through unidirectional [SimpleX queues](https://github.com/simplex-chat/simplexmq/blob/stable/protocol/simplex-messaging.md#simplex-queue), and SimpleX has been [audited](https://simplex.chat/blog/20241014-simplex-network-v6-1-security-review-better-calls-user-experience.html#simplex-cryptographic-design-review-by-trail-of-bits). 
+
+Note that SimpleX describes itself as decentralized, even though only [two entities are in charge of servers by default](https://simplex.chat/blog/20241125-servers-operated-by-flux-true-privacy-and-decentralization-for-all-users.html). SimpleX also claims to have some of the strongest metadata leakage protections, however [they do not see leaking IP addresses to the server as a problem](https://discuss.privacyguides.net/t/simplex-vs-cwtch-who-is-right/19256/112). Most messengers like Signal don't bother to hide your IP address from them, but IP addresses are metadata that SimpleX fails to recognize in importance.
+
+## Attributions (not endorsements)
+- [Privacy Guides - Real Time Communication](https://www.privacyguides.org/en/real-time-communication)
diff --git a/content/posts/linux/Linux Phones.md b/content/posts/linux/Linux Phones.md
new file mode 100644
index 000000000..2f832cc9d
--- /dev/null
+++ b/content/posts/linux/Linux Phones.md	
@@ -0,0 +1,46 @@
+---
+title: "Linux Phones"
+date: 2022-03-06
+tags: ['Operating Systems', 'Linux', 'Security']
+author: madaidan
+---
+
+Linux phones, such as the Librem 5 or Pinephone, are a major degradation from traditional mobile operating systems, such as Android or iOS. A few of the points in this article do apply to the Librem 5 specifically, but the majority applies to any Linux phone unless specified otherwise.
+
+Note that by Linux phones, we mean phones with OSs that rely on more traditional types of Linux distributions (for example, using systemd + polkit + glibc + GNOME, etc). Android phones use the Linux kernel and are technically just as much Linux phones as the phones mentioned above, but we are not referring to them that way for the sake of this article. Services presenting their products as "Linux phones" are using marketing to make consumers think that their phones are somehow more Linux than Android.
+
+Linux phones lack any significant security model, and most desktop Linux security issues apply to Linux phones fully. There is not yet a single Linux phone with a sane security model. They do not have modern security features, such as full system MAC policies, verified boot, strong app sandboxing, modern exploit mitigations and so on, which modern Android phones already deploy.
+    
+Distributions like PureOS are not particularly secure. They are mostly a reskinned Debian and do not include substantial hardening. While AppArmor is enabled, the majority of processes still run unconfined, so that is mostly negligible. PureOS [changes a few security-relevant settings](https://source.puri.sm/pureos/packages/pureos-security-hardening), but these are also mostly negligible:
+
+- PureOS does not apply the exec-shield patch, so that sysctl doesn't even exist in the first place.
+- The purpose of disabling kexec is to prevent root from booting a malicious kernel, but [root can do so many other things to modify the kernel](https://mjg59.dreamwidth.org/55105.html), such as loading a kernel module.
+- Attempting to hide kernel symbols via 'kptr_restrict' ignores the fact that they're clearly visible in the 'System.map' file on disk, among other sources.
+- And finally, disabling source routing is already a Debian default.
+
+PureOS also uses [linux-libre](https://en.wikipedia.org/wiki/Linux-libre). This will prevent the user from loading any proprietary firmware updates, which just so happens to be almost all of them. [The Librem 5 prevents the user from updating new firmware even with an alternative kernel](https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurdle/), which forces the user to use outdated and insecure firmware with known vulnerabilities.
+   
+The hardware itself lacks many modern security features too, such as [proper verified boot](https://source.android.com/security/verifiedboot/), [a hardware-backed keystore](https://source.android.com/security/keystore/) (some PGP smartcard is not equivalent), and more.
+
+Although one way to fix the issues in software would be to install a more sane OS like Android or its derivatives, such as GrapheneOS, if support for the hardware was added. Keep in mind though that it would still lack important hardware and firmware security features like verified boot, so it still isn't close to a normal Android device.
+
+These devices are also not open hardware/firmware unlike what they try to imply. The majority of the hardware/firmware is still proprietary.
+
+## Hardware Kill Switches
+
+Hardware kill switches are nothing but marketing frills.
+
+The microphone kill switch is useless since audio can still be gotten via the sensors (such as the [gyroscope](https://crypto.stanford.edu/gyrophone/files/gyromic.pdf) or [accelerometer](https://dl.acm.org/doi/pdf/10.1145/3309074.3309076)). While the Librem 5 does have a "lockdown mode" that disables the sensors, it also requires flipping all of the other switches, including the network switches, which effectively turns your device into a brick just to prevent audio recording. <br>
+
+The network kill switch has two primary threat models: preventing cell tower triangulation, or preventing data exfiltration after the device has been compromised. The switch is useless in either of these threat models:
+
+- To prevent cell tower triangulation, you can simply enable airplane mode and it is just as effective.
+- The network kill switch is useless for preventing data exfiltration since the attacker can just wait until you toggle the switch on again to exfiltrate data. If you need to temporarily disable network access, you can use airplane mode. Airplane mode can be disabled via a software vulnerability, but if an attacker has those capabilities already, then they can also simply sit and record any sensitive data and eventually upload it once you re-enable the hardware network kill switch, making it no more effective than airplane mode.
+
+The camera kill switch can be useful as a small usability improvement, but it is really no better than some tape.
+
+## Modem Isolation
+
+Modem isolation isn't anything special. For example, [Qualcomm SoCs have isolated the modem via an IOMMU for years](https://i.blackhat.com/USA-19/Thursday/us-19-Pi-Exploiting-Qualcomm-WLAN-And-Modem-Over-The-Air-wp.pdf), among others. The unorthodox way in which the Librem 5 attempt to isolate the modem is via the Linux kernel USB stack, which is not a strong barrier.
+
+There is also a lot of misinformation as to how the modem being on a separate chip means it's isolated — this is completely untrue. Just look at how, for example, [FireWire can be abused for DMA](https://en.wikipedia.org/wiki/IEEE_1394#Security_issues) while being completely separate from the rest of the hardware. Whether or not the modem is on a separate chip is irrelevant to if it's isolated.