S4M — приватная сетевая инфраструктура: VPN и прокси

01Обзор проекта

S4M — это приватная сетевая инфраструктура, собранная в один продукт: VPN на WireGuard и OpenVPN для всего устройства, аутентифицированные SOCKS5/HTTP-прокси для скриптов и автоматизации, выделенные статические IP и собственные приватные серверы. Всё живёт в одном аккаунте, с одним биллингом и одной точкой управления. Позиционирование умещается в две короткие фразы с главной страницы: «Hide your real IP. Own your privacy» — спрячьте свой реальный IP и владейте своей приватностью.

Важно сразу зафиксировать рамку. S4M — это инструмент приватности для легитимных задач: защитить автоматизацию и origin-сервер от раскрытия адреса, ходить по собственным целям мониторинга, не «светя» боевым IP, и приватно пользоваться сетью с любого устройства. Именно так продукт описывает себя сам: ваша автоматизация и ваш сервер остаются невидимыми — третьи стороны видят узел выхода, и только его. Никаких обещаний «обойти» или «обмануть»: это инфраструктура, которая закрывает вопрос происхождения трафика так же буднично, как CDN закрывает вопрос доставки.

Мы спроектировали и собрали S4M целиком — сетевую архитектуру с двумя плоскостями (VPN и прокси), учёт потребления, кабинет и биллинг, публичный каталог бесплатных прокси с непрерывной проверкой, документацию, гайды и трёхъязычный сайт (EN/UK/RU). Ниже разбираем, из чего состоит продукт, как согласуются no-logs и коммерческая тарификация и почему формула «два продукта — один защищённый выход» оказалась стержнем всей архитектуры.

И ещё один слой контекста. S4M — продукт собственной экосистемы студии, и он не остался витриной: сегодня через его аутентифицированный SOCKS5-выход идёт весь серверный исходящий трафик остальных наших продуктов — от HTTP-вызовов к внешним API до отправки почты. То есть инфраструктура, о которой этот кейс, каждый день работает в нашем собственном проде — и это лучший тест, который мы могли ей устроить.

02Контекст и задача

Спрятать IP «технически» несложно — сложно превратить это в инфраструктуру: надёжную, управляемую и честную по отношению к пользователю. Когда мы раскладывали задачу, набрался характерный список болей, знакомый каждому, кто работает с сетью всерьёз:

• Origin-сервер раскрывает себя. Каждый исходящий HTTP-вызов и каждое отправленное письмо показывают третьей стороне реальный адрес сервера — а по адресу находят хостинг, соседние сервисы и поверхность для атак.
• Зоопарк инструментов. VPN для людей и прокси для машин традиционно живут в разных продуктах: две учётки, два биллинга, две поддержки — и ни одного общего контроля потребления.
• Публичные прокси ненадёжны. Бесплатные списки быстро умирают, не имеют аутентификации, их анонимность неизвестна. Для быстрого теста годятся, для работы — нет.
• Лимиты постфактум. Обычно потребление считают по журналам в конце периода: превышение замечают, когда оно уже случилось. Для сетевого продукта это слишком поздно — и слишком дорого.
• Приватность на словах. «Мы не храним логи» в политике конфиденциальности — не то же самое, что архитектура, в которой журналов активности физически не возникает.

Задача формулировалась так: собрать единую сетевую инфраструктуру, где VPN и прокси — две плоскости одного продукта, где отсутствие логов — свойство конструкции, а не абзац юридического текста, и где лимиты применяются в реальном времени на самом узле. При этом продукт должен оставаться простым снаружи: аккаунт за секунды, конфиг или реквизиты в пару кликов, проверка результата одной командой.

Отдельный пласт — доверие. Privacy-продукт продаёт именно его, и заработать доверие можно только честностью: прямо говорить, что бесплатные публичные прокси — это тест, а не прод; что анонимная регистрация — опция, а не обман биллинга; что no-logs — это про то, чего сервер не записывает, а не про то, чего он «не покажет». Эта честность закладывалась в тексты, интерфейсы и FAQ с самого начала — как продуктовое требование, а не как тон-оф-войс.

03Цели проекта

Из задачи выросли конкретные цели, которые мы удерживали на всех этапах — от схемы узлов до текстов на посадочной:

