# privacy-respecting: a two-file list where the editorial rule is a link behind every entry > This is a curated list of services that collect personal data and the alternatives to them, split across thirteen categories, and its one real standard is that every entry cites a source explaining why you would stop using the thing. That rule is what separates it from the many other lists of the same kind. The page covers three categories of the thirteen before it stops, and the part it does cover contains its sharpest argument, which is that end to end encryption and privacy are different properties. **nikivdev/privacy-respecting** — Curated List of Privacy Respecting Services and Software - Repository: https://github.com/nikivdev/privacy-respecting - Stars: 2,059 · Forks: 107 - Language: Unknown - License: not declared - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/nikivdev-privacy-respecting ## The rule is a citation behind every entry, not an opinion The framing paragraph says the list covers services described as free, in quotation marks, whose business model is to collect as much personal data about you as possible, and alternatives for anyone who cares about not losing control of their data. Then it states the editorial standard, and it is the only real standard on the page: the list is separated into topics, and each service or software listed comes with support for why you might want to stop using it, as well as alternatives and why you might want to switch to those. Look at how that plays out in practice rather than in the abstract. Google is not listed with the sentence Google collects data. It is listed with a linked article about what the company is projected to become. Bing is listed as owned by Microsoft. Facebook is listed with a linked page about what you should think about when using it. Instagram is listed as owned by Facebook. Yandex is described in the list's own words as Russia's version of Google. That is the difference between this and the hundreds of similar lists: the claim is never the author's, it is always somebody else's, and it is one click away. You can disagree with the conclusion and still have the evidence, which is the only way to be useful to a reader who already knows what they believe. It is worth noticing that the standard does not require the evidence to be scholarly. Mastodon's entry links a video explaining what Mastodon is. Steemit's links a magazine article. The bar is that a source exists, not that the source is peer reviewed. ## The strongest entry is the one about an encrypted messenger The messengers section opens with WhatsApp, and the entry is the best argument the list makes. It says WhatsApp uses the Signal Protocol, and therefore chats are end to end encrypted. Then it says that it nevertheless sends the user's entire contact book to Facebook servers, and that it is owned by Facebook. That structure is the whole list in one bullet. The encryption is real and it is specified, with a link to the protocol description. And it is irrelevant to the thing the list cares about, because the address book is not message content, so end to end encryption never applied to it, and it leaves the device. A reader who arrives from the phrase end to end encrypted and stops reading has concluded the opposite of the truth. Facebook Messenger gets a shorter entry, ownership only. And the alternatives bucket that follows runs to fifteen entries, which is the largest single block on the visible page: Signal, a fork of Signal based on SMS, a messenger that minimises metadata and needs no phone number, Element and its former name, Threema, Jami and its former name, Ricochet, Briar, Tox, Wire, Conversations on XMPP, a list of public XMPP services, Wickr, Semaphor and Vector. Two conventions are visible in that list and both are useful. Projects that have changed their names keep the old one in parentheses, so somebody searching for Riot or Ring finds the entry. And several entries state the protocol as the justification rather than the brand, which is what lets you reason about a fork you have not heard of. ## A third bucket for front-ends, which change the client and not the service Three of the visible categories add a bucket beyond products and alternatives, and one of them introduces a genuinely different axis. Search engines and social networks have the standard two buckets. Social networks adds a third for private front-ends, with seven entries: Invidious and Piped for video, Nitter for Twitter, Libreddit and Teddit for Reddit, Bibliogram for Instagram, and Beatbump for video music. The reason this deserves its own heading is that a front-end is not a different service. It is a different client for the same one. You keep the account, the history, the subscription and the social graph, and what changes is who sits between you and the company. That is a genuinely different trade from the one the rest of the list is offering, and a much smaller one to make, because nothing has to be migrated. The source links are what make the bucket useful rather than aspirational. Invidious, Piped, Nitter, Libreddit, Teddit and Beatbump all carry a code link, so you can see whether the thing is real and whether anyone is working on it. Those links are not all in one place: most point at GitHub, Teddit's points at Codeberg, and Bibliogram's points at a sourcehut address instead. And Bibliogram is also the one entry with broken markup, since its link wraps another link inside the link text and does not render as intended. So the bucket is a category where the answer depends on the health of somebody else's project, which is worth knowing before you move an account to one. ## A questionable bucket, which is where the list argues with itself The messengers section has a third heading of its own, and it is the one that makes this list worth more than a set of recommendations. It is called questionable, and it holds two entries. Keybase is described as end to end encrypted chat and a Dropbox alternative, with the problem stated in the entry itself: the backend is not open source, and it was merged with Zoom. Telegram is described as using its own mobile protocol, with two specific objections: group channels cannot be end to end encrypted, and private chats default to not being end to end encrypted. The Telegram entry is doing something specific and rarely done well. The list could have omitted it. Instead it names the protocol, which is real cryptography, and then names the two places where the property the protocol is famous for does not hold. A default is a design decision, so defaulting to no end to end encryption is a choice somebody made, and the list says so with a link to the project's own FAQ. Putting your own recommended services in a bucket headed questionable is a commitment to the reader's ability to check. It also means the list has a maintenance obligation it cannot delegate: a project that fixed its defaults would need its entry moved, and a project that did not would be listed forever as questionable. Nothing in the structure automates that. One small sign of how this is maintained: the same misspelling of formerly appears twice, in the entries for the two renamed projects, and the Keybase entry has a possessive where an adjective belongs. The content is careful and the copy editing is not, which is the usual state of a hand-maintained list. ## Two files, no license, no releases, and a default branch called master The repository contains two files. One is the list. The other is a contribution guide, which the page asks you to read before contributing. That is the whole project, and several consequences follow. There is no license file and the license field comes back empty, so the terms are unspecified. There are no releases and no tags, so there is no version to reference and nothing to pin. The default branch is called master rather than main. And there is no structured data of any kind: the entries are markdown, hand-maintained, with no schema, no identifiers and no per-entry timestamp, which means a tool cannot consume this list and a reader cannot tell when an individual entry was last checked. That last point is the one that matters most in practice. A list without entry-level dates ages unevenly. Some services change their privacy practices quietly; some front-ends break when an upstream site changes its interface; some ownership claims stay true for a decade. The list records what was true when somebody wrote the sentence, and it has no way to record when that was. The provenance is one click away rather than stated. The title of the page links to a different repository, a curated lists project, so the lineage is discoverable from the first line without the page explaining where this copy came from. And the list's own argument for existing is a link to an article on a blogging platform, written under the author's personal handle rather than the repository owner. That is a small inconsistency in a document whose entire method is holding services to what they do with your data. ## Thirteen categories, and the page stops inside the fourth The table of contents names thirteen categories: search engines, social networks, messengers, cloud storage, VPN, hosting, email, operating systems, browsers, video sharing, AI assistants, maps and navigation, and a closing category of related lists. Three of them are fully on the page. A fourth, messengers, stops partway through, in the second entry of its questionable bucket. So the majority of the list's coverage is not visible here, and the categories that are not on the page include the ones that change fastest. What can be said about the set of categories is more interesting than the entries themselves. Video sharing is its own category rather than an afterthought, which in a list of this kind means somebody decided that watching video is a distinct privacy question rather than a sub-case of social networking. Maps and navigation is also its own category, which matters because location is the hardest category to switch and usually the one nobody attempts. AI assistants appears as a category at all, which tells you the list has been updated for the current period rather than assembled once and abandoned, and that its author treats a model assistant as a service with a business model like any other. Hosting and email being separate categories rather than one is a sign of the same care. They are the two services a technically inclined reader is most able to run themselves, so they get their own sections instead of being folded into cloud storage. The closing category of related lists is worth noting for what it says about scope. This document does not try to be complete. It is one list among several, and it says so by pointing at the others. ## Conclusion Take this as a reading list with a discipline attached, not as a purchasing guide. The discipline is the valuable part: an entry that cannot link to something someone else wrote about why the service is a problem is not admitted, which means the list is checkable and you can disagree with a conclusion while keeping the evidence. Three things to know before you rely on it. First, it is hand-maintained markdown in two files with no structured data, so nothing here can be queried, diffed against a database or used by a tool; a stale entry stays stale until somebody notices. Second, it is a snapshot, and the categories tell you when it was written: thirteen of them including video sharing, AI assistants and maps, with no sense of which entries were reviewed when. Third, the front-end section is the part most likely to change underneath you, because a front-end for someone else's service breaks when that service changes. If you are deciding what to switch to, this is a good place to find candidates and a poor place to confirm that a candidate still works, since the entries describe what the service did, not what it does today. And if you want the same discipline in a different form, the contribution guide is the thing to read before adding anything, because the standard is the whole point. ## FAQ ### What is the nikivdev/privacy-respecting list? A hand-maintained markdown list of services whose business model collects personal data, together with alternatives, split across thirteen categories from search engines to maps and navigation. Its stated rule is that every entry comes with a source explaining why you might stop using the service. ### What does the privacy-respecting list say about WhatsApp? That it uses the Signal Protocol and so chats are end to end encrypted, that it nevertheless sends the user's entire contact book to Facebook servers, and that it is owned by Facebook. The entry is the list's argument that encryption of messages and control of your data are different properties. ### Why does the privacy-respecting list separate private front-ends? Because a front-end is a different client for the same service rather than a different service. Its video section lists Invidious, Piped, Nitter, Libreddit, Teddit, Bibliogram and Beatbump, most of them with a source code link, and the code links point at three different hosting sites. ### Which entries does the privacy-respecting list mark as questionable? In the messengers section it marks Keybase, whose backend is not open source and which was merged with Zoom, and Telegram, whose group channels cannot be end to end encrypted and whose private chats default to not being end to end encrypted. ### How do I contribute to the privacy-respecting list? The page asks you to read its contribution guidelines file first. The repository contains two files, the readme and that guide, has no license file, and publishes no releases or tags. ## Sources - [Issues](https://github.com/nikivdev/privacy-respecting/issues) - [nikivdev/privacy-respecting on GitHub](https://github.com/nikivdev/privacy-respecting) - [README](https://github.com/nikivdev/privacy-respecting/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nikivdev-privacy-respecting