counter-osint-guide-ru: a privacy handbook for the Russian internet

A handbook that admits it is unfinished

The repository description calls the guide an exhaustive one on privacy and counter-OSINT for the Runet and the whole post-Soviet space, and the title at the top of the readme names the subject directly: counter-OSINT, a guide to privacy and protecting your own data on the network.

What makes it a project rather than a document is the community around it. The readme credits the OSINT mindset community and links its Telegram channel, its YouTube channel, and a forum, and invites readers with remaining questions to join and write. The authors section at the bottom of the page lists four people with their avatars, so the authorship is public and credited rather than anonymous.

And the first thing a reader is told is that the guide is not finished. The readme says the document has not yet been completed, and asks people to watch the repository for updates or to follow the badges at the top, which show the date of the last commit and the commit activity. The badges are doing real work in that sentence: for a document that is still being written, the commit history is the changelog.

The guide also has an English version, in a separate repository. That split is worth noting, because it means the two are maintained independently rather than one being generated from the other, and it also means the language of the source is the language of the original.

The licence is Creative Commons Attribution-ShareAlike 4.0, and the readme spells out what that allows in plain terms: you may freely copy, distribute, and remix the contents, including commercially, as long as you give attribution and license derivative works under the same terms. For a handbook meant to be adapted for one's own situation, that is the right licence.

Organised by identifier rather than by tool

The table of contents is the most useful thing in the repository, and its shape is the argument of the whole guide.

It opens with an introduction and a chapter on why this matters, and then moves to what it calls basic digital hygiene, and that section is not a list of tools. It is a list of the pieces of data that make up a person in the eyes of a database: the phone number, the mailbox, the surname, given name and patronymic together with the date of birth, the address and location, the password, and the photograph.

That ordering is a deliberate argument. The usual privacy guides are organised by service, one chapter per platform, and the reader is left to work out which of their identifiers each service exposes. This one is organised by identifier, and the services come later, which means the reader works out how many places hold a phone number before they work out what to do about Facebook.

The Russian context makes the choice of identifiers read differently than it would in a Western handbook. A full name with a patronymic, a date of birth, and an address is a much richer identifier set in a country where those combinations are used for identity verification, and it is also a much more common requirement for accessing services. A guide that treats the name and the birth date as one unit, which is what the chapter title does by listing them together, is reflecting the local reality rather than importing a template.

The password chapter and the photograph chapter are the two that break the pattern a little, because they are about a single practice rather than a datum, and the photograph is the one that is most often overlooked, since a face is treated as a picture rather than as a data point until somebody points out that it can be matched against everything else.

Leaks, and working out where one came from

The section on data breaches is the longest in the table of contents, and it has three parts, which tells you the guide treats a breach as a process rather than as an event.

The first part is about identifying the source of a leak, which is a page of its own. When your data turns up somewhere, the useful question is not only what was exposed but through which of the dozen services you use it got there, because the fix is different for each. A guide that teaches the reader to trace a leak back to its origin is teaching a diagnostic skill rather than a precaution.

The second part is about canary tokens. A canary token is a value that looks like a secret, often a distinct email address or a unique string, that you give to one service and nowhere else. When it turns up in a leak, you know exactly which service leaked it, and when it never turns up, you know that service is still clean. It is a small technique with a large diagnostic value, and it is the kind of thing that a general privacy guide would leave out because it is too specific.

The third part is about complicating the use of leaked data, which is a more interesting idea. If the goal is to make a leak less useful to whoever obtained it, then the question becomes what shape your data has once it is out. The guide's framing is that the defensive move is not only to plug the leak but to change what the data would be worth if it leaked again.

The chapter is titled in the informal register of the rest of the readme, which is a reminder that this is a practitioner handbook written by people who work in the field, and that the register is deliberate rather than careless.

Platforms and mobile devices, chapter by chapter

The next two sections move to the things people actually use, and they are the longest part of the document by page count.

The mobile section is one chapter on the privacy of mobile applications, and the social section covers the networks and messengers with a chapter each for Facebook, Telegram, the Russian network, and Instagram. Each is a separate page, which is the right granularity, because the settings and the legal position differ per platform and a combined chapter would end up as advice that applies to none of them.

The order of the platform chapters is itself informative. Facebook and Telegram come first, then the Russian network, then Instagram, which is roughly the order in which these services are used in the region the guide is written for, and it shows that the author is writing for a specific audience rather than translating an English guide.

After the platforms there is a chapter on privacy for developers, which is the one chapter that changes register completely. A general audience chapter about a messenger is about settings and defaults, while a chapter for developers is about what you leak by accident: the identifiers your own application and your own infrastructure expose, the ways a test environment reaches production data, and the metadata that a deployment leaves behind. The other chapters in the guide are about being hunted, and this one is about being the one who does the hunting of its own users.

The final part of that section is a set of three chapters under a heading that translates as miscellaneous but important, and the topics are telling. One is about linking a phone number to an account, with the note in the title that it is not always a good idea. Another is about deleting information about yourself. The third is about screen sharing, which is a small operational security topic that most privacy guides leave out because it is not about the internet, and which is exactly the kind of habit that undoes every other precaution.

The country chapters, and why they are the hard part

The last structural section is the one that makes this guide specific rather than generic, and it is arranged by country.

There is a chapter for Russia, one for Ukraine, one for Belarus, one for Kazakhstan, and then a separate heading for Latin America with a chapter on Brazil. The post-Soviet grouping is the main one, and the Latin America section is listed after it as its own top-level heading, which suggests it is the beginning of an expansion rather than a peer set of the others.

The reason a privacy guide needs country chapters is that privacy is not only a matter of what settings you change on a service. It is a matter of what the law in your jurisdiction requires a service to hold, what the registration process asks you for, what the local payment and identity systems expose, and what your own state can compel. A reader in one of these countries is operating in a legal environment with its own data retention rules, its own identification requirements, and its own set of actors who are interested in the same identifiers that an advertising company would be.

The guide is explicit about the scope of the project in the description, which names the Runet and the entire post-Soviet space. That is a deliberate boundary rather than an accident of coverage, and it is a helpful one for a reader, because the advice in a country chapter is advice that only makes sense inside that country's legal and commercial reality.

There is also a small language point in the structure. The country chapters appear as sub-items of the post-Soviet heading while the Latin America chapter sits at the top level, so the table of contents itself records which regions the project considers its primary audience and which are being added later.

Editorial conclusion

This guide fits a reader in Russia or a neighbouring country who wants to understand what the identifiers in their own life add up to when combined, and who reads Russian faster than English. It does not fit an English-only reader, although an English version exists in a separate repository, and it does not fit anyone who wants a step-by-step hardening checklist for one specific platform, because the chapters are organised by category of data rather than by product. Verify first that the guide is still being written, since the readme says plainly that it is unfinished and asks readers to watch the repository for updates, and that the country-specific chapters match the jurisdiction you actually live in, since the registration, identification, and data retention rules differ from one of them to the next.

Frequently asked questions

Official sources

1. Issues
2. License: CC-BY-SA-4.0
3. README
4. soxoj/counter-osint-guide-ru on GitHub