• Одна учётка — два продукта. VPN и прокси делят аккаунт, биллинг и панель управления; пользователь не собирает конструктор из разных сервисов.
• No-logs by design. RAM-first узлы и ключи WireGuard на стороне пользователя: отсутствие журналов активности — свойство архитектуры, а не пункт политики.
• Контроль на проводе. Тонкие лимиты per plan / per IP / per account применяются в реальном времени на самом узле, а не постфактум по логам.
• API-first. Всё, что можно сделать в кабинете, можно сделать программно: REST API и токены доступны с базового тарифа.
• Предсказуемая тарификация. Фиксированная месячная плата за VPN, метеринг за прокси-трафик, выделенный IP как аддон — без скрытых наценок.
• Анонимность как опция. Регистрация без личных данных, оплата картой или криптовалютой, отмена в любой момент.

Как и в других наших продуктах, цели сформулированы как ограничения — и каждое из них отсекало архитектурные варианты ещё на бумаге. No-logs исключил классические биллинг-пайплайны, построенные на разборе логов: раз журналов нет, учёт обязан быть потоковым и жить на узле. Контроль в реальном времени запретил выносить лимиты в «ночной пересчёт». А API-first продиктовал, что кабинет — просто клиент того же API, который получают пользователи: у нас физически не может быть возможности, доступной из панели, но недоступной программно.

04Что мы сделали

S4M складывает приватную сеть из четырёх продуктовых блоков, которые закрывают весь спектр — от «спрятать ноутбук» до «спрятать парк серверов»:

Поверх этих блоков — кабинет с управлением конфигами, реквизитами и лимитами, биллинг с оплатой картой или криптовалютой, REST API с токенами, набор гайдов и сравнений и трёхъязычный сайт. Всё вместе — один продукт с одной моделью данных, а не четыре сервиса под общей вывеской.

Ключевое свойство — связность. Одна учётка порождает и VPN-конфиг, и прокси-реквизиты; выделенный IP подключается к любой из плоскостей; учёт потребления один и тот же, в каком бы виде трафик ни выходил. Пользователь думает категориями «спрятать устройство» или «спрятать скрипт», а не категориями «какой из моих пяти сервисов за это отвечает».

05Архитектура: два продукта — один выход

Внутри S4M «два продукта» — это две плоскости данных над общим ядром:

• VPN-плоскость — WireGuard и OpenVPN: шифрует всё устройство целиком. Пользователь скачивает готовый конфиг и подключается в один тап на любой платформе.
• Прокси-плоскость — аутентифицированные SOCKS5- и HTTP-эндпоинты: проводят через выход отдельное приложение или скрипт. Идеально для автоматизации, где VPN на всю машину избыточен.
• Общее ядро — аккаунты, тарифы, лимиты, учёт потребления и выдача реквизитов: единая модель данных, которой подчиняются обе плоскости.

Второе разделение — управление и данные. Control plane (кабинет, API, биллинг) решает, кому что можно: создаёт доступы, назначает лимиты, считает деньги. Data plane (узлы выхода) исполняет: терминирует WireGuard/OpenVPN-сессии, авторизует прокси-соединения и применяет лимиты прямо на проводе. Узлы устроены как RAM-first: рабочее состояние живёт в памяти, а не в долговременных журналах — это фундамент no-logs, о котором подробно ниже.

И третья идея, вынесенная в заголовок раздела: один выход. Чем бы пользователь ни пользовался — VPN-туннелем для ноутбука или SOCKS5 для парсера — снаружи виден один и тот же класс сущности: exit-узел S4M. Третья сторона видит адрес выхода и никогда — адрес источника. Одна модель выхода означает одну модель безопасности, одну модель учёта и одно место, где применяются правила.

Наконец, архитектура с самого начала проектировалась под расширение линейки. Выделенный персональный IP — это не отдельный продукт, а атрибут, который привязывается к любой из плоскостей: тот же VPN или те же прокси, но со стабильным адресом, принадлежащим только вам. Приватный сервер — логическое продолжение: персональный узел данных в той же модели управления, без общего выхода и без соседей. Ни один из этих шагов не потребовал ломать ядро — они ложатся в него по построению.

06Как это работает: три шага

Весь путь от «у меня виден IP» до «IP скрыт» продукт формулирует как «приватность в три шага» — и это не маркетинговое упрощение, а реальный сценарий онбординга:

• 1. Создайте аккаунт. Регистрация за секунды — по email или полностью анонимно, без личных данных.
• 2. Выберите VPN или прокси. Скачайте конфиг WireGuard/OpenVPN для своего устройства — или возьмите реквизиты SOCKS5/HTTP-прокси для скрипта.
• 3. Подключитесь. Трафик выходит через узел S4M: третьи стороны видят узел выхода — и никогда ваш реальный IP.

Отдельно мы добивались того, чтобы результат был проверяем одной командой. Направьте любой инструмент через прокси S4M — и адресат увидит только выход: curl --socks5 USER:PASS@узел:1080 https://api.ipify.org возвращает адрес exit-узла, а не вашего сервера. Работает с curl, Python, Scrapy и любым браузером; проверка против api.ipify.org занимает секунды. Этот терминальный блок вынесен прямо на главную страницу продукта: лучший аргумент в пользу инфраструктуры — показать её работу, а не описать её.

«Время до приватности» мы с самого начала рассматривали как продуктовую метрику. Если между регистрацией и скрытым IP лежит переписка с поддержкой, ручная настройка или изучение мануалов — продукт проиграл, каким бы сильным ни было ядро. Поэтому конфиги генерируются готовыми под платформу, реквизиты прокси выдаются сразу в формате «вставь в команду», а сценарий онбординга укладывается в минуты — от пустой формы регистрации до проверенного чужого адреса в ответе ipify.

07Ключевые возможности

Разберём то, что делает S4M не «ещё одним VPN», а сетевой инфраструктурой продакшн-уровня.

VPN на WireGuard и OpenVPN

Два протокола покрывают весь спектр устройств и сетей: современный аудированный WireGuard как основной и OpenVPN как совместимый запасной. Конфиг выдаётся в один тап под каждую платформу, тарификация — фиксированная месячная плата без сюрпризов. В комплекте — kill-switch, split-tunnel и DNS-фильтр рекламы, трекеров и малвари: VPN закрывает не только адрес, но и фоновый шум слежки.

Аутентифицированные SOCKS5 и HTTP-прокси

Датацентровые прокси с авторизацией по логину и паролю: реквизиты — только ваши, случайный трафик через ваш эндпоинт не пойдёт. Прокси-трафик тарифицируется по потреблению — платите за то, что реально использовали. Это рабочий инструмент для скрапинга собственных целей мониторинга, автоматизации и любых серверных задач, где происхождение запроса не должно указывать на боевую машину.

Выделенные персональные IP

Статический адрес, который принадлежит только вам: заказывается как аддон, привязывается к VPN или к прокси и — по желанию — не связывается с вашей личностью. Стабильный выход нужен везде, где адрес попадает в белые списки или где репутация IP должна зависеть только от вас.

Приватные серверы

Верхняя ступень изоляции: собственный сервер с собственным IP в выбранном регионе, с WireGuard/OpenVPN и той же no-logs дисциплиной. Без общего выхода и без соседей — весь узел работает на одного клиента.

Аккаунт, оплата, отмена

Регистрация по email или анонимная, оплата картой или криптовалютой через платёжного партнёра, отмена в любой момент. Приватность начинается с того, что продукт не требует от пользователя больше данных, чем нужно для работы.

Управление потреблением

Тонкие лимиты per plan, per IP и per account, применяемые на проводе в реальном времени. Это одновременно и защита инфраструктуры, и конструктор тарифов — подробно разбираем в разделе 09.

08No-logs и приватность как инженерия

Главный принцип S4M — не знать лишнего. Узлы выхода построены как RAM-first: рабочее состояние — сессии, соединения, счётчики — живёт в оперативной памяти и не оседает в долговременных журналах. История браузинга не записывается вовсе: не потому, что «мы обещали», а потому, что в конструкции узла для неё нет места назначения.

Второй столп — ключи на стороне пользователя. WireGuard-ключи контролирует владелец аккаунта, прокси-реквизиты принадлежат только ему. Инфраструктура аутентифицирует и маршрутизирует, но не претендует на владение идентичностью клиента. Сюда же — анонимная регистрация и оплата криптовалютой: связка «аккаунт ↔ личность» существует ровно настолько, насколько её захотел создать сам пользователь.

Такой дизайн меняет модель угроз в правильную сторону. Ценность узла для любого злоумышленника или любопытствующего определяется тем, что на нём хранится, — а RAM-first узел хранит операционный минимум. Мы сознательно проектировали систему от вопроса «что останется на диске в худший день?» и добивались ответа «ничего, о чём стоит говорить». Это же дисциплинирует и сам продукт: никакие «временные» отладочные логи с адресами пользователей не могут появиться незаметно, потому что им противоречит базовая конструкция.

09Контроль потребления на проводе

Самая интересная инженерная развилка проекта — согласовать два требования, которые на первый взгляд исключают друг друга: no-logs и коммерческий учёт. Классический метеринг строится на разборе логов: собрали журналы, посчитали, выставили счёт, заметили злоупотребление. Но журналов у нас нет — значит, учёт обязан жить в другом месте.

Ответ S4M: считать на проводе. Узел ведёт потоковые счётчики прямо в момент обслуживания соединения — байты и число сессий, агрегатами по аккаунту, тарифу и IP. Считается объём, а не содержимое; счётчики, а не события; агрегаты, а не история посещений. Этого достаточно и для биллинга, и для лимитов — и это не создаёт ни одной записи вида «кто куда ходил».

Лимиты применяются там же и тогда же: per plan, per IP, per account — в реальном времени. Разница с постфактум-моделью принципиальна. Биллинг «в конце месяца» замечает превышение, когда трафик уже ушёл и деньги уже потеряны; лимит на проводе — это часть протокола обслуживания: соединение либо укладывается в правила, либо не обслуживается. Инфраструктура защищает себя сама, в момент события, а не письмом постфактум.

Для администратора та же механика оборачивается конструктором тарифов: план — это набор лимитов, а не строка в прайсе. Изменение правил доезжает до узлов и начинает действовать на живых соединениях — без перевыпуска реквизитов и без «вступит в силу со следующего цикла».

10Бесплатный список прокси как продукт

Отдельный продукт внутри продукта — живой каталог публичных прокси: сотни работающих SOCKS5/HTTP/HTTPS-адресов (порядка восьмисот; число постоянно плавает) в 79 странах, с фильтрами по стране, протоколу и уровню анонимности. В отличие от статичных «списков из интернета», каталог S4M проверяется непрерывно: мёртвые адреса выпадают, живые — подтверждаются заново.

За витриной стоит собственный конвейер: краулер собирает кандидатов из открытых источников, а чекер по кругу перепроверяет каждый адрес — жив ли, каким протоколом отвечает, какую анонимность обеспечивает и из какой страны выходит. Результат — не «список на сегодня», а живой срез состояния публичного прокси-пространства, где у каждой записи есть свежая отметка проверки. Именно эта непрерывность и есть продукт: сам по себе список адресов не стоит ничего, ценность в том, что он всегда актуален.

В экономике продукта каталог играет роль честной воронки. Он полезен сам по себе и приводит аудиторию, которой сетевые инструменты уже нужны, — а дальше продукт не давит, а объясняет. Прямо в интерфейсе и FAQ сказано: публичные прокси — это сторонние серверы из открытых источников, они хороши для быстрого теста, но не для чувствительного трафика, используйте на свой риск. Рядом — трезвое сравнение: аптайм, скорость, аутентификация, гарантированная анонимность, выделенный IP, контроль потребления и поддержка есть только в платной части. Пользователь сам доходит до вывода, к которому его никто не подталкивал силой.

11Выделенные IP и приватные серверы

Выделенный персональный IP в S4M — это полноценный жизненный цикл, а не строка в тарифе. Адрес заказывается из кабинета, выдаётся как статический и персональный — им пользуетесь только вы, — и привязывается к любой из плоскостей: к VPN, чтобы устройство всегда выходило с одного адреса, или к прокси, чтобы автоматизация имела стабильную точку выхода. По желанию адрес оформляется без связи с личностью владельца — приватность распространяется и на сам факт владения ресурсом.

Зачем это нужно, понятно любому, кто работал с белыми списками: динамический выход хорош для приватности, но плох для систем, которые ждут вас с известного адреса. Персональный статический IP решает обе задачи сразу — происхождение трафика скрыто за выходом, но сам выход постоянен и его репутация зависит только от вашего собственного трафика, а не от поведения соседей по пулу.

Верхняя ступень линейки — приватный сервер: собственный выделенный узел с собственным IP в выбранном регионе OVH, с WireGuard/OpenVPN на борту и той же no-logs дисциплиной. Без общего выхода и без соседей: вся пропускная способность, вся репутация и весь узел принадлежат одному клиенту. Архитектурно это тот же data plane, что и общие узлы, — просто развёрнутый персонально, поэтому панель, лимиты и учёт работают с ним без единой оговорки.

12Опыт разработчика и API

S4M строился как API-first продукт: всё, что видно в кабинете, доступно программно. REST API с токенами открыт с базового тарифа — создание и чтение ресурсов, конфиги, реквизиты, потребление. На старших тарифах добавляются вебхуки и повышенные лимиты API, а для тех, кто строит на S4M собственный сервис, — white-label и реселлерские суб-аккаунты. Провижининг доступа — это вызов API, а не тикет в поддержку.

Опыт разработчика мы мерили простым тестом: сколько строк отделяет реквизиты от работающего кода. Ответ — одна: та самая команда curl с ключом --socks5. Прокси работают с curl, Python, Scrapy и любым браузером без специальных SDK — это стандартные протоколы, а не проприетарная обёртка. Проверка выхода — мгновенная, против api.ipify.org. Вокруг этого собрана библиотека гайдов: как скрыть IP сервера, чем VPN отличается от прокси, что такое SOCKS5, датацентровые против резидентных — документация работает и как обучение, и как органический вход в продукт.

Самая показательная интеграция — наша собственная. Экосистема Ostohlo переводит весь серверный исходящий трафик своих продуктов через аутентифицированный SOCKS5-выход S4M: каждый HTTP-вызов к внешнему API и каждая отправка почты уходят через exit-узел, и IP origin-серверов не касается сторонних хостов вовсе. S4M здесь — не «дополнительная защита», а штатный egress-слой, через который живёт продакшн.

Эта интеграция дала продукту то, чего не даёт ни один тестовый стенд: требования реального прода. Стабильность выхода, предсказуемые реквизиты, поведение лимитов под непрерывной нагрузкой — всё это проверялось не синтетикой, а живым трафиком сервисов, которым нельзя падать. Каждая шероховатость API сначала била по нам самим — и чинилась до того, как её увидел бы внешний пользователь.

13Технологический стек и инфраструктура

Под S4M собрана отдельная среда с чётким разделением: панель и биллинг — своим контуром, узлы выхода — своим. Управление ничего не знает о содержимом трафика, узлы ничего не знают о платёжных данных.

• Бэкенд — PHP 8.3: кабинет, биллинг, REST API, каталог бесплатных прокси и его краулер-чекер.
• Сетевой слой — VPN-плоскость (WireGuard/OpenVPN) и прокси-плоскость (SOCKS5/HTTP) на RAM-first узлах выхода; покрытие — 79 стран, заявленный аптайм — 99.9%.
• Биллинг — оплата картой или криптовалютой через платёжного партнёра; фиксированная плата за VPN, метеринг за прокси-трафик, аддоны за выделенные IP и приватные серверы.
• Периметр — Cloudflare (DNS, TLS, защита) перед публичными поверхностями продукта.

Выбор PHP 8.3 для управляющего контура прагматичен: зрелая быстрая платформа, на которой в одном предсказуемом окружении живут кабинет, API, биллинг и каталог. Сетевой слой сознательно отделён и говорит на стандартных протоколах — WireGuard, OpenVPN, SOCKS5, HTTP: пользователю не нужен наш клиент, подойдёт любой инструмент, который он уже использует. Это разделение окупается и в эксплуатации: панель можно обновлять, не трогая узлы, а узлы — наращивать и заменять, не замечая панели.

14Дизайн и UX

Privacy-продукт продаёт доверие — а доверие у технической аудитории покупается не обещаниями, а проверяемостью. Поэтому главный приём интерфейса S4M — «покажи, а не расскажи»: прямо на главной странице живёт терминальный блок с командой curl и ответом ipify, демонстрирующий подмену адреса за одну строку. Рядом — живые счётчики: число работающих бесплатных прокси в каталоге, страны покрытия. Это данные из продукта, а не маркетинговые константы, и техническая аудитория мгновенно чувствует разницу.

Тот же принцип честности — в структуре сайта. Таблица «бесплатные прокси против S4M» не прячет сильные стороны бесплатного варианта, а спокойно раскладывает, где он заканчивается: аптайм, скорость, аутентификация, анонимность, контроль. FAQ отвечает прямо, включая неудобное: да, публичные прокси — на свой риск; нет, мы не записываем вашу активность; да, можно анонимно. Гайды и сравнения превращают сайт в справочник, в который возвращаются, — и который приводит новую аудиторию.

Продукт трёхъязычный — EN/UK/RU, и это не «перевод лендинга», а полная локализация: интерфейс, гайды, FAQ. Для инфраструктурного сервиса язык — часть UX: пользователь принимает решения о приватности, и принимать их он должен на языке, на котором думает.

15Как мы работали

Проект шёл последовательными этапами с работающим результатом на каждом шаге:

• Исследование. Разобрали сценарии — защита origin-серверов, автоматизация, приватный браузинг, — модель угроз и то, как рынок разводит VPN и прокси по разным продуктам.
• Архитектура. Спроектировали две плоскости над общим ядром, модель лимитов на проводе, no-logs конструкцию узлов и формат API.
• Разработка ядра. Собрали VPN- и прокси-плоскости, потоковый учёт, кабинет, биллинг с картой и криптовалютой, выдачу конфигов и реквизитов.
• Каталог прокси. Построили краулер и непрерывный чекер публичных прокси, фильтры и живые счётчики каталога.
• Интеграция и обкатка. Перевели серверный egress собственной экосистемы на SOCKS5-выход S4M и прогнали инфраструктуру под живым продакшн-трафиком.
• Запуск. Оформили посадочную, гайды и сравнения, FAQ и полную локализацию на три языка.

Порядок не случаен: сначала фиксировался контракт — форматы конфигов и реквизитов, модель лимитов, схема API, — и только потом вокруг него строилась реализация. Стабильный контракт позволил вести ядро и каталог параллельно, а собственная экосистема сыграла роль первого и самого требовательного клиента: к моменту публичного запуска через S4M уже шёл реальный трафик, и целые классы проблем были найдены и закрыты изнутри.

16Результат

Получился не «ещё один VPN-сервис», а сетевая инфраструктура, в которой VPN, прокси, выделенные IP и приватные серверы — грани одного продукта с одной моделью учёта и приватности.

• Один аккаунт закрывает VPN, прокси, выделенные IP и приватные серверы — без зоопарка сервисов и дублирующихся биллингов.
• Приватность за минуты: регистрация → конфиг или реквизиты → проверка выхода одной командой против api.ipify.org.
• Лимиты per plan / per IP / per account работают на проводе в реальном времени — и не требуют ни одного журнала активности.
• Бесплатный каталог из сотен живых прокси приводит аудиторию и честно конвертирует её в платные планы.
• Продукт работает в нашем собственном проде: весь серверный исходящий трафик экосистемы идёт через выход S4M.

Главный результат — в смене модели. Раньше «спрятать IP» означало собирать конструктор: VPN здесь, прокси там, статический адрес у третьего поставщика, и нигде — общего контроля. Теперь это одна инфраструктура с одной точкой управления, которая одинаково обслуживает и ноутбук, и парк серверов, — и которую мы сами используем каждый день.

17Выводы

Главная инженерная история S4M — согласование того, что кажется несовместимым: no-logs приватности и коммерческого учёта. Решение — считать байты, а не поведение; на узле, а не в журнале; агрегатами, а не событиями — выглядит очевидным задним числом, но именно оно определило всю архитектуру: RAM-first узлы, потоковые счётчики, лимиты на проводе. Приватность здесь — не функция и не обещание, а форма конструкции.

Второй вывод — про доверие. В категории, где продукт покупают за приватность, честность оказалась самой сильной продуктовой стратегией: проверяемая демонстрация вместо лозунгов, живые счётчики вместо круглых цифр, прямые ответы про границы бесплатного. И третье — сила «собственной шкуры»: лучший тест privacy-инфраструктуры — поставить на неё собственный продакшн, что мы и сделали, направив через S4M весь исходящий трафик экосистемы.

Для нас это был проект на стыке сетевой инженерии, продуктового мышления и той самой дисциплины, где важно не что сервер делает, а чего он принципиально не делает. Если вам нужна сетевая инфраструктура, API-first сервис или продукт, в котором приватность должна быть архитектурой, а не абзацем политики, — мы умеем доводить такое до запуска.