# [[Signal]] Blog https://signal.org/blog/ - Contains posts going back to [[2013]] ### Lots of posts about "Spring break of Code" "Winter break of code" etc - I'd love to participate sometime ## Censorship Circumvention https://signal.org/blog/doodles-stickers-censorship/ [[2016-12-21]] In countries with a small number of ISPs that all apply filtering rules defined by the state, circumventing censorship can be difficult. After all, they can always turn off network access entirely. The goal for an app like Signal is to make disabling internet access the only way a government can disable Signal. Today’s Signal release uses a technique known as **domain fronting**. Many popular services and CDNs, such as Google, Amazon CloudFront, Amazon S3, Azure, Cloudflare, Fastly, and Akamai can be used to access Signal [in ways that look indistinguishable from other uncensored traffic](https://www.bamsoftware.com/papers/fronting/). The idea is that to block the target traffic, the censor would also have to block those entire services. With enough large scale services acting as domain fronts, disabling Signal starts to look like disabling the internet. ### Update: [[Domain Fronting#Didn't work for Signal because Google and Amazon were cowards]] ## How to set up a TLS proxy for Signal ##### "Help users in Iran reconnect to Signal" https://signal.org/blog/help-iran-reconnect/ Link to repo: https://github.com/signalapp/Signal-TLS-Proxy ## Technology preview: Sealed sender for Signal https://signal.org/blog/sealed-sender/ [[2018-10-29]] *We have been exploring techniques to further reduce the amount of information that is accessible to the service, and the latest beta release includes changes designed to move Signal incrementally closer to the goal of hiding another piece of metadata: who is messaging whom.* ## Technology Preview: Signal Private Group System https://signal.org/blog/signal-private-group-system/ [[2019-12-09]] *Signal provides private groups: the Signal service has no record of your group memberships, group titles, group avatars, or group attributes. We’ve been working on new private group technology that will enable group administrators and access control, improve group scalability, and set the stage for a much richer group experience – all while maintaining Signal’s unique group security and privacy properties. We’re moving into the future while keeping what we loved about the past.* ## Sometimes once is better than a lifetime https://signal.org/blog/view-once/ [[2020-01-06]] *Today’s beta releases of Signal for Android and iOS include a new way to send individual photos and videos that are automatically removed from a conversation thread after they have been viewed.* ## Storage management for Signal Android https://signal.org/blog/storage-management-for-android/ [[2020-01-13]] *Signal for Android now includes storage management functionality that helps visualize files across all of your conversations, sorted by size and type, in order to assist you in reducing the amount of space Signal uses on your device.* ### Castles in the sandbox The Android environment is an interesting inversion of the typical Unix-inspired desktop environment. On the desktop, filesystem permissions are commonly segmented by “users.” Each user has a directory (e.g. `/home/alan`) where data can be stored, which is inaccessible to other users by default. This is largely a leftover practice from the days when people said the word “mainframe” out loud and when simpler multi-tenancy usage was more common, but it can be a somewhat outdated way of thinking about isolation given the direction computing has taken. Since many typical desktop environments now only have one user, there isn’t a lot of actual isolation happening at that level. And because the desktop isolation strategies were initially conceived of in terms of users, rather than the type of information those users were managing, nearly every desktop app can read data from almost every other desktop app, because they’re all being run by the same user. Android tweaked this model by making each app a “user” – which attempts to keep data from one app isolated from other apps (e.g. `/home/signal` and `/home/chrome` rather than `/home/alan/…`), while defining a more dynamic permission system for how apps interact with common data and each other. By default, Signal for Android stores files and media inside this sandbox rather than writing it to the public camera roll or other shared storage locations. ## Introducing Signal PINs https://signal.org/blog/signal-pins/ [[2020-05-19]] *In the latest version of our apps, we’re introducing Signal PINs. Signal PINs are based on [Secure Value Recovery](https://signal.org/blog/secure-value-recovery/), which we previewed in December, to allow supporting data like your profile, settings, and who you’ve blocked to be securely recovered should you lose or switch devices. PINs will also help facilitate new features like addressing that isn’t based exclusively on phone numbers, since the system address book will no longer be a viable way to maintain your network of contacts.* ## The Instagram ads Facebook won't show you https://signal.org/blog/the-instagram-ads-you-will-never-see/ [[2021-05-04]] ## Spam prevention on Signal https://signal.org/blog/keeping-spam-off-signal/ [[2021-11-01]] We build Signal in the open, with [publicly available](https://github.com/signalapp) source code for our applications and servers. To keep Signal a free global communication service without spam, we must depart from our totally-open posture and develop _one_ piece of the server in private: a system for detecting and disrupting spam campaigns. Unlike encryption protocols, which are designed to be provably secure even if everyone knows how they work, spam detection is an ongoing chore for which there is no concrete resolution and for which transparency is a major disadvantage. If we put this code on the Internet alongside everything else, spammers would just read it and adjust their tactics to gain an advantage in the cat-and-mouse game of keeping spam off the network. The Signal protocols, cryptography, and source code are peer reviewed, shared for independent inspection, and provably private by design. We are bound by these security guarantees, so that your conversations and contacts remain as private and protected as ever, even if we keep spam-fighting tools out of sight. The worldwide community of people using Signal has grown dramatically this year, and that growth has made Signal a more attractive target for enterprising scammers. We’ve been making adjustments to keep the Signal network free of spam, through minor changes to our client applications and with new server software to detect and disrupt spammers. Fighting spam without message content or social graphs is challenging, but we do so in a way that is in line with Signal’s commitment to privacy. ### Server Code and Spam Fighting Signal is designed from the [protocol level on upwards](https://signal.org/docs) such that client applications do not trust the server that is delivering end-to-end encrypted content. The server-side inspection that other platforms use to filter unwanted messages is not possible on Signal because we build our systems so nobody – not even Signal – can read your messages or [know who your contacts are](https://signal.org/blog/keeping-spam-off-signal/blog/private-contact-discovery/). We make all of that client code, library code, **and** server code [public](https://github.com/signalapp) for contributions and reviews. In a system without insight into message _content_, we rely on messaging _behavior_ to enforce limits on the service. When a user clicks “Report Spam and Block”, their device sends only the phone number that initiated the conversation and a one-time anonymous message ID to the server. When accounts are repeatedly reported as spam or network traffic appears to be automated, we can issue “proof of humanity” checks to suspicious senders so they can’t send more messages until they’ve completed a challenge. For example, if you exceed a configured server-side threshold for making requests to Signal, you may need to complete a CAPTCHA within the Signal application before making more requests. This approach slows down spammers while allowing regular messages to continue to flow. As our spam-fighting capabilities expand, so does the complexity and size of our spam-specific software. To prevent spam on Signal, we need to build this spam-battling logic in a separate server component. The interfaces to this code will be public, but the implementation will not be shared. We’re working hard to keep the amount of non-public code as small as we possibly can, and all other parts of the server software and all of its interactions with spam-fighting code remain available in the open. Keeping this small piece of software private helps us stay one step ahead of spammers and doesn’t change the fundamentals of Signal’s security model.