Для приложения с серверной выдачей контента это означает, что пользователь заплатил и несколько часов не получает подписку или покупку. Google зафиксировала инцидент Play Billing 1 сентября с 08:54 до 11:43 UTC и объявила о решении в 13:59 UTC, но по данным отчёта задержки продолжались и после закрытия инцидента. Официального комментария Google к отчёту на момент публикации нет.

• Две задержанные транзакции: от покупки до RTDN 3 ч 55 мин 40 с и 2 ч 11 мин 55 с; доставка уже созданного события на сервер заняла 0,6 и 1,4 с.
• Девять нормальных транзакций того же периода: 0,086–0,148 с до eventTimeMillis, доставка 0,3–2,3 с.
• Pub/Sub со стороны разработчика работал: максимум одно неподтверждённое сообщение возрастом до 3 с, push-запросы завершались ack_200, максимальная задержка push 4,5 с.
• Затронуты и одноразовые покупки, и подписки, в нескольких странах и валютах; Россия в отчёте не названа.
• Официальный инцидент Play Billing: 1 сентября, 08:54–11:43 UTC; отчёт утверждает, что задержки были и позже.

Где именно терялось время

Автор отчёта разложил путь уведомления на два отрезка. Первый: от завершения покупки до момента, когда Google создала событие (это и есть eventTimeMillis, время события в миллисекундах Unix). Второй: от создания события до получения его сервером через Pub/Sub. Второй отрезок оставался быстрым, 0,6 и 1,4 секунды в проблемных случаях. Всё время ушло на первый: уведомление не доходило часами, при том что метрики Pub/Sub со стороны разработчика чистые: очередь пустая, подтверждения приходят, задержка доставки в пределах секунд. На каком именно внутреннем этапе у Google застревало событие, по этим данным установить нельзя.

Есть оговорка, которую автор делает сам: он не сохраняет внешнее поле publishTime из конверта Pub/Sub, поэтому не может доказать, где именно внутри инфраструктуры Google лежала задержка, до публикации в Pub/Sub или после. Вывод о том, что событие создавалось поздно, сделан по eventTimeMillis.

Почему RTDN нельзя считать единственным источником правды

Документация Google требует после получения RTDN вызывать Developer API: уведомление не содержит полного состояния покупки. Этот случай добавляет к этому редакционный вывод: уведомление может прийти поздно или, в худшем сценарии, не прийти вовремя вообще. Если сервер выдаёт доступ только по RTDN, при задержке пользователь остаётся без оплаченного. Если клиент после покупки сам сообщает серверу токен покупки, а сервер проверяет его через Developer API, задержка RTDN ни на что не влияет.

Что проверить в своём приложении

1. Убедиться, что клиент после успешной покупки отправляет purchase token на сервер, а сервер подтверждает его через Google Play Developer API, не дожидаясь RTDN.
2. Логировать eventTimeMillis и publishTime из конверта Pub/Sub вместе с временем получения, чтобы при следующем инциденте было видно, на каком отрезке задержка.
3. Проверить логи за 1–2 сентября на покупки, у которых разница между временем оплаты в клиенте и RTDN больше нескольких минут.
4. Не завязывать acknowledge покупки только на RTDN: неподтверждённая в течение трёх дней покупка возвращается пользователю автоматически.

Отчёт говорит о нескольких странах и валютах, но Россию не называет; учитывая, что оплата в Google Play российскими картами не работает с 2022 года, задержки касаются в первую очередь приложений с зарубежной аудиторией. Что ещё менялось в правилах Play в последние дни: требование к AnkiDroid убрать ссылку на пожертвования и стабильный релиз Android Studio Quail 4. Появится ли по этому отчёту официальный ответ Google или новая запись в статусе Play Billing, мы проверим.

Источники: Отчёт разработчика в сообществе Google Play, Google Play Status Dashboard: инцидент Play Billing, Справочник RTDN

История касается не только AnkiDroid. Правило, на которое ссылается Google, запрещает вести пользователей к оплате мимо Google Play Billing; пожертвования допускаются лишь для организаций с подтверждённым налоговым статусом благотворительной и на определённых условиях. У большинства open source-проектов таких документов нет.

• Google Play счёл ссылку AnkiDroid на Open Collective нарушением Payments Policy; первое уведомление пришло 20 июля, документы проекта Google 7 августа не принял.
• Требование: убрать ссылки на платежи вне Google Play Billing или подтвердить статус tax-exempt организации; сам Play Billing для пожертвований таких организаций запрещён.
• Дата удаления при отсутствии исправления: сначала 3 августа, затем 11 сентября 2026 года, оба раза с оговоркой «везде, кроме Индии и России»; причина исключения не объяснена.
• AnkiDroid связан с организацией статуса 501(c)(6), в приложении ничего не продаётся, Open Collective — единственный источник денег; мейнтейнеры убирают ссылки из Play-сборки ветки 2.24.x.
• Разработчикам с кнопкой «поддержать» в бесплатном приложении: ссылка на внешнюю площадку без статуса благотворительной организации — ровно случай AnkiDroid.

Что именно нарушил AnkiDroid

По тикету Google номер 9-2777000041594, нарушение относится к Payments Policy: внутри приложения была ссылка на Open Collective, платформу, через которую проект собирает пожертвования, а проблема помечена для сборки с version code 122400300. Google предложил два выхода: убрать все ссылки, «направляющие пользователей на оплату через системы, отличные от биллинга Google Play», либо доказать, что AnkiDroid — организация со статусом tax-exempt, освобождённая от налогов по американским правилам.

Remove any links directing users to make payments using systems other than Google Play's billing system.

Загвоздка в том, что политика Google одновременно запрещает использовать сам Google Play Billing для пожертвований освобождённым от налогов организациям, а AnkiDroid связан с организацией статуса 501(c)(6), профессиональной ассоциацией, а не благотворительным фондом. То есть донаты через Play невозможны, а ссылка наружу запрещена. Команда отдельно подчёркивает, что в приложении ничего не продаётся, Open Collective — единственный источник финансирования, а сам AnkiDroid не связан с Anki, AnkiWeb, AnkiMobile и AnkiHub.

Хронология

• 20 июля 2026 года: первое автоматическое уведомление Google с датой удаления 3 августа «везде, кроме Индии и России».
• 7 августа: Google сообщил, что присланные документы нарушение не устранили.
• Позднее уведомление: новая дата удаления 11 сентября 2026 года с той же региональной оговоркой.
• 29 августа: мейнтейнеры открыли issue #21656 с просьбой о помощи сообщества и решением убрать ссылки «под протестом».
• 1 сентября: обсуждение на Hacker News; изменений в позиции Google в issue нет.

Почему Индия и Россия отдельно

В уведомлениях Google оба раза называл дату удаления приложения из Play «везде, кроме Индии и России». Причина исключения в переписке не объясняется; в issue нет и подтверждения, что удаление где-либо уже произошло. Для пользователей из России это означает лишь то, что из Play приложение не пропадёт. Для разработчиков, которые распространяют приложение и через RuStore или прямой установкой, напрашивается редакционный вариант: держать ссылки на пожертвования только вне Play-сборки; AnkiDroid подтвердил лишь удаление ссылок из сборки для Play.

Что проверить в своём приложении

• Найдите в приложении все ссылки на внешние платежи: Boosty, Patreon, Open Collective, «Купить кофе», номера кошельков, QR-коды. Ссылка на площадку пожертвований без подтверждённого статуса благотворительной организации — ровно случай AnkiDroid.
• Разделите сборки: в версию для Google Play ссылки не включайте, в сборку для F-Droid, RuStore или прямой загрузки APK оставьте.
• Не рассчитывайте на «объяснить в апелляции»: AnkiDroid отправлял документы, Google 7 августа ответил, что нарушение не устранено.
• Если приложение платное или с подпиской, донаты как отдельный товар возможны только через Google Play Billing с его комиссией, и только если вы не благотворительная организация.
• Держите под рукой историю уведомлений: первое письмо AnkiDroid получил 20 июля, а дедлайн подошёл через шесть недель.

Что дальше

Ближайшая веха — сборка ветки 2.24.x без ссылок на донаты. Дата 11 сентября покажет, выполнит ли Google угрозу удаления в остальных странах. Реакцию Google на публичность ждать имеет смысл, но на момент публикации в issue никаких изменений позиции магазина нет, а сам Google на запросы в треде не отвечал.

Источники: Issue #21656 в репозитории AnkiDroid, Обсуждение на Hacker News

Изображение на обложке: AnkiDroid

Quail 4 — финальный стабильный выпуск линейки Quail, и автор анонса, менеджер продукта Android Studio Амман Фасил Асфав, называет её «готовой к использованию в продакшене». Помимо локальной модели в IDE вошли 23 готовых «навыка» агента под типовые задачи Android, кликабельные ссылки на классы и методы в ответах, индикаторы состояния в списке чатов и сворачиваемый показ рассуждений модели.

• Android Studio 2026.1.4 (Quail 4) стабильна; это последний выпуск линейки Quail.
• Gemma 4 работает локально через встроенный движок инференса; код не покидает машину, лимитов на токены нет.
• Минимум 12 ГБ оперативной памяти для самых маленьких моделей; по словам Google, «машины с 32 ГБ и больше будут работать лучше всего».
• 23 встроенных навыка агента (AGP 9 Upgrade, Android Profiler, Navigation 3, Adaptive и другие) выбираются автоматически по запросу и отключаются одним переключателем.
• Локальный режим включается в Agent model selector или в Settings, Tools, AI, Model Providers, Gemma; веса IDE скачивает, проверяет и обновляет сама.

Как устроена локальная модель

Android Studio сама скачивает веса Gemma 4, проверяет их и обновляет. Внутри IDE работает лёгкий движок инференса, поэтому отдельный сервер вроде Ollama поднимать не нужно. Модель выбирается в переключателе Agent model selector или в настройках: Settings, Tools, AI, Model Providers, Gemma. После этого агент работает локально: анонс подтверждает многофайловые рефакторинги полностью офлайн; остальные сценарии облачного агента Google для локального режима отдельно не перечисляет. Google подчёркивает два свойства: исходный код не покидает локальную машину, и квоты на токены не действуют.

Your source code never leaves your local machine and you never hit token quota limits.

Требования к железу компания называет прямо: самые маленькие варианты Gemma 4 стартуют на 12 ГБ оперативной памяти, а лучше всего работают машины с 32 ГБ и больше. На ноутбуке с 16 ГБ, где рядом крутятся эмулятор и Gradle, стоит ожидать, что локальная модель окажется медленнее и заметно проще облачной. Это цена за приватность и отсутствие квот, и оценивать её нужно под свой проект: по нашему опыту, многофайловый рефакторинг на маленькой модели требует больше ручных проверок, чем на облачной.

Что такое навыки агента

«Навык» здесь — заранее написанная инструкция с контекстом под конкретную задачу Android: как обновить проект на Android Gradle Plugin 9, как читать данные профилировщика, как переехать на Navigation 3 или сделать адаптивную вёрстку под планшеты и складные устройства. В Quail 4 таких навыков 23, и IDE подбирает их по метаданным запроса сама. Если подбор мешает, навыки отключаются общим переключателем в настройках IDE.

Что ещё изменилось в интерфейсе агента

• Ссылки на классы, функции, методы и пути файлов в ответах агента стали кликабельными.
• В списке Recent Chats появились индикаторы: загрузка, ожидание ввода, завершение фоновой задачи.
• Вкладки Task и Walkthrough объединены во вкладку Summary of Changes; по ней стоит проверять правки перед применением.
• Рассуждения моделей с режимом reasoning показываются сворачиваемым блоком.

Что менять в проекте и процессе

• Обновите Android Studio до 2026.1.4 через Check for Updates; проект менять не нужно.
• Если в компании запрещено отправлять код во внешние сервисы, включите Gemma в Model Providers и убедитесь, что облачный провайдер в настройках не выбран.
• Проверьте память: 12 ГБ — заявленный минимум для самых маленьких моделей, 32 ГБ и больше — рекомендация Google; на 16 ГБ закройте эмулятор перед работой агента или пользуйтесь физическим устройством.
• Для миграции на AGP 9 попробуйте одноимённый навык: это задача с сотней мелких правок, где агент экономит время.
• Региональных оговорок в анонсе нет, но доступность загрузки весов из России Google не подтверждает; проверяйте на своей машине. Локальный режим не требует подписки на облачные модели.

Контекст

Линейка Quail шла к этому весь цикл: в Quail 2 появились параллельные чаты с агентом, затем навыки, интеграция с Firebase и первая поддержка локальных моделей в Canary-сборках. Quail 4 закрывает линейку и делает локальный режим штатным в стабильной версии. Следующая линейка Android Studio получит новое кодовое имя; сохранится ли в ней локальная Gemma как основной сценарий, Google не говорит, и это предположение редакции по тону анонса.

Источники: Leverage Android skills and Gemma 4 in Android Studio Quail 4 (Android Developers Blog), Android Studio release notes

Изображение на обложке: Google, Android Developers Blog

Потом проект вырос, в команду пришли ещё люди, и стало понятно: этот красивый монолит пора разделять.

Это было взвешенное решение. В какой-то момент общий фреймворк превратился в поле мерж-конфликтов, где ты уже не тесты пишешь, а разбираешься, кто чей page object сломал и почему Android отвалился после правки для iOS.

Appium тут ни при чём, как и скорость тестов. Проблема была в архитектуре: один общий слой для двух разных платформ начал мешать сильнее, чем помогать.

Как говорил один мой коллега, перефразируя классическое “вам шашечки или ехать”:

Ты сюда страдать пришёл или тесты писать?

После этого решение разделить Android и iOS на два проекта стало очевидным.

Сейчас у меня два отдельных проекта: mb-android-tests и mb-ios-tests. И знаете что? Это лучшее архитектурное решение за всё время на этом проекте. Серьёзно.

Контекст: что за проект и почему это важно

Финтех. Нативное приложение. Отдельные кодовые базы, Kotlin на Android, Swift на iOS. И UI там не «три кнопки и список», формы с десятками полей, кастомные контролы, WebView-вставки, платежи, валютные операции, бюджетные переводы. Ну вы поняли.

Стек: Java 21, TestNG, Appium 2.x, Selenide, Allure, Maven. CI на GitLab, крутится на Mac Mini. 5 Android-эмуляторов, 4 iOS-симулятора, 9 Appium-серверов — по одному на устройство.

Но это сейчас. А начиналось всё с одного жирного монолита.

Старый проект: 8 модулей и конструктор-монстр

Идея была «как в книжке»: один репозиторий, модульная структура, переиспользование. DRY во все поля. Ну а чё, красиво же.

8 модулей. Один mvn clean install. Все зависят от mobile-automation-framework, в котором живут DriverFactory, BaseTest, общие Page Objects и слой Steps.

А DriverFactory принимал 11 параметров. Одиннадцать, Карл.

Половина нужна только Android, другая только iOS. Но метод один. Потому что так более по программистцки, как написано в каждой второй статье про архитектуру автотестов.

Когда я работал один, было норм. Ты сам знаешь, от куда что идет.

А потом пришли люди.

Почему с людьми всё навернулось

Мерж-конфликты каждый божий день

Вот конкретная ситуация. Один человек правит LoginPage в общем фреймворке, добавляет метод для iOS, меняет локатор. Второй в тот же момент рефакторит этот же LoginPage под новую версию Android-приложения.

Мерж. Конфликт.

И тут начинается самое весёлое: какой локатор правильный? Для Android? Для iOS? Для обоих? Кто будет разбираться? Тот, кто мёрджит? А он вообще контекст понимает?

Это не единичный случай. Это было каждый день. Потому что mobile-automation-framework получился общим модулем, от которого зависят все. И все туда лезут. Постоянно.

Обновление одной библиотеки = блокировка всех

Решил обновить java-client с 7.x на 8.x. Нормальное желание — API поменялся, MobileElement удалили, capabilities переехали на типизированные Options.

Вот что произошло в реальности:

1. Меняю версию в parent pom.xml
2. MobileElement удалён → compilation error в DriverFactory, во всех DriverManager’ах
3. DesiredCapabilities → UiAutomator2Options / XCUITestOptions → переписываю все менеджеры
4. selenide-appium 1.x несовместим с java-client 8.x → обновляю до 2.x
5. selenide-appium 2.x требует Selenide 6.x → обновляю Selenide
6. Selenide 6.x ломает API page objects → переписываю page objects во всех модулях
7. А Selenide 6.x ещё и Java 8 не поддерживает → обновляю Java

Одна библиотека.

Задача «обновить одну библиотеку» превратилась в 50+ файлов, 4-5 каскадных обновлений, 2-3 недели работы. И всё это время develop нестабилен. Все заблокированы. Тесты не запускаются.

Две недели.

Из-за одной строчки в pom.xml.

Page Objects с if/else — это два page object в одном файле

Общие Page Objects звучат красиво на бумаге: пишем один раз, используем для обеих платформ. А на практике…

Это не page object. Это два page objects, запиханных в один файл через if/else. И так в каждом методе.

А сверху ещё слой Steps. Обёртки над page objects «для читаемости». И в steps тоже if (platform), потому что логика взаимодействия разная. На Android ты скроллишь через UiScrollable семантически, «прокрути до элемента с текстом X». На iOS координатами, «двигай палец из точки A в точку B». Один метод в steps, а внутри два разных мира.

В какой-то момент ловишь себя на мысли: я же не тесты пишу. Я подгоняю pages и steps под две платформы, чтобы фреймворк не развалился. Это уже не автоматизация тестирования, это поддержка фреймворка ради поддержки фреймворка.

Каждый работает в своём темпе и все друг другу мешают

У одного задача покрыть тестами новый экран на Android. У второго пофиксить падающие тесты на iOS. У третьего добавить тестовые данные.

Все трое лезут в mobile-automation-framework. Все трое меняют pom.xml, BaseTest, page objects. Каждый в своей ветке.

А потом мёрдж.

Технические причины, которые добили окончательно

Ладно, человеческий фактор. Но были и чисто технические штуки, которые окончательно убедили меня, что кроссплатформа тут бессмысленна.

Локаторы: работай с тем, что дают

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

В теории есть AccessibilityID единый локатор для обеих платформ. Звучит хорошо. А на практике? Попробуй попросить мобильных разработчиков расставить одинаковые accessibility-идентификаторы на сотнях экранов. На Kotlin и Swift. Одновременно. Они тебя вежливо пошлют, но скорее всего не вежливо. И будут правы, у них свои спринты, свои дедлайны, и твои автотесты в их приоритетах где-то между «поправить тень у кнопки» и «никогда».

Так что реальный выбор:

XPath - работает, но на iOS может быть тормозным. На Android через UiSelector быстро, нативно, надёжно. На iOS через NSPredicate тоже ок. А «универсальные» XPath типа //*[@text='Войти' or @label='Войти'] это путь к боли, потому что Page Source на двух платформах два совершенно разных XML-дерева.

Координаты - костыль? Да. Но иногда единственный вариант. Когда у тебя кастомный контрол без accessibility-свойств, а разработчик говорит «это декоративный элемент», ты либо тыкаешь по координатам, либо не тестируешь.

OpenCV - есть ещё вариант с распознаванием элементов по картинке. Для некоторых кейсов реально выручает. Но это отдельная тема на целую статью, может напишу потом.

Суть в том, что «напиши один локатор и работай на двух платформах» это миф. Page Source на Android это android.widget.Button с resource-id. На iOS XCUIElementTypeButton с name и label. Разные типы элементов, разные атрибуты, разная глубина вложенности. Разные миры.

StaleElementReferenceException — «подарок» от iOS

Android рендерит UI через Choreographer синхронно с VSYNC. Элемент появился → стабилен → кликаем.

iOS рендерит через CoreAnimation с неявными анимациями. Элемент есть в дереве, но ещё анимируется. Формально кликабелен, фактически хрен.

Стандартный WebDriverWait с elementToBeClickable это не ловит. Элемент «кликабелен» по мнению Appium wait завершается. А потом click() падает, потому что DOM изменился между вызовами.

На Android этой проблемы нет вообще. Тот же тест, тот же wait, тот же код зелёный на Android, красный на iOS. Один и тот же метод, два разных результата. И это не баг это фундаментальное различие платформ.

Кастомные wait-стратегии для iOS отличаются от Android принципиально. Пихать их в один фреймворк строить leaky abstraction, которая протекает на каждом шаге.

Жесты — два разных мира

Свайп вниз на Android:

Свайп вниз на iOS:

Чувствуете разницу? И даже длительность свайпа важна: на Android 200мс это нормальный скролл. На iOS 200мс это fling, и элемент улетает за экран.

«Кроссплатформенная» обёртка для скролла функция на 40 строк с двумя ветками if (platform), внутри каждой и ещё if для performSwipeDown() vs performSwipeUp(). На 50+ экранах таких обёрток, которых десятки.

И каждая место для бага.

Решение: разделяй и властвуй

Решение было болезненным. Я реально откладывал, потому что казалось, что это шаг назад. Дублирование кода, нарушение DRY, всё такое. Мозг сопротивлялся.

А потом я просто сел и разделил.

Никаких общих page objects. Никаких общих steps. Никакого общего DriverFactory с 11 параметрами. Каждый проект со своим pom.xml, свои зависимости, свой BaseTest, свои локаторы.

Что осталось общего: подход к структуре (Maven + TestNG + Allure), CI-шаблоны, принципы организации. Но не код. Код полностью раздельный.

Что поменялось на практике

В Android-проекте DriverManager типизирован под AndroidDriver. В iOS под IOSDriver. Не AppiumDriver<MobileElement> с кастами и проверками, а конкретный тип для конкретной платформы. IDE подсказывает только релевантные методы. Компилятор ловит ошибки на этапе сборки, а не в рантайме.

BaseTest принимает ровно те параметры, которые нужны. Android: deviceName, platformVersion, udid, appPackage, appActivity, systemPort, serverUrl, appPath — 8 штук, все релевантные. iOS: deviceName, platformVersion, udid, appPath, serverUrl, wdaLocalPort — 6. Никаких @Optional("systemPort") со строкой “systemPort” в качестве дефолта.

А мерж-конфликты?

Когда один человек работает в mb-android-tests, а второй в mb-ios-tests то они вообще не пересекаются. Разные репозитории. Конфликт невозможен физически.

Обновление java-client в Android-проекте не затрагивает iOS. Хочешь обновить, обновляй. iOS продолжает работать на старой версии.

Добавить новый параметр для iOS? Меняешь BaseTest и testng.xml в iOS-проекте. Android даже не узнает.

Это прям кайф.

А как же дублирование кода?!

Конечно, конечно. Первый вопрос, который задают: «Но ведь ты пишешь тесты дважды!»

Нет.

Я пишу каждый тест один раз и без костылей. Без if (platform) в каждом методе. Да, для одного и того же экрана есть два теста, один для Android, один для iOS. Но каждый из них чистый, понятный, заточенный под свою платформу.

В старом варианте я тоже «писал один раз», а потом тратил столько же времени на поддержку if/else, мерж-конфликты и каскадные обновления. «Экономия» на создании оборачивалась переплатой на поддержке. С процентами.

Когда кроссплатформа всё-таки ок

Я не топлю за то, что кроссплатформенный фреймворк абсолютное зло. Есть ситуации, где он работает:

Приложение простое, пара экранов, стандартные контролы, минимум кастомного UI.

UI реально идентичен на обеих платформах. Бывает, наверное.

Команда из одиного человека. Сам пишешь, сам мёрджишь, сам разруливаешь. Голова справляется.

Минимум жестов. Нет сложных свайпов, drag-and-drop, pinch-to-zoom.

Если у тебя финтех, банк, enterprise-приложение с сотнями экранов, кастомными контролами и тремя+ QA, то два проекта дешевле. Не в строках кода, а во времени. В нервах. В часах, потраченных на мерж-конфликты вместо написания тестов.

Итого

Два проекта это не шаг назад и не двойная работа. Со стороны может выглядеть именно так, но на практике ты пишешь каждый тест один раз, под конкретную платформу, без лишних компромиссов. Потом поддерживаешь его без постоянных мерж конфликтов, каскадных обновлений и if/else в каждом втором методе.

Кроссплатформенный фреймворк на Appium для сложного нативного приложения часто оказывается иллюзией экономии.

В следующей статье покажу, как у нас устроена инфраструктура для 9 параллельных устройств на одном Mac Mini: порты, bash скрипты, Appium серверы и workaround’ы, которых нет в документации. Спойлер: там тоже всё не совсем как в гайдах.

Для российских разработчиков это особенно близкая история: Kotlin создавался в JetBrains, компании, основанной выпускниками Санкт-Петербургского политехнического университета. Язык, названный в честь острова в Балтийском море, стал одним из самых заметных российских технологических экспортов последнего десятилетия.

15 лет Kotlin. Первый анонс состоялся в июле 2011 года, стабильная 1.0 — в феврале 2016-го.

Kotlin 2.4.0. Стабильные context parameters, explicit backing fields, поддержка Java 26, Swift packages в Kotlin/Native и совместимость с Gradle 9.5.0.

Kotlin Toolchain 0.11. Amper эволюционировал в единый инструментарий: одна команда kotlin для создания, сборки, тестирования и публикации проектов.

Koog 1.0. JetBrains выпустила стабильный фреймворк для AI-агентов на Kotlin и Java с годовой гарантией совместимости ядра.

Compose Multiplatform 1.12.0-beta01 и Compose Hot Reload 1.2.0-beta01 развивают shared UI и экспериментальный MCP-сервер для AI-агентов.

Гранты Kotlin Foundation 2026. Приём заявок на финансирование open-source библиотек и инструментов открыт до 14 июля 2026 года.

Пятнадцать лет: от внутреннего проекта до мейнстрима

История Kotlin началась в 2010 году как попытка JetBrains решить собственные проблемы с Java. В 2011-м язык впервые показали публике, а в феврале 2016 года вышла стабильная версия 1.0. Переломным моментом стал Google I/O 2017: Kotlin получил статус первоклассного языка для Android, после чего интерес к нему резко вырос.

Сегодня Kotlin используется не только в мобильной разработке. На нём пишут backend на Spring и Ktor, делают кроссплатформенные приложения через Kotlin Multiplatform, экспериментируют с Kotlin/Wasm и даже строят AI-агентов. По данным ежегодных опросов JetBrains, доля Kotlin в коммерческих проектах стабильно растёт как в Европе, так и в России, несмотря на санкционные ограничения в части корпоративных лицензий.

If I were to choose one word to describe Kotlin's design, it would be pragmatism. For us it means caring about the usefulness.

Kotlin 2.4.0: что вошло в релиз

3 июня 2026 года JetBrains выпустила стабильный Kotlin 2.4.0. Это не инкрементальный патч, а полноценная мажорная версия с изменениями в языке, стандартной библиотеке, компиляторе и всех целевых платформах.

• Язык. Стабилизированы context parameters и explicit backing fields, добавлены новые target'ы для аннотаций.
• Стандартная библиотека. UUID API вышел из экспериментального статуса, появились функции для проверки отсортированности коллекций.
• Kotlin/JVM. Поддержка Java 26 и аннотации в метаданных включены по умолчанию.
• Kotlin/Native. Swift packages можно использовать как зависимости, обновлён Swift export, по умолчанию включён CMS GC.
• Kotlin/Wasm. Инкрементальная компиляция по умолчанию и поддержка WebAssembly Component Model.
• Kotlin/JS. Экспорт value-класс и возможности ES2015 при инлайнинге JS-кода.
• Gradle. Совместимость с Gradle 9.5.0.
• Maven. Автоматическое выравнивание версий Java и JVM target.
• Компилятор. Более предсказуемое поведение inline-функций при компиляции .klib.

Для практики это означает: если ваш проект живёт на JVM, можно обновляться ради Java 26 и улучшений stdlib; если вы работаете с iOS через Kotlin/Native — стоит посмотреть на Swift packages; для WebAssembly-экспериментов 2.4.0 делает сборку заметно быстрее.

Как обновиться

Обновление до 2.4.0 проходит через указание версии в Gradle или Maven. В Android Studio и IntelliJ IDEA новая версия уже включена в последние сборки.

Kotlin Toolchain 0.11: Amper уходит в прошлое

В июне 2026 года JetBrains окончательно переименовала Amper в Kotlin Toolchain и выпустила версию 0.11. Это не просто ребрендинг: инструмент позиционируется как единая точка входа для работы с Kotlin-проектами. Одной командой kotlin можно создать, собрать, протестировать и опубликовать проект.

В 0.11 появилась возможность публиковать JVM-библиотеки, улучшена разработка плагинов и упрощена начальная настройка. Для российских команд, часть которых уходит от корпоративных Gradle-лицензий к open-source инструментам, Kotlin Toolchain может стать интересной альтернативой для новых проектов и прототипов.

Важно: Kotlin Toolchain пока в статусе Alpha. Для существующих Gradle-проектов массово мигрировать смысла нет — инструмент ещё не покрывает все сценарии зрелых сборок. Но пробовать на небольших сервисах и pet-проектах уже можно.

Koog 1.0: AI-агенты на Kotlin

Фреймворк Koog от JetBrains вышел в версии 1.0. Он предоставляет примитивы для построения агентных приложений: инструменты, workflow, персистентность, память, observability и интеграции с JVM/KMP-проектами. Главное для Java-команд: Koog теперь предлагает идиоматичный Java API, то есть переходить на Kotlin ради агентов не обязательно.

Koog интегрируется со Spring AI, что делает его естественным выбором для backend-разработчиков, которые уже используют Spring Boot. Появилась мультиплатформенная observability и годовая гарантия совместимости ядра — это важно для команд, которые рассматривают агентов не как прототип, а как часть продакшена.

Compose и инструменты UI

Для UI-разработчиков в выпуске два значимых обновления. Compose Multiplatform 1.12.0-beta01 продолжает развивать shared UI: новые графические возможности, улучшения accessibility на iOS, обновления поведения UI-тестов и исправления для десктопа, веба и Gradle-плагина.

Отдельно стоит Compose Hot Reload 1.2.0-beta01. В нём развивается экспериментальный MCP-сервер: AI-агенты получают доступ к логам, ошибкам UI, могут перезапускать приложение и управлять его жизненным циклом. Это ещё не production-ready, но демонстрирует направление: разработка интерфейсов становится более визуальной и интерактивной.

Экосистема: библиотеки, гранты и корпоративный опыт

В обзоре JetBrains упомянуты три KMP-библиотеки, которые стоит изучить: ComposeMediaPlayer для кроссплатформенного видео, NSExceptionKt для улучшенной обработки крэшей на Apple-платформах и multiplatform-settings для хранения key-value данных в shared-коде.

Кроме того, Kotlin Foundation открыл грантовую программу 2026. Финансирование могут получить open-source проекты вокруг Kotlin Multiplatform, AI и больших языковых моделей. Заявки принимаются до 14 июля 2026 года. Для российских авторов библиотек это реальный способ поддержать проект, особенно если он пользуется спросом у зарубежного комьюнити.

Ещё один сигнал зрелости экосистемы — история Booking.com. Компания внедрила Kotlin Multiplatform для экспериментальной библиотеки и получила результаты выше ожиданий: улучшилась консистентность между Android и iOS, при этом команды не отказывались от платформенно-специфичной разработки.

Обучение: бесплатные курсы на Hyperskill

К юбилею JetBrains сделала часть Kotlin-курсов на Hyperskill бесплатными. Это проектно-ориентированная платформа: можно укрепить основы или пойти в сторону мобильной и backend-разработки. Для тех, кто только начинает или переходит с Java, это удобный способ получить практику, а не только теорию.

Выводы

15 лет Kotlin — это не только юбилей, но и точка, где язык перешёл из фазы «быстрого роста» в фазу «экосистемного инструмента». Kotlin 2.4.0 делает язык зрелее на всех платформах, Kotlin Toolchain упрощает вход в экосистему, а Koog и Compose Hot Reload показывают, что Kotlin активно используется в новой волне AI-разработки.

Для работающих проектов самый безопасный шаг — обновиться до Kotlin 2.4.0 в тестовом окружении и проверить совместимость. Новые инструменты вроде Toolchain и Koog стоит пробовать на pet-проектах, прежде чем тащить в продакшен. А если у вас есть open-source библиотека вокруг Kotlin — грантовая программа Kotlin Foundation может стать хорошим подспорьем.

Источник: Kodee's Kotlin Roundup: Kotlin Turns 15, Kotlin 2.4.0, and the Kotlin Toolchain — блог JetBrains.

Почему инфраструктура начинает привлекать больше, чем фичи

С фичами всё прозрачно: написал код — увидел результат на экране. Быстрая и понятная обратная связь. Но со временем замечаешь, что проблемы повторяются. Приложение тормозит не из-за плохого кода, а потому что на один экран уходит пять-шесть сетевых вызовов. Логика на клиенте. Хочешь что-то изменить — готовь релиз, проходи App Store Review и жди недели, пока обновление дойдёт до всех.

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

Возвращаться к фичам стало неинтересно. В инфраструктуре задачи сложнее, результат измеряется метриками — latency, error rate, скорость релизов, — а влияние на всю систему, а не на один экран.

Что Android даёт для инфраструктуры — а чему учиться с нуля

Мобильный бэкграунд оказался не балластом, а преимуществом. Я понимал ограничения изнутри. Backend-инженер может прочитать, что мобильные сети ненадёжны, память ограничена, а батарея — критичный ресурс. Но прочитать и прочувствовать — разное. Я годами наблюдал, как приложение “захлёбывается” на устройствах среднего сегмента. Знал, что 60% пользователей сидят именно на таких. Видел, как баг, который мы починили за день, продолжает висеть у людей неделями — просто потому, что они не успели обновиться.

Когда я проектировал gateway, я точно знал, что почувствуют мобильные разработчики, если ошибусь. Добавить ещё один сетевой вызов — это будет не бесплатно. Оставить логику в приложении — значит отдать её на устройство, которое я не контролирую.

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

Чему пришлось учиться с нуля? Операционному мышлению. В Android ты выпускаешь релиз — и он либо работает, либо нет. Если крашится, починишь в следующей версии. В инфраструктуре нет «следующей версии». Если gateway падает, всё приложение ложится для миллионов пользователей прямо сейчас.

Пришлось учиться думать в терминах деградации, частичных отказов, плавного падения.

Что делать, если один из пяти сервисов не ответил? Как понять, что мы катимся к инциденту, до того, как пользователи начнут жаловаться?

Этому в мобильной разработке не учат.

Как я учился: пробелы, сроки и смена мышления

Формального плана у меня не было — учился на практике. Это лучший, хотя и самый стрессовый способ. Пробелы выявляла практика. Столкнулся с нерешаемой задачей — понял, чего не знаю. Пошёл разбираться.

Учился итеративно, не пытаясь объять необъятное сразу. Gateway начинался как простой прокси. Затем добавили агрегацию ответов, потом — конфигурационные определения экранов. Каждый такой шаг вынуждал осваивать следующий уровень: circuit breakers, стратегии повторов, observability, планирование мощностей.

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

Что означает «выдающийся уровень» в инфраструктуре

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

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

Затем — миграция живой системы, где права на ошибку практически нет. Приложение нельзя выключить или отрепетировать в реальном масштабе. Остаётся только постепенный перевод трафика: shadow mode → 1% → 5% → 25% → 50% → 100%, с автоматическим откатом при любом росте ошибок. И всё это — пока миллионы пользователей активно работают с продуктом, не подозревая, что под капотом идёт замена двигателя на ходу. Такой уровень дисциплины и инструментации приходит только с практикой.

Наконец, владение надёжностью. Gateway — единая точка отказа: упал он, упало всё. Годы уходят на то, чтобы сделать его скучным и предсказуемым: резервирование, автомасштабирование, circuit breakers, режимы деградации, еженедельный пересмотр мощностей. Высший пилотаж — когда о системе просто не думаешь, потому что она работает.

Почему путь в инфраструктуру доступнее, чем кажется?

Карьерные траектории в инфраструктуре редко бывают чётко описаны. Здесь нет готового чек-листа в духе «диплом по Computer Science, пять лет в бэкенде, обязательное знание Kafka и Kubernetes». С одной стороны, такая неопределённость пугает. С другой — именно она и делает этот путь более доступным, чем принято думать.

Когда перед тобой лежит жёсткий список формальных требований, люди часто отсеивают себя сами, даже не попробовав. А в инфраструктуре по-настоящему важно только одно: можешь ли ты решать задачи. Я пришёл сюда без профильного диплома и учился ровно тому, что требовалось в моменте, потому что задачи сами подталкивали к этому.

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

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

Мобильный бэкграунд как преимущество архитектора

Считаю ли я, что мобильный опыт сделал меня лучшим архитектором для mobile-first продуктов? Безоговорочно, да.

Я помнил, как ощущается медленный экран на устройстве среднего сегмента. Помнил, что случается, когда API возвращает слегка неправильные данные и приложение падает при парсинге. Помнил то чувство, когда баг уже в проде, а ты ждёшь App Store Review и ничего не можешь исправить.

Поэтому когда я проектировал gateway, я не занимался абстрактной «оптимизацией перформанса». Я опирался на совершенно конкретный опыт. Знал, что убрать один сетевой round trip — это подарок каждому мобильному разработчику. Знал, что перенос логики на сервер означает перенос в место, где я могу починить всё за минуты, а не за недели.

Лучшая инфраструктура для мобильных продуктов строится теми, кто сам их создавал и знает все узкие места не понаслышке. Этот опыт даёт верное направление: ты чувствуешь, где настоящие проблемы, потому что сталкивался с ними лично. Такому не учат по книгам.

Коротко: что делать, если думаете о переходе

• Найдите промежуточный шаг. Не прыгайте сразу в бэкенд. Начните с задач на стыке: оптимизация API, инструменты для мобильных разработчиков, улучшение сетевого слоя.
• Используйте мобильный контекст как рычаг. Вы понимаете то, о чём бэкенд-инженеры только догадываются. Говорите об этом вслух.
• Учитесь измерять невидимое. В инфраструктуре результат — это метрики: latency, error rate, скорость релизов. Учитесь рассказывать историю через цифры.
• Проектируйте под отказ, а не тушите пожары. Senior-уровень — это определить, что сломается и кто за это отвечает, до того, как оно сломается.
• Не ждите разрешения. Путь не размечен, но он открыт. Начните с малого — и двигайтесь туда, где задачи становятся интереснее.

Попытка №1. Путь в лоб: Классы и интерфейсы

Самый очевидный способ - создать родительский класс с переменными, а языки сделать его наследниками. Но это просто… фиаско. Даже если не писать from/toJson, процесс выглядит так:

1. Объявил переменную в родителе.
2. Прописал её в конструкторе.
3. Повторил то же самое для всех дочерних классов (всех языков).

Если бы я работал на аутсорсе в Индии и мне платили за количество строк кода - это был бы идеальный вариант. Но я хотел, чтобы одной строки при объявлении было достаточно.

Попытка №2. Стандарт (ARB/JSON)

Я поплевался, но решил попробовать - «стандарт» всё-таки. Мало ли, может чего поменялось за годы. Вроде всё завелось, но сам процесс… это боль. Бегать по разным файлам, чтобы добавить одну строчку - так себе удовольствие.

Почему я от него окончательно отказался? Когда данных становится реально много (десятки языков, тысячи строк), ты попадаешь в ловушку: тебе нужно эту махину либо целиком держать в памяти, либо постоянно подгружать и парсить. Ради смены одного слова на кнопке заставлять девайс ворочать тяжелые JSON-ы в рантайме - так себе затея для производительности.

Попытка №3. Таблицы и костыли

Подумал: «Окей, почему бы не подтянуть старый добрый CSV или вообще закинуть всё в табличку?». И тут официальный пакет локализации сказал: «Извини, мужик, тут наши полномочия всё».

Ну, я тоже не пальцем деланный. Решил припахать нейросеть, чтобы она написала мне собственный генератор. Флоу получился такой:

1. Добавляю строку в таблицу.
2. Запускаю генератор.
3. Он лепит «родительский» файл.
4. После Freezed генерит toJson, fromJson…

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

Красный флаг для программиста

Но главная проблема даже не в этом. Необходимость запускать генератор после добавления каждой переменной - это для любого программиста красный флаг.

Что происходит на практике? Когда ты пишешь код и тебе нужно добавить одну несчастную строку, тебе лень (читать: нехочется выходить из потока творения) запускать весь этот цикл с генерацией. Ты просто её хардкодишь в надежде «потом скопом всё добавлю одним махом». А «потом» наступает тогда, когда уже весь проект завален хардкодом, и вычищать его - то еще удовольствие. Даже нейросетки с такими запросами помогают не с первого раза, и с сомнительной эффективностью.

Нутром чуял - флоу неправильный. В итоге я пришел к тому, что называю идеальной локализацией.

Эволюция лени: почему Enum победил интерфейсы

Я начал мучить нейросеть разными вариантами реализации. Для меня в первую очередь был важен флоу работы: мне было тупо лень писать больше одной строки кода, чтобы добавить переменную.

Моя философия проста: строку захардкодить - моментально. Добавление даже одной строки в другом файле требует доп. действий. НО, если действий минимум, то кодер поймет, что выигрыш во времени сейчас мизерный против больших потерь в будущем, и исправно добавит строку в правильное место. Этого не произойдет, если для добавления строки нужно «отчитаться» в десяти местах.

Попытка №4. Рекорды (Records)

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

Идеальный костыль: Enum

В итоге я пришел к самому, казалось бы, «неправильному» способу, который оказался идеальным. Enum. Само название намекает на перечисления и цифры, но оказалось, что хранить в нем буквы и целые фразы - это лучший путь для локализации.

Знаете, мне моё решение так понравилось, что я пошел к нейросетям и проверил его со всех сторон. Все модели остались в полном восторге. Под это дело я даже подготовил монументальную «нейро-статью» на полтора часа внимательного чтения, со всеми графиками, бенчмарками и анализом производительности.

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

А здесь мы будем говорить по делу.

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

Реализация

Принцип разделения:

• enum Strings → типизированный контракт (что существует).
• translator → источник данных (откуда берётся текст).

Структура файлов - минимальная. Никаких внешних зависимостей:

Ядро - strings.dart

Весь контракт локализации в одном enum. Два режима - хардкод switch и серверный кеш - за одним и тем же

. Даже сообщения об ошибках локализации — сами локализованы:

Список языков - languages_enum.dart

Каждый язык - самодостаточная единица: знает свой код, название, направление текста и как себя загрузить:

Хотите грузить с сервера? Одна строка + loader. И

- тоже одна строка, потому что

уже является registry:

Переводчик - i18n/russian.dart

Как это выглядит в жизни (и почему я перестал хардкодить) Я намеренно не привожу здесь код оберток виджетов или конкретных стейт-менеджеров. Всё это - чистая «вкусовщина». Для работы системы нужен лишь элементарный вещатель событий (Notifier), повешенный на метод смены языка.

Но главное - это мой ежедневный флоу. Сейчас, чтобы добавить строку в UI, я просто вызываю нужный мне ключ: Strings.someKey(). Без контекста, везде.

А если ключа еще нет? Я тупо иду в Strings и добавляю одну строчку в Enum. Всё.

Благодаря дефолтному конструктору, приложению абсолютно плевать, что у меня там еще 100 языков не переведены. Оно компилируется и работает здесь и сейчас. А дальше в дело вступают гит-хуки: при комите нейросетка сама подхватывает изменения и заполняет недостающие поля в переводчиках.

Знаете, какое самое странное чувство? Мне сейчас реально проще и быстрее завести переменную в локализации, чем хардкодить строку в коде. Кажется, это и есть признак здоровой архитектуры - когда делать «правильно» становится физически удобнее, чем делать «быстро» и криво.

Собственно если в кратце это все о чем я хотел рассказать. Если тема зайдет или кто-то сам не сможет допереть, как прикрутить это к своей архитектуре - пишите в комментариях, разберемся.

Надеюсь, мой опыт сэкономит вам пару литров нервных клеток. Всех благ и чистого кода без «магических строк»!

Если верить статистике, сейчас ежедневно создается около 402,74 миллионов терабайт данных.

Согласитесь, довольно внушительная цифра.

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

Меня зовут Оксана, я маркетолог в Beget и в этой статье хочу поделиться решением, которое мы выбрали у себя в отделе для хранения файлов, когда заметили, что их стало слишком много.

Мы решили перейти на гибкое объектное хранилище S3 – чтобы централизовано хранить и управлять текстами, креативами, отчетами и другими маркетинговыми материалами с удобным доступом внутри команды, ведь S3 позволяет хранить файлы любого типа и объема и масштабируется автоматически. Осталось только выбрать ПО для хранения файлов в облаке, к которому можно подключить S3.

Ранее у нас был опыт использования Nextcloud, однако его функционал, подобный швейцарскому ножу (встроенные календарь, конференции, таск-трекер и т. д.), оказался слишком объемен для нашей, по сути, скромной задачи – удобного и стабильного хранения файлов.

Вот почему мы подыскали аналог Nextcloud – ownCloud. В отличие от более функционального Nextcloud, ownCloud заточен исключительно на работу с файлами. И при этом он поддерживает подключение облачного объектного хранилища S3. Поэтому для нас в сравнении Nextcloud vs ownCloud выбор был очевиден.

В этой статье я расскажу, какие возможности есть у ownCloud, почему это ПО может быть полезно и как настроить связку ownCloud и S3. Если вы хотите организовать безопасное, контролируемое хранение и обмен данными на работе или дома, то этот материал будет для вас полезен.

Что может ownCloud

Для начала – буквально несколько слов об ownCloud и его возможностях.

Это программное обеспечение с открытым исходным кодом для хранения, синхронизации и обмена файлами появилось в 2010 году благодаря усилиям разработчика KDE Франка Карличека, который стремился создать бесплатную альтернативу коммерческим облачным сервисам хранения данных.

OwnCloud позволяет:

1. получать доступ к данным из любой точки мира и хранить файлы на собственном сервере – под вашим полным контролем;
2. синхронизировать данные между устройствами – доступ к файлам возможен с компьютеров (Windows, macOS, Linux), смартфонов (iOS, Android) и через браузер, изменения на одном устройстве мгновенно появляются на всех остальных;
3. делиться файлами и папками по ссылке, настраивая права доступа, пароли и срок действия ссылок;
4. совместно работать с документами, отслеживать историю изменений и возвращаться к любой предыдущей версии файла.

Только ownCloud сочетает в себе полный контроль над данными с простыми в использовании функциями обмена файлами, делая совместную работу более эффективной и безопасной.

Сегодня ownCloud используют компании (Philips, Nationwide, Zeppelin и др.) в самых разных сферах (IT, машиностроение, медицина и т. д.).

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

С ownCloud мне не нужно слепо доверять какой-то неопределенной организации. Я контролирую, как происходит обмен файлами, и ownCloud помогает мне на каждом этапе.

OwnCloud позволяет решать самые разные задачи, связанные с работой с файлами, – расскажем на примере трех кейсов, как это облачное хранилище помогает нам в отделе маркетинга.

Для каких задач мы используем ownCloud и S3

1. Централизованное управление материалами

Мы часто работаем с текстами, изображениями и презентациями. Дизайнеры и авторы загружают эти материалы в ownCloud, файлы автоматически сохраняются в S3, а для удобства поиска у нас настроены теги.

В итоге каждый член команды может видеть версии файлов (это важно для правок), нет хаоса в почте и мессенджерах.

2. Безопасное взаимодействие с подрядчиками

Связка ownCloud и S3 позволяет выгружать внешним специалистам материалы и получать результаты работ без прямого доступа к внутренней сети компании. Мы создали папку с публичной ссылкой, но жесткими ограничениями – паролем, сроком жизни ссылки в течение нескольких дней и разрешением на загрузку файлов без права просмотра папки.

На практике это работает так: менеджер создает ссылку и отправляет подрядчику, подрядчик переходит по ссылке и загружает архив с готовыми материалами, файл попадает в ownCloud, а его содержимое сохраняется в S3. Таким образом, подрядчик не видит, какие еще файлы лежат в папке, а мы контролируем, кто, что и когда загрузил.

3. Долгосрочный архив креативов и отчетов

По закону (152-ФЗ в РФ или GDPR в Европе) компания обязана хранить персональные данные клиентов, а также отчеты о рассылках и рекламных акциях на протяжении определенного времени.

Для решения этой задачи мы настроили правило: файлы старше 90 дней автоматически перемещаются в S3 Glacier (холодное хранилище) – этот класс снижает стоимость хранения, а если, например, юристу понадобится скачать какой-нибудь отчет спустя 2–3 года, он просто выгрузит его из ownCloud буквально за 5–10 минут.

Теперь – в деталях и по шагам о том, как начать использовать ownCloud в связке с S3.

Как развернуть ownCloud и подключить S3

OwnCloud удобно использовать с объектным хранилищем S3 – таким образом можно:

1. масштабировать систему – S3 расширяется автоматически и не имеет ограничений по объему и количеству размещаемых данных и файлов;
2. оптимизировать затраты – можно платить не за дорогую конфигурацию виртуального сервера с большим объемом диска, а лишь за фактически занимаемое место, по модели pay as you go (оплата по мере потребления);
3. повысить надежность хранения – за счет встроенной в S3 тройной репликации данных (файлы хранятся в 3 копиях и размещаются на независимых серверах в разных стойках для абсолютной сохранности данных).

Итак, разберем, как настроить связку ownCloud и S3.

Разработчики ownCloud предлагают два варианта установки. Можно скачать ownCloud и установить его вручную или использовать Docker-контейнеры. Мы выберем второй вариант.

Для размещения ownCloud в нашем примере создадим виртуальный сервер на базе готового решения Docker.

Можно подключиться к серверу по SSH или с помощью терминала в панели управления.

Для размещения файлов создайте бакет объектного хранилища S3. Реквизиты доступа к нему будут в карточке бакета в панели:

Создайте директорию для размещения конфигурационных файлов проекта и перейдите в нее:

Затем вставьте в файл docker-compose.yml следующее содержимое с помощью любого текстового редактора:

После этого создайте файл .env, в котором будут храниться значения переменных. Шаблон файла следующий:

Теперь необходимо отредактировать эти строки:

1. ownCloud_DOMAIN и ownCloud_TRUSTED_DOMAINS – укажите домен (так как ownCloud будет размещен за обратным прокси, указывать рабочий порт здесь не требуется);
2. ADMIN_USERNAME – логин администратора;
3. ADMIN_PASSWORD – пароль администратора.

Обратите внимание! Изменение ADMIN_USERNAME и ADMIN_PASSWORD уже после развертывания контейнеров не возымеет эффекта. Изменить пароль администратора вы можете в настройках пользователя в веб-интерфейсе.

Далее необходимо указать параметры подключения к S3.

• ownCloud_OBJECTSTORE_BUCKET – имя бакета S3;
• ownCloud_OBJECTSTORE_ENDPOINT – эндпоинт хранилища (например, https://s3.ru1.storage.beget.cloud);
• ownCloud_OBJECTSTORE_REGION – регион (ru1 для Beget);
• ownCloud_OBJECTSTORE_KEY – Access key бакета;
• ownCloud_OBJECTSTORE_SECRET – Secret key бакета.

Сохраните файл.

Остается лишь добавить файл конфигурации для Caddy – обратного прокси, через который пользователи будут получать доступ к ownCloud.

Создайте директорию config:

После чего создайте в ней файл конфигурации Caddyfile. Добавьте в него следующее содержимое, указав вместо ownCloud.betutorial.ru ваш домен ownCloud:

Обратите внимание! Caddy выпустит SSL-сертификат на домен автоматически.

Все запросы к домену будут проксироваться в контейнер ownCloud_server.

На этом настройка конфигурационных файлов завершена, можно запускать контейнеры:

Потребуется несколько минут, чтобы docker загрузил образ и развернул контейнеры.

После запуска перейдите по домену, чтобы проверить работу хранилища:

Выполните вход со стандартными доступами.

Обратите внимание! Если ownCloud недоступен или вы получаете ошибку при входе со стандартными доступами, проверьте корректность конфигурационных файлов. После внесения изменений перезапустите контейнеры.

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

Теперь проверим работу объектного хранилища – перейдем на главную страницу и загрузим файлы:

Файлы также появились и в объектном хранилище:

Обратите внимание! Файлы, которые вы удалите в ownCloud, будут перемещены в корзину и останутся в S3. Для их полного удаления очистите корзину ownCloud.

Чтобы делиться паролями с новыми пользователями, необходимо настроить отправку почты в ownCloud, сделать это можно в разделе Settings>General.

В нашем примере мы настроим отправку через SMTP:

После указания данных введите тестовый email и нажмите “Send email”. Если отправка успешна, вы получите уведомление об этом:

А на почтовый ящик поступит письмо:

На этом настройка завершена – можно начинать работать с файлами, используя связку ownCloud и S3.

Заключение

Если вы ловите себя на мысли, что данных стало настолько много, что поиск нужного файла порой происходит дольше, чем работа с ним (особенно если одни файлы хранятся на почте или в мессенджере, а другие – на ноутбуке или флешке), облачное хранилище может вам помочь.

Подобное ПО пригодится как для личных целей, так и для бизнеса – недаром в 2025 году в нашей стране был зафиксирован рост интереса крупного и среднего бизнеса к технологии облачного хранилища.

Надеюсь, эта статья была для вас полезна, а облачные хранилища помогут сделать ежедневную работу комфортнее.

Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом.

В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза "end-to-end encryption"? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства?

Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger.

Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои.

Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать.

В статье расскажу, как работает E2EE изнутри: как устанавливается сессия через X3DH, как каждое сообщение получает отдельный ключ через Symmetric Ratchet, почему сервер хранит только зашифрованные конверты, и какие ошибки я допустил по дороге.

Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.

Важная оговорка про web-E2EE

Когда я говорю, что сервер не может прочитать сообщения, я имею в виду backend, базу данных, WebSocket-слой и уже сохранённые ciphertext-конверты. У них нет ключей и plaintext.

Но у web-E2EE есть отдельная проблема: frontend-код тоже приходит с сервера. Теоретически скомпрометированный сервер может отдать изменённый JavaScript, который украдёт ключи или plaintext до шифрования. Это ограничение не конкретно моего проекта, а браузерной модели в целом.

Поэтому корректная формулировка такая: backend не получает ключи и не может расшифровать уже переданные или сохранённые сообщения. Защита от подмены клиентского кода — отдельный слой безопасности: подпись сборок, независимая верификация клиента, desktop/mobile-приложения, reproducible builds.

Почему обычный подход не работает

Большинство "мессенджеров" на GitHub выглядят примерно так:

Сервер знает всё. Видит каждое сообщение. Если БД утекла — утекла вся переписка. Если сервер взломали — читай что хочешь. Если завтра компания решит продать данные — технически ничего не мешает.

E2EE решает это радикально: backend не получает ключи и не хранит plaintext. Сообщение шифруется на устройстве отправителя до отправки в сеть, а расшифровывается только на устройстве получателя.

Это уже не вопрос политики конфиденциальности в стиле "мы обещаем не читать". Это архитектурное ограничение: если у сервера нет ключа, он не может превратить ciphertext обратно в текст.

Звучит как магия. На самом деле — два протокола и немного WebCrypto.

Главная идея: конверты

Представь что Алиса хочет написать Бобу. Вместо того чтобы положить письмо на стол и надеяться что никто не прочитает — она кладёт его в запечатанный конверт. Конверт может открыть только Боб своим ключом. Сервер просто передаёт конверт не заглядывая внутрь.

Именно так это работает в коде. В базе данных у меня это выглядит так:

Когда я впервые увидел

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

А вот что сервер возвращает при запросе списка чатов через API:

Не

. Не

. Буквально

(DevTools → Network → ответ API с

)

Откуда берутся ключи: X3DH

Главный вопрос: как Алиса и Боб получают общий секрет, если они никогда раньше не общались? И как сделать это так, чтобы сервер только помог передать публичные данные, но сам не смог вычислить итоговый ключ?

Для этого используется X3DH — Extended Triple Diffie-Hellman, протокол из экосистемы Signal. Его задача — установить общий секрет между двумя устройствами, используя долгосрочные и временные ключи.

Что хранится на сервере

Когда пользователь регистрирует устройство, он загружает на сервер пакет публичных ключей:

На сервер уходят только публичные части. Приватные ключи сериализуются и хранятся локально в браузере — и никогда не покидают устройство в сеть.

Здесь важно сказать честно: хранение приватных ключей в

Более строгий вариант — использовать Web Crypto API с

, чтобы приватный ключ жил внутри браузерного crypto runtime и его нельзя было экспортировать в байты. Но у этого подхода есть практическая сложность: ключи нужно переживать между перезагрузками страницы, синхронизировать с IndexedDB, аккуратно восстанавливать состояние устройства и не сломать UX.

В браузерных E2EE-приложениях обычно приходится выбирать между несколькими вариантами:

• Сериализуемые ключи в localStorage или IndexedDB — проще реализовать, но нужно очень серьёзно относиться к XSS и целостности frontend-кода.
• extractable: false + IndexedDB — безопаснее, но сложнее в реализации и восстановлении состояния.
• Нативное secure storage вроде Android Keystore или iOS Secure Enclave — лучший вариант для мобильных клиентов, но он недоступен обычному web-приложению.

В текущей версии Chaos Messenger используется первый вариант. Это осознанный компромисс для pet/open-source проекта и удобного запуска в браузере. Переход на non-extractable ключи и более строгую модель хранения стоит в roadmap.

Ключевой момент: backend всё равно не получает приватные ключи и не может расшифровать сохранённые ciphertext-конверты. Но защита ключей на клиенте — отдельная задача, и её нельзя честно замалчивать.

Установка сессии

Когда Алиса открывает переписку с Бобом впервые, происходит следующее:

В классическом X3DH четвёртая DH-операция с one-time prekey опциональна: она выполняется, если сервер выдал доступный OPK получателя. В моей реализации устройство публикует набор one-time prekeys при регистрации, поэтому первое сообщение обычно использует DH4. Если OPK закончились, сессию всё равно можно установить через остальные DH-компоненты, но это уже менее сильный вариант.

Боб, получив конверт с эфемерным публичным ключом Алисы, повторяет те же операции со своими приватными ключами и получает тот же самый

. Математика симметрична.

Сервер в этот момент видит только публичные ключи и зашифрованный конверт. Он помогает устройствам найти друг друга, но не участвует в вычислении секрета.

Получить

Как шифруется каждое сообщение: Symmetric Ratchet

X3DH даёт нам стартовый

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

Решение — симметричный ratchet. После каждого сообщения цепочка ключей продвигается вперёд:

Визуально это выглядит так:

используется для шифрования одного сообщения через AES-GCM, после чего уничтожается. Если атакующий компрометирует

— он прочитает только второе сообщение.

В рамках такой симметричной цепочки это даёт forward secrecy назад по цепочке: зная текущий или отдельный

Само шифрование сообщения:

А вот что уходит на сервер — живой пример из DevTools:

Сервер получает

и

. Расшифровать без

Важная оговорка: это ещё не полный Double Ratchet

В этом проекте реализован Symmetric Ratchet — цепочка, где из

для каждого сообщения выводится отдельный

Это защищает прошлые сообщения: если атакующий узнает текущий ключ или отдельный

, он не сможет откатить HMAC назад и получить старые ключи.

Но это не полный Double Ratchet из Signal Protocol.

В полном Double Ratchet есть ещё DH ratchet step: стороны периодически выполняют новый Diffie-Hellman обмен и обновляют root key. Это даёт break-in recovery — возможность восстановить безопасность будущих сообщений после компрометации части состояния.

В моей реализации DH ratchet step пока нет. Если атакующий получит актуальное состояние сессии на устройстве и сможет продолжать его читать, он сможет расшифровывать будущие сообщения до переустановки сессии. Это честное ограничение текущей версии, и оно стоит первым пунктом в roadmap.

Мультиустройство: один пользователь, несколько конвертов

Первый неочевидный момент: в E2EE сообщение адресуется не просто пользователю, а конкретным устройствам пользователя.

Если у Боба два устройства — телефон и ноутбук — нужен отдельный encrypted envelope для каждого устройства. Сервер не может взять один конверт, расшифровать его и "переупаковать" для второго устройства: у него нет ключей и он не знает plaintext.

Значит при отправке сообщения нужно зашифровать его отдельно для каждого устройства каждого участника чата.

Для чата где у каждого по 2 устройства — 4 конверта на одно сообщение. Для группы из 10 человек — потенциально 20 конвертов. Это нормально, это цена безопасности.

Сервер: хранение и доставка конвертов

На сервере сообщение создаётся с контентом

, а конверты сохраняются отдельно:

После сохранения — fanout по WebSocket. Каждое устройство получает свой конверт и только его:

Это важное отличие от обычного WebSocket-чата. В обычном чате сервер рассылает одно и то же событие всем участникам. В E2EE-чате сервер рассылает разные события разным устройствам: payload для каждого устройства содержит свой

Топик

— строго персональный. Устройство А не получает конверт устройства Б. Никакого broadcast — только адресная доставка.

Архитектура целиком

Баг который долго не замечал

В панели чатов показывается превью последнего сообщения. Я реализовал это через

Запускаю — в списке чатов у всех написано

.

Конечно. Сервер же не знает что там написано.

Я полчаса думал как решить это на сервере. Потом дошло: нельзя решить это на сервере — у него нет ключей. Решение только на клиенте.

После того как пользователь открыл чат и сообщения расшифровались — кешируем последнее в памяти:

Это хороший пример того, как E2EE меняет привычное мышление backend-разработчика. В обычном приложении preview — это поле в SQL-запросе. В E2EE-приложении preview — это локальное клиентское состояние, потому что только клиент видел plaintext.

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

Rate limiting: дыра которую легко не заметить

Эндпоинт

отправляет SMS с кодом. Без защиты любой скрипт может дёргать его тысячи раз — это называется SMS pumping fraud, SMS стоят реальных денег.

Redis у нас уже был для хранения онлайн-статусов. Добавил rate limiting поверх него:

При превышении — HTTP 429 с заголовком

. Клиент знает через сколько секунд можно повторить.

Важный нюанс: в текущей реализации, если Redis недоступен, сервис не блокирует авторизацию полностью. Для pet-проекта это приемлемый компромисс: лучше рискнуть одним лишним SMS, чем положить вход в приложение.

В production я бы сделал строже: fallback in-memory лимит на инстанс, отдельные лимиты по IP и телефону, антифрод-логику и алерты на всплески отправки кодов.

Авторизация WebSocket

Отдельная история — авторизация WebSocket соединений. HTTP-эндпоинты защищены Spring Security автоматически, но WebSocket — другое дело. STOMP-соединение устанавливается один раз, и нужно проверять JWT при каждом подключении.

Отдельно важно не только проверить JWT, но и связать WebSocket-соединение с конкретным устройством. Пользователь может быть один, но устройств у него несколько, а encrypted envelope адресован именно

Поэтому при подключении я проверяю не только токен, но и

: устройство должно быть зарегистрировано и принадлежать текущему пользователю. Иначе легко случайно превратить per-device E2EE-доставку обратно в обычный broadcast по пользователю.

Что получилось — живые скрины

Что реализовано:

• E2EE-модель с per-device encrypted envelopes
• X3DH session setup + Symmetric Ratchet + AES-GCM
• Мультиустройство
• Личные и групповые чаты
• Realtime доставка через WebSocket/STOMP
• Статусы SENT → DELIVERED → READ
• Редактирование и soft delete сообщений
• Online presence, typing indicator
• Фото-вложения
• Поиск пользователей
• Rate limiting на SMS через Redis
• Prometheus метрики + Grafana дашборд
• Swagger UI с JWT авторизацией
• 24 backend-теста на Testcontainers, 12 frontend на Vitest, E2E на Playwright
• GitHub Actions CI

Что ещё не сделано:

• Полный Double Ratchet с DH ratchet step и break-in recovery
• Ротация signed prekey и аккуратное пополнение one-time prekeys
• Более строгая модель хранения приватных ключей на клиенте: non-extractable CryptoKey + IndexedDB
• Защита от подмены frontend-кода: подпись сборок, независимая верификация клиента, reproducible builds
• Android-клиент с Android Keystore
• Реальный SMS-провайдер вместо кода в backend-логах
• Push-уведомления без утечки содержимого сообщений
• Более строгая metadata-модель для групповых чатов

Главный инсайт

E2EE — это архитектурное решение, а не библиотека.

Нельзя взять обычный Spring Boot чат и просто "включить шифрование". Нужно с самого начала проектировать систему так, чтобы backend не был участником доверенной зоны: он не должен получать plaintext, не должен иметь ключи и не должен уметь пересобирать сообщение из данных в базе.

Это меняет почти всё:

• структуру БД — вместо текста появляются encrypted envelopes
• API — сервер отдаёт [encrypted], а не preview сообщения
• WebSocket — доставка идёт не по пользователю, а по конкретному устройству
• мультиустройство — одно сообщение превращается в несколько ciphertext-конвертов
• frontend — становится полноценной криптографической частью системы, а не просто UI

Второй инсайт: мессенджер — это не "чат с WebSocket". В E2EE-модели это система доставки зашифрованных конвертов с адресацией по устройствам. Как только это принимаешь, многие странные на первый взгляд решения становятся логичными.

Репозиторий

Код открыт: github.com/vaazhen/chaos-messenger

В репозитории есть README на русском и английском, диаграммы, скриншоты, security audit, Docker Compose и запуск одной командой.

Проект не претендует на уровень production-криптомессенджера вроде Signal. Это учебный и инженерный open-source прототип, цель которого — показать, как E2EE меняет архитектуру backend, frontend и realtime-доставки.

Если вы делали что-то похожее — особенно интересно сравнить подходы к ротации prekey-ов, хранению non-extractable ключей в браузере и реализации DH ratchet step. Вопросы и критика приветствуются.

Проект набрал 686 звёзд на GitHub и попал на главную Hacker News.

• Podroid запускает Linux-контейнеры на Android без root — через QEMU TCG и Alpine Linux VM
• Встроенный Podman: docker-совместимый рантайм с персистентным хранилищем
• Работает на любом ARM64-устройстве с Android 8.0+ — не требует Pixel или KVM
• Порт-форвардинг, SSH, пресеты для Pi-hole, Nginx, Gitea, Grafana
• Open source под GPL v2, один APK без внешних зависимостей

Зачем это нужно

Встроенный Linux-терминал Android (из Developer Settings) использует аппаратную виртуализацию KVM — и поэтому работает только на Pixel. Формально его поддерживают и некоторые устройства с Exynos, но Samsung часто блокирует функцию через Knox. На Snapdragon-чипах (а это большинство Android-телефонов) терминал недоступен из-за отсутствия поддержки non-protected VM.

Podroid обходит это ограничение за счёт программной эмуляции через QEMU TCG. Это медленнее, чем KVM, но работает везде. Для задач вроде запуска скриптов, Pi-hole, лёгкого веб-сервера или SSH-туннеля производительности достаточно.

Как это работает

Podroid поднимает лёгкую виртуальную машину Alpine Linux через QEMU TCG (без аппаратной виртуализации KVM). Внутри VM работает Podman — docker-совместимый контейнерный рантайм с rootless-архитектурой по умолчанию.

При загрузке QEMU монтирует Linux-ядро и initramfs. Двухфазный init поднимает персистентный ext4-диск как overlayfs — всё, что вы установите или скачаете, сохраняется между перезапусками.

Что внутри

Контейнерный рантайм. Podman с crun, netavark и slirp4netns. Rootless по умолчанию — без демона с root-привилегиями. Контейнеры запускаются одной командой:

Терминал. Полная VT100/xterm-эмуляция на базе Termux. Настоящий PTY с поддержкой job control, сигналов и escape-последовательностей. 114 цветовых тем (Dracula, Nord, Solarized, Tokyo Night, Catppuccin, Gruvbox), 13 шрифтов (JetBrains Mono, Fira Code, Cascadia Code), поддержка мыши для TUI-приложений — btop, htop, mc, vim.

Сеть. Интернет из коробки через QEMU SLIRP. Порт-форвардинг с горячим добавлением через QMP — можно пробросить порты VM на Android-устройство прямо во время работы. Готовые пресеты для Pi-hole, Nginx, Gitea и Grafana. Встроенный SSH на порту 9922.

Хранилище. Размер диска на выбор: 2, 4, 8, 16, 32 или 64 ГБ. Папка Downloads с Android монтируется в VM через virtio-9p.

Требования и установка

• ARM64-устройство (большинство телефонов с 2018 года)
• Android 8.0+ (API 26)
• ~150 МБ для приложения + выбранный размер диска VM

Установка — один APK из GitHub Releases. Никаких внешних зависимостей, Termux не нужен. Открыть приложение → нажать Start VM → подождать ~20 секунд → Open Terminal.

Podroid — не замена полноценному серверу, но для локальной разработки, self-hosted сервисов и экспериментов на ходу — рабочий вариант. Исходный код — на GitHub под лицензией GPL v2.

Мне эта модель быстро наскучила.

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

Сразу зафиксируем рамки, чтобы не плодить фантомные ожидания:

- это не убийца Telegram;

- это не презентация для инвестора с KPI и growth loops;

- это не проповедь о том, как всем теперь жить.

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

И вот здесь началось смешное.

Я рассчитывал на бодрую гаражную поделку. Но эта штука оказалась заметно живее, упрямее и интереснее, чем я ожидал. Поэтому я и притащил ее на TProger. Не за аплодисментами. За самым ценным, что здесь умеют делать лучше многих: находить слабое место раньше, чем автор успевает самодовольно сказать «ну вроде едет».

Что это вообще такое

На текущем этапе это PWA-мессенджер.

Да, PWA. Да, осознанно. Да, я знаю весь стандартный набор комментариев про ограничения платформы, кривые пуши, фоновые ограничения и то, что

«настоящие пацаны пишут только натив». Можете не разогреваться, я это всё уже сам себе рассказал.

Почему все равно PWA:

- мне нужен был короткий путь от идеи до живого клиента;

- мне нужен был быстрый цикл выката без ритуальных танцев с

магазинами приложений;

- мне нужен был клиент, который можно быстро ломать, чинить,

пересобирать и снова кидать в бой;

- мне нужно было что заработает на разных платформах;

- мне нравится, что PWA живет в браузерной песочнице, а не лезет в телефон как хозяин квартиры.

У PWA есть реальные потолки:

- нет такой свободы по платформенным API, как у нативного клиента;

- фон, пуши и некоторые сценарии мобильной жизни работают хуже, чем

хотелось бы;

- нет нормальных VoIP-пушей (звонки работают только когда приложение

открыто), нет нормальной интеграции со списком вызовов телефона;

- по голой производительности натив его обгоняет.

И, да, Service Workers иногда ведут себя как подростки в пубертате, а iOS местами режет фоновую жизнь PWA так, будто лично обиделась на идею веб-клиента. Я в курсе. Выживаем с тем, что есть.

Но для моей задачи PWA дал главное: скорость эволюции. А в экспериментальном проекте это иногда важнее, чем стерильная идеология.

И да, работает эта штука подозрительно хорошо. Лучше, чем я ожидал, если честно.

Зачем вообще писать еще один мессенджер, когда мир и так ими забит

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

Потому что я люблю контролировать инфраструктуру, а не молиться на чужую.

Потому что читать статьи про очереди, ретраи, доставку, порядок сообщений и борьбу с race condition — это теория. А написать свое, увидеть, где оно течет, и потом руками это затыкать — уже ремесло.

Потому что мне скучно.

Да, это тоже важная часть правды. На обычной работе мозг периодически начинает зевать от предсказуемости. А когда ты в одиночку пытаешься собрать живой real-time-сервис, где есть сессии, доставка сообщений, поиск, синхронизация состояния, очереди и weird cases мобильной сети —

то зевота быстро заканчивается.

То есть да: это учебный проект. Но из тех учебных проектов, которые в какой-то момент говорят: «всё, детский сад закончился, теперь давай как взрослые».

Где начинаются не разговоры про highload, а настоящая инженерная жизнь

Пока не собираешь такое сам, кажется, что мессенджер — это просто чатик.

Ну текстик, ну websocket, ну кнопка «отправить», господи. А потом начинается взрослая часть спектакля.

1. Сообщение должно не просто уйти, а дойти правильно

Самая скучная и самая дорогая ошибка — считать, что «отправил» значит

«доставил».

Нет. В реальной жизни между клиентом, сетью, сервером и хранилищем полно мест, где всё может стать интересно:

- клиент послал пакет, но сеть моргнула;

- сервер принял, но клиент не получил подтверждение;

- клиент решил, что ничего не дошло, и отправил повторно;

- внезапно у тебя уже не просто доставка, а идемпотентность,

дедупликация, подтверждения, ретраи и очень неприятные разборки с

дублями.

И это только один кусок.

2. Порядок сообщений — штука гораздо более капризная, чем кажется

Пользователь хочет простой магии: чтобы сообщения были в нужном порядке, статусы не врали, а история не прыгала, как пьяный курсор.

Инженерная реальность куда веселее:

- локальный optimistic update на offline-first клиенте хочет быть

быстрым;

- серверная истина хочет быть правильной;

- база хочет жить в своей временной линии;

- несколько устройств одного пользователя могут в это время смотреть на

мир разными глазами.

Как только начинаешь совмещать низкую задержку с внятной консистентностью, выясняется, что ты не «чатик пишешь», а торгуешься с физикой и распределенными состояниями.

3. Race condition — это когда баг уже произошел, но ты еще не знаешь, где именно тебя унизили

Race conditions — мой любимый жанр инженерного фольклора. Это когда всё прекрасно, пока ты смотришь. И ломается ровно в тот момент, когда отвлекся налить кофе.

Условно:

- один поток думает, что пользователь в онлайне;

- второй уже считает, что он отвалился;

- третий в это время честно пишет новое состояние;

- четвертый с невинным лицом отдает клиенту вчерашнюю правду.

А потом ты сидишь и объясняешь себе, почему в 99.7% случаев всё идеально, а в оставшихся 0.3% система внезапно начинает разговаривать голосами. А когда еще и пытаешься заставить работать реалтайм систему еще в кластере, то все сложности возводятся в квадрат.

4. Любая «маленькая фича» очень быстро приходит за твоей архитектурой с ножом

Захотел новую механику? Например, необычную резервацию UIN еще до регистрации? На бумаге выглядит забавно. На бэкенде начинается вечеринка:

- появляется состояние для еще не существующего пользователя;

- нужно резервировать ресурс так, чтобы его не вымели любопытные и жадные боты;

- нужно думать о TTL, освобождении, гонках, повторных запросах и кривом клиентском поведении;

- нужно следить, чтобы веселая фича не превратилась в атаку на собственную логику.

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

5. Поиск и история сообщений сначала кажутся простыми. Потом ты взрослеешь

Пока данных мало, Postgres прощает тебе оптимизм. Потом история растет, индексы начинают намекать, что дружба дружбой, а latency по расписанию, и любой неаккуратный запрос внезапно становится личным конфликтом с CPU.

И тут выясняется, что в реальном мессенджере мало просто «хранить сообщения». Нужно еще:

- быстро искать;

- не ломать горячий путь доставки;

- не превращать сервер в печку под нагрузкой;

- думать наперед, где потом начнется горизонтальное масштабирование, а

где сначала будет боль, потом переписывание, потом снова боль.

Чтобы это не выглядело как очередная литература про «сложности highload», вот живой пример. Это кусок поиска по групповым сообщениям в моем бекенде: с проверкой доступа, выборкой только текстовых сообщений и сортировкой по релевантности.

Под этот запрос у меня лежит не молитва, а вполне конкретная опора: partial GIN index по выражению`(content->>'text') gin_trgm_ops`.Иначе такая красота очень быстро превращает сервер в отопление стойки за счет тупого перебора JSONB.

А вот так тот же самый функционал очень часто пишут новички — вроде работает, пока данных смешно мало:

Проблема тут не в эстетике. Проблема в том, что верхний вариант ищет по нужному полю, умеет нормально ранжировать результат и опирается на индекс. Нижний часто уезжает в тяжелый scan по JSONB, ищет по строковому представлению всего объекта и под нагрузкой начинает жечь CPU просто потому, что автору было лень договориться с базой по-хорошему.

На реальном объеме истории в проде разница здесь может быть уже не в процентах, а на порядок и выше. То есть это очень быстро превращается не в «чуть-чуть быстрее», а в 10x+, а дальше всё зависит от размера истории, доли текстовых сообщений, партиций и того, насколько сильно вы любите мучить PostgreSQL.

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

6. Очереди, ретраи и backpressure — это не украшения, а повод спать чуть спокойнее

В сетевом сервисе нельзя жить по принципу «ну отправили и ладно». Когда клиентов много, а сеть у части из них вечно в состоянии «между EDGE и молитвой», тебе нужны механизмы, которые умеют не только гнать трафик, но и не убивать систему собственным рвением.

То есть нужны:

- очереди (Kafka, или что вы там предпочитаете);

- повторные попытки (retry-логика);

- backpressure;

- вменяемая реакция на временную деградацию (graceful degradation);

- circuit breaker чтобы какой-нибудь маленький и вроде бы некритичный сервис не мог каскадно положить бы всю инфраструктуру;

- архитектура, которая умеет признавать, что мир не идеален.

Красиво это звучит только в статьях. В коде это обычно выглядит как серия компромиссов, которые ты принимаешь с лицом человека, только что подписавшего договор с хаосом. И все это когда у тебя нет сотен высокопроизводительных серверов в кармане, которые уже лишь за счет их мощности могли бы прощать многое.

Интерфейс я подсматривал у Telegram. И да, специально

Я не стал устраивать дизайнерский карнавал ради уникальности. У пользователя уже есть мышечная память. Она дороже моего самолюбия.

Если человек открывает новый мессенджер, он хочет быстро разобраться и написать сообщение. Ему не нужен артхаус-квест «найди кнопку отправки, автор так видит».

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

Моя любимая инженерная шалость: UIN-рулетка до регистрации

Тут я, конечно, немного похулиганил.

Я сделал резервацию UIN еще до этапа регистрации. То есть можно зайти, поймать красивый номер, а уже потом решить, нужен тебе вообще этот зоопарк или нет.

С человеческой стороны это фан, ностальгия и немного ICQ-вайба.

С серверной стороны это пачка вопросов:

- как хранить состояние для «почти-пользователя»;

- как не раздать красивые номера слишком щедро;

- как не дать мимо проходящему ботнету выгрести пул;

- как освобождать резервы и не плодить мусор;

- как не застрелить логическую целостность ради красивой игрушки.

С практической точки зрения миру, возможно, и не нужна эта фича. С инженерной — она просто слишком вкусная, чтобы я прошел мимо.

Про безопасность — без дешевой магии и без сказок для инвестора

Нет, я не изобретал свою криптографию. Я вообще считаю, что желание «сейчас быстренько придумаю свой защищенный протокол» должно автоматически активировать тревожную сирену. Да, создать защищенный протокол возможно, но это сложнее и дольше чем кажется из-за необходимости учета множества edge-cases; и в реальности сделанные на коленке протоколы чаще ненадежны, и, что еще хуже, об их уязвимостях могут знать лишь немногие пронырливые и порой не самые добросовестные люди.

Поэтому мой подход скучный, взрослый и не очень годится для красивых презентаций:

- транспорт закрыт современным TLS 1.3 (который на текущий момент, март 2026, взломать прямым криптографическим методом практически невозможно);

- клиент живет как PWA в браузерной песочнице, какая уже сама по себе имеет ряд уровней защиты;

- поверх этого я стараюсь не творить откровенной дичи;

Но важная оговорка, и она принципиальна: проект развивается быстро, агрессивно и временами как лаборатория под кофеином. Некоторые части еще могут отваливаться на ходу. Какие-то углы я уже вижу. Какие-то, уверен, еще нет.

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

Если вам нужна зрелая крепость для деликатной переписки — берите зрелые решения, которым вы уже доверяете.

Если вам нужен живой инженерный эксперимент, резервный канал связи и объект для вдумчивого краш-теста — вот он.

Почему я вообще тащу это именно на TProger

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

А у меня как раз тот случай, когда мне интереснее не «собрать лайки», а получить нормальную техническую реакцию:

- где архитектура выглядит спорно;

- где логика доставки сообщений может начать чудить;

- где PWA упрется в реальные ограничения платформы;

- где резервация UIN создает лишнюю поверхность атаки;

- где под нагрузкой начнет хрустеть то, что в одиночных тестах ведет себя прилично;

- где в протоколе, порядке событий, ретраях или кешировании я недооценил крайний случай.

Мне не нужен хор в духе «вау, круто».

Мне нужен ваш внутренний вредный сеньор. Тот самый тип, который открывает статью, хмыкает, а потом начинает мысленно разбирать чужую систему на части.

Вот ему я и пишу.

Что я от вас хочу

По сути — честной драки, но умной.

- Хотите проверить, как это переживает плохую сеть — отлично.

- Хотите посмотреть, как выглядит поведение в edge-cases — вообще прекрасно.

- Хотите понять, насколько легко читается логика протокола — давайте.

- Хотите найти баг в порядке сообщений, в кеше, в подтверждениях, в резервации UIN, в клиентском поведении — тем более.

Только давайте без детского жанра «я что-то молча сломал и ушел сиять в закат». Если найдете слабое место, баг, странность, дыру, подозрительный сценарий или красивый способ заставить систему вести себя не так, как я планировал, — пишите.

Мне это полезнее, чем аплодисменты.

И да: я не заявляю, что построил новый и единственно верный мессенджер.

Я заявляю другое. Я собрал свой рабочий велосипед, уже довольно злой и живой, и мне интересно, где именно TProger попробует вставить ему отвертку в спицы, и на какой секунде этот велосипед упадет.

Что можно делать прямо сейчас

- Если вы параноик или устали от мейнстрима и навязанных решений — держите это как запасной канал связи.

- Если вы соскучились по временам красивых UIN — приходите ловить UIN-номер.

- Если вы любите sniff, разбор трафика и сетевые игры — смотрите что идет по проводу.

- Если у вас профессиональная привычка первым делом искать edge-cases — вот, собственно, ради вас всё это и принесено.

И если что-то положите, вскроете или красиво разберете — пришлите детали. Я не обидчивый. Я, строго говоря, именно ради этого и открыл двери.

Что дальше

Планы без корпоративной шелухи, но вполне понятные:

- дальше допиливаю PWA-версию;

- нативные Android и iOS-клиенты — в планах, но пока не в приоритете;

- клиентскую часть, вероятно, позже открою, когда там станет меньше творческого барокко;

- идея с SDK / библиотекой для кастомных клиентов мне нравится отдельно: если люди захотят писать свои оболочки, это будет уже совсем красивый уровень игры.

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

Итог

На сегодня это экспериментальный PWA-мессенджер, который родился из упрямства, паранойи, скуки и любви к инженерным задачам, от которых нормальные люди обычно стараются держаться подальше.

Я делал его в первую очередь для себя. Но он уже дорос до стадии, когда его интересно не только строить, но и показывать наружу.

Если будете пробовать — лучше сразу добавить его на домашний экран (PWA так устанавливается). Так приложению жить будет заметно удобнее: платформа позволит заработать пуш-уведомлениям, появится нормальное кеширование, а оффлайн-режим перестанет быть декоративной надписью.

Если хотите просто еще один канал связи — пожалуйста.

Если хотите посмотреть и проверить, насколько крепок мой цифровой эксперимент, — тем более пожалуйста.

Если хотите проверить заодно и собственные навыки на живой системе, которая не притворяется идеальной, — вот, собственно, и весь смысл этой публикации.

Добро пожаловать.

Посмотрим, кто кого утомит первым: вы — мой сервер, я — ваши попытки его удивить, или реальность — нас обоих.

PS:

Меня там можно найти по нику IGRYM или по UIN 10001. Также есть внутренняя группа для первых пользователей (Early Birds, доступна на экране списка чатов через «+» вверху экрана)

Ссылки:

- Приложение: https://beta.plumb-app.ru/

- Телеграм-канал с новостями проекта: https://t.me/plumb_channel

- Телеграм-группа обсуждения: https://t.me/plumb_group

Программа обязывает всех разработчиков Android-приложений пройти верификацию личности — независимо от того, распространяют ли они приложения через Google Play, сторонние магазины или напрямую через APK. 62 организации из 19 стран, включая EFF, F-Droid и Tor Project, подписали открытое письмо против программы, назвав её угрозой открытости Android.

— Google требует верификацию личности для всех Android-разработчиков — не только в Play Store

— С 30 сентября 2026 незарегистрированные приложения блокируются в 4 странах, в 2027 — глобально

— F-Droid заявляет, что программа фактически уничтожает проект

— 62 организации (EFF, Tor Project, Proton, KDE) подписали открытое письмо против

— Для хобби-разработчиков предусмотрен бесплатный аккаунт с лимитом в 20 устройств

Android Developer Verification — программа верификации разработчиков, анонсированная Google во второй половине 2025 года. До сих пор верификация требовалась только для публикации в Google Play. Новая программа распространяет это требование на все каналы дистрибуции: сторонние магазины (F-Droid, Galaxy Store, Amazon Appstore), прямую загрузку APK и любой другой способ установки на сертифицированные Android-устройства (то есть практически все телефоны с Google Play Services — более 95% активных Android-устройств за пределами Китая).

Что требуется для верификации

Google предлагает два типа аккаунтов (регистрация — на developer.android.com/developer-verification):

• Full Distribution ($25) — полная верификация: юридическое имя, адрес, email, телефон, загрузка государственного удостоверения личности. Для организаций — дополнительно D-U-N-S-номер (бесплатный бизнес-идентификатор Dun & Bradstreet, но получение занимает до 28 рабочих дней)
• Limited Distribution (бесплатно) — упрощённая верификация без госдокументов, только email. Ограничение: не более 20 устройств. Запуск в июне 2026

Для разработчиков, уже верифицированных в Google Play Console, ничего не меняется — Google автоматически зарегистрирует подавляющее большинство существующих приложений.

Что происходит с незарегистрированными приложениями

С 30 сентября 2026 года в Бразилии, Индонезии, Сингапуре и Таиланде незарегистрированные приложения будут заблокированы для установки и обновления на сертифицированных Android-устройствах. В 2027 году требование распространится глобально.

В апреле 2026 на все сертифицированные устройства (Android 7+) через Google Play Services будет установлен системный сервис «Android Developer Verifier» — он и будет проверять регистрацию разработчика при каждой установке.

Для установки незарегистрированных приложений пользователю нужно пройти «расширенный режим» (advanced flow):

1. Включить режим разработчика в настройках
2. Подтвердить, что установка добровольная (защита от социальной инженерии)
3. Перезагрузить телефон (обрывает потенциальный удалённый доступ)
4. Подождать 24 часа (обязательный «период охлаждения»)
5. Пройти биометрическую аутентификацию
6. Установить приложение — с постоянной меткой «от неверифицированного разработчика»

Установка через ADB (для разработки и тестирования) по-прежнему работает без ограничений.

Почему Google это делает

Google ссылается на собственное исследование: вредоносное ПО из сайдлоуд-источников встречается в 90 раз чаще, чем из Google Play. Главная проблема — анонимность: разработчик, пойманный на распространении малвари, может удалить аккаунт и мгновенно зарегистрировать новый. Верификация привязывает дистрибуцию к реальной личности. 24-часовой «период охлаждения» в advanced flow направлен против сценариев социальной инженерии — когда жертву дистанционно вынуждают установить вредоносное приложение под давлением:

В течение этих 24 часов атакующему становится значительно сложнее удержать жертву. За это время вы, вероятно, выясните, что ваш близкий на самом деле не в тюрьме и что ваш банковский счёт не под угрозой.

Почему 62 организации против

В феврале 2026 года коалиция из 62 организаций опубликовала открытое письмо на имя Сундара Пичаи, Ларри Пейджа и Сергея Брина. Среди подписантов:

• EFF (Electronic Frontier Foundation)
• F-Droid — крупнейший альтернативный магазин свободного ПО
• Tor Project
• Proton (ProtonMail, ProtonVPN)
• KDE, GNOME Foundation
• LineageOS, Nextcloud, Vivaldi
• FSF, FSFE, Software Freedom Conservancy
• Chaos Computer Club, La Quadrature du Net, Privacy Guides

Главная претензия: F-Droid под угрозой закрытия

F-Droid — альтернативный магазин приложений, который компилирует программы из открытого исходного кода и подписывает их собственным ключом. По новым правилам F-Droid не может зарегистрировать чужие приложения от своего имени (это означало бы ложное заявление на владение), и не может обязать тысячи волонтёров-разработчиков лично регистрироваться в Google.

F-Droid заявил напрямую: если Google реализует программу в текущем виде, это фактически уничтожает проект. Аналогичная проблема у IzzyOnDroid и других репозиториев свободного ПО.

Шесть претензий открытого письма

1. Гейткипинг за пределами Play — Google становится единственным арбитром, кто может распространять ПО для Android
2. Барьеры входа — D-U-N-S-номер, госдокументы, $25 — непропорциональная нагрузка на инди-разработчиков
3. Приватность — централизация данных обо всех разработчиках у Google
4. Произвольное применение — Google может отозвать верификацию по своему усмотрению
5. Антиконкурентная разведка — Google получает данные обо всех приложениях конкурирующих экосистем
6. Регуляторные риски — возможный конфликт с DMA (Digital Markets Act) в ЕС

Хронология

• 2025 — программа анонсирована
• 30 марта 2026 — регистрация открыта для всех разработчиков
• Апрель 2026 — «Android Developer Verifier» устанавливается на все сертифицированные устройства через Play Services
• Июнь 2026 — запуск бесплатных Limited Distribution аккаунтов
• Август 2026 — глобальный запуск advanced flow для пользователей
• 30 сентября 2026 — начало блокировок в Бразилии, Индонезии, Сингапуре и Таиланде
• 2027 — глобальное распространение

Что не затронуто

• Установка через ADB — без ограничений
• Корпоративные managed-устройства (Enterprise MDM) — освобождены
• Альтернативные AOSP-прошивки (GrapheneOS, LineageOS, /e/OS) — не затронуты (нет Play Services)
• Разработка и тестирование — не требует регистрации

Выводы

Android Developer Verification — самое значительное ограничение открытости Android за всю историю платформы. Google аргументирует его борьбой с малварью (90x чаще из сайдлоуда), но критики указывают: программа превращает Android в подобие iOS, где единственный арбитр дистрибуции — владелец платформы.

Для разработчиков, публикующихся через Google Play, ничего не меняется. Для тех, кто распространяет приложения за его пределами — F-Droid, прямые APK, корпоративные решения — начинается обратный отсчёт до 30 сентября 2026.

Приложение White House (gov.whitehouse.app, версия 47.0.1) — официальный Android-клиент Белого дома, доступный в Google Play. Под капотом — React Native на Expo SDK 54 с движком Hermes. Бэкенд — WordPress, который отдаёт контент через REST API на whitehouse.gov.

— Приложение содержит JavaScript-инжектор, который скрывает cookie-баннеры, GDPR-диалоги, пейволлы и логин-стены на любых сайтах, открытых через встроенный браузер

— В коде заложена инфраструктура GPS-трекинга через OneSignal: опрос координат каждые 4,5 минуты при активном использовании и каждые 9,5 минут в фоне

— YouTube-плеер загружает HTML-страницу с GitHub Pages мейнтейнера сторонней библиотеки — компрометация аккаунта позволит выполнить произвольный код

— В продакшен-сборке остались артефакты разработки: URL localhost, IP разработчика и экспортированная Activity

Что из себя представляет приложение

Приложение Белого дома — по сути, обёртка над WordPress. Весь контент загружается через REST API с эндпоинтами вида /wp-json/whitehouse/v1/*. Вот основные разделы:

• /home — главный экран
• /news/articles — новости
• /wire — лента «The Wire»
• /live — прямые трансляции
• /galleries — фотогалереи
• /issues и /priorities — политические приоритеты
• /achievements — «достижения»
• /media-bias — раздел «предвзятость СМИ»
• /social/x — прокси ленты X/Twitter

Среди контента — разделы «THE TRUMP EFFECT», «Greatest President Ever!», «Text President Trump» (с номером 45470) и ссылки на TrumpRx.gov, TrumpAccounts.gov, а также форма доноса ICE. Конфиг Expo указывает владельца forty-five-press — судя по всему, это медиа-команда, а не государственное агентство.

Инжектор обхода cookie-баннеров и пейволлов

Самая неожиданная находка — JavaScript-код, который инжектируется в каждый сайт, открытый через встроенный WebView приложения. Пейволл (paywall) — это платная стена, блокирующая доступ к контенту для неподписчиков. Скрипт использует механизм injectedJavaScript в React Native WebView.

Что именно скрывает инжектор:

• Cookie-баннеры (по CSS-селекторам *cookie*, *Cookie*)
• GDPR-диалоги согласия (*consent*, *gdpr*, *GDPR*)
• Баннеры OneTrust (*onetrust*)
• Баннеры приватности (*privacy-banner*)
• Логин-стены (*login-wall*, *loginWall*)
• Стены регистрации (*signup-wall*, *signupWall*)
• Апсейл-блоки (*upsell*, *Upsell*)
• CMP-боксы (.cmpboxBtnYes, .cmpbox)
• Любые элементы с aria-label, содержащим «cookie» или «consent»

Скрипт работает в два этапа. Сначала создаёт CSS-правило display: none !important для всех элементов, соответствующих селекторам. Затем устанавливает MutationObserver, который отслеживает любые изменения DOM и скрывает новые элементы с соответствующими классами. Дополнительно принудительно снимает блокировку прокрутки: body { overflow: auto !important }.

По сути, приложение Белого дома обходит GDPR-требования и пейволлы на сторонних сайтах. Для государственного приложения это, мягко говоря, неожиданно.

Инфраструктура GPS-трекинга

В конфиге Expo есть плагин withNoLocation, который, казалось бы, отключает геолокацию. Однако в скомпилированном коде присутствует полноценная инфраструктура трекинга через OneSignal SDK.

Константы опроса координат

В классе LocationConstants жёстко заданы интервалы опроса:

• FOREGROUND_UPDATE_TIME_MS = 270000 — 4,5 минуты при активном использовании
• BACKGROUND_UPDATE_TIME_MS = 570000 — 9,5 минут в фоне
• TIME_FOREGROUND_SEC = 300 — 5-минутный порог для переднего плана
• TIME_BACKGROUND_SEC = 600 — 10-минутный порог для фона

Как работает трекинг

Класс GmsLocationController использует Google Fused Location API. При каждом опросе запрашивает координаты с приоритетом PRIORITY_BALANCED_POWER_ACCURACY (код 102) и устанавливает maxWaitTime в полтора раза больше интервала.

Перехваченные координаты обрабатывает LocationCapturer: широта, долгота, точность, временная метка, флаг фоновой работы и тип (грубый/точный). Всё сохраняется в PropertiesModel и отправляется на серверы OneSignal (api.onesignal.com).

Есть и фоновый сервис LocationBackgroundService, который продолжает собирать координаты даже когда приложение свёрнуто.

Защита — есть, но условная

Формально GPS-трекинг защищён гейтом: флаг _isShared по умолчанию false. Трекинг активируется только после вызова setLocationShared(true). Плагин withNoLocation по идее не должен его включать. Но вся инфраструктура скомпилирована в приложение. Поскольку трекинг реализован в нативном коде (Java), простое OTA-обновление JavaScript-бандла его не активирует. Однако если в приложении есть bridge-вызов к setLocationShared из JS — достаточно серверного конфига для включения без обновления через Google Play.

Риски цепочки поставок

JavaScript с чужого GitHub Pages

Для YouTube-плеера используется библиотека react-native-youtube-iframe, которая загружает HTML-страницу с GitHub Pages пользователя lonelycpp — мейнтейнера этой библиотеки:

Если аккаунт lonelycpp на GitHub будет скомпрометирован, злоумышленник сможет подменить эту страницу и выполнить произвольный JavaScript в WebView приложения Белого дома. Это классическая supply-chain атака (атака через цепочку поставок — компрометация стороннего компонента для проникновения в целевую систему). Хостинг ресурсов на GitHub Pages вместо CDN с Subresource Integrity — плохая практика для любого приложения, тем более государственного.

Виджеты Elfsight

Приложение загружает JavaScript-платформу Elfsight с CDN:

Elfsight — это виджет-платформа для социальных сетей. Никакой песочницы — скрипт исполняется в том же контексте, что и основное приложение.

Сторонние сервисы вместо госинфраструктуры

Ни один из сторонних сервисов не является государственной инфраструктурой:

• Mailchimp (whitehouse.us10.list-manage.com) — обработка email-подписок. Адреса пользователей уходят на серверы Mailchimp
• Uploadcare (ucarecdn.com) — хостинг контентных изображений через 6 захардкоженных UUID
• Truth Social — захардкоженный embed с профилем Трампа, аватаркой со static-assets-1.truthsocial.com и кнопкой «Follow»
• Facebook — плагин страницы через iframe facebook.com/plugins/page.php

Профилирование пользователей через OneSignal

OneSignal SDK в приложении — это не просто пуш-уведомления. Платформа предоставляет широкие возможности для профилирования пользователей:

• addTag — тегирование пользователей для сегментации
• addSms — привязка номеров телефонов к профилям
• addAliases — кросс-девайсная идентификация пользователей
• addOutcomeWithValue / addUniqueOutcome — отслеживание действий и конверсий
• Полный цикл in-app сообщений: WillDisplay, DidDisplay, WillDismiss, DidDismiss, inAppMessageClicked
• Отслеживание изменений состояния: подписки, разрешения, пользовательский профиль

Локальная SQLite-база хранит таблицы notification (с полями notification_id, opened, dismissed, title, message, full_data) и in_app_message (с отслеживанием показов и кликов).

Артефакты разработки в продакшен-сборке

В релизной версии приложения остались следы, которых там быть не должно:

• URL http://localhost:8081/wp-json/whitehouse/v1/galleries?page= — захардкоженный адрес локального дев-сервера
• IP-адрес разработчика 10.4.4.109 — прописан в strings.xml как react_native_dev_server_ip
• Пакеты expo-dev-client, expo-devlauncher, expo-devmenu — средства разработки Expo
• Иконка дев-меню dev_menu_fab_icon.png
• Экспортированная PreviewActivity из Compose UI Tooling — доступна другим приложениям через android:exported="true"

Экспортированная Activity — это потенциальный вектор атаки. Любое приложение на устройстве может запустить PreviewActivity через Intent.

Отсутствие certificate pinning

Certificate pinning (закрепление сертификата) — это метод защиты от атак «человек посередине» (MITM), при котором приложение принимает только заранее известные сертификаты сервера. Приложение Белого дома использует стандартный Android Trust Manager без закрепления сертификатов. Это означает, что при использовании скомпрометированного Wi-Fi или корпоративного прокси трафик между приложением и серверами whitehouse.gov может быть перехвачен и прочитан.

Разрешения и файловый доступ

Манифест запрашивает следующие разрешения:

• INTERNET — доступ к сети
• VIBRATE — вибрация
• ACCESS_NETWORK_STATE — состояние сети
• POST_NOTIFICATIONS — отправка уведомлений
• WAKE_LOCK — предотвращение засыпания
• RECEIVE_BOOT_COMPLETED — автозапуск при загрузке
• C2DM.RECEIVE — облачные пуш-уведомления
• CHECK_LICENSE — проверка лицензии Google Play

Конфигурация FileProvider описывает путь external-path name="shared" path="." — приложение может предоставлять любые файлы из внешнего хранилища другим приложениям через FileProvider. Это не означает чтение чужих данных, но расширяет поверхность атаки при взаимодействии между приложениями.

Полный стек зависимостей

Список SDK внутри приложения впечатляет:

• Фреймворк: React Native, Expo SDK 54, Hermes JS engine
• Пуш/вовлечение: OneSignal, Firebase Cloud Messaging, Firebase Installations
• Аналитика: Firebase Analytics, Google Data Transport, OpenTelemetry
• Сеть: OkHttp 3, Apollo GraphQL, Okio
• Изображения: Fresco, Glide, Coil 3, Uploadcare CDN
• Видео: ExoPlayer (Media3), Expo Video
• ML: Google ML Kit Vision (сканирование штрих-кодов), модель Barhopper
• Криптография: Bouncy Castle
• Хранилище: Expo Secure Store, React Native Async Storage
• WebView: React Native WebView (с инжектором)
• DI: Koin
• Сериализация: GSON, Wire (Protocol Buffers)
• Лицензия: PairIP license check (Google Play Verification)

Что делать пользователям

1. Не открывать ссылки через встроенный браузер приложения — копировать URL и открывать в Chrome/Firefox, где cookie-баннеры отображаются корректно
2. Проверить разрешения приложения в настройках Android: Настройки → Приложения → White House → Разрешения — убедиться, что геолокация отключена
3. Учитывать, что RECEIVE_BOOT_COMPLETED запускает сервисы приложения при каждой загрузке устройства — даже если вы не открывали приложение
4. Для параноиков: использовать отдельный рабочий профиль Android (Настройки → Система → Несколько пользователей) для изоляции

Чеклист для разработчиков: что не должно попадать в прод

Этот случай — хороший повод проверить собственные приложения. Вот что стоит убрать перед релизом:

1. URL localhost и IP-адреса разработчиков — искать в strings.xml, конфигах и коде
2. Дев-пакеты (expo-dev-client, devmenu) — исключать из релизных сборок через build flavors
3. Экспортированные Activity для отладки — убирать android:exported="true" у дев-компонентов
4. Внешние JS-зависимости без SRI — хостить критичные ресурсы на собственном CDN
5. Избыточные SDK-модули — если не используете геолокацию, исключить модуль из сборки, а не просто «отключить» флагом
6. Широкие пути в FileProvider — ограничивать до конкретных директорий вместо path="."
7. Certificate pinning — добавить для всех критичных эндпоинтов через network_security_config.xml

Выводы

Приложение Белого дома — это React Native обёртка над WordPress с инжектором обхода cookie и пейволлов, инфраструктурой GPS-трекинга через OneSignal и JavaScript-зависимостями с GitHub Pages стороннего разработчика. Без certificate pinning.

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

Оригинальный анализ доступен в блоге thereallo.dev.

А вы проверяли, какие разрешения у государственных приложений на вашем телефоне?

Релиз немного задержался — компания в последний момент отложила старт тестирования, пообещав, что обновление выйдет «скоро». В итоге пауза продлилась всего несколько дней.

Бета уже распространяется «по воздуху» для участников Android Beta Program. Владельцы актуальных Pixel получат обновление автоматически.

Обязательная адаптивность и доработанная камера

Одно из ключевых изменений — обязательная поддержка адаптивных интерфейсов для приложений, ориентированных на Android 17.

Разработчикам придется корректно обрабатывать разные размеры экранов и форм-факторы, включая складные устройства и планшеты. Формально это не то чтобы революция. Но теперь за игнорирование адаптивности можно будет заплатить совместимостью.

Вторая важная новинка — обновленные API камеры. Они должны устранить рывки и пропуски кадров при переключении режимов съемки. Это как раз та категория проблем, которую достаточно сложно показать на презентации, но которая напрямую влияет на пользовательский опыт.

Также в системе появились визуальные правки интерфейса. Google продолжает постепенно дорабатывать дизайн, не меняя радикально общую концепцию.

Как установить и когда ждать релиз

Участники программы тестирования получат Android 17 Beta 1 автоматически. Тем, кто не хочет устанавливать бета-версию, нужно выйти из программы и дождаться стабильной сборки.

Финальный релиз Android 17 ожидается во II квартале 2026 года. Судя по первой бете, Google делает ставку не на громкие функции, а на стабильность, производительность и требования к качеству приложений.

Для экосистемы это может оказаться важнее любой эффектной анимации.

Об этом компания сообщила в соответствующем Reddit-треде, параллельно выкатив обновление Android 16 QPR3 Beta 2.1 для совместимых устройств.

Пока деталей немного — Android 17 Beta 1 сосредоточится на исправлении багов, повышении производительности и общей стабильности системы. Но сам факт анонса означает, что цикл тестирования стартует по привычному для Google графику.

Кто получит Android 17 первым

Традиционно первыми доступ к новым версиям Android получают смартфоны линейки Google Pixel. Обновление автоматически придёт пользователям, уже зарегистрированным в программе Android Beta.

С высокой вероятностью Android 17 Beta 1 станет доступен для следующих моделей:

• Pixel 9 / 9 Pro / 9 Pro Fold / 9a;
• Pixel 8 / 8 Pro / 8a;
• Pixel 7 / 7 Pro / 7a;
• Pixel Fold.

Официальный список Google пока не опубликовала, но именно эти устройства сейчас участвуют в бета-программе Android 16.

Внутреннее кодовое имя Android 17 — Cinnamon Bun. Google продолжает гастрономическую традицию, хотя публично названия десертов больше не использует.

Как выйти из беты без потери данных

Если вы участвуете в программе Android Beta, Android 17 Beta 1 установится автоматически. Тем, кто не хочет переходить на новую ветку тестирования, нужно:

1. Выйти из программы бета-тестирования сейчас.
2. Проигнорировать уведомление об обновлении с пометкой Downgrade.
3. Дождаться стабильной версии Android 16 QPR3.

Если же установить Android 17 Beta и потом передумать, вернуться без полного сброса устройства не получится до окончания бета-цикла — ориентировочно до июня 2026 года.

Когда выйдет стабильная версия

Ожидается, что финальный релиз Android 17 состоится во II квартале 2026 года. Google обещает улучшения производительности, новые игровые функции и системные доработки.

*WhatsApp заменил более 160 000 строк C++-кода на Rust в критически важной части приложения — обработке медиафайлов. Новый код уже развернут на миллиардах устройств: от Android и iOS до веба, десктопа и носимых гаджетов.

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

Откуда вообще взялась проблема

История тянется с 2015 года и уязвимости Stagefright в Android. Тогда выяснилось неприятное: достаточно отправить специально собранный видеофайл и он выполнит код на устройстве жертвы еще до того, как пользователь что-то нажмет.

Проблема была в системных медиабиблиотеках операционной системы. Именно поэтому приложения вроде *WhatsApp не могли решить ее самостоятельно.

После этого в *WhatsApp появился собственный C++-модуль wamedia, который проверял медиафайлы на соответствие стандартам, чтобы не скормить ОС заведомо опасный контент.

Все это работало, но с оговоркой: код автоматически обрабатывал недоверенные данные, а значит сам становился идеальной мишенью для эксплойтов.

Почему именно Rust

В *WhatsApp довольно рано сделали неприятный, но честный вывод: значительная часть критических багов связаны с банальными ошибками работы с памятью в C и C++. Rust эту категорию проблем убирает на уровне языка.

Вместо аккуратного «подкручивания гаек», разработчики пошли чуть более радикальным путем: переписали медиабиблиотеку целиком, параллельно поддерживая две реализации — на C++ и на Rust.

Их прогоняли через дифференциальный фаззинг, тесты и сравнение поведения, пока результаты не совпали.

Что получилось на выходе

Итог оказался даже лучше ожидаемого. 160 000 строк на C++ превратились примерно в 90 000 строк на Rust. И это уже с тестами.

Производительность не просела, а потребление памяти в ряде сценариев даже снизилось. Основные сложности были не в коде, а вокруг него: размер бинарников из-за стандартной библиотеки Rust и сборка под десятки платформ.

Тем не менее, библиотеку полностью выкатили в прод. Сейчас этот Rust-код ежемесячно доставляется на миллиарды устройств, включая *WhatsApp, *Messenger и *Instagram.

В *Meta прямо называют это крупнейшим клиентским деплоем Rust, о котором им известно.

Зачем это пользователю, который «просто шлет мемы»

Новая система, внутри компании получившая имя Kaleidoscope, проверяет файлы еще до того, как ими займутся системные библиотеки.

Она отсекает битые и нестандартные структуры, ловит подмену типов (когда «картинка» на деле исполняемый файл), отдельно помечает рискованные форматы вроде PDF со скриптами и вложениями.

По сути, это еще один слой защиты. Пользователь его не видит, но это и не нужно.

Речь идет о баге, который позволяет атаковать пользователя без его участия — достаточно добавить его в специально подготовленный групповой чат.

Уязвимость затрагивает механизм автоматической загрузки медиафайлов в *WhatsApp-группах. В худшем сценарии злоумышленнику не нужно отправлять ссылки или заставлять жертву что-то открывать: вредоносный файл загружается на устройство сам.

Как работает атака

По описанию исследователя Project Zero Брендона Тишки, атака начинается с создания группы *WhatsApp.

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

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

Ключевая особенность уязвимости — отсутствие взаимодействия с пользователем. Жертве не нужно нажимать на вложение или даже открывать чат.

Почему Google раскрыла баг публично

Project Zero уведомила *Meta о проблеме 1 сентября 2025 года. По правилам программы, у компании было 90 дней на выпуск исправления. К 30 ноября полноценного патча не появилось, и Google опубликовала детали уязвимости.

Позже *Meta внедрила частичное серверное ограничение, которое снижает риск эксплуатации, но не устраняет саму проблему. Полноценного клиентского патча на момент публикации все еще нет.

Именно из-за этого Google решила не продлевать дедлайн и раскрыть информацию публично.

Кто под угрозой и что делать пользователям

Уязвимость касается только *WhatsApp на Android. О версиях для iOS и других платформ Project Zero не сообщает.

Чтобы снизить риск, Google рекомендует:

• включить расширенную приватность чатов в группах;
• отключить автоматическую загрузку медиафайлов;
• внимательнее относиться к неожиданным добавлениям в групповые чаты.

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

*Компания Meta и ее продукты признаны экстремистскими, их деятельность запрещена на территории РФ

Новую волну вредоносных Android-приложений обнаружили специалисты Dr.Web.

Как работают «умные» трояны

В основе новой схемы — TensorFlow.js. Это open-source библиотека от Google, которая позволяет запускать модели машинного обучения прямо в JavaScript. Вместо заранее заданных правил, троян анализирует изображение экрана и сам определяет, куда «нажать».

Сценарий выглядит так:

• троян загружает обученную ML-модель с удаленного сервера;
• открывает сайт с рекламой во встроенном скрытом WebView;
• делает скриншоты виртуального экрана;
• модель распознает нужные элементы (кнопки, видео, баннеры);
• вредоносное ПО имитирует реальные действия пользователя.

За счет визуального анализа, троян лучше адаптируется к современным рекламным форматам: динамической верстке, iframe, видео и постоянно меняющимся шаблонам.

Два режима работы: автономный и ручной

По данным Dr.Web, трояны используют сразу два режима.

Phantom-режим. Это полностью автоматический вариант, когда вредоносный код работает в фоне. Пользователь ничего не видит, а клики по рекламе выглядят максимально естественно.

Signalling-режим. Это уже более опасный вариант, при котором через WebRTC троян транслирует экран виртуального браузера операторам атаки. Злоумышленники могут в реальном времени нажимать, скроллить и вводить текст, управляя устройством удаленно.

Где распространяется вредоносное ПО

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

Среди выявленных приложений — мобильные игры с десятками тысяч установок. Параллельно трояны активно распространяются через сторонние APK-сайты и «моды» популярных сервисов вроде Spotify и YouTube, а также через Telegram-каналы и Discord-серверы.

Почему это опаснее обычного кликфрода

Формально такие трояны не крадут пароли и не вытаскивают личные данные. Но их скрытность делает их особенно неприятными:

• пользователь не видит подозрительных действий;
• ускоряется разряд батареи и износ устройства;
• растет расход мобильного трафика;
• рекламные системы получают фейковую «человеческую» активность, которую сложнее отфильтровать.

Главное же — это сигнал: ИИ все чаще используют не только для защиты, но и для атак. Вредоносное ПО постепенно перенимает те же инструменты, что и легальные разработчики.

Что делать пользователям

Рекомендации остаются простыми и банальными, но от этого не менее важными:

• не устанавливать APK из сторонних источников;
• избегать модов и бесплатных премиум-версий приложений;
• внимательно относиться даже к альтернативным официальным магазинам;
• регулярно обновлять систему и защитное ПО.

Компания просто дала доступ к сервису всем желающим по адресу chatgpt.com/translate. Причем доступен он буквально всем — даже тем, у кого нет платной подписки.

По интерфейсу ChatGPT Translate сильно напоминает браузерную версию Google Translate, но на этом сходство быстро заканчивается.

Чем ChatGPT Translate отличается от классических переводчиков

Формально это «переводчик». Но по сути — отдельный режим ChatGPT, заточенный под работу с переводом. Пользователь может:

• вставить или набрать текст;
• загрузить файл;
• прикрепить изображение с текстом (например, меню или вывеску);
• продиктовать фразу голосом.

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

Главное отличие — перевод не буквальный. ChatGPT Translate старается сохранить смысл, контекст и интонацию.

Перевод с учетом аудитории и контекста

После перевода диалог не обрывается. Пользователь может сразу уточнить: сделать текст более формальным, адаптировать его под деловую переписку, академический стиль или, наоборот, объяснить «как ребенку».

На базе какой модели это работает — неизвестно

OpenAI не раскрывает, какая именно модель используется в ChatGPT Translate.

Возможно, это GPT-5.2 Auto с кастомным системным промптом под перевод. Возможно — отдельная оптимизированная версия. Компания никак это не комментирует.

Почему это важный шаг для OpenAI

Запуск Translate хорошо вписывается в текущую стратегию OpenAI. Компания все больше уходит в массовые потребительские продукты, в то время как Anthropic концентрируется на корпоративных клиентах и разработчиках.

ChatGPT Translate — прямой удар по нише, которую годами считали съеденной Google Translate. Но вместо очередного клона, OpenAI предложила просто другой подход. В ее сервисе перевод — это скорее лишь начало работы с текстом, а не финальный результат.

Ограничения и текущий статус

На момент запуска переводчик доступен только в браузере. В мобильных приложениях ChatGPT для Android и iOS отдельного переключателя Translate пока нет.

Баг находился в Rust-реализации Binder — ключевого механизма межпроцессного взаимодействия в Android. Ошибка могла приводить к повреждению памяти и, как следствие, к kernel panic.

Исправление уже принято в стабильное дерево Linux и распространяется через обновления.

Что пошло не так

Проблема возникла в логике работы со списком death_list, который используется для отслеживания завершенных объектов Binder.

В коде применялся небезопасный вызов remove, который предполагал, что элемент либо присутствует в списке, либо не используется параллельно.

На практике это допущение оказалось неверным. В момент, когда один поток извлекал элементы списка и переносил их во временный локальный список, другой поток мог одновременно обращаться к тем же структурам данных.

Это создавало гонку данных и приводило к повреждению указателей prev/next в связанном списке.

В результате происходило обращение к невалидным адресам памяти внутри ядра. В логах такие ситуации проявлялись как ошибки обработки страничных запросов и завершались kernel panic.

Почему это особенно важно

Binder — один из базовых компонентов Android. Любые ошибки в его реализации потенциально затрагивают миллионы устройств.

При этом баг находился именно в Rust-коде, что делает ситуацию особенно чувствительной на фоне дискуссий о безопасности Rust в ядре Linux.

Напомним, что Rust активно продвигается как язык, снижающий риск ошибок работы с памятью. Однако этот случай показывает важную деталь: использование unsafe снимает часть гарантий языка и ошибки проектирования многопоточности никуда не исчезают.

Как баг исправили

Разработчики изменили логику очистки death_list. Вместо извлечения элементов во временный список и последующей обработки вне блокировки, код теперь:

• работает напрямую с оригинальным списком;
• извлекает элементы по одному под защитой блокировки;
• исключает параллельный доступ к структурам данных.

Таким образом, опасный сценарий с одновременной модификацией списка стал невозможен.

Что это значит для Rust в ядре

Этот инцидент не отменяет преимуществ Rust, но служит напоминанием: безопасность — это не только язык, но и архитектура кода.

Даже в Rust ошибки синхронизации и неверные предположения о владении данными могут приводить к критическим сбоям.

Для ядра Linux это еще один аргумент в пользу осторожного и постепенного расширения Rust-кода — с тщательным аудитом, ревью и минимизацией unsafe-участков.

Мессенджер MAX снова испытывает масштабный сбой. Утром 30 марта 2026 года пользователи по всей России начали массово жаловаться на недоступность сервиса — приложение не открывается, сообщения не отправляются, а у части пользователей не приходят уведомления.

Проблемы затронули Android, iOS и веб-версию. По данным Detector404, резкий всплеск жалоб начался около 09:25 МСК — число обращений быстро приблизилось к тысяче. Больше всего жалоб поступает из Москвы, Самарской области, Краснодарского края и Санкт-Петербурга.

Это уже не первый крупный сбой MAX в 2026 году: 10 февраля сервис также массово «падал» (тогда пресс-служба утверждала, что «всё работает в штатном режиме»). А накануне, 29 марта, фиксировались проблемы с VK Видео — сервисом из той же экосистемы VK.

Официальных комментариев от команды MAX по сбою 30 марта пока нет.

Предыдущий сбой MAX — 8 декабря 2025 года

8 декабря 2025 года мессенджер MAX столкнулся с крупным техническим сбоем.

По данным Detector404, количество жалоб за последний час превысило 944, а за сутки — более 1200. При этом сервис «упал» практически мгновенно — на графике видно резкое вертикальное поднятие кривой жалоб.

Пользователи сообщали о полной недоступности приложения: MAX не открывался, не пускал в аккаунт, не отправлял сообщения, а у некоторых приложение просто зависало на заставке.

Со сбоем столкнулись как владельцы Android-смартфонов, так и iPhone. И даже пользователи веб-версии.

География сбоя 8 декабря

Проблемы фиксировались в десятках регионов. Среди лидеров по числу жалоб — Краснодарский край, Республика Коми, Алтай, Новосибирская область, Республика Саха (Якутия) и Москва.

Данные были собраны на основе сообщений за последний час, но тенденция была общероссийской. Пользователи массово отмечали одинаковые симптомы:

• «не работает приложение»;
• «невозможно отправить сообщение»;
• «не приходит код авторизации»;
• «не открывается MAX, пишет ошибку сети».

Где именно «ломался» MAX

Согласно статистике Detector404, 45,9% жалоб пришло от пользователей Android, 29,7% — от владельцев iPhone и 18,9% пришлось на долю веб-версии.

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

Отдельная часть пользователей жаловалась, что мессенджер «видит интернет», но фактически не соединяется с серверами.

Что говорили пользователи и что было известно официально

Команда MAX тогда не опубликовала официального комментария. Пользователи предполагали, что это либо крупная внутренняя авария, либо сбой в CDN/серверной инфраструктуре.

Некоторые связывали проблемы с обновлением, вышедшим накануне.

Кампания стартовала на Indiegogo, где Jolla запросила около $5 млн, чтобы начать производство первой партии устройств в 2026 году.

Jolla давно известна своим альтернативным взглядом на мобильные операционные системы. После экспериментов с Sailfish OS, компания решила вернуться к идее открытого смартфона, созданного при участии пользователей, а не крупных инвесторов.

Что известно о новом Linux-смартфоне

Устройство пока фигурирует под рабочим названием Jolla Linux Phone. Компания публикует рендеры: корпус в теплых оттенках, вертикальная камера, минималистичный дизайн.

Основной акцент — на приватность, открытость и контролируемость пользовательских данных. Все то, традиционно является сильными сторонами проектов на Linux.

По словам Jolla, смартфон будет работать на полностью открытом ПО. В отличие от Android-устройств, здесь обещают отсутствие трекинга и отсутствие зависимости от крупных облачных сервисов.

Под капотом ожидаются характеристики среднего уровня: энергоэффективный процессор, 5G, приличная батарея и камера, которой будет «достаточно для повседневной съемки».

Конкретных спецификаций пока нет — компания обещает раскрыть их после формирования первой производственной партии.

Почему проект профинансировали так быстро

Комьюнити Jolla исторически активно поддерживает независимые мобильные платформы.

На старте кампании фанаты буквально за часы обеспечили основную сумму, а обсуждения на форумах и в комментариях показывают, что запрос на долгожданную «альтернативу Android» вырос.

Пользователи пишут, что устали от закрытых экосистем, навязанных сервисов и ускоряющегося темпа устаревания смартфонов.

Кроме того, рынок Linux-смартфонов переживает второе дыхание: Purism Librem 5 и PinePhone доказали, что нишевые устройства могут найти аудиторию. Особенно если предлагают прозрачность, ремонтопригодность и независимость от крупных корпораций.

Что дальше

Jokka планирует начать производство в 2026 году. Первые прототипы будут представлены публике раньше — после завершения инженерной фазы.

Команда подчеркивает, что финальная конфигурация смартфона будет обсуждаться вместе с сообществом.

Первичка и не только

Когда мы говорим «бухгалтерские документы», мы имеем в виду не пару стандартных бланков, а множество первичных, учредительных, учетных и распорядительных документов, полуструктурированных и гибких форм. Среди них счета-фактуры, УПД, формы ТОРГ-12, транспортные накладные, акты, УКД, КСФ, ИСФ, уставы, приказы, бухгалтерский баланс, отчеты о финансовых результатах и многие другие.

Визуальный контроль и ручная перепечатка этих документов в системы бухучета – одна из наиболее времязатратных задач бухгалтерии. Даже при выборочной проверке и среднем уровне автоматизации сотрудник успевает обработать около 200-300 документов в день, в то время как объем документооборота у крупных компаний исчисляется десятками и сотнями тысяч страниц.

Снять практически 100% нагрузки в части ввода и проверки данных из бумажных документов и поступающих по ЭДО сканов можно при помощи OCR-систем. Автоматическое распознавание документов исключает человеческий фактор и связанные с ним ошибки. Если сотрудник может банально устать или некорректно перенести информацию из документа, то ИИ, напротив, обеспечивает высочайшую точность извлечения данных.

Возможности ИИ для работы с бухгалтерскими документами

Для автоматизации работы с бухгалтерскими документами недостаточно простого полнотекстового распознавания. Чтобы действительно принести видимый экономический эффект, система OCR должна классифицировать документ, обнаруживать и считывать таблицы, чекбоксы и штрихкоды, извлекать даты, суммы, данные контрагентов, контролировать наличие подписей в документах, а также поддерживать распознавание многостраничных форм. Только такой комплекс возможностей ИИ способен внести реальный вклад в упрощение бухучета, учета НДС и налогов по УСН, ускорить делопроизводство и сэкономить часы времени сотрудников.

Мы в Smart Engines занимаемся разработкой таких решений. Наш флагманский продукт для распознавания документов Smart Document Engine способен выполнить месячный объем работы отдела из 10 бухгалтеров всего за 1 час. Система обрабатывает изображения документов без передачи данных в облака, на внешние серверы или краудсорсинговые платформы. Это означает, что содержание документов не покидает устройство сотрудника – бизнес при этом получает гарантию сохранения коммерческой тайны.

Интеграция системы распознавания в мобильные приложения позволяет получить доступ к возможностям ИИ прямо со смартфона – без необходимости в компьютерах и сканерах. Для извлечения структурированных данных достаточно просто загрузить скан или сфотографировать документ в приложении. У интеграции нашей системы в iOS и Android есть еще одно преимущество – благодаря ей банк может развернуть мобильный сервис для бухгалтерского сопровождения малого бизнеса и ИП, у которых нет на эти задачи штатных сотрудников.

Интеграция в Android

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

Вы переносите библиотеки (архитектурные срезы), бандл (набор документов, необходимых для распознавания) и jar-файл (интерфейс библиотеки) к себе в приложение. Подключаете jar-файл в вашей конфигурации gradle и после этого вы уже можете использовать наше API.

На этом этапе мы должны подготовить изображение для передачи в сессию. Мы создаем изображение класса se.common.Image с помощью соответствующих методов API.

Например, вы выбираете из галереи что-то в формате HEIC и система возвращает вам bitmap

Объект result содержит в себе не только распознанные поля документа, но и изображение документа: исправленное по перспективе и обрезанное по шаблону, уровень уверенности распознавания каждого поля и т.п.

Интеграция в iOS

Процесс интеграции в iOS-приложение тоже не вызывает сложностей, но имеет несколько вариантов из-за долгого отсутствия в экосистеме нормального пакетного менеджера зависимостей.

Первый вариант интеграции – ручной.

Вы перетаскиваете себе в проект две папки, одна из них содержит xcframework, обертку на objc и бандл. Вторая - готовый UI-контроллер, который можно вызывать из своего проекта.

Также необходимо в проекте прописать пути к заголовкам обертки и указать путь к файлу *-Bridging-Header.h, для раскрытия делегатов в swift из нашего контроллера.

Более удобные для интеграции SPM и Cocoapods мы тоже поддерживаем.

Сценарий взаимодействие с библиотекой на iOS точно такой же как и на Android, но в iOS мы имеем больше инкапсулированной логики. Для начала следует добавить в ваш класс два протокола SmartDocumentEngineDelegate, SmartDocumentEngineInitializationDelegate

Приведем сразу коллбек imagePicker, где реализована основная логика распознавания после выбора изображения из галереи.

Ожидать результата следует в делегате.

Объект результата по структуре идентичен объекту, который вы получаете в Android.

Подведем итоги

Как вы видите, интеграция нашего распознающего ИИ в мобильные приложения происходит быстро и бесшовно, а механика для iOS и Android отличается незначительно.

Помимо мобильных телефонов, наши технологии можно встроить и на компьютеры, планшеты или сервера компании, однако на смартфоне весь бухгалтерский документооборот становится проще и доступнее для сотрудников.

Подробнее с нашими решениями можно ознакомиться на сайте Smart Engines. А если вам понравился материал, предлагаем к прочтению нашу предыдущую статью про распознавание документов в мессенджерах.

Если PEP примут, Python впервые за историю станет «двуязычным» проектом — частично на C, частично на Rust.

Зачем Python нужен Rust

Разработчики приводят несколько причин:

• Безопасность памяти. Rust устраняет категории ошибок, привычные для C: use-after-free, гонки, переполнения.
• Подготовка к free-threaded Python. Переход к работе без GIL требует безопасных примитивов — Rust подходит идеально.
• Производительность. Rust позволяет создавать быстрые структуры данных без ручного менеджмента памяти.
• Современный стек. Linux, Android и Firefox уже используют Rust в системных компонентах — Python догоняет тренд.
• Поддержка долгосрочного развития CPython. Сложность кода растет, а Rust упрощает сопровождение.

Что именно планируют делать

Стоит отметить, что Rust не планируют использовать в качестве полной замены C — появится возможность использовать оба языка. В идеале, должен получиться симбиоз:

• Crate cpython-sys. Это набор автоматически сгенерированных привязок (FFI-слоя), которые позволяют Rust-коду безопасно «общаться» с внутренним API CPython.
• Поддержка модулей на Rust. Некоторые части стандартной библиотеки можно будет писать и подключать так же, как C-модули — только на Rust.
• Прозрачное разделение зон безопасности. «Безопасный» Rust будет использоваться по максимуму, а unsafe — только там, где нужно напрямую взаимодействовать с C-частями интерпретатора.

Уже есть рабочий пример — модуль _base64 на Rust, который оказался быстрее варианта на C.

Переходный план

Если PEP утвердят, переход займет три релиза:

• Python 3.15 — предупреждение при сборке без Rust.
• Python 3.16 — Rust остается опциональным, но его отключение потребует отдельного флага.
• Python 3.17 — Rust становится обязательной частью сборки CPython.

То есть через два релиза Python не соберется там, где нет Rust.

Какие есть проблемы

В обсуждении упоминают несколько рисков. Например, циклическая зависимость при сборке — Rust требует Python, Python требует Rust.

Вместе с тем, внедрение нового языка приведет и к повышению порога входа для новых участников разработки CPython. Как минимум потому, что им придется изучить Rust.

Появятся и сложности со сборкой в ограниченных средах, например embedded-системах. При этом остается неясной судьба Rust-API для сторонних расширений — скорее всего, его не откроют.

Что это значит для сообщества

Для пользователей Python почти ничего не изменится. А вот для разработчиков интерпретатора это станет одним из самых крупных сдвигов в истории проекта.

Так, Python наконец-то станет сильно безопаснее. При этом CPython получит более надежный фундамент для будущих фич вроде полного отказа от GIL.

Из интересностей: выпустил 5 игр в Steam одновременно, WebGL против WebGPU, интересная AR-механика.

Обновления/релизы/новости

Путешествие по чистилищу, встреча со смертными грехами и бой сЛюцифером: концепт-арты и подробности отменённой Dante’s Inferno 2

В планах была и третья часть — в сеттинге средневековой Флоренции.

BioWare: следующая Mass Effect остаётся в разработке, а сериал расскажет новую историю после оригинальной трилогии

Майк Гэмбл заявил, что EA и BioWare нацелены на то, чтобы рассказать новые истории во вселенной Mass Effect.

Square Enix проведёт массовые сокращения из-за «реорганизации операций» в Европе и Северной Америке

Компания хочет сосредоточиться на разработке игр у себя на родине.

Крис Авеллон заявил, что Obsidian не планирует The Outer Worlds 3, но готовит Avowed 2

Сооснователь и ветеран Obsidian рассказал, что студия не планирует работать над триквелом The Outer Worlds, однако вторая игра получит хотя бы одно DLC.

GTA VI опять перенесли — в этот раз на 19 ноября 2026 года

Дополнительное время разработчики потратят на то, чтобы довести игру до уровня качества, которого ждёт и заслуживает аудитория. Издатели, тем временем, бегают с горящей жопой.

Ubisoft заявила, что люди «любили ненавидеть» Assassin’s CreedShadows, но компании удалось противостоять «даже самым громким хейтерам»

Ubisoft выступила на Paris Games Week и показала ролик о культурном скандале вокруг Assassin’s Creed Shadows, вызванном участием в сюжете темнокожего главного героя Ясукэ.

«Мы не хотим, чтобы студия исчезла из-за одного неудачного проекта»: главное из интервью с руководителями Obsidian

Они рассказали о желании определить, что значит быть игрой студии, и осторожности в разработке.

NetEase закроет студию бывших авторов Watch Dogs

Бывшие авторы Watch Dogs, основавшие студию Bad Brain, искали других партнёров для своего проекта Midnight Riders, однако пока издатели не заинтересовались игрой.

Google и Epic Games заключили мировое соглашение

Гугл пообещал снизить комиссию до 20% в целом, а для некоторых типов транзакций вообще до 9%.

Компания согласилась создать новую программу в следующей версии Android, где альтернативные магазины смогут зарегистрироваться в Google и (теоретически) стать полноценными приложениями, которые пользователи смогут легко устанавливать.

Unity запускает Unity Studio (ранее Unity Lite)

Новая бета-версия редактора Unity с очень минималистичным и урезанным набором функций, включая совершенно новый язык визуального программирования. Unity Studio ориентирована на аудиторию, не связанную с играми, и стремится сделать Unity доступной для неигровых разработчиков.

Авторы ремейка Gothic выпустили ролик о русском дубляже — Пётр Гланц-Иващенко озвучил главного героя

Безымянный говорил голосом актёра в оригинальной второй части.

Продано 100к копий Slots & Daggers

Разработчики поделились радостью в Стиме.

Халява/раздачи/бандлы/курсы

Fab: Лимитированный контент до 18 го ноября

Новый пак от Epic Games.

Новые примеры проекта от Agora Studio для Unreal Engine

Epic games выпустили два новых проекта примеров с анимациями для Unreal Engine: A-COM Animatic Sample и A-COM Animation Sample. Доступны для UE 5.6, а скоро выйдет обновление для UE 5.7.

Интересные статьи/видео

[RU] Выпустил 5 игр в Steam одновременно. Создал генератор игр и заработал на этом

Движок использовали Unity, а заливку в Google Play и добавление рекламы автоматизировали скриптом.

[EN] Как создать вид на японскую улицу с помощью Unreal Engine 5 и ZBrush

Массимо Росса рассказада про проект Street View, объяснив, как использовала различные сценарии освещения, чтобы увидеть, как может меняться окружение.

[RU] Подключение PlayStation2 Джойстика к Микроконтроллеру (или Переходник между человеком и компьютером)

В разработке электронных устройств на МК порой надо как-то посылать в прошивку команды. Обычно такая задача встаёт при ручном управлении подвижными агрегатами: краны, роверы, игрушечные вертолеты и прочее.

[EN] Переносим уютный двухмерный фэнтезийный коттедж в трёхмерный мир

Тринь Нгуен рассказала о проекте Cozy Fantasy Cottage, поделившись кистями, которые использовала для пропсов и материалов, а также некоторыми приёмами, экономящими время.

[RU] Зал Славы видеоигр: зачем это делается

Какую роль играют видеоигры для России? Зачем популяризировать российские проекты? Как работает Зал Славы видеоигровой индустрии?

[EN] WebGL против WebGPU: пора ли переходить

Неплохая обзорная статья-сравнение.

[RU] Конспект GDC лекции Stress-Free Game Development

Хорошая лекция про DevOps и менеджмент игровых проектов.

[EN] Скульптинг и текстурирование реалистичной жабы в ZBrush, Mari и Substance 3D

Фернандо Гутьеррес показал рабочий процесс, лежащий в основе проекта «Мистер Жаба», и рассказал о создании реалистичной кожи жабы, объяснив, как он черпал вдохновение в мимике взрослого человека и объединял её с линиями и текстурами старой жабы.

[RU] Как впервые делали игру для пользователей Эльбы, но не учли, что некоторые из них читеры

Как придумывали объекты и персонажей, чтобы это было интересно пользователям онлайн-бухгалтерии, какой игровой движок попробовали, что о нём думаем и почему выбрали для разработки формат хакатона.

[EN] Как создать дверь в стиле модерн с помощью Blender и Substance 3D

Ник Хофбауэр рассказал о процессе создания проекта Art Nouveau Door, показав, как он монтировал витраж, вручную нанося многочисленные слои друг на друга, и объяснив, как он настраивал отражения в Marmoset Toolbag.

[EN] Оптимистичный взгляд на то, что инди-игры сейчас переживают золотой век

Анализируем вместе с Крисом.

[EN] Продажи дебютной инди-игры за первый месяц — полный анализ

Выпускать инди-игру — это странно и страшно. Особенно в нишевом жанре. Но можно ли на этом заработать? Вот как выглядели первые несколько дней и недель после запуска дебютной игры с точки зрения цифр.

[EN] Почему трейлер игры привлёк 150к вишлистов в Steam

Разбираемся в успехе ABRISS вместе с gamediscover.

[EN] Зачем нам дизеринг

Объясняется, как методы дизеринга обманывают человеческое зрение, позволяя воспринимать больше цветов, чем есть на самом деле

[EN] Introduction to Clustered Meshlet Optimization

Представлен кластерный оптимизатор мешей для разделения моделей на независимые части с непрерывным уровнем детализации.

Разное

Интересная механика

Самописный движок на C++. Вычисляет, по каким объектам можно ходить, и в результате объекты одного цвета смешиваются друг с другом, и сквозь них можно пройти. На бумаге выглядит вполне себе интересно.

Волшебные карточки как в Балатро, созданные в Blender

Из Твиттера.

Если хотите поддержать выход дайджеста и других материалов, сделать это можно одним из способов.

• На Патреоне
• На Boosty
• Через Paypal
• Через Яндекс.Деньги

Также вы можете подписаться на рассылку дайджеста.

Если находка подтвердится, перед нами — одна из старейших копий легендарной операционной системы.

Как нашли ленту

Ленту обнаружил профессор Роберт Риччи во время уборки в школе вычислительной техники Университета Юты.

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

Чтобы не повредить артефакт, Риччи передал его в Computer History Museum в Калифорнии. И там, прямо сейчас, ленту осторожно побитово «снимают», не запуская на обычных магнитофонах. Это нужно для того, чтобы не стереть данные.

Почему это важно

Unix V4 — одна из первых версий, переписанных на языке C. Именно этот шаг сделал систему переносимой между разными машинами. И уже из этого решения выросли Linux, macOS и Android, а архитектура Unix до сих пор лежит в основе большинства современных ОС.

До последнего считалось, что оригинальная V4 утеряна — в архивах сохранились лишь обрывки кода и фрагменты мануалов.

Если лента окажется полной, это закроет огромный пробел в истории вычислительной техники.

Проблема «цифровой археологии»

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

Кроме того, формат данных может быть уникальным — в те годы каждый разработчик использовал свои схемы записи.

Почему Unix из Юты — особенный

В 1970-х Юта была одним из ключевых узлов ARPANET и первых университетов, получивших Unix по исследовательской лицензии Bell Labs. Местные студенты и инженеры активно модифицировали систему.

Именно из таких экспериментов, например, позже выросли BSD и многие современные утилиты.

Что дальше

Эксперты из Computer History Museum планируют оцифровать ленту и, при возможности, опубликовать исходники для исследователей.

Если восстановление удастся, это будет самое значимое возвращение утерянного программного кода за последние десятилетия — своеобразная «цифровая археология» уровня открытия древнего манускрипта.

Скачать его уже можно в Google Play, но пока только в США, Канаде, Японии и Южной Корее. Остальные регионы (включая Европу) получат доступ позже.

Что умеет Sora на Android

Функционал полностью совпадает с веб- и iOS-версиями:

• создание коротких видеороликов по текстовым описаниям;
• настройка стиля, атмосферы и эффектов;
• генерация реалистичных сцен и персонажей.

Главное обновление — функция Cameo, теперь умеющая работать не только с людьми, но и с анимированными героями.

Этот апдейт позволяет создавать ролики, где реальные и вымышленные персонажи появляются в одном кадре.

Как получить доступ

Sora 2 пока работает по приглашениям, но OpenAI постепенно открывает вход новым пользователям. Компания обещает, что в ближайшие недели доступ станет шире.

Таким образом, Android-пользователи наконец-то дождались релиза. А также того, что Cameo больше не эксклюзив iPhone.

Если суд одобрит условия, Google обязуется открыть Android для сторонних магазинов приложений и снизить комиссии для разработчиков до 9–20%. Причем изменения вступят в силу по всему миру.

Что изменится

• Разработчики смогут размещать альтернативные магазины прямо в Google Play.
• Пользователи — устанавливать их «в один клик» без предупреждений и «пугающих экранов».
• Комиссия снизится до 9% для простых транзакций и 20% для игровых покупок с преимуществами.
• В приложениях появятся альтернативные платежные системы — рядом с Google Play Billing, с возможностью выставлять разные цены.

Эти правила будут действовать до июня 2032 года.

Что говорят участники

Самир Самат, президент Android:

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

Тим Суини, CEO Epic Games:

«Это возвращение Android к его изначальной идее — открытой платформе. В отличие от Apple, Google делает реальный шаг к честной конкуренции».

Почему это важно

До этого суд уже обязал Google разрешить установку сторонних магазинов, но только в США и на три года. Теперь — глобально и надолго.

Для разработчиков это значит:

• меньше комиссий,
• больше свободы,
• и шанс строить свои экосистемы без риска блокировки.

Если суд одобрит сделку, Android наконец станет тем, чем его когда-то задумывали — по-настоящему открытой платформой.

Исследование охватило 5000 пользователей смартфонов из США, Индии и Бразилии. Его результаты показали, что владельцы iPhone на 65% чаще сообщают о получении трех и более мошеннических сообщений в неделю, чем пользователи Android.

При этом владельцы Android на 58% чаще заявляют, что не получали ни одного такого сообщения за неделю до опроса.

Android эффективнее блокирует фишинг и спам

По данным YouGov, пользователи Android также на 20% чаще оценивают встроенные механизмы защиты от мошенников как «очень эффективные» или «чрезвычайно эффективные».

Особенно заметен разрыв между владельцами Pixel и iPhone:

• владельцы Pixel на 96% чаще, чем пользователи iPhone, сообщали об отсутствии мошеннических SMS;
• владельцы iPhone на 136% чаще говорили, что получают большой объем спама;
• и на 150% чаще заявляли, что их смартфон не справляется с защитой от мобильного мошенничества.

Почему Android впереди

Эксперты также провели отдельный анализ встроенных защитных функций сразу четырех смартфонов: Pixel 10 Pro, iPhone 17 Pro, Samsung Galaxy Z Fold7 и Motorola Razr+ 2025.

Результат оказался неожиданным — iPhone занял последнее место по количеству и эффективности встроенных антифрод-механизмов.

Главные преимущества Android:

• распознавание мошеннических звонков и сообщений в реальном времени с помощью встроенного ИИ;
• автоматическая фильтрация SMS-спама и фишинговых ссылок в Google Messages;
• функция Call Screen, которая может сама отвечать на звонок и проверять собеседника;
• защита от «социальной инженерии» во время разговора — Android блокирует опасные действия (например, установку подозрительных приложений).

Компания представила официальный Swift SDK для Android, позволяющий писать нативные Android-приложения на фирменном языке, изначально созданном для iOS и macOS.

От iPhone до Android

Swift появился в 2014 году как альтернатива Objective-C — более безопасный, современный и лаконичный язык для экосистемы Apple.

За 11 лет он вырос из «внутреннего» инструмента в многофункциональную платформу, на которой создают облачные сервисы, десктопные приложения для Windows и даже прошивки для микроконтроллеров.

Теперь Swift впервые официально выходит за пределы «яблочной экосистемы. Превью-версия SDK для Android доступна уже сегодня — в составе Swift-инсталлятора для Windows или отдельно для macOS и Linux.

Как это работает

Новый SDK — результат многомесячной работы Swift Android Workgroup, открытого сообщества, куда может присоединиться любой разработчик. С его помощью можно:

• собирать нативные Android-приложения на Swift;
• переносить существующие Swift-пакеты — более 25% уже совместимы с Android;
• интегрировать Swift-код с Java через проект swift-java, автоматически генерирующий безопасные биндинги между языками.

Apple опубликовала подробное руководство «Getting Started» и примеры кода, демонстрирующие полный цикл разработки Android-приложений на Swift.

Что это значит для экосистемы

Релиз открывает дорогу к кроссплатформенным приложениям без использования Flutter, Kotlin Multiplatform или React Native.

Теперь компании смогут писать бизнес-логику один раз на Swift и использовать ее и в iOS-, и в Android-версиях.

Эксперты отмечают, что шаг Apple может снизить барьеры между мобильными экосистемами и ускорить развитие open-source сообщества Swift.

Что дальше

По словам участников проекта, впереди — создание полноценного Android-Toolchain, улучшение совместимости со средами разработки и официальное внедрение CI-сборок.

Разработчики уже готовят документ с видением будущего Swift на Android, который определит приоритеты и стратегию развития.

«Swift вырос из языка для iOS в универсальный инструмент для всего программного мира. Теперь он будет жить и в Android-экосистеме», — говорится в сообщении разработчиков.

Редакция Tproger сделала и адаптировала перевод подборки программ для Windows и macOS. Здесь вы найдёте проверенные временем решения для работы, развлечений и повседневных задач. Мы сосредоточились на бесплатных и условно-бесплатных приложениях с отличной репутацией, которые решают реальные задачи без навязывания ненужных функций.

Список разбит по категориям: от браузеров и гейминга до утилит безопасности и инструментов для продуктивности.

Неважно, опытный вы пользователь или новичок — здесь найдётся что-то полезное для каждого.

Браузеры

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

• Большинство пользователей: Chrome, Edge или Safari
• Защита приватности: Firefox, Brave, Ungoogled Chromium
• Опытные пользователи: Vivaldi
• Максимальная анонимность: Tor Browser

Google Chrome

Chrome остаётся самым популярным браузером в мире — и не просто так. Он быстрый, стабильный и отлично интегрируется с экосистемой Google. Огромная библиотека расширений из Chrome Web Store позволяет настроить браузер под любые задачи. Синхронизация между устройствами работает безупречно: вкладки, пароли, закладки и история всегда под рукой.

Минус один, но существенный: Chrome прожорлив. Если у вас открыто больше десятка вкладок, он может съесть несколько гигабайт оперативной памяти. На компьютерах с 8 ГБ RAM и меньше это становится проблемой.

Mozilla Firefox

Firefox — это выбор тех, кто ценит приватность и открытость. Mozilla не зарабатывает на продаже ваших данных, а сам браузер активно развивается сообществом. Встроенные инструменты защиты от трекинга работают из коробки, блокируя рекламные сети и скрипты слежения.

По скорости Firefox не уступает Chrome, а по потреблению памяти даже выигрывает. Библиотека расширений чуть меньше, чем у Chrome, но все основные инструменты доступны.

Microsoft Edge

Edge построен на том же движке Chromium, что и Chrome, но при этом лучше оптимизирован для Windows. Microsoft вложилась в производительность: браузер работает быстро, потребляет меньше ресурсов и отлично интегрируется с системой.

Особенно приятны функции вроде Collections (коллекции вкладок для организации исследований), режим чтения и встроенный скриншотер. Edge поддерживает все расширения Chrome, так что переход безболезненный.

Brave

Brave — это Chrome на стероидах приватности. Браузер блокирует рекламу и трекеры по умолчанию, что делает сёрфинг быстрее и безопаснее. При этом он полностью совместим с расширениями Chrome.

Есть интересная фишка: Brave Rewards позволяет зарабатывать криптовалюту за просмотр приватной рекламы (если захотите её включить). Спорная механика, но как опция — почему нет. Для тех, кто хочет Chrome без Google и с упором на приватность, Brave — отличный выбор.

Safari (только macOS)

Если у вас Mac, Safari заслуживает внимания. Это самый энергоэффективный браузер для macOS: на MacBook он даёт ощутимо больше автономности по сравнению с Chrome или Firefox. Интеграция с экосистемой Apple безупречна: Handoff, синхронизация через iCloud, Reading List, автозаполнение паролей.

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

Ungoogled Chromium

Для ультраосторожных Ungoogled Chromium удаляет всё отслеживание и сервисы Google — но вам придётся настраивать всё самостоятельно, так как в нём нет автообновлений или встроенной синхронизации.

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

Tor Browser

Выводя приватность на следующий уровень, Tor Browser маршрутизирует ваш трафик через сеть Tor, анонимизируя ваш IP и многократно шифруя соединение. Он медленнее по задумке, но идеален, если ваш приоритет — максимальная анонимность, а не скорость или удобство.

Vivaldi

Vivaldi — браузер мечты для тех, кто хочет полного контроля. Стекирование вкладок, тайлинг, кастомные горячие клавиши, встроенная почта и календарь, веб-панели — это полноценный десктопный опыт внутри браузера. Хотите боковую панель браузера, открывающую ваши заметки, RSS-ленты или любой нужный сайт? Vivaldi это умеет.

Arc

Наконец, Arc — когда-то новичок на рынке браузеров, нацеленный на переосмысление UX: замена традиционной панели вкладок на боковую панель, акцент на веб-приложениях, интегрированные разделённые виды и easels для заметок и доски. К сожалению, компания за Arc прекратила разработку, чтобы полностью переключиться на ИИ с новым браузером, который сейчас в закрытой бета-версии.

Управление паролями

• Лучший бесплатный выбор: Bitwarden
• Также отлично: 1Password, Dashlane, KeePass

Миллионы людей продолжают использовать одни и те же слабые пароли на всех сайтах — или, что ещё хуже, держатся за классику вроде «123456». Даже сильные пароли мало помогают, если их повторяют или забывают. Конечно, большинство браузеров предлагают встроенные менеджеры паролей, но они ограничены, привязаны к одному браузеру и менее безопасны, чем специализированные решения.

Также не будем забывать о passkeys (ключах доступа). Если говорить практически, можно сказать, что passkeys объединяют концепцию пароля и двухфакторной аутентификации (2FA) в одно плавное действие, но гораздо безопаснее и гораздо менее раздражающе.

Bitwarden

Полностью опенсорсный, зашифрованный и щедрый даже в бесплатной версии. Вы получаете неограниченное количество паролей, синхронизацию между устройствами и приложения для всех платформ. Премиум ($10/год) добавляет безопасный обмен файлами и инструменты 2FA. Также есть доступные семейные и командные планы.

1Password

Премиум-решение с отполированным интерфейсом, сильной кроссплатформенной поддержкой и отличными функциями вроде Travel Mode (режим путешествий) и полной интеграцией passkeys.

Dashlane

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

KeePassXC

Отличная оффлайн-альтернатива, если хотите полного контроля и не против ручной синхронизации (или использования чего-то вроде Syncthing или Dropbox для синхронизации базы данных).

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

Продвинутые утилиты и дополнения к ОС

• Поиск + лаунчеры: Everything или Wox (Windows), Alfred или Raycast (macOS)
• Пакетные менеджеры: WinGet, Homebrew (macOS)
• Для пользователей Windows: PowerToys
• Для пользователей Mac: Rectangle
• История буфера обмена: ClipClip, Flycut (macOS)
• Скриншоты + аннотации: Monosnap

Winget

Официальный менеджер пакетов Microsoft, встроенный в Windows 10 и 11. Работает похоже на Chocolatey, но разработан и поддерживается Microsoft. Homebrew — самый популярный менеджер пакетов для macOS. Позволяет быстро устанавливать, обновлять и управлять приложениями и CLI-инструментами с помощью команд в терминале.

Everything

Что касается поиска, Everything остаётся золотым стандартом сверхбыстрого поиска по именам файлов в Windows. Он индексирует диски за секунды и выдаёт почти мгновенные результаты с минимальной нагрузкой на систему. Если нужен функционал шире базового поиска, Wox использует движок Everything и добавляет мощные возможности лаунчера: поиск файлов, запуск приложений, калькулятор, перевод текста и расширения через плагины. Получается более гибкий опыт в духе Spotlight для Windows.

Command Palette/Alfred/Raycast

В который раз Microsoft не смогла существенно улучшить встроенный поиск Windows, хотя Command Palette в PowerToys даёт неплохой компромисс для тех, кто не хочет ставить сторонние утилиты.

На macOS Alfred по-прежнему главный лаунчер и утилита поиска. Он быстрый, интуитивный и в бесплатной версии включает историю буфера и настраиваемые поиски; расширенная автоматизация и «воркфлоу» доступны в Powerpack.

Тем, кто хочет современную облачно-интегрированную альтернативу с готовыми расширениями и встроенной поддержкой Notion, GitHub и Slack, стоит присмотреться к Raycast — это стильный, дружественный к разработчикам вариант, который стремительно набирает популярность.

Менеджеры буфера обмена

Они позволяют возвращаться к ранее скопированному — тексту, изображениям, ссылкам — и сильно ускоряют рутинные операции.

В Windows встроенная история буфера (Win + V) кое-как выручает, но продвинутым пользователям обычно хочется большего. В числе бесплатных рекомендаций — ClipClip для Windows и Flycut для macOS.

Когда речь о скриншотах и аннотациях, штатные инструменты macOS и Windows заметно выросли. Но многим всё равно удобнее сторонние решения. Нам по-прежнему нравится Monosnap за простоту и возможность мгновенно заливать снимки в облако для шаринга (и это бесплатно).

PowerToys — набор полезных утилит от Microsoft для продвинутых пользователей Windows, повышающих продуктивность и упрощающих рабочие процессы. Среди инструментов: FancyZones для продвинутого раскладывания окон, PowerRename для пакетного переименования, Keyboard Manager для ремапинга клавиш, универсальный color picker и другие.

Rectangle и Magnet — два самых популярных приложения на macOS для закрепления окон: быстрые выравнивание и ресайз по хоткеям или перетаскиванием, примерно как по умолчанию в Windows. Пользователям, пришедшим с Windows и скучающим по системному снапингу, одно из них жизненно необходимо.

Широко используемая альтернатива в Windows — FancyZones (часть PowerToys), предлагающая продвинутое управление окнами: настраиваемые сетки, зоны привязки и поддержку нескольких мониторов — поэтому это фаворит пауэр-пользователей на Windows.

Для рутины и создания проектов

• Бесплатные инструменты: FreeOffice, LibreOffice и WPS Office
• Microsoft Office за единовременную плату $49, Office 2024 — $129
• Заметки: Notion, OneNote, Obsidian
• Бесплатный PDF-редактор: PDFsam
• Почтовые клиенты: Thunderbird, eM Client

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

Microsoft Office остаётся отраслевым стандартом для профессиональной продуктивности. Подписка Microsoft 365 открывает доступ к Word, Excel, PowerPoint, Outlook и включает 1 ТБ облачного хранилища.

Среди бесплатных альтернатив LibreOffice — мощный open-source комплект с сильным сообществом (хотя интерфейс некоторым кажется старомодным). Если нужна внешне более майкрософтовская альтернатива, попробуйте FreeOffice или WPS Office Free — у них хорошая совместимость.

На macOS Pages, Numbers и Keynote предустановлены и более чем достаточны для большинства задач, особенно если вы в экосистеме Apple.

Знания и ведение заметок

Notion стал универсальной платформой организации: заметки, базы данных, to-do, управление проектами, создания совместных рабочих пространств. Если нужны более локальные заметки с синхронизацией между устройствами и поддержкой Markdown, Obsidian — любимец студентов и исследователей.

Для быстрых кроссплатформенных заметок OneNote — крепкий бесплатный вариант от Microsoft. В качестве альтернатив — Simplenote или open-source Joplin.

Если вы занимаетесь академической работой и научными статьями, Zotero — отличный open-source менеджер источников с интеграцией в браузер и совместными коллекциями. Milanote предлагает визуальный подход к заметкам и планированию — идеально для креативных пользователей.

Работа с PDF

Хотя Adobe Acrobat остаётся премиальным редактором PDF, бесплатные альтернативы вроде PDFsam позволяют без усилий объединять, разбивать, редактировать и поворачивать страницы.

Инструменты для дизайна и создания контента

Для дизайна два выделяющихся приложения хорошо дополняют набор продуктивности. Figma Desktop — совместная платформа интерфейс-дизайна, широко используемая UI/UX-дизайнерами и фронтенд-разработчиками. Десктоп-версия работает быстрее, чем браузер, и лучше интегрируется с ОС — это удобно для сложных дизайн-систем и коллаборации в реальном времени.

Canva с интуитивным drag-and-drop превосходно чувствует себя и как десктоп-приложение. Отлично подходит для быстрых графических материалов для соцсетей, маркетинга, постеров и презентаций. Благодаря тысячам шаблонов и совместной работе это фаворит как у профи, так и у новичков.

Почтовые клиенты

Если вы предпочитаете отдельный почтовый клиент, у eM Client много функций, бесплатный — до двух аккаунтов. Mozilla Thunderbird — мощная open-source альтернатива с удобной настраиваемостью, а Mailbird — вариант с упором на продуктивность для тех, кого не пугает подписка.

Инструменты разработчика

• Редакторы кода и текста: VS Code, Cursor, Sublime Text
• Система контроля версий: SourceTree, GitHub Desktop
• Контейнеры: Docker
• Локальные LLM: Ollama
• SFTP, загрузка файлов: WinSCP, Forklift

Для разработчиков Visual Studio Code — безусловный вариант. Бесплатный, лёгкий, но мощный, кроссплатформенный — тысячи расширений покрывают практически любой язык, фреймворк или инструмент. Набирающая популярность альтернатива — Cursor, редактор на базе VS Code с усиленной AI-помощью. Он подходит для связки с LLM: даёт inline-подсказки, генерирует код, рефакторит и позволяет редактировать кодовую базу.

При этом Sublime Text остаётся для скорости и простоты, а Notepad++ — отличный лёгкий редактор для быстрых правок в Windows.

Для Git графические клиенты SourceTree и SmartGit дают понятный интерфейс для управления репозиториями на GitHub, GitLab и не только. GitHub Desktop раньше был простоват и не слишком хорош, но сейчас существенно прибавил — всё ещё простой для работы, но в хорошем смысле.

Для локальных окружений, API-тестирования или терминального воркфлоу инструментов — пруд пруди. Например, Docker Desktop стал стандартом для тех, кто собирает и запускает контейнеризированные приложения на разных платформах. Он упрощает настройку окружений и держит систему чистой.

Ollama позволяет запускать большие языковые модели (LLM) локально с минимальной настройкой. Поддерживает модели вроде LLaMA, Mistral и другие open-weight альтернативы GPT, так что можно работать с ИИ прямо на своём компьютере без отправки данных в облако.

Если вы работаете с облачными хранилищами или SFTP, WinSCP (Windows) и ForkLift (macOS) — отличные клиенты с двухпанельным управлением файлами, синхронизацией и автоматизацией. На Mac также популярны Commander One и Transmit — у них есть встроенные подключения к удалённым и облачным путям.

Безопасность

И Windows, и macOS сегодня предлагают более чем достойную встроенную защиту. С защитой в реальном времени, интеграцией с файерволом и биометрией вроде Windows Hello и Touch ID. Для обычных пользователей, которые соблюдают гигиену безопасности: не скачивают сомнительное ПО, используют менеджеры паролей и включают 2FA — встроенной защиты часто хватает.

Для продвинутых пользователей есть дополнительные варианты.

Отличное первое дополнение — Malwarebytes. Это давний фаворит в обнаружении и удалении malware, adware и руткитов; бесплатная версия по-прежнему хороша для ручных сканов. В платной — защита в реальном времени без ощутимой просадки производительности.

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

Ещё один отличный инструмент — VirusTotal: бесплатный веб-сервис, который проверяет файлы и URL через десятки антивирусных движков. Прежде чем открывать подозрительную загрузку, можно залить файл на VirusTotal.com или использовать их расширение для браузера, чтобы проверять ссылки в реальном времени. Быстро, просто и удобно для осторожных пользователей.

Мы не поклонники установки антивирусов на каждый компьютер и не полностью в курсе, какие сейчас показывают лучшие результаты. Тем не менее, AV-Test давно и регулярно оценивает популярные решения, поэтому советуем смотреть их свежие отчёты. В текущем списке высокооценённых — Avast, BitDefender, ESET и другие; многие из них предлагают бесплатные версии для пробы.

Удалённый доступ и вспомогательные утилиты

RustDesk стал современным, ориентированным на приватность аналогом TeamViewer. Он с открытым исходным кодом, быстрый и работает кроссплатформенно.

Тем, кому нужны более устоявшиеся коммерческие решения, подойдёт AnyDesk, который остаётся лёгким и надёжным вариантом для личного и командного использования.

Превращение смартфона в пульт дистанционного управления компьютером бывает невероятно удобно — будь то презентации, потоковое видео или просто навигация с дивана.

Remote Mouse — простой и эффективный способ эмулировать мышь и клавиатуру с телефона. Для более продвинутых сценариев можно использовать приложения вроде Unified Remote.

Редактирование изображений и видео

• Профессиональный видеомонтаж: DaVinci Resolve
• Простой видеомонтаж: CapCut
• Редакторы изображений: GIMP, PhotoDemon, Pixelmator Pro
• Бесплатное улучшение изображений: Upscayl
• RAW-редактирование: RawTherapee
• Видеоконвертация: HandBrake

Если вам нужен бесплатный инструмент для редактирования изображений, GIMP — один из самых мощных вариантов. Он предоставляет профессиональные возможности, такие как слои, маски и настраиваемые плагины, что делает его идеальным для продвинутых пользователей. Если вы ищете более лёгкий редактор с чистым интерфейсом, стоит обратить внимание на PhotoDemon. Он работает как портативное приложение на Windows, поддерживает слои и редактирование — отличный выбор для быстрых правок или ретуши.

Если вы хотите увеличивать разрешение изображений без потери качества, Upscayl — мощный и бесплатный инструмент для апскейла. Он кроссплатформенный, и по нашим тестам показывает результаты на уровне платных решений вроде Topaz.

Для векторной графики — логотипы, иллюстрации — Inkscape является достойным open-source вариантом с полной поддержкой редактирования SVG. Krita — ещё один отличный бесплатный инструмент, особенно подходящий для цифровой живописи и художественного творчества.

Для редактирования RAW-фотографий, Darktable и RawTherapee — два высококлассных open-source аналога Adobe Lightroom. Их широко используют фотографы, которым нужна работа с изображениями без подписки.

Для простых GIF-анимаций ScreenToGif — удобная утилита, мгновенно записывающая область экрана и экспортирующая в GIF или другие форматы с оверлеями.

Среди платных фоторедакторов Adobe Photoshop остаётся лидером, но для macOS есть Pixelmator Pro — мощное приложение с разовой оплатой, а Affinity Photo предлагает профессиональные возможности по более доступной цене.

Видеомонтаж и конвертация

DaVinci Resolve считается лучшим бесплатным профессиональным ПО. Его используют и энтузиасты, и профессионалы — от простого тримминга до цветокоррекции и сложного постпродакшена.

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

Для пользователей macOS iMovie предустановлен и остаётся надёжным вариантом для базовых видео. Если вам нужно просто конвертировать или сжимать видео в современные форматы, HandBrake — проверенное бесплатное решение с поддержкой и вариацией входных и выходных форматов.

Тем, кто ищет топовый профессиональный монтаж, подойдут Adobe Premiere Pro и Final Cut Pro, но там есть дорогая подписка и более высокий порог входа.

Коммуникации и совместная работа

• Для повседневной связи: WhatsApp, Messenger и Zoom, если у вас нет FaceTime
• Для приватности: Signal
• Для работы: Slack, Teams
• Для игр и общения: Discord

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

Для личной переписки WhatsApp и Facebook Messenger остаются самыми массовыми платформами по всему миру. У них есть десктопные клиенты и встроенное сквозное шифрование по умолчанию. Telegram также крайне популярен благодаря синхронизации между устройствами и поддержке крупных чатов. Пользователи Apple продолжают активно использовать iMessage для приватного, шифрованного общения в экосистеме Apple.

Из видеоконференций Zoom остаётся одним из лидеров для групповых звонков и онлайн-ивентов, предлагая локальные записи, демонстрацию экрана и комнаты (breakout rooms). Однако бесплатный тариф ограничивает 1:1 звонки 40 минутами, если не перейти на платный план. Zoom поддерживает сквозное шифрование, но при включении E2EE отключаются некоторые функции вроде облачной записи и комнат.

Google Meet — отличный браузерный аналог без необходимости установки, который заметно улучшился по качеству и удобству использования. Многие компании применяют Meet в ежедневной работе и гибридных форматах. Если ваша организация использует Microsoft 365, скорее всего, вы работаете в Microsoft Teams, который уже заменил Skype на корпоративном уровне. Teams поддерживает большие созвоны, обмен файлами и глубоко интегрирован с Office. Сквозное шифрование доступно, но только для 1:1 звонков.

FaceTime по-прежнему отличный для пользователей Apple, и благодаря новым обновлениям к звонку теперь могут присоединяться и пользователи Android/Windows по ссылке через браузер.

Когда приватность критична, Signal — один из лучших вариантов. Разработан некоммерческой организацией, бесплатен, open-source, без рекламы, использует надёжное сквозное шифрование для сообщений и звонков.

Для рабочих коммуникаций Slack и Teams продолжают использоваться в бизнес-среде. Бесплатный тариф Slack ограничивает историю 90 днями и звонки, но остаётся любимцем стартапов и малых команд благодаря интеграциям и ботам. Cisco Webex — также крепкий вариант, особенно популярен в корпоративной среде.

Если вы работаете с креативными командами, сообществами или геймерами, Discord стал явным лидером. Изначально созданный для игр, он превратился в полноценную коллаборативную платформу с текстом, голосом и видео, стримингом экрана и ботами для автоматизации. Многие комьюнити — и даже IT-компании — используют Discord как основной рабочий инструмент.

Для внутриигрового голосового чата TeamSpeak остаётся олдскульным достойным вариантом: можно использовать анонимно и получать полный контроль над сервером. Встроенный чат Steam лучше, чем раньше, и помогает в игровой координации, но большинство всё же выбирает Discord.

Гейминг, моддинг и стриминг

• Игровые платформы: Steam, Epic Games, EA App, Ubisoft, GOG
• Последние драйверы для GPU: Nvidia GeForce, AMD Radeon, Intel Arc
• Стриминг: OBS Studio

Steam остаётся центром PC-игр. Это не только магазин, но и социальная платформа, лаунчер и площадка с модами, облачными сохранениями и встроенным стримингом. Регулярные распродажи, поддержка контроллеров и сообщества делают его обязательным для любого PC-геймера.

Не менее важно установить Epic Games Store. Хотя библиотека меньше, он регулярно раздаёт бесплатные игры, доступные любому с аккаунтом Epic. Это также must-have, если вы играете в Fortnite.

Помните: не все издатели размещают игры на Steam или Epic. Для тайтлов EA понадобится EA App (ранее Origin), для Ubisoft — Ubisoft Connect, для Blizzard/Activision — Battle.net, а GOG Galaxy не только предлагает DRM-free классику, но и может агрегировать игры из других лаунчеров.

Некоторые сверхпопулярные игры распространяются отдельно: Minecraft (через Minecraft.net или Microsoft Store), Roblox, League of Legends и Valorant (через лаунчер Riot Games). Если вы новичок и ищете что-то лёгкое, можно начать с free-to-play тайтлов или классики вроде Brutal Chess или GZDoom.

Если вы играете с геймпадом, Windows поддерживает Xbox-контроллеры из коробки. PlayStation-контроллеры теперь тоже отлично работают: Steam через Steam Input поддерживает DualShock 4 и DualSense практически во всех играх. При необходимости глубокой кастомизации можно использовать DS4Windows, но большинству хватает возможностей Steam.

Если вас интересует моддинг, хороший менеджер модов время в этой жизни:

• Mod Organizer 2 — лучший для RPG Bethesda (Skyrim, Fallout).
• Vortex (от Nexus Mods) — дружелюбный к новичкам и поддерживает широкий перечень игр.

Для записи геймплея или стриминга Nvidia ShadowPlay и AMD Radeon ReLive подходят для простых задач. Но для стриминга с вебкой, сценами, оверлеями или многосценовым продакшеном OBS Studio — безальтернативный лидер. Он бесплатный, open-source и подходит как новичкам, так и про-стримерам (Twitch, YouTube, Kick и т.д.). SignalRGB помогает синхронизировать весь RGB-зоопарк и задавать динамические эффекты.

Мониторинг железа и разгон

• Мониторинг: CPU-Z, HWMonitor, HWiNFO64
• Настройка и разгон: Afterburner, FanControl, ThrottleStop, SignalRGB

Одно из первых дел, которое стоит сделать после сборки ПК — убедиться, что компоненты соответствуют ожиданиям и работают корректно. К счастью, существует много инструментов, позволяющих мониторить, тестировать и настраивать железо.

Начать стоит с CPU-Z — классического бесплатного инструмента, показывающего информацию о CPU, материнской плате, оперативной памяти и других компонентах. Он также умеет запускать простой стресс-тест и бенчмарк для проверки стабильности.

Для более широкого мониторинга HWMonitor показывает температуры, напряжения и скорости вентиляторов в реальном времени. Если нужно ещё глубже и с более гибким интерфейсом — HWiNFO64 считается одним из лучших: поддерживает логирование датчиков и интеграцию с оверлеями (например, RTSS или Rainmeter).

Чтобы проверить хранилище, CrystalDiskMark измеряет скорость чтения/записи SSD и HDD — это помогает понять, соответствует ли диск заявленным характеристикам. Глубже оценить здоровье накопителя можно в Hard Disk Sentinel, который анализирует SMART-данные, оценивает срок службы и предлагает ограниченный ремонт.

С точки зрения охлаждения, всё больше геймеров используют утилиты для настройки вентиляторов. FanControl — актуальный бесплатный фаворит: поддерживает сложные кривые оборотов, привязку к датчикам, и совместим с большинством современных материнских плат. На Mac одной из лучших утилит остаётся Macs Fan Control.

Для настройки видеокарт долгое время стандартом был MSI Afterburner — для разгона, настройки вентиляторов и мониторинга с RTSS-оверлеем. Однако из-за замедления обновлений многие сегодня используют встроенные утилиты от Nvidia (GeForce Experience/Control Panel) и AMD (Adrenalin Software).

Если вы меняете видеокарту или подозреваете проблемы с драйверами, обязательно используйте Display Driver Uninstaller (DDU) — он полностью очищает систему от старых драйверов перед переустановкой.

Если вы играете на ноутбуке или хотите снизить нагрев и повысить автономность, ThrottleStop остаётся одним из лучших инструментов для андервольта CPU и настройки энергопрофилей.

Тем, кто серьёзно подошёл к разгону CPU и GPU, пригодятся фирменные инструменты вроде Intel XTU (для Intel) и AMD Ryzen Master — они дают контроль над частотами, напряжениями и лимитами мощности.

Управление файлами

• Поиск больших файлов: SpaceSniffer, WizTree, Disk Drill (macOS)
• Поиск дубликатов: dupeGuru
• Архивы и ZIP: PeaZip, The Unarchiver
• Очистка: BCUninstaller, CCleaner Portable, AppCleaner (macOS)

Чтобы грамотно управлять файлами и освобождать место, нужно понимать, что именно занимает пространство. На Windows популярны WinDirStat и WizTree — быстрые бесплатные инструменты для визуализации диска. SpaceSniffer предоставляет динамическую схему.

На macOS — GrandPerspective и Disk Drill предлагают аналогичный функционал, а DaisyDisk — один из самых красивых платных вариантов с молниеносным сканированием.

Если дубликаты засоряют диск, dupeGuru (open-source) отлично справляется с поиском повторяющихся изображений и музыки, даже слегка изменённых.

Для пакетного переименования файлов (например, фоточек с камеры) существует гибкий Bulk Rename Utility. Если нужно что-то попроще: PowerRename из PowerToys (Windows) или встроенный инструмент в Finder (macOS) подходят большинству.

Встроенный File Explorer в Windows недавно получил вкладки и стал удобнее, но Files (open-source) — современная альтернатива с улучшенным UX. Кто-то ещё пользуется Total Commander или Directory Opus, благодаря расширяемости и скриптам, хотя новичкам они кажутся устаревшими. Для просмотра изображений по-прежнему незаменим IrfanView.

Для работы с архивами, если не устраивает встроенный ZIP-менеджер Windows, скачайте 7-Zip или PeaZip. На Mac лучшим бесплатным инструментом остаётся The Unarchiver.

Для очистки системы важно выбирать надёжные утилиты. На Windows, BCUninstaller (Bulk Crap Uninstaller) — один из самых проверенных для удаления программ и их хвостов. BleachBit и Wise Disk Cleaner — безопасные альтернативы CCleaner (лучше использовать Portable-версию, так как стационарная испортила репутацию). На Mac AppCleaner всё ещё любим за полное удаление приложений без мусора.

Если вы организуете большую библиотеку медиа, стоит взглянуть на open-source TagSpaces, позволяющий тегировать файлы локально, без облака.

Облачное хранилище и резервное копирование

• Простая синхронизация: Dropbox, Google Drive
• Фото между устройствами: Apple iCloud, Google Photos
• Приватность: pCloud, Proton Drive, Internxt
• Полные бэкапы: Backblaze, IDrive

Базовое облачное хранилище

Dropbox — один из самых простых в использовании, хотя бесплатных 2 ГБ мало.

Google Drive — 15 ГБ бесплатно, используется Gmail, Docs и Photos. Идеален для Android.

OneDrive — идёт в комплекте с Windows и Microsoft 365. 1 ТБ включён в большинство Office-планов. Хотя по скорости и интерфейсу уступает Dropbox/Google.

iCloud Drive — лучший выбор для пользователей Apple, глубокая интеграция с macOS/iOS. Бесплатно 5 ГБ, далее по планам до 2 ТБ.

Proton Drive — шифрованная альтернатива от создателей ProtonMail.

Фото и видео

На macOS приложение Photos автоматически создаёт альбомы по людям и локациям, синхронизирует всё через iCloud.

На Windows мы часто рекомендуем Google Photos, который предлагает аналогичный набор функций и автоматизацию. Для пользователей Android — это стандарт по умолчанию. Да, раньше было безлимитно, теперь фото занимают общее место Google Drive (15 ГБ), которое быстро заканчивается.

Полные бэкапы

Если требуется сохранять всю систему, терабайты медиа, состояние дисков используйте отдельные сервисы резервного копирования.

Backblaze — топ в этой категории: фиксированная цена (~$8/месяц за устройство), безлимитное хранилище, минимум настроек: установил и забыл.

IDrive — более контролируемый вариант, поддерживает несколько устройств, внешние диски и версионность файлов.

Простой для не-технарей — Carbonite, с возможностью быстрого восстановления и круглосуточной поддержкой.

Профессионалам — Acronis Cyber Protect: клон дисков, анти-вымогатель, гибридное облако.

Для особо чувствительных данных

Если вы храните личные финансовые документы или медицинские сведения, стоит выбрать end-to-end решений.

pCloud предлагает клиентское шифрование (через платный «Crypto»). Даже при взломе аккаунта файлы не расшифруются без ключа.

Proton Drive — аналогичный подход, с прозрачностью open-source.

Прочие полезные инструменты, не вошедшие в другие разделы

Google Earth — для любителей карт и планировки.

qBittorrent — лучший torrent-клиент: чистый, без рекламы, с поиском. Альтернатива — легковесный Transmission или кастомизируемый Deluge.

iMazing — must-have для владельцев iPhone: резервные копии, экспорт медиа, проверка батареи, конвертация HEIC.

AirDroid — аналог для Android: управление файлам, уведомления, SMS с ПК.

Rufus — лидер по созданию загрузочных USB-дисков для Windows/Linux.

Open Shell — возвращает классическое меню «Пуск» в стиле Windows 7.

Stretchly — напоминает делать перерывы — полезно удалёнщикам и фрилансерам.

AutoHotkey — скриптовый движок для Windows: переназначение клавиш, макросы, автоматизация.

VPN: бесплатные — ProtonVPN, Windscribe, TunnelBear (с лимитом). Платные — ProtonVPN, NordVPN.

Calibre — лучшее бесплатное решение для чтения, организации и конвертации e-book (EPUB, MOBI, PDF и др.).

Заключение

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

Несколько советов напоследок:

1. Не захламляйте систему. Устанавливайте только то, что действительно используете. Чем меньше фоновых процессов — тем быстрее работает компьютер.
2. Следите за обновлениями. Большинство программ обновляются автоматически, но некоторые требуют ручного апдейта. Свежие версии — это не только новые функции, но и закрытые уязвимости.
3. Делайте резервные копии. Никакие утилиты не спасут от отказа жёсткого диска. Регулярный бэкап на внешний носитель или в облако — обязательная практика.
4. Экспериментируйте. Попробуйте несколько браузеров, редакторов, плееров. То, что подходит большинству, может не подойти именно вам.
5. Читайте отзывы. Перед установкой незнакомого приложения загляните на форумы или Reddit. Сообщество быстро выявляет проблемы и подводные камни.

Теперь ваш компьютер готов к работе, учёбе, развлечениям — и чему угодно ещё. Главное — не забывайте, что инструменты важны, но ещё важнее то, как вы их используете. Удачи!

Современные приложения для камеры должны сочетать мощные функции: пользователи хотят снимать видео в HDR, с частотой 60 кадров в секунду и стабилизацией изображения — и всё это одновременно. Но как разработчику гарантировать, что устройство поддерживает такую комбинацию?

Ранее совмещение нескольких функций было рискованным: проверка поддержки каждой функции по отдельности не гарантировала их совместной работы. Это могло привести к нестабильной работе камеры или её полному сбою. Чтобы избежать проблем, разработчики ограничивали функциональность, лишая пользователей с мощными устройствами, такими как Pixel 10 Pro, полноценного опыта.

CameraX 1.5 решает эту проблему с помощью нового API Feature Group. Теперь вы можете заранее проверить поддержку комбинации функций или задать приоритеты, а библиотека сама подберёт оптимальную конфигурацию для устройства.

Что такое CameraX?

CameraX — это библиотека Jetpack, которая упрощает разработку приложений для камеры на Android. Она предлагает удобный и единообразный API, совместимый с большинством устройств, начиная с Android 6.0 (API level 23). Для новичков рекомендуем изучить официальную документацию и пройти практический codelab.

Возможности API Feature Group

Новый API позволяет создавать продвинутые приложения для камеры, избегая проблем с совместимостью. Вы сможете:

• Создавать адаптивные интерфейсы: Динамически включать или отключать настройки в зависимости от возможностей устройства. Например, если пользователь включает HDR, опция 60 FPS автоматически станет недоступной, если комбинация не поддерживается.
• Реализовать режим “Максимальное качество”: Укажите желаемые функции с приоритетами, и CameraX выберет лучшую комбинацию, поддерживаемую устройством, без сложной логики.
• Избежать сбоев: Проверка поддержки комбинаций заранее предотвращает ошибки при настройке камеры, обеспечивая стабильную работу.

Как это работает: основные компоненты

API построен на обновленных классах SessionConfig и CameraInfo.

• GroupableFeature: Включает набор функций, таких как HDR_HLG10, FPS_60, PREVIEW_STABILIZATION и IMAGE_ULTRA_HDR. Список пока ограничен из-за вычислительных требований, но будет расширен в следующих версиях.
• Новые параметры SessionConfig:requiredFeatureGroup: Для обязательных функций. Если комбинация не поддерживается, вызов bindToLifecycle завершится ошибкой IllegalArgumentException.preferredFeatureGroup :Для необязательных функций. Укажите список с приоритетами, и CameraX выберет лучшую комбинацию.
• requiredFeatureGroup: Для обязательных функций. Если комбинация не поддерживается, вызов bindToLifecycle завершится ошибкой IllegalArgumentException.
• preferredFeatureGroup: Для необязательных функций. Укажите список с приоритетами, и CameraX выберет лучшую комбинацию.
• CameraInfo#isFeatureGroupSupported(): Метод для проверки поддержки комбинации функций. Передайте SessionConfig, чтобы узнать, поддерживается ли набор функций, и настройте интерфейс соответственно.

Практическое применение

Рассмотрим два сценария использования API.

Сценарий 1: Режим "Максимальное качество"

Чтобы автоматически включить лучшие функции, задайте список приоритетов в preferredFeatureGroup. Например, приоритет: HDR, затем 60 FPS, затем стабилизация. CameraX сам выберет оптимальную комбинацию.

CameraX проверит комбинации в порядке приоритета, выбрав первую поддерживаемую:

1. HDR + 60 FPS + Стабилизация
2. HDR + 60 FPS
3. HDR + Стабилизация
4. HDR
5. 60 FPS + Стабилизация
6. 60 FPS
7. Стабилизация
8. Ничего

Сценарий 2: Адаптивный интерфейс

Для интерфейса, реагирующего на выбор пользователя, проверяйте неподдерживаемые комбинации:

Интегрируйте логику в интерфейс для отключения неподдерживаемых опций и привязки стабильной конфигурации:

Ознакомьтесь с тестовым приложением CameraX для примера реализации (не для продакшена).

API Feature Group устраняет неопределенность при работе с продвинутыми функциями камеры, позволяя создавать надежные приложения. Он доступен как экспериментальный в CameraX 1.5 и станет стабильным в версии 1.6 с дополнительными улучшениями.

Что исправили

Две ключевые правки касаются дисплея. Первая устраняет мерцание экрана и внезапные выключения устройства в определённых сценариях. Вторая — проблему с «замершим» или размытым изображением.

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

Отдельно компания починила отображение статуса фонарика в виджете At a Glance и баг, из-за которого могла происходить аварийная перезагрузка при старте или остановке трансляции через Media Output Switcher.

Почему стоит установить обновление

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

Напомним, что в 2023 году жюри признало, что практики Google вокруг Play нарушают антимонопольное законодательство. В октябре 2024 г. судья Донато утвердил трёхлетний запрет, обязав Google открыть Play для конкуренции. Девятый округ летом 2025 г. подтвердил решение.

Сейчас судьи отклонили ходатайство Google о временной заморозке части судебного запрета. Верховный суд не стал замораживать ключевые части запрета судьи Джеймса Донато, которые были подтверждены Апелляционным судом Девятого округа летом.

Google планирует подать полноценную жалобу в Верховный суд до 27 октября, но это будет уже после даты исполнения. На данный момент запрет действует, и Google обязан начать исполнение.

Что Google должен сделать уже в октябре

Согласно приказу суда и его трактовке в материалах дела и СМИ, Google обязан:

• Прекратить требовать от разработчиков обязательного использования Google Play Billing.
• Разрешить разработчикам информировать пользователей (включая ссылки из приложений) о внешних способах оплаты без дополнительных комиссий и отпугивающих экранов.
• Открыть путь к распространению приложений вне Play Store (включая указание способов загрузки).
• Разрешить разработчикам устанавливать собственные цены.
• Прекратить выплаты/бонусы производителям устройств, операторам и разработчикам за эксклюзивы в Play или предустановку.
• Сотрудничать с Epic в рамках совместного технического комитета по безопасному доступу конкурирующих магазинов к каталогу Play.

Google публично сообщил, что выполнит юридические обязательства, параллельно продолжая попытки обжаловать запрет в Верховном суде. Компания предупреждает о рисках для безопасности пользователей при ослаблении контроля в платежах и дистрибуции.

• Google Play Store v48.3 (06.10.2025): обновленные иконки в некоторых уведомлениях Google Play Protect на телефонах, ПК, ТВ, Auto.

Важно: функция в релиз-нотах не гарантирует её мгновенную доступность на всех устройствах. Google часто вводит функции постепенно, «поэтапно разворачивая» (staged rollout).

Google Play services v25.39

Через APKMirror задокументирован выпуск версии 25.39.30 (beta).

Разработчики из Google усилили возможности управления аккаунтами — теперь система работает гибче с профилями под присмотром, упрощая родительский контроль и настройку устройств для детей. Темы, используемые в интерфейсах поднадзорных аккаунтов, получили визуальное обновление и стали единообразнее, чтобы пользователи лучше ориентировались в настройках.

Отдельного внимания заслуживает и визуальная часть — привычные аватарки теперь оформлены в новом, более современном и чистом стиле. Для разработчиков Google добавила свежие инструменты и API, которые позволяют глубже интегрировать функции управления аккаунтами и безопасности в сторонние приложения, обеспечивая плавную работу и более высокий уровень конфиденциальности.

Особое улучшение касается защиты и безопасности: функция Sensitive Content Warnings в Google Messages научилась распознавать нежелательный контент не только на фотографиях, но и в видеороликах — шаг, который повышает безопасность общения в мессенджере. Параллельно был переработан и режим Driving Do Not Disturb — он стал работать стабильнее, меньше отвлекать водителя и лучше подстраиваться под дорожные ситуации.

В более ранних версиях (v25.37) Google уже вводил исправления стабильности при управлении аккаунтами, улучшения соединений устройств и дополнения к API. Droid Life. Версия 25.39, скорее, эволюция этих функций, сглаживающая баги и добавляющая новые интерфейсы.

Google Play Store v48.3

В релиз-нотах отмечено, что в уведомлениях Google Play Protect обновлены иконки на всех поддерживаемых платформах: Auto, ПК, телефон, ТВ.

Безопасность: Android Security Bulletin (сентябрь 2025)

Параллельно с системными обновлениями Google продолжает выпускать ежемесячные безопасностные бюллетени Android (Android Security Bulletin).

В бюллетене за сентябрь 2025 описано множество уязвимостей — например:

• CVE-2025-48543 — уязвимость в Android Runtime, позволяющая эскалацию привилегий, без необходимости дополнительного запуска кода.
• Несколько уязвимостей в Framework и ядре классифицируются как высокие (High) — могут дать локальное повышение привилегий.
• Устройства с Android 10 и выше могут получить обновления безопасности через Google Play system updates.

Что проверять и как обновиться?

С учётом подтверждённых данных, рекомендуем:

• Проверять на вашем устройстве версии:
  Google Play services — должна быть 25.39.x (или выше, если уже вышли патчи).
  Google Play Store — версия v48.3 или выше.
  Google Play system update (в Настройках телефона) — наличие новых системных патчей безопасности.
• Google Play services — должна быть 25.39.x (или выше, если уже вышли патчи).
• Google Play Store — версия v48.3 или выше.
• Google Play system update (в Настройках телефона) — наличие новых системных патчей безопасности.
• Если устройство не получает обновления автоматически — попробуйте вручную запустить обновление Google Play services через доступные источники (Play Store, Google Play System Update).
• Следите за бюллетенями безопасности Android: версия безопасности (security patch level) должна быть актуальной.
• У устройств с более старыми версиями Android (менее Android 10) возможности получать обновления безопасности через Google System могут быть ограничены.

Что случилось

Согласно новым правилам, которые Google планирует внедрить с сентября 2026 года, каждый разработчик Android-приложений должен будет:

• подтвердить свою личность с помощью государственных документов;
• передать Google информацию о приложении, включая идентификатор и ключ подписи.

Это касается всех приложений, даже если они не публикуются в Google Play.

Фактически это будет конец F-Droid и других открытых репозиториев приложений в их нынешнем виде.

Почему это важно

Ключ подписи APK — это основа доверия в экосистеме Android. Без него пользователь не может быть уверен, что приложение не было подменено.

На данный момент альтернативные магазины, такие как F-Droid, сами управляют подписью приложений, проверяют их безопасность и следят за обновлениями.

Теперь же Google хочет взять контроль над этими ключами, даже если приложение распространяется вне Google Play. Это создает монопольную модель, при которой все пути ведут через Google, несмотря на официальную поддержку сторонней установки .apk-файлов.

Под угрозой: свобода, приватность и конкуренция

Авторы F-Droid отмечают, что:

• не все разработчики хотят или могут регистрироваться у Google;
• это ударит по открытому ПО, анонимным проектам и альтернативным экосистемам;
• Android уже обладает встроенными механизмами безопасности (Play Protect), а Google Play регулярно пропускает вредоносные приложения.

Что делает F-Droid

Проект F-Droid уже обратился в регуляторные органы США, ЕС и других стран, призывая проверить инициативу Google на предмет злоупотребления доминирующим положением и монополизации рынка Android-приложений.

Что говорит Google

Google объясняет нововведения борьбой с вредоносными программами и мошенниками, а также повышением доверия к Android-приложениям.

Компания подчеркивает, что распространение через .apk и сторонние магазины останется доступным — но без контроля над ключами их значимость может снизиться до нуля.

Когда начнут действовать новые правила

Сентябрь 2026 года — начало поэтапного внедрения. Пока детали требований полностью не опубликованы, но разработчики уже бьют тревогу.

Смотреть подкаст на YouTube, в VK.

Анна Жаркова пишет нативные приложения под iOS и Android и кросс-платформенные приложения на Xamarin, Xamarin.Forms и Kotlin Multiplatform. Написала книгу о Kotlin Multiplatform, которая выходит в сентябре. Пишет статьи, выступает на конференциях и митапах. Член программного комитета Mobius, CodeFest, «Стачка». Увлекается живописью и участвует в выставках.

Поговорили о безумных проджект-менеджерах, войне Android и iOS, о том, почему ИИ не заменит программистов, и что делать, если вам позарез нужно установить ВСЕ приложения из магазина. Добро пожаловать в абсурдный и увлекательный мир мобильных разработчиков!

О смысле мобильных приложений

Какие нам вопросы задали наши прекрасные подписчики. Первый вопрос: «А зачем вообще нужны мобильные приложения? У меня вот компьютер, а у друга ноутбук».

Ну, да, вопросы бывают разные, мы к этому привыкли. Начнём с того, что это, конечно, здорово, что есть компы и ноутбуки, но с собой человек, скорее всего, носит именно смартфон, а не компьютер или ноутбук.

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

Ну да, взять то же банковское приложение, оплату с телефона… Ребята, с компьютером не походишь, чтобы это всё делать. Давай поедем к следующему. Можно делать так, чтобы приложение ставилось не из App Store?

Конечно. Если это приложение под Android, оно будет ставиться через Google Play, а также есть специальные магазины, например, AppGallery для Huawei или RuStore. Также у некоторых вендоров есть свои маркеты, например, у Samsung.

Если же говорить про iOS, то тут всё строго с App Store. Но кто знает, возможно, в будущем появятся и кастомные магазины для iOS. Хотелось бы, чтобы поскорее.

А скажи, пожалуйста, насколько широкий ассортимент приложений в этих альтернативных магазинах? У меня всё на яблоках, я не особо разбираюсь, что там происходит, особенно с Huawei, с RuStore. Можешь рассказать, насколько там всё хорошо или плохо?

Я думаю, если говорить про приложения, которые имеют ограничения в загрузке в App Store, они, в принципе, есть и в Google Play, но свободно грузятся в остальные магазины. Особых ограничений нет. Конечно, бывают ситуации, когда приложение пропадает из магазина по чьей-то жалобе. Но выбор приложений довольно большой. Например, в компании, где я работаю, мы свободно загружаем наши приложения в разные магазины, и всё в порядке.

Супер. А насколько вообще отличается разработка для, скажем, Huawei от классической Android? Там есть какая-то своя специфика, или всё тоже самое? Может, свой стэк?

Плюс-минус как Android, но есть определённые различия. У них своя среда разработки, свои сервисы, дополнительные технологии. Тема довольно обширная, но в принципе, всё это плюс-минус то же самое, и Android-разработчику освоить это несложно. Главное — поставить нужную IDE (Интегрированную среду разработки) и взять устройство для отладки.

А какие там специфические IDE?

Да, там есть, по-моему, собственная IDE, но я скажу честно, я с ней особо не работала. Я сейчас копаю немножко в другом направлении.

О фантастическом девайсе

«Пользователю позарез нужно установить вообще все мобильные приложения, которые существуют на маркете. Всё использует, всё жизненно важно. Вопрос: что представлял бы из себя девайс, который смог бы это выдержать?» Я с трудом представляю, интересно твоё мнение.

Что ж, ну, возникает вопрос: наверное, у этого пользователя очень много денег, он может позволить себе все платные приложения. Порадуемся за него!

Но если говорить про аппарат, то это должен быть какой-то супермощный с параметрами из серии «Чёрная дыра». Современное приложение, тот же самый «суперап», который объединяет кучу сервисов, может занимать сотни мегабайт. Обычное банковское приложение — тоже несколько сотен мегабайт.

Поэтому если у пользователя есть какой-то супермощный компьютер, возможно, он причастен к каким-то научным, суперсекретным, может быть, даже военным разработкам, и у него память на каком-то кристалле из чёрной дыры… то, возможно, это и сработает.

В реальности, конечно, это похоже на шутку «я сейчас все игры установлю». Но ни одного нормального девайса даже с супервозможностями не хватит. Сейчас максимум — это 512 ГБ внутреннего хранилища, часто без возможности расширения. Но даже с картой памяти вам точно не хватит.

Да, вот у меня даже на айфоне он сгружает в облако всё, что не нужно. И у меня стоит довольно много приложений, в том числе детские, с ИИ, чтобы звёзды смотреть, цветы диагностировать… Куча странных приложений, которые я использую очень ситуативно. Я не представляю, сколько надо времени, чтобы скачать себе даже десятую часть всех существующих приложений в Store. Ну, это невозможно.

Ну, может, человек решил стать суперблогером по приложениям, решил сделать краш-тест всего маркета и всех возможных аппаратов. Удачи ему и успехов.

О разработке на мобильном телефоне

«Раз для компов проги пишут на компах, разве не уместнее для мобилок писать на мобилках?»

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

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

Конечно, на мобильном устройстве можно скомпилировать какие-то простые, легковесные приложения, например, на скриптовых языках. Есть такие технологии. И в том числе можно использовать мобильные устройства как инструмент для разработки. У того же GitHub такое было.

Но честно говоря, если есть желание что-то писать на мобильном аппарате, то лучше работать с облачными средами разработки. Потому что даже на компе та же Android Studio может кушать очень много памяти и сохранять много кэша. Облачная среда, конечно, в какой-то степени небезопасна, потому что вы что-то загружаете на сторонние сервера. Но если это ваше собственное, настроенное место, то вполне можно по удалёнке получать доступ. Другой вопрос, что вам тогда необходим хороший интернет.

Ну, ты знаешь, у меня вот был странный опыт. Когда я училась на Python-разработчика, у меня был старый макбук. Он у меня сдох через полгода, просто потому что не вывез: ты ставишь все эти библиотеки, прописываешь команды, подгружаешь версии… В общем, у меня просто сдох жесткий диск. Поэтому да, хороший вопрос. Не всякий даже ноут это выдержит, как выяснилось.

Более того, даже для сборки мощных мобильных приложений на Mac сейчас часто требуется 32, а то и 64 ГБ памяти. Были бы, конечно, такие крутые мобильные устройства, полноценные мини-компьютеры… Но это уже из области фантазии наших зрителей.

О Keycloak и мобильной безопасности

Так, следующий вопрос. «Подскажите, кто-нибудь пользуется Keycloak для SSO (стандарт единого входа)?»

Интересный, конечно, вопрос про Keycloak. Я слышала такое слово от бэкендеров — это механизм, который используют для безопасности на бэкенд-части. Но что примечательно, с вопросом про Keycloak часто приходят именно к нам, мобильным разработчикам.

Тебе говорят слово «Keycloak», и ты думаешь: «Хорошо, а я тут причём?» Так что да, это довольно часто задаваемый не по адресу вопрос. Ответ — спросите у аналитика или у бэкенд-разработчика.

А как ты думаешь, почему к мобильным разработчикам приходят с этим вопросом?

Я думаю, потому что говорят, что это какой-то механизм, необходимый для безопасной разработки. И часто люди путают, с чьей стороны должно быть внедрение того или иного решения.

Keycloak — это система идентификации и управления доступом с единой точкой входа. Мобильное приложение — это фронтенд-клиент, который обращается к API вашего сервера. Поэтому вся система должна быть реализована на бэкенде. Мобильщик будет лишь использовать готовое API. Если вам говорят, что вы должны это сделать сами на мобилке, ну тогда вы, получается, не мобильщик, а фуллстэк. Я вас поздравляю!

О выборе технологии: натив vs Flutter

Так, переходим к следующему вопросу. «Стоит ли погружаться в нативную разработку или сразу учить Flutter?»

Очень хороший вопрос. Flutter — это отдельная технология со своим языком Dart. Но тут есть маленький нюанс. Да, Flutter — технология отличная, но вы разрабатываете под Android и iOS, и поэтому вам необходимы знания нативной разработки, хотя бы в минимальном объёме. Есть проекты, где пишут код Flutter-разработчики, но от них требуют хороших, крепких знаний по нативу хотя бы одной платформы.

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

То есть, сначала учим какую-то одну платформу как базу, а потом уже идём во всякие Flutter’ы с ними.

Безусловно. Вы исходите из того, что пишете под Android (или iOS). И уже смотрите: как я могу это делать? Я могу писать на нативе, а могу на Flutter’е. Но Flutter всё равно будет опираться на натив, поэтому получается такая ступень по изучению технологий.

О роли ИИ в мобильной разработке

Что сейчас можно сделать с помощью ИИ в мобильной разработке?

Довольно много. Но тут возникает уточняющий вопрос: использовать ИИ как инструмент или внедрять ИИ в приложение? Есть возможности по внедрению ИИ, чтобы оно что-то генерировало в вашем приложении: умные ассистенты, генерация изображений и т.д.

Есть также возможности с помощью ИИ генерировать код. Но это явно не для начинающих. Почему? Потому что ошибок в таком коде довольно много. Чтобы этот код работал, нужен человек, который понимает, как такой код писать самому. То есть ИИ может помочь сократить время, выступить инструментом генерации, но не более.

К тому же сейчас есть технологии, которые позволяют разместить у себя модель нейросети, обучить её под свои нужды и использовать. Да, это дорого и ресурсоёмко, но возможность есть. В целом, возможности широкие, но они не заменят нормального разработчика. Все помнят мем про кружку, которую ИИ не догадался перевернуть? Это показательно.

Вопрос от этого же задавателя вопросов. «Используют ли Kotlin Multiplatform React Native (технологии для кроссплатформенной разработки) и так далее? Если да, бывают ли задачи с адаптацией под мобильный веб?»

Хм, хороший вопрос. Если говорить про работу с искусственным интеллектом в контексте этих технологий… Вы можете попробовать сгенерировать код под любую платформу. Для этого нужно писать много промтов и иметь много ресурсов для обучения модели.

Но если говорить о продакшене, то тут имеет смысл использовать только то, что безопасно. Есть компании, которые разрабатывают свои инструменты на основе LLM-моделей, как, например, Яндекс. Есть те, кто берут открытые модели, разворачивают их и используют.

А вот публичные сервисы вроде ChatGPT я не рекомендую использовать для продакшена. Они могут залогировать ваш код и потом выдать его кому-то. Это крайне небезопасно. В прошлом или позапрошлом году был скандал, когда ChatGPT выдавал куски кода одной компании, вплоть до креденшиалов. Так что в продакшене — только собственные решения.

О сегментации рынков Android и iOS

Насколько реально сегментированы рынки Android и iOS?

Если говорить про iOS, то тут всё просто: один вендор — Apple. Вся экосистема: iOS, iPadOS, watchOS, специальная OS для авто. Минимальная сегментация. А вот с Android вендоров много. Это и гиганты типа Samsung, большой кусок рынка у Xiaomi и её суббрендов вроде Poco или Redmi.

Но стоит не забывать, что есть страны Латинской Америки, Африки, Юго-Восточной Азии, где ситуация с разработкой и устройствами совершенно другая, чем в Штатах, Европе или СНГ. Там до сих пор используют такие технологии, как Cordova, PhoneGap, потому что это дёшево, а iPhone там очень непопулярны — банально не по карману.

О самых сложных задачах

Какие задачи в мобильной разработке самые сложные?

Всё зависит от того, что считать задачами. Есть интересные фичевые задачи, которые дают возможность разрабатывать что-то новое. Есть рутинные, неинтересные, но простые задачи, которые просто отнимают много времени.

А есть задачи-челленджи, когда ты создаёшь что-то на основе сложной библиотеки или, наоборот, из простых исходников делаешь суперсложное решение — например, для работы со звуком, видео, сканеры и т.д.

Но многие скажут, что самая сложная задача — это работа с заказчиком, с ТЗ, работа между командами. То есть, есть элемент технического челленджа, а есть — психологического. Разработчику надо уметь преодолевать и те, и другие, потому что это позволяет потом работать проще и интереснее.

Об ассемблере в 2025 году

«Какое место в Android и, видимо, iOS-разработке занимает ассемблер в 2025 году?» Вообще ассемблер и мобильная разработка, мне кажется, две немножко разные сущности.

Честно говоря, я не пользовалась ассемблером для мобильной разработки. Если у того, кто это задал, есть наработки, пусть пришлёт, посмотрим. Или придёт на Mobius и расскажет про это — у нас ещё открыт CFP. Если это будет супер-хардовый доклад, это будет здорово!

Например, пару лет назад у нас был человек, который встроил Doom (а он написан на ассемблере) в SwiftUI. То есть низкоуровневое что-то встраивается через C, C++ (например, через NDK для Android). Всё это можно сделать.

Но возникает вопрос: зачем? Потому что есть решение «потому что могу» — и это круто. А есть принцип разумной достаточности: не надо усложнять решение там, где это не нужно. Мы экономим и делаем оптимальной не только архитектуру приложения, но и время разработчика. Так что, отвечая на вопрос: есть Doom UI. Можете посмотреть: где только Doom не запускали.

О дизайне под Android и iOS

«Почему менеджеры и дизайнеры всегда хотят, чтобы на Android всё выглядело точно так же, как на iOS?»

Я думаю, потому что это красиво. У iOS долгое время очень много вкладывалось в визуал, в неповторимые жесты и систему. Это было просто супер. Затем Google решил догнать. Сначала появился Material Design, потом более продвинутый. И теперь, если посмотреть на доклады Google и Apple, можно заметить, что в какой-то момент предложения инженеров Google превращают Android в iOS, а у iOS есть тенденция становиться визуально похожим на Android.

Основная причина, почему хочется использовать iOS-подобный дизайн на Android, — «потому что красиво». Но Android не повезло: красивые вещи довольно затратны. Изначально Android затачивался под аппараты для всех, включая страны с дешёвыми устройствами малой мощности. Тащить туда всю красоту — вредить пользователям. Там действует принцип «максимум возможностей при минимальных затратах».

Ну да, Apple всегда стремились делать очень красиво. Так, скоро же выйдут новые модели Apple, они там всё выкатят в сентябре. Там какие-то изменения по разработке будут под iOS?

Я думаю, не без этого. Изменения идут каждый год, иногда несколько раз в год. Но что хорошо у Apple и Google — нет таких радикальных изменений, чтобы все бросали работу и шли переписывать приложение под новую парадигму.

Были у них такие периоды, но это было связано скорее с языками (Swift у Apple, Jetpack Compose у Google), которые сильно менялись. Но кардинальной смены инструментов или парадигмы в ближайшее время не планируется.

Крик души мобильного разработчика

Так, ещё у нас остался один большой вопрос, прямо крик души. Цитирую: «Почему на симуляторе всё работает, а на телефоне нет? Телефон тупее? Если отключу фоновые процессы, батарейка начнёт заряжаться в обратную сторону? А можно сделать так, чтобы приложение работало одинаково на всех 19 тысячах моделей телефонов? Почему я должна платить 99 долларов в год, чтобы тестировать на своем же телефоне? Почему пуши приходят только тогда, когда я уже сама все проверила вручную? Почему SwiftUI делает все проще, но я все равно страдаю?»

Я так понимаю, это крик души. Мы пойдём по частям. Судя по желанию, «чтобы оно работало везде одинаково», — это PM или Product Owner detected. «Нехорошо, неправильно не делайте, делайте правильно». Вот такой тезис.

Давай пройдёмся по частям.

Про симулятор и телефон. Эмулятор имеет ограниченные ресурсы и параметры ОС. Он запускается на вашем компьютере, где ресурсов больше, и вы можете настроить сеть, например, прокси. А телефон — это реальное железо с ограниченными ресурсами, которых может не хватить. Кроме того, на эмуляторе некоторые вещи могут игнорироваться или, наоборот, не воспроизводиться. Тестировать на эмуляторе безопаснее для вашего телефона, его ресурсы просто сожрутся. Хотя тестировщик, конечно, должен проверять на реальных устройствах.

Про 99 долларов. Вы платите не мне, а компании Apple. А компания Apple считает, что вы должны платить, «потому что они красивые». Вот. Такова жизнь.

Про пуши и SwiftUI. Можно сказать, что страданиями душа совершенствуется, а также навыки разработчика. У каждой технологии есть подводные камни, главное — правильно её использовать. Но даже если вы знаете, как правильно, вы не застрахованы от багов и питфолов.

С пушами отдельная история. Доставка пуш-уведомлений — вещь негарантированная. Многое зависит от сервиса, который вы используете (Firebase часто капризничает, try RuStore, они стабильнее), от территориальных особенностей, от того, как настроена рассылка. На Android и iOS разные политики работы с пушами. Иногда, если понизить приоритет пушам, они дойдут гарантированнее, чем с высоким приоритетом. Всё индивидуально.

А по SwiftUI... Я очень сочувствую вашему опыту. Если вы посмотрите WWDC последних двух лет, особенно этот год, они даже не прикладывают исходники тех примеров, которые показывают. То есть покажут сниппет, а целиком приложение не дают. Так что, возможно, это всё на их совести. Пусть они спят плохо.

О собеседованиях и офферах

«Почему для получения оффера недостаточно, что в своём телефоне я разработчик?»

Хороший вопрос. Когда вы приходите на собеседование и у вас проверяют знания, это не потому что мы редиски и хотим попить вашу кровушку. Мы выбираем человека, с которым будем работать.

Это как на стройке: есть прораб и рабочие. Каждый делает свою операцию. Человек, которого мы ждём в коллектив, будет брать часть нашей работы. А вы меняете ваше время, усилия и навыки на денежки. Вот так работает экономика.

Чтобы вы получили оффер, мы должны понимать, что вы придёте и сможете делать задачи. 90% вопросов на собеседовании — это либо общая теория, либо обсуждение кейсов. Тестовые задания сейчас практически не дают, особенно на миддлов и сеньоров. Мы надеемся, что человек с опытом может мысленно разложить задачу и рассказать, как бы он это сделал. Чтобы показать, что он сможет с этим работать.

Скажи, а вот такие тест-кейсы на собеседованиях помогают вычислить и не допустить тех, кто опыт накручивает?

Ох, на самом деле да. Бывает, людей вводят в заблуждение разные кураторы, и они считают, что если суперуверенно рассказать что-то HR, то он уже прошёл. Вот эти кейсы, где предлагается подумать и рассказать, как бы ты это делал, — довольно показательны.

Тем более, человек может запнуться на теории, войти в ступор. У меня самой такое было лет шесть назад. А когда просишь рассказать, как бы ты это делал, это показывает, как человек думает, как решает задачи на практике, с какими технологиями он умеет работать.

Если человек говорит: «Это всё гуглится», — возникает вопрос: «Зачем ты тогда тут?» Кейсы экономят время, не у всех может открыться среда для лайвкодинга, и они помогают понять, как человек мыслит и насколько он адекватен.

Об автомобильной разработке

Так, и вот последний странненький, на мой взгляд, вопрос. «Зачем нужны специалисты по мобильной разработке, если есть уже автомобильная?»

Хороший вопрос. Можно обыграть, что автомобильная — это разработка на vibe-кодинге, just for fun. Если говорить серьёзно, то автомобильную разработку тоже делают мобильные разработчики! Так что можно быть автомобильным разработчиком, но не сужайте себе поле, попробуйте другие девайсы, вам тоже понравится.

Например, брать с собой в карман автомобиль — это, конечно, шикарно, но не везде реализуемо. Он тяжёлый.

Вместо стандартного похода к специалистам, он решил собрать уникальный слайдер, объединив корпус, плату и экран Z Flip5 с физической клавиатурой от BlackBerry Q10.

Получился кастомный смартфон-франкенштейн, который не только работает, но еще и вызывает ностальгию по эпохе слайдеров вроде Nokia N97 и Samsung D500.

Как устроен самодельный гибрид

Проект начался с того, что у Плазы сломался основной экран на Z Flip5. Устройство все еще включалось, и его внешний (вспомогательный) экран оставался рабочим.

Вместо замены матрицы, он полностью демонтировал оригинальный шарнир, разобрал смартфон и извлек все, что можно было использовать повторно.

Затем он:

• изготовил две алюминиевые рамки на фрезере — для верхней части с экраном и нижней с клавиатурой;
• встроил магнитный механизм слайдера, как у старых телефонов-раскладушек;
• подключил клавиатуру от BlackBerry Q10, спаяв проводку и установив Arduino Pro Micro — для эмуляции клавиатуры через USB;
• разработал и припаял собственную печатную плату, отвечающую за интерфейс между клавишами и системой Android.

В результате получился настоящий рабочий слайдер: экран снаружи, физическая клавиатура снизу, полноценное управление интерфейсом и ввод текста.

Работает — даже в Minecraft

Проверить результат Плаза решил максимально просто: он запустил YouTube, Minecraft и Terraria, набрал текст и поиграл — все через физическую клавиатуру.

Управление действительно работает: клавиши не просто нажимаются, а отправляют события в систему как обычная USB-клава.

Разумеется, на устройстве также доступен сенсорный ввод с виртуальной клавиатурой, если физическая не устраивает.

Это ограничение касается всех способов установки, включая сторонние магазины и прямое скачивание APK-файлов из интернета.

Формально речь не о блокировке альтернативных источников, а об обязательной проверке личности разработчика.

Как будет работать новая система

До сих пор обязательная верификация требовалась лишь при размещении приложений в Google Play. Теперь Google расширяет это требование на все каналы распространения:

• Google Play и сторонние магазины;
• установку APK напрямую (sideloading);
• корпоративные и кастомные дистрибуции.

Чтобы распространять приложения, разработчик должен будет пройти процедуру подтверждения личности или компании. Для организаций потребуется D-U-N-S номер, а для частных лиц — базовая верификация через новую консоль Android Developer Console.

Отдельный процесс будет предусмотрен для студентов и энтузиастов, не связанных с коммерческой разработкой.

Когда и где это вступит в силу

Google запускает верификацию в несколько этапов:

• Октябрь 2025 — ограниченный доступ к системе для первых разработчиков.
• Март 2026 — открытие верификации для всех.
• Сентябрь 2026 — обязательная проверка в Бразилии, Индонезии, Таиланде и Сингапуре.
• 2027 год — глобальное распространение.

В этих странах любое приложение, устанавливаемое на сертифицированный Android-устройство (то есть с предустановленными сервисами Google), должно будет принадлежать подтвержденному разработчику.

Зачем это Google

В компании заявляют, что цель — борьба с мошенничеством и вредоносным ПО. Анализ Google показал, что в 50+ раз больше вредоносных программ поступает через APK с интернета, чем из Google Play.

Разработчики не в восторге

Несмотря на одобрение от властей стран Юго-Восточной Азии, среди независимых разработчиков новость вызвала беспокойство.

Также звучат опасения, что новая система усилит монополию Google и затруднит работу сторонним девелоперам, особенно если верификация будет сопровождаться автоматическими банами без объяснений, как это уже происходит в Play Console.

Что дальше

Пока остается много вопросов:

• можно ли будет отключить это ограничение на уровне устройства;
• как будет работать студенческий/непубличный режим;
• будет ли верификация обязательной на кастомных прошивках (AOSP, Lineage и др.);
• и как поступит Google в странах с юридическим запретом на такие ограничения.

Формально Android остается открытым, но шаг за шагом Google приближает его к модели iOS: доступ к платформе только после одобрения централизованной системы.

И даже если APK-файлы не исчезнут полностью, доступ к ним будет только у тех, кто предъявил паспорт.

Но в действительности в Linux 6.16 есть сразу несколько значимых улучшений, особенно для разработчиков и системных админов.

Rust теперь умеет работать с драйверами и GPU

Rust всё глубже проникает в ядро:

• В 6.16 появились биндинги к драйверному ядру и PCI — можно писать драйверы на Rust.
• Поддержка Rust‑абстракций добавлена в Direct Rendering Manager (DRM) — включая ioctl, управление памятью и инфраструктуру драйверов для AMD, NVIDIA и Intel.
• Улучшена работа с крейтами — станет проще собирать и встраивать модули на Rust.

Код ядра по-прежнему в основном пишется на C, но Rust уверенно занимает своё место в системной разработке.

Большие апдейты файловых систем

• XFS теперь поддерживает атомарную запись многоблочных данных — это важно для баз данных и отказоустойчивых систем.
• Ext4 получил поддержку больших folio, ускорение коммитов и атомарную запись для bigalloc — это дало до +37% скорости на последовательных I/O-нагрузках.

Устройство спит — музыка играет

Теперь можно передавать звук через USB даже во сне. Буквально при спящем режиме устройства. Это давно было в Android, теперь и в основном ядре.

Прокачали безопасность

• Добавлена поддержка Intel TXT и TDX — технологий для защищённых вычислений.
• Улучшения в AMD SEV-SNP — безопасная виртуализация и шифрование памяти.

Новый уровень оптимизации под железо

• Поддержка Intel APX: 32 единиц x86‑регистра вместо 16. Больше регистров — больше производительности.
• Новый флаг CONFIG_X86_NATIVE_CPU — можно собирать ядро, оптимизированное под конкретный процессор. Полезно как для энтузиастов, так и для корпоративных девопсов.

Для ИИ, VPN и high-speed сетей

В новой версии ядра улучшена поддержка видеокарт NVIDIA Blackwell — их уже используют в ИИ‑решениях на Linux. Также нашлось место переработке TCP/IP и DMABUF — меньше нагрузки на CPU, быстрее работа сетевых интерфейсов.

OpenVPN стал быстрее — хоть и не обогнал WireGuard, но сократил отставание.

1. Yonote

Yonote — российская база знаний и система для работы с проектами. Помогает командам и отдельным пользователям собирать и систематизировать информацию, вести базы знаний, планировать проекты и обмениваться документами. Платформа сочетает гибкий интерфейс, как в Notion, и функциональность KMS-систем: блочный редактор, доски, таблицы и базы данных работают в одном окне. Отличие Yonote — бесконечные доски для визуального планирования, поддержка on-prem-развёртывания и хранение данных в России.

Сценарии использования

Yonote подходит для:

• Командной работы: планирование задач, контроль
  сроков, управление проектами, CRM, сбор и визуализация отчётов, хранение
  инструкций и регламентов.
• Личных целей: заметки, трекер задач,
  бюджетирование, планирование поездок, учёба и хранение материалов.
• Создания Wiki: организация базы знаний о
  продукте с древовидной структурой, вставкой таблиц, диаграмм и медиа, историей
  изменений и комментариями.
• Ведения
  документации: базы данных по
  клиентам, проектам и инвентарю с таблицами, фильтрами, канбан-досками и
  календарями, прикреплением файлов и ссылок.

Формат работы

Yonote работает через web-интерфейс с удобным Markdown-редактором, поиском и историей изменений. Можно встраивать код, схемы и embed-ссылки из GitHub, Figma, Miro и других сервисов.

Поддерживается полный доступ по API, импорт и экспорт в Markdown и PDF, хранение на своих серверах (on-prem) и в облаке. Yonote предлагает более 30 интеграций, включая GitHub, Jira, Trello, Telegram, Miro и Airtable. Настраиваются уровни доступа: можно создавать гостевые аккаунты, разграничивать права на чтение и редактирование, делиться публичными ссылками.

Yonote заменяет несколько инструментов сразу (Trello, Google Docs, Confluence, личные заметки), легко адаптируется под любые задачи, подходит для госорганизаций, частных компаний и личного использования.

Тарифы

• Базовый — бесплатно, 5 ГБ, до 5 пользователей и 10 гостей.
• Старт — 149 ₽ за пользователя в месяц, 20 ГБ, до 50 гостей.
• Про — 249 ₽ за пользователя в месяц. Доступен безлимит гостей, неограниченное хранилище, SSO.
• Enterprise — тариф для организаций с расширенной поддержкой и контролем.

2. Anytype

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

Главное отличие — Anytype полностью локален и использует P2P-синхронизацию без серверов и посредников, данные остаются только у вас, никто не имеет к ним доступа. Приложение с открытым кодом и доступной архитектурой, работает без интернета и требует установки на устройство.

Сценарии использования

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

Работа в команде: организация командных вики и канбан-досок, совместная работа в группах, ведение календарей.

Сообщество и креатив: управление блогом, создание лент-контента, рекомендаций и курируемых подборок, построение сообщества с объявлениями и вики-страницами.

Формат работы

Anytype работает офлайн на мобильных и десктопных устройствах (iOS, Android, Windows, macOS, Linux), без веб-версии. Скоростная P2P-синхронизация возможна через локальные сети.

Интерфейс основан на визуальном код-фри (no-code) редакторе: можно создавать базы данных, таблицы, канбаны, галереи и граф-связи между объектами.

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

Для разработчиков:

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

Цена и условия пользования

• Explorer — бесплатно, подходит для личного использования.
• Builder — $99 в год за пользователя, открывает расширенные функции и поддержку командной работы.
• Co-Creator — $299 в год за пользователя, с расширенными возможностями и дополнительной свободой кастомизации.

Весь интерфейс и работа — на английском языке.

3. Obsidian

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

Сценарии использования

Есть несколько сценариев:

• Личные заметки и дневники: быстрый доступ к записям на устройстве, структурирование мыслей, создание связей между идеями.
• База знаний и обучение: построение персональных вики с перекрёстными ссылками, графами связей и быстрым поиском.
• Управление проектами и исследованиями: создание канбанов и карт идей в Canvas для планирования и брейншторминга, публикация заметок для команды

Формат работы

Obsidian — десктопное и мобильное приложение (Windows, macOS, Linux, iOS, Android). Доступны следующие форматы:

1. Поддержка открытых форматов файлов (Markdown), которая обеспечивает долгосрочное хранение данных без зависимости от сервиса.
2. С помощью Obsidian Publish можно публиковать заметки как публичную вики, документацию с настраиваемым внешним видом и быстрым поиском.

Плагины позволяют создавать интеграции и автоматизировать процессы в зависимости от потребностей команды.

Есть поддержка истории версий и работы с командой в рамках общих хранилищ, при этом приватность отдельных файлов сохраняется.

Цена и условия пользования

• Бесплатно: использование приложения для личных нужд, хранение данных локально.
• Sync — $4 в месяц за пользователя при оплате за год, синхронизация заметок между устройствами с шифрованием, история версий, совместная работа в общих хранилищах.
• Publish — $8 в месяц за сайт при оплате за год, публикация заметок на сайт без технических знаний, настройка тем и структуры.

4. Gramax

Gramax — платформа для подготовки документации в подходе Docs as Code. Позволяет создавать и редактировать статьи в визуальном редакторе, хранить исходники в Markdown и версионировать их с помощью Git. Подходит для тех, кто хочет управлять документами, знаниями и любым другим контентом в своей инфраструктуре гибко и безопасно.

Как и в Notion, в Gramax есть совместное использование, комментарии и AI-функции (создание и форматирование текста, перевод, поиск по статьям). Отличие — в Git‑first подходе, открытом коде и возможности использовать платформу бесплатно без ограничений.

Сценарии использования

Gramax особенно полезен для:

• Документации по продукту: создание портала с инструкциями, оформленного в корпоративном стиле, с быстрым обновлением и AI-поиском.
• Внутренней проектной документации: база знаний с версиями, Merge Request, поддержкой OpenAPI и технических требований.
• Базы знаний для команд: хранение описаний процессов и систем с удобным поиском и доступом через Git.

Формат работы

Gramax делится на:

• Редактор: web и десктоп на Win/Mac/Linux, можно использовать офлайн.
• Git-хранилище: подключается GitLab, GitHub, Bitbucket и другие, команды Git встроены в интерфейс.
• Портал документации: разворачивается как статический сайт или через Docker.

Для разработчиков есть поддержка диаграмм (Mermaid, Draw.io, PlantUML), подсветка кода (100+ языков), механизм сравнения версий, мультиязычность. Также на портале для чтения можно отображать документацию на разные версии ПО.

Gramax также поддерживает API для передачи данных в сторонние системы и CLI для интеграции в CI/CD, позволяя автоматически собирать документацию в HTML, PDF и DOCX. Есть импорт из Confluence, Notion и Yandex Wiki, экспорт в DOCX и PDF с фирменным стилем.

Цена и условия

• Open Source — бесплатно, без ограничений. Управление доступом на уровне репозиториев.
• Gramax Enterprise Server — 54 000 ₽ за редактора навсегда, первый год обновления бесплатно, далее 40% от лицензии. Управление доступом — по ролям и группам с SSO и корпоративными политиками.

5. KMS Gran

KMS Gran — база знаний с API и выстроенными бизнес-процессами. Помогает создавать и структурировать проектную документацию, управлять знаниями в команде и автоматизировать рутину. Платформа сочетает возможности вики, систем управления документами, визуальных блок-схем и AI-инструментов для поиска и анализа.

Как и в Notion, в KMS Gran есть WYSIWYG-редактор, мобильная версия и AI для работы с текстом. Отличие в том, что на платформе есть модуль «Скриптинг» для построения процессов и гибкая система прав доступа. Подходит командам, которым важно хранить данные локально и быстро строить рабочую рутину.

Сценарии использования

• Вики по продуктам и техдокументация. Доступно создание структурированных статей, глоссариев, руководств и спецификаций. Удобный поиск с морфологией и AI-помощником помогает находить информацию, а кириллица поддерживается корректно.
• Автоматизация бизнес-процессов. С помощью модуля «Скриптинг» можно строить визуальные блок-схемы процессов, задавать условия и добавлять к шагам инструкции и файлы. Подходит для команд поддержки и контакт-центров.
• AI-помощник для пользователей. Индексирует статьи и отвечает на вопросы по проектам с указанием источников. Сохраняет контекст диалогов, позволяет оценивать ответы и формирует отчеты для анализа востребованности контента.

Формат работы

KMS Gran работает через web-интерфейс с удобным WYSIWYG-редактором, поддерживающим Markdown, и адаптирован под мобильные устройства. В системе доступен полнотекстовый поиск с морфологией и возможностью получать ответы от AI, а также версионирование с откатом и архивацией статей. Для согласования внутри команды предусмотрена отметка о прочтении. В документы можно вставлять код и схемы через интеграцию с Draw.io, но подключение embed-ссылок из GitHub и Figma не поддерживается.

Платформа поддерживает работу через API для интеграции с внешними системами, хотя CLI в ней не предусмотрен. Можно настроить подключение к Slack, GitHub, CI/CD и Jira через API. Гибкая система управления доступом позволяет задавать роли как на уровне всей системы, так и в отдельных проектах и разделах, а также управлять доступом к разным документам.

Цена и условия

• SaaS: аренда по подписке, ежемесячная оплата за пользователя. Включены базовый функционал, серверные ресурсы и поддержка 9×5, опционально AI-модуль.
• On-Premise: развёртывание у заказчика, лицензия на длительный срок, поддержка AI-модуля и техподдержка.
• AI-модуль доступен как в SaaS, так и On-Premise.

Условия зависят от объема лицензий, срока использования и набора функций, обсуждаются индивидуально. Все тарифы включают базовый функционал.

Как выбрать платформу для базы знаний

Выбор платформы зависит от ваших задач. Для удобства собрали таблицу с особенностями платформ.

Таким образом:

Если приоритет — работа с документацией как с кодом, версионирование и публикация через Git — ваш выбор Gramax.

Нужна визуализация, работа с таблицами, досками и интеграции для команды — стоит обратить внимание на Yonote.

Если вы ищете корпоративное решение с AI, разграничением прав доступа и встроенными процессами — подойдёт KMS Gran.

Anytype или Obsidian подойдут тем, кто ценит контроль над данными и гибкость кастомизации.

Он весит всего 2,1 МБ, не требует интернета или аккаунта и позволяет обмениваться зашифрованными сообщениями через Bluetooth.

Приложение позиционируется как экспериментальный проект выходного дня и работает без серверов — всё хранится локально на устройстве.

Что уже умеет BitChat

• Работает в фоновом режиме.
• Поддерживает сквозное шифрование для приватных чатов.
• Позволяет добавлять избранных пользователей.
• Включает панический режим — три нажатия на логотип стирают все данные.
• Автоматически обновляет Peer ID — идентификатор пользователя.
• Работает без аккаунтов, e-mail и номера телефона.

Разработчик подчёркивает: никакой серверной инфраструктуры. Все коммуникации — через Bluetooth и локальные p2p-сети. Медиа пока не поддерживаются — только текстовые сообщения.

«Когда рядом появится другой битчаттер, система пришлёт уведомление»

Пользователи жалуются, что «там пока никого нет»

Пока в BitChat пустовато: пользователи в соцсетях пишут, что не могут найти собеседников.

Дорси призвал не спешить с выводами: «Дайте приложению время». Также уже отправлено обновление, которое должно устранить баги в переписке между Android и iOS.

На момент публикации:

• Официальная версия доступна только в App Store.
• Android-сборку можно установить вручную через GitHub-инструкцию.
• В iOS-приложении висит предупреждение: «Безопасность переписок ещё не прошла полный аудит». Не рекомендуется использовать в критических ситуациях.

BitChat — ещё один шаг в сторону локальной приватности, децентрализации и мессенджеров без бигтеха. Но станет ли проект чем-то большим, чем просто «проект выходного дня» — покажет время.

Такая практика носит массовый характер: по данным исследований, около 95% россиян принимают условия без изучения документа. При этом часть опрошенных вообще считает, что прочитать соглашение полностью физически невозможно (слишком много букв). Половина опрошенных даже не в курсе, о чем там написано.

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

Причины массового игнорирования: системные ловушки

Проблема кроется не в лени пользователей (или не только в ней), а в продуманной системе, превратившей соглашения в формальность. Три ключевых барьера делают осознанное согласие практически недостижимым.

Большой объем и языковой барьер

Современные соглашения напоминают юридические трактаты. Средний документ российских сервисов содержит 16,800 слов. Роскомнадзор критикует избыточность текстов, но не публикует официальной статистики. Например, документация Ozon занимает 23,700 слов — это больше, чем повесть Чехова «Дуэль» (13,700 слов). Политика Яндекс.Диска занимает 57 страниц, а условия СберБанк Онлайн — 43 страницы.

Главная проблема — язык. Юридические термины вроде «сублицензирование», «деперсонализация данных» или «арбитражная оговорка» требуют специальных знаний. Как показывает практика судебных споров и жалоб в Роскомнадзор, такие формулировки часто непонятны рядовым пользователям. Барьер усугубляется тем, что юридическая грамотность в РФ остается низкой: далеко не все россияне уверенно читают договоры.

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

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

UX-дизайн, провоцирующий спешку

Современные интерфейсы часто проектируются так, что внимательное прочтение соглашений становится затруднительным. Кнопка «Принять» обычно выделяется контрастным цветом (например, зеленым или синим), а опция отказа скрывается:

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

Такие паттерны усиливают «эффект туннельного зрения» — психологический феномен, при котором пользователь фокусируется на цели (быстром доступе к сервису), игнорируя второстепенные элементы. Дизайнеры дополнительно стимулируют это: например, используют таймеры обратного отсчета («Осталось 00:59»), чем создают искусственную спешку. Сообщения типа «99% пользователей уже приняли условия» формируют социальное давление.

Мнимый выбор в условиях монополий

После блокировки зарубежных сервисов в 2023 году российский рынок заняли локальные альтернативы. Но переход к отечественным платформам не дал пользователям реальной свободы.

Почему выбор остаётся мнимым? Попробуйте использовать СберБанк Онлайн без принятия политики обработки данных. Система выдаст ошибку: «Для продолжения необходимо согласиться с условиями». Аналогично в VK: отказ от соглашения означает потерю доступа к сообщениям и группам.

Мнимый выбор — это не всегда подвох со стороны сервиса. Даже по новым европейским правилам (Digital Services Act) платформы должны давать вам «базовую версию» без персонализированной рекламы, но не обязаны работать вообще без сбора данных.

В России всё устроено схоже: если без ваших персональных данных сервис просто не сможет функционировать (например, банк или мессенджер), отказ в доступе — это не нарушение закона.

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

Евросоюз в 2024 году ввел Digital Services Act, обязывающий платформы предлагать базовую версию без сбора данных. В России аналогичные нормы в законе «О персональных данных» (152-ФЗ) начали работать только с 2025 года. У пользователя есть право отозвать согласие на обработку данных, но не все сервисы готовы сохранять функционал после отказа.

Что скрывают соглашения: реалии цифрового мира

Игнорируя пользовательские соглашения, пользователи невольно соглашаются на условия, иногда выходящие за рамки разумного сбора данных. Эти практики подтверждены регуляторными решениями, судебными кейсами и открытой документацией сервисов.

Расширенный сбор данных под видом «аналитики»

Яндекс.Карты сохраняют историю перемещений даже при деактивированном приложении. Сбор геоданных без явного уведомления при каждом запуске нарушает принцип минимальной достаточности (предоставление только необходимого для достижения цели). Это возможно, если в настройках устройства и приложения включена геолокация и история местоположений.

VK Музыка в пункте 4.3 пользовательского соглашения разрешает анализ аудиопотока через микрофон для идентификации фоновых треков. Технология активируется автоматически при первом запуске, без отдельного запроса на разрешение.

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

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

Формулировки про «хранение данных столько, сколько нужно для бизнеса» выглядят довольно расплывчато и, с юридической точки зрения, не могут считаться самостоятельной и достаточной целью: такая причина хранения вряд ли будет признана обоснованной при проверке. Тем не менее, именно за такими фразами иногда скрывают ссылку на так называемый законный интерес — этот механизм широко применяется в Европе по стандарту GDPR. В России, напротив, операторы редко ссылаются на законный интерес напрямую: это связано с тем, что у нас сложнее требования к обоснованию сроков и объёмов хранения данных, и риски для компании выше.

В качестве примера можно привести ситуацию, когда оператор оставляет ваши контактные данные и историю заказов после завершения сделки, чтобы иметь возможность вернуть деньги или рассмотреть вашу жалобу. Или, например, хранит историю обращений для расследования мошенничества или предотвращения повторных атак (антифрод).

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

Умные колонки с голосовыми помощниками (такие как «Яндекс.Станция» или устройства Sber) постоянно анализируют звуковое окружение для активации по ключевым словам, что создает риск случайной записи приватных разговоров.

Обезличенная статистика нужна бизнесу: знать, сколько пользователей на сайте, когда пик нагрузки, какие разделы популярны. Закон такое разрешает, если никто не может узнать, что это были именно вы.

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

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

Исследования подтверждают:

• Ложные срабатывания. Ассистенты активируются до 19 раз в сутки из-за фоновой речи, слов-омофонов или аудиоконтента (например, при просмотре сериалов).
• Технические уязвимости. Ученые обнаружили, что MEMS-микрофоны в таких устройствах излучают радиосигналы, которые можно перехватить FM-приемником даже через бетонные стены.
• Хранение данных. Записи голосовых команд сохраняются на серверах производителей неограниченное время. В 2019 году сотрудники Amazon признались в прослушке аудио с Echo без ведома пользователей.

Как минимизировать угрозы:

1. Отключайте микрофоны колонок физической кнопкой (если есть) при обсуждении конфиденциальных тем.
2. Откажитесь в настройках от «персонализированных ответов» и отправки аудиоданных для «улучшения сервиса».
3. Регулярно удаляйте историю запросов через приложение-компаньон (например, «Дом с Алисой»).

Важно: Пользовательское соглашение «Яндекса» прямо разрешает обработку фонового аудио для «технического анализа», но не уточняет сроки хранения или алгоритмы фильтрации. Для устройств Sber аналогичные условия описаны в разделе «Данные голосового взаимодействия».

Передача прав на контент

Стандартная формулировка «неисключительная лицензия» в облачных сервисах имеет далеко идущие последствия. Политика Mail.ru Cloud прямо разрешает использовать загруженные файлы для обучения ИИ-алгоритмов. На практике это означает, что ваши фото могут стать частью тренировочных данных для нейросетей распознавания лиц.

Маркетплейс Ozon в разделе «Обмен информацией» своего соглашения допускает передачу истории покупок партнерам для таргетированной рекламы. Вряд ли пользователи добровольно согласились бы на такие условия, если бы прочли о них заранее.

Автоматическое продление подписок

Проблема скрытых списаний остается массовой. Пользователи массово жалуются на автоматическое продление подписок. Например:

• Сервис IVI продлевает платный доступ без отдельного подтверждения после пробного периода.
• Яндекс.Плюс списывает средства за 3 дня до окончания расчетного цикла в случае, если юзер не отключил автопродление. Яндекс делает это, «чтобы обеспечить клиентам непрерывный доступ к сервису, даже если платеж задерживается».

Особую опасность представляют детские приложения, где случайные покупки происходят из-за неочевидного интерфейса. В 2024 году Федеральная торговая комиссия США (FTC) оштрафовала Epic Games (американскую компанию по разработке игр и ПО) в общей сложности на $520 млн за сложную процедуру отмены несанкционированных платежей в Fortnite (кроссплатформенной формально бесплатной игре).

Российские сервисы могут использовать схожие паттерны:

• в обучающих приложениях кнопки покупок размещаются рядом с игровыми элементами;
• отмена требует письменного заявления или звонка в поддержку.

Ещё несколько лет назад — и в зарубежных, и в российских сервисах — действовали более лояльные правила возврата: если пользователь забывал отменить подписку в течение льготного периода, деньги можно было вернуть. По данным на 2021 год, такую опцию предлагали и IVI, и Яндекс, и Okko.

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

При этом крупные сервисы, как Яндекс, в явном виде указывают: изменение или ограничение контента, региональные блокировки и другие изменения не считаются основанием для возврата средств. Но важно помнить: если недоступность контента становится существенным недостатком услуги, Закон о защите прав потребителей (ст. 29) сохраняет за пользователем право на возврат оплаты — независимо от того, что написано в соглашении.

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

Как защитить себя: стратегии для 2025 года

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

Для пользователей: цифровая гигиена

Проверяйте репутацию сервиса перед согласием

Роскомнадзор ведёт открытый реестр нарушителей закона 152-ФЗ. Например, каршеринг «Делимобиль» был внесен в список после массовой утечки номеров телефонов.

На некоторых сервисах публикуются расшифровки соглашений популярных российских платформ: там же сообщают о возможности сервисов изменять условия без персонального уведомления пользователей.

Жёстко контролируйте разрешения

Современные ОС предлагают инструменты для защиты:

• в Android 14 функция «Одноразовый доступ» ограничивает работу камеры/микрофона одним сеансом;
• в iOS 18 «Детальный контроль» позволяет блокировать фоновый сбор данных.

Для браузеров установите uBlock Origin — расширение блокирует скрытые трекеры, упомянутые в политиках конфиденциальности. В соцсетях отключайте «аналитику поведения» в настройках приватности — это снижает объем собираемой информации.

Требуйте отчёт о ваших данных

Статья 14 закона 152-ФЗ гарантирует право запросить у компании:

• полный список хранимых персональных данных;
• историю их передачи третьим лицам;
• правовые основания обработки.

В случае отказа или неполного ответа подавайте жалобу через портал Роскомнадзора.

Если вы хотите узнать, какие именно ваши персональные данные обрабатывает компания, просто напишите им запрос — укажите свои ФИО, паспортные данные (или иные, подтверждающие личность), и четко сформулируйте, что именно вы хотите узнать: какие данные у них есть, откуда они их получили, зачем обрабатывают и кому передают. Такой запрос можно отправить письменно или через электронную почту, если подпишете его электронной подписью. По закону компания обязана ответить вам в течение 10 рабочих дней.

И если вас ответ не устроил, вы вправе требовать удаления ваших персональных данных - оператор обязан будет это сделать (кроме тех данных, которые он обязан хранить в силу закона). Правда, нередко это одновременно будет означать, что вы не сможете более пользоваться этим сервисом.

Для разработчиков: прозрачность как конкурентное преимущество

Сокращайте и визуализируйте соглашения

Т-Банк провел редизайн пользовательского договора: заменил юридические термины простыми формулировками, добавил инфографику и чек-листы ключевых пунктов. Это снизило количество обращений в поддержку по вопросам непонятных условий.

Внедряйте градацию согласия

Разделите запросы на данные по категориям:

• базовые — необходимые для работы сервиса;
• опциональные — аналитика, реклама, улучшение продукта.

Европейский GDPR требует такой практики — например, при установке приложения Signal пользователь отдельно разрешает доступ к контактам и уведомлениям. В России подобный подход выделит ваш продукт на фоне конкурентов.

Добавьте «режим адвоката»

Встройте в интерфейс кнопку «Главные риски за 60 секунд»: краткую выжимку ключевых положений. Сервис ProtonMail делает это эффективно — на странице регистрации четко указано: «Мы не храним IP-адреса и не передаём данные третьим лицам».

Будущее соглашений: нейросети и законодательство

Эволюция пользовательских соглашений развивается по двум направлениям: технологические инструменты для упрощения понимания и ужесточение законодательных требований. Оба тренда активно проявляются в 2025 году.

ИИ-ассистенты: возможности и ограничения

Крупные IT-компании разрабатывают инструменты для анализа юридических документов. Яндекс.Помощник интегрировал функцию сканирования соглашений: система выделяет спорные пункты цветными маркерами и генерирует упрощенные пояснения.

Однако нейросети не заменяют юристов. ИИ-сервисы нередко пропускают скрытые условия в длинных документах.

Основные проблемы:

• неспособность интерпретировать двусмысленные формулировки;
• игнорирование ссылок на внешние документы;
• ошибки в трактовке арбитражных оговорок.

Законодательные изменения: новые требования

В июне 2024 года принят Федеральный закон № 123-ФЗ, вносящий поправки в 152-ФЗ.

Ключевые новации:

• запрет автоматического продления платных подписок без отдельного подтверждения через SMS или email (ст. 15.4);
• обязательное выделение условий сбора биометрических данных жирным шрифтом;
• штрафы до 3% годового оборота за сокрытие практик передачи данных третьим лицам.

Новые требования уже дают результаты.

Перспективы: стандартизация и блокчейн

ЕС разрабатывает AI Act — единый стандарт для ИИ-анализа соглашений. Эксперименты с блокчейн-реестрами условий проводят Сбербанк и Тинькофф: технология фиксирует версии документов и предотвращает скрытые изменения.

Заключение: ваша цифровая подпись — это ответственность

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

Что делать сегодня? Начните с малого. Даже беглый просмотр разделов «Данные» и «Автоматическое продление» снижает риски. Не забывайте о законе 152-ФЗ. Если это необходимо, требуйте от компаний полный отчёт о ваших данных через форму на портале Роскомнадзора.

Голосуйте кошельком. Переходите на сервисы с прозрачными правилами. Осознанное согласие — не роскошь, а базовый навык цифровой эпохи. Ваши данные стоят тех 10 минут, которые вы потратите на чтение перед кликом «Принять».

Цифровой контент — актив, который требует защиты не меньше, чем банковские данные. Многие привыкли, что свежий сериал или долгожданный фильм оказывается в сети за неделю до премьеры или в день релиза, а дорогостоящий курс можно скачать бесплатно на «складчинах». В 2024 году пиратство нанесло российским правообладателям ущерб в 3,36 млрд рублей, а глобальные потери медиаиндустрии превысили $71 миллиард. Утечки контента происходят через уязвимости в системах доставки, запись экрана или взлом серверов.

Но угрозы безопасности видеконтента не ограничиваются пиратством. Кибератаки добавляют новый уровень сложности: в отличие от пиратов, которые стремятся монетизировать контент через нелегальное распространение, хакеры могут преследовать иные цели — от вымогательства до саботажа инфраструктуры. Например, говорить, что в их распоряжении есть интимные видеозаписи жертвы (ещё лучше, если это CEO известной компании) и вымогать крупную сумму денег. Или взломать Rutube и саботировать инфраструктуру сервиса, как это было в 2022 году. Киберугрозы также могут включать DDoS-атаки, эксплуатацию уязвимостей в API или кражу пользовательских данных, что приводит к последствиям:

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

Важно понимать, что защита должна учитывать не только копирование контента, но и целостность всей экосистемы — от API до клиентского плеера.

Многоуровневая защита: из чего она состоит

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

1. Защита от несанкционированного доступа и копирования

Первый барьер — ограниченный доступ к контенту:

• Шифрование: AES-128 или AES-256 для защиты видеопотоков.
• Авторизация: токены JWT или OAuth для проверки прав пользователей.
• Системы управления цифровыми правами (DRM) устанавливают ограничения на воспроизведение контента — по устройствам, географическому положению и времени. Если отсутствует соответствующий ключ шифрования, выдаваемый лицензионным сервером, воспроизведение может быть заблокировано.

2. Пиратские копии

Даже если контент уже украден, важно оперативно выявить его нелегальное распространение. Технологии AI-мониторинга и цифровой форензики сканируют даркнет, соцсети и пиратские сайты. ИИ распознает видео по фрагментам, даже если оно перекодировано.

Технический нюанс: ИИ-системы используют сверточные нейросети (CNN) для анализа визуальных и аудиохарактеристик. Разработчикам стоит интегрировать такие решения через API, например, от Google Cloud Vision или специализированных вендоров.

3. Отслеживание источника утечки

Ключевой вопрос при утечке: кто и как получил доступ к контенту? Водяные знаки и «цифровые отпечатки» (fingerprinting) позволяют встраивать уникальные идентификаторы в видеофайлы. Fingerprinting, например, создает хэши аудио- и видеофрагментов для поиска копий.

Технический нюанс: сессионные водяные знаки добавляют задержку в стриминг. Проблема решается предварительной обработкой сегментов для HLS/DASH-протоколов.

4. Противодействие пиратским ресурсам

Удалить копии после обнаружения можно через:

• Обращение в РКН и к платформе, где появилось видео. Если реакции от платформы нет, РКН или провайдер хостинга заблокируют сайт по запросу.
• Автоматическую блокировку ссылок через API хостингов.
• Юридическое давление на пиратские платформы.

Технологии против пиратов: DRM, ИИ, водяные знаки и «цифровые отпечатки»

Современные решения для защиты видео объединяют несколько технологий, каждая из которых решает определенные задачи. Рассмотрим их подробнее.

DRM (управление цифровыми правами)

DRM-системы шифруют контент и управляют лицензиями на доступ к видеопотоку. DRM защищает контент на уровне клиента и сервера, предотвращая неавторизованный доступ и перехват. Такие системы интегрируются в плееры и платформы и показывают контент только авторизованным пользователям.

DRM-системы опираются на три ключевых компонента:

1. Лицензионный сервер отвечает за выдачу и проверку ключей расшифровки контента.
2. Клиентская часть DRM (Content Decryption Module, CDM) интегрирована в браузер/плеер.
3. Упаковщик контента (Packager) подготавливает видеопотоки для защищенной доставки.

Но есть техническая проблема совместимости — DRM-системы неоднородны по платформам:

• Widevine (Android, Chrome, Firefox, Opera);
• PlayReady (Windows, Xbox, некоторые Smart TV);
• FairPlay (экосистема Apple);
• WisePlay DRM (экосистема Huawei).

Решение — мульти-DRM упаковщики, поддерживающие все стандарты через единую интеграцию. Используйте библиотеки, например, Shaka Player, для упрощенной интеграции мульти-DRM.

Водяные знаки (Digital Watermarking)

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

Отслеживание «цифровых следов» (Fingerprinting)

В отличие от водяных знаков, которые внедряются в контент, технология фингерпринтинга генерирует хэши фрагментов видео и аудио для поиска копий в сети без модификации самих файлов. Это позволяет находить пиратские копии, даже если они были изменены (например, перекодированы или обрезаны). Работает это так: система создает «цифровой отпечаток» оригинального видео и затем автоматически сканирует интернет в поисках материалов с похожими характеристиками.

Например, YouTube Content ID верифицирует права на материалы и затем в автоматическом режиме отслеживает загрузки на платформе. Когда пользователь загружает видео, Content ID сравнивает его с базой отпечатков, и, если обнаруживает совпадение с материалами, может заблокировать ролик за нарушение авторских прав, перенаправить доход от рекламы правообладателю или уведомить владельца контента.

Цифровая форензика

Цифровая форензика — это сбор и исследование данных для раскрытия цифровых преступлений. Проще говоря, цифровая криминалистика. Специалисты-форензики анализируют источники пиратских копий через анализ метаданных, характеристик кодирования, артефактов сжатия и других цифровых «улик», чтобы выявить, как и когда произошла утечка. Например, уникальные артефакты в H.264-кодеке могут указать на устройство, с которого записали экран.

AI-мониторинг

Искусственный интеллект ускоряет поиск пиратских копий через анализ огромных массивов данных в интернете с помощью компьютерного зрения и машинного обучения. ИИ-системы мониторинга используют сверточные нейросети (CNN), которые способны распознавать визуальные образы и алгоритмы, такие как Mel-Frequency Cepstral Coefficients (MFCC) (используется для распознавания речи). С их помощью можно находить копии даже при перекодировании или обрезке.

Уже существует множество готовых решений на основе ИИ. Например, Red Points постоянно мониторит соцсети, видеоплатформы и пиратские сайты с применением машинного обучения, компьютерного зрения и распознавания изображений, а при обнаружении совпадений автоматически отправляет запросы на удаление через API. Piracymeter и Bytescare анализируют списки доменов, поисковые результаты Google и торрент-трекеров. Bytescare также может находить пиратские копии ПО.

Такие решения быстрее ручного мониторинга и больше подходят для больших каталогов видео. Они могут работать автономно или подключаться через REST API, но требуют настройки для снижения ложных срабатываний.

Пример комплексного подхода к защите видео

Для защиты видеоконтента компании всё чаще используют решения, которые сочетают несколько технологий. Например, разработчик систем безопасности GS Labs совместно с видеохостингом Kinescope создал систему, интегрирующую DRM, водяные знаки и цифровую форензику. Она позволяет шифровать контент, встраивать уникальные идентификаторы для отслеживания утечек и анализировать источники пиратских копий. Такое решение работает как в облаке, что даёт стриминговым платформам масштабируемость, так и локально, что важно для компаний с собственной инфраструктурой.

Модели внедрения технологий защиты видеоконтента

Выбор модели внедрения зависит от потребностей компании, ее бюджета и технических возможностей. Рассмотрим три основные модели.

Локальные решения (on-premises)

Локальные системы устанавливаются на серверах компании, что подходит для крупных медиакомпаний с собственной инфраструктурой. Их преимущества — полный контроль над данными и независимость от внешних провайдеров. Из минусов — высокие затраты на оборудование, обслуживание и персонал.

Облачные/SaaS-решения

Облачные платформы минимизируют затраты, предлагают гибкость и масштабируемость. Они идеальны для стартапов и онлайн-кинотеатров, которые не хотят инвестировать в собственные серверы. SaaS-модель позволяет быстро внедрить защиту, минимизируя затраты на инфраструктуру.

Совет: используйте облачные решения с SOC 2 или ISO 27001 сертификацией для защиты данных.

Гибридные модели

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

Совет: используйте Kubernetes для оркестрации гибридных систем и минимизации downtime.

Что стоит сделать прямо сейчас, чтобы защитить видеоконтент

1. Подобрать постоянное комплексное решение: исследуйте вендоров и технологии на рынке.
2. Провести аудит инфраструктуры: проверьте уязвимости в CDN, API и плеере, например, с помощью OWASP ZAP.
3. Интегрировать DRM: выберите мульти-DRM решение, совместимое с Widevine, PlayReady и FairPlay.
4. Внедрить мониторинг: подключите ИИ через API для поиска копий.
5. Провести пентесты в BurpSuite, симулируя пиратские атаки и взлом.
6. Отработать реакцию на инциденты.

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

Мы в Smart Engines занимаемся разработкой интеллектуальных систем для распознавания документов. Мы уже рассказывали вам, как просто и быстро интегрировать наши решения для распознавания паспорта, а также распознавания жестких и гибких форм в Android.

Сегодня речь пойдет про браузерное распознавание. Оно в последние несколько лет пользуется колоссальным спросом со стороны рынка – прежде всего у финтеха. Кроме того, развертывание PWA-приложений понадобится компаниям при интеграции функциональности в новый отечественный мессенджер MAX.

Поговорим о том, в чем плюсы распознавания в вебе и главное – как его развернуть на примере банковской карты.

Исторический экскурс

Технология WebAssembly (WASM) появилась в 2015 году и два года спустя была реализована во всех основных браузерах. Тогда же ученые Smart Engines начали проводить с WASM первые эксперименты.

Немного похвастаемся: в 2021 году мы первыми в стране представили промышленные технологии для распознавания документов в вебе. Это оказалось очень кстати, поскольку на фоне удаления мобильных приложений из магазинов к интерес к технологиям распознавания QR и банковских карт в браузере вырос.

Банки и финтех стали искать способы, как перенести привычную для пользователя функциональность – платежи по QR, распознавание номера телефона, распознавание банковской карты – из мобильного приложения в веб.

Ответ нашелся быстро – WASM и Smart Engines.

В чем плюсы?

Браузерное распознавание имеет очень много преимуществ. Во-первых, это все преимущества веб приложения:

• Кроссплатформенность;
• Возможность доступа к приложению из любой точки с интернет-соединением
• Мгновенное развертывание и обновление приложения, что позволяет пользователям всегда работать с актуальной версией.

Во-вторых, предусматривает совершенно иной уровень защиты персональных данных. Пользователь не выгружает свои данные на сервер для распознавания, а, напротив, загружает модуль для распознавания изображений с персональными данными себе.

И, в-третьих, позволяет в сжатые сроки реализовать фронтэнд-интеграцию силами web-разработчиков.

Все преимущества браузерного распознавания уже оценили наши партнёры, нацеленные на развитие своих интернет-сервисов. Среди них – Альфа-Банк, Газпромбанк и другие.

Распознавание кодифицированных объектов

Одним из самых востребованных направлений в OCR сейчас является распознавание кодифицированных объектов, таких как баркоды, номера телефонов, банковских карт и прочие машиночитаемые зоны.

В своё время мы выделили распознавание таких объектов в отдельный продукт Smart Code Engine для того, чтобы иметь возможность гибче работать с различными сценариями распознавания, а также иметь возможность пойти дальше в деле оптимизации скорости и размера библиотеки. В результате появился Smart Code Engine 2.0 – продукт получил новый интерфейс и возможность максимально гибко настраивать поведение для получения лучшего качества распознавания.

Библиотека Smart Code Engine написана на С++ и портировалась в веб с помощью инструмента Emscripten. Поскольку вся кодовая база, от низкоуровневых вычисления над изображениями до архитектуры поисковой сети, поддерживается нашим научным отделом, качественное портирование не составляло особых проблем.

Js-интерфейс библиотеки представляет собой практически зеркальный С++ интерфейс и с его помощью распознавание банковской карты реализуется вот так:

Этот код необходимо поместить в веб-воркер, чтобы не нагружать UI поток браузера лишними вычислениями.

Передача изображений в библиотеку осуществляется прямо с чтения пикселей элемента canvas, где вы выводите изображения с камеры устройства или прикрепленного файла PDF.

В процессе работы распознавания у вас есть возможность нарисовать поверх изображения найденные элементы документа за мгновение до распознавания.

Вот как это выглядит на выходе:

Как вы можете заметить, интеграция Smart Code Engine SDK не вызывает сложностей – внедрение происходит практически мгновенно, а скорость распознавания сопоставима с нативными библиотеками.

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

Метавселенная — красивый технологический концепт, но без реального запроса со стороны людей. Одни видели в ней VR и AR, другие — NFT и блокчейн, третьи — некий 3D-интернет. И стало непонятно: что это вообще было и зачем?

Метавселенная обещала стать новым поколением соцсетей, что именно там будет жить наше будущее общение и работа. Весь хайп смыл новый тренд: волна генеративного ИИ. Meta* (признана в России экстремистской организацией и запрещена) и другие техногиганты свернули свои эксперименты и переключились на нейросети.

У бизнеса с метавселенными тоже не сложилось: ни чёткой модели монетизации, ни реальных кейсов. Продажа виртуальной недвижимости в Decentraland, мерч для аватаров, баннеры в виртуальных тусовках — всё больше напоминает Web3-версию The Sims, чем серьёзную платформу с реальной экономикой. Так что будущее в 3D отложили до лучших времён.

Игровые платформы вроде Minecraft, Roblox, Fortnite — это по сути и есть настоящие метавселенные, которые давно живут своей жизнью. Среднестатистический пользователь от виртуальных тусовок отказывается: ему проще зайти в Discord или залипнуть в обычный стрим на Twitch, чем надевать шлем ради планёрки в Horizon Worlds.

Я могу просто посмотреть стрим и получить лучший опыт. Надевать шлем не имеет смысла — никакой пользы

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

Есть надежда, что метавселенная вернётся — когда технологии и контекст будут готовы. Когда VR-шлемы станут лёгкими, дешевыми и удобными, появятся реальные сценарии, а не просто презентации для инвесторов. Тогда, может быть, мы ещё туда заглянем. А пока — rest in pixels, Metaverse.

NFT-мания

Пока одни тусовались в метавселенной и зарабатывали миллионы на продаже пикселей, другие гуглили, что такое OpenSea и почему JPEG стоит как однушка в Москве. Сейчас NFT называют либо финансовым пузырём, либо зачатками новой цифровой инфраструктуры.

Пандемия и локдаун дали интернету второе дыхание. Люди заскучали и начали скупать цифровое искусство, как раньше собирали марки, карточки или скины в играх. В 2021 году NFT стали мейнстримом: CryptoPunks, Bored Ape, Beeple — эти имена знали все. К цифровой лихорадке подключились бренды: Adidas, Nike и даже McDonald’s начали продавать цифровой мерч в метавселенных. Пиксельные обезьяны разлетались, как будто золото будущего: в январе 2022 NFT-маркетплейс OpenSea побил все рекорды, ведь месячный объём торгов составил около $5 млрд. Владение NFT стало признаком цифрового престижа. Люди устанавливали токены себе на аватарки в Twitter, потому что это был цифровой Rolex: если у тебя был токен — ты в теме. А если нет — шёл читать гайды на Tproger.

Но уже к лету того же года рынок начал сдуваться. В июне 2022 объем OpenSea упал до ~$700 млн, а в октябре 2023 он составлял лишь $91 млн. Минус 98% от пиковых значений. Что же пошло не так?

Большинство NFT не дают прав на владение цифровым активом. Вы покупаете не саму картинку, а ссылку на неё в блокчейне. Если сервер с изображением ляжет — останется только строчка кода, свидетельствующая о вашем хорошем вкусе. Многие NFT были просто картинками. Ни привязки к играм, ни доступа к сообществам, ни других функций — только красивая (или не очень) обёртка.

Зачем мне вообще покупать этот NFT вместо настоящего произведения искусства?

Тысячи NFT-проектов выходили каждый день, рынок быстро перенасытился, и в итоге NFT-платформы утонули в спаме и мошенничестве. Один из самых распространённых трюков — wash trading: пользователь продаёт токен сам себе, чтобы искусственно раздуть спрос. Исследования показывают, что по итогам 2022 года более половины объёма торгов NFT на Ethereum приходилось на липовые сделки. Кто-то считает, что NFT со временем обесценились. Но возможно, что они с самого начала были пустышками.

Ещё один удар по доверию — кражи и хаос с плагиатом. Работы художников массово превращали в NFT без их ведома: копировали, заливали и продавали, как своё. Никто не спрашивал разрешения у авторов, и уж точно не предлагал процент с продаж. NFT также критиковали за углеродный след и загрязнение окружающей среды.

NFT как спекулятивный пузырь — фактически умер. Большинство коллекций потеряли всякий торговый смысл: объёмы упали, активные игроки исчезли, а токены превратились в мёртвые цифровые артефакты. Лихорадочные инвестиции, основанные на спекуляциях, просто сдулись.

Но сама концепция уникального цифрового актива живёт дальше. Токен как технология адаптируется и трансформируется. В играх NFT уже показали себя как востребованный юзкейс: игроки могут владеть, торговать и прокачивать виртуальные предметы. Эксперты считают, что инфраструктура останется, и на её базе появятся проекты с реальной практической ценностью. А NFT превратится в элемент цифровой инфраструктуры — как инструмент доступа и сертификат владения. Цифровой «паспорт», который фиксирует принадлежность к сообществам, открывает возможности для участия в клубах и эксклюзивных событиях.

3D‑телевизоры: история провала объёмного кино у вас дома

В начале 2010-х 3D-ТВ казались мегатрендом после хита «Аватар». Однако к 2016 году большинство крупных производителей отказались от выпуска моделей с поддержкой 3D. Многие пользователи так и не получили качественный опыт из-за технических ограничений и ранней стадии развития.

Я знаю, почему 3D-телевизоры провалились: производители поспешили поймать волну кинотеатрального бумa, сделав технологию с тяжёлыми и требующими подзарядки очками. В то же время на горизонте появились большие плоские телевизоры без очков, которые выглядели гораздо лучше и удобнее для пользователей.

Что пошло не так? Во-первых, сами 3D-очки. Их нужно было заряжать, носить поверх своих, а сидеть при этом строго под определённым углом, иначе магия пропадала. Многие отмечают, что это было неудобно — очки были дорогими, тяжелыми, а некоторые зрители уставали уже на середине фильма: жаловались на напряжение в глазах, дискомфорт и головные боли. Технология, которая должна была удивлять, в итоге просто раздражала.

Контента почти не было, и пользователи, купив дорогой телевизор, сталкивались с вопросом: а что, собственно, смотреть? 3D-телевизоры были дороже своих 2D-аналогов, и с развитием 4K, HDR и OLED-технологий потребители начали отдавать предпочтение лучшему качеству изображения без 3D. Зачем платить за условную «глубину», если можно просто получить красивую живую картинку из коробки.

Несмотря на провал 3D-ТВ в их классическом виде, эксперты не ставят на них технологии крест. Как пишет WIRED, новый виток связан с автостереоскопическими дисплеями: они используют трекинг взгляда, линзы и AI, чтобы создавать объёмное изображение прямо на экране — без всяких аксессуаров.

Google Glass: будущее было на носу

Google Glass подавали как прорыв — интерфейс будущего прямо у вас перед глазами. Но вместо футуризма — странная дужка с экранчиком сбоку. Стоила как хороший ноутбук, делала как плохой смартфон. Пользователи получали уведомления на уровне браслета и фото из 2005 года. Памяти почти нет, батарея умирает быстрее, чем вы успеете сказать «Окей, Google».

Соучредитель Google Сергей Брин позже признал, что не понимал, как устроены поставки и насколько сложно произвести такие очки массово и недорого. И это многое объясняет: в Google Glass вложили идею, но не довели её до жизнеспособного устройства.

Хотя запуск обставили красиво: дали очки техноинфлюенсерам, звёздам, первопроходцам — маркетинг остался без главного: никакой конкретики, ни сроков, ни объяснения, зачем это всё нужно. Продукт обсуждали, хайп был — но в продаже его не было. Сама общественность встретила Glass с настороженностью: главной проблемой стала конфиденциальность. У очков не было явного индикатора съёмки, и люди не понимали, записывают их или нет.

Некоторые считают, что Google Glass просто опередили своё время. Прототип показали ещё в 2013 году на Google I/O, а уже к 2015-му производство свернули. На практике очки оказались недостаточно удобными, многие обозреватели говорили, что они нелепо выглядят, а способов их применения никто так и не придумал. При цене в $1500 очки превратились в атрибут избранных гиков, а не в массовый гаджет.

По оценкам аналитиков, всего было продано не более 250 тыс. таких устройств, причем на старте Google отдала лишь 10 000 очков ограниченному кругу «избранных». Попасть к покупателю было сложно — очки продавали только по рекомендациям действующих владельцев. Функционально устройство не впечатляло: маленький прозрачный дисплей с разрешением 640×360, слабая 5-Мп камера, мало памяти и скромные 2–3 часа работы от батареи не соответствовали ожиданиям пользователей.

После провала на массовом рынке Google сменила стратегию на бизнес‑фокус. С 2014 года разрабатывалась корпоративная версия Glass Enterprise Edition, адаптированная для промышленных задач. Однако эти бизнес-успехи не спасли проект на массовом рынке, и Google окончательно закрыла проект в 2023 году.

На фоне фиаско Google Glass, современные игроки делают выводы — и действуют иначе. Ray-Ban Meta* (признана в России экстремистской организацией и запрещена) не обещают революцию — они интегрируют ИИ и камеру в повседневную форму очков. Не «будущее на лице», а стильный способ снять сторис и получить подсказки от ИИ. Apple Vision Pro, напротив, сознательно уходит в премиум и не обещает быть массовым — только для профессионалов, с чётким сценарием: дополнительный дисплей, работа с контентом и Facetime. А Android XR (например, от Samsung) с амбицией создать экосистему, куда подключаются другие производители.

Главные фейлы: почему хайп умер быстрее, чем мы успели надеть шлемы

• Переоценка трендов: компании хотели влететь в хайповый тренд. В итоге технологии оказывались сырыми или неудобными.
• Нет ценности для пользователя: эти продукты часто не решали реальных задач, а разработчики не объясняли, почему именно их стоит использовать.
• Сложность и неудобства: тяжёлые VR-шлемы, громоздкие или нелепые устройства.
• Непроработанные риски: проблемы с приватностью, мошенничеством и токсичностью подрывали репутацию и доверие.

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

Функции кажутся удобными — скажите: «Отправь сообщение в WhatsApp [контакту]», и Gemini выполнит команду. Но всё не так однозначно.

В чём проблема

Gemini теперь может:

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

Google заявляет, что не будет использовать ваши чаты для обучения моделей при отключённой активности.

Но технически помощник продолжает иметь доступ к WhatsApp и другим приложениям через Google Ассистента и «Утилиты».

Как отключить доступ Gemini к WhatsApp и другим приложениям

1. Откройте приложение Gemini на Android.
2. Перейдите в профиль → Apps.
3. Отключите все расширения вручную.

Чтобы полностью отключить отслеживание:

1. Зайдите в Gemini → Profile → Gemini Apps Activity.
2. Переключите в выключено (off).

⚠️ Даже после этого Google будет хранить ваши данные ещё 72 часа — «для безопасности и контекстных ответов».

Как удалить Gemini полностью (спойлер: непросто)

Google не даёт прямого способа удаления Gemini. Но энтузиасты нашли обходной путь — через ADB (Android Debug Bridge):

1. Скачайте Platform Tools с developer.android.com.
2. Включите USB-отладку (Настройки → О телефоне → 7 раз тапните по номеру сборки → Разработчик → Включить отладку).
3. Подключите телефон к компьютеру и разрешите доступ.
4. В терминале выполните:

Это удалит Gemini… но не полностью.

Помощник остаётся встроенным в приложение Google — и пока оно есть, Gemini тоже с вами. Чтобы избавиться от него окончательно:

• удалите все обновления приложения Google;
• отключите его (если позволяет устройство).

⚠️ Важно: Удаление приложения Google может повлечь за собой сбои в работе других сервисов. Действуйте на свой страх и риск.

Современный человек часами зависает в интернете. Исследования показывают, что постоянные уведомления и действия в режиме вынужденной многозадачности снижают продуктивность на 40% и увеличивают уровень стресса.

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

Суть цифрового минимализма: философия осознанного потребления

Концепцию цифрового минимализма популяризировал профессор Джорджтаунского университета Кэл Ньюпорт в книге «Цифровой минимализм: Как перестать жить на автомате и вернуть себе концентрацию» (2019). Его основная идея заключается в том, что технологии должны служить человеку, а не подчинять его себе.

Спустя шесть лет проблема стала еще актуальнее. Согласно Digital 2025 Report, среднестатистический пользователь тратит 5,7 часов в день на взаимодействие с цифровыми устройствами, причем 37% этого времени уходит на бессмысленный скроллинг. Это не просто пустая трата времени: нейробиологи доказали, что постоянное переключение между задачами ухудшает когнитивные функции и повышает уровень кортизола, гормона стресса.

Почему цифровой минимализм важен в 2025 году

Есть объективные причины ограничивать потребление цифрового контента:

• Информационная перегрузка. Ежедневно человек сталкивается с тысячами рекламных сообщений, уведомлений и новостных заголовков. Мозг не успевает фильтровать этот поток, что приводит к хронической усталости и снижению концентрации.
• Социальные сети заменяют реальное общение. Исследования показывают, что активные пользователи соцсетей на 30% реже встречаются с друзьями лично, что ведет к эмоциональному выгоранию и чувству одиночества.
• Технологии крадут время. В среднем человек проверяет смартфон 150 раз в день, при этом 60% этих действий не имеют конкретной цели.

Важно! Зависимость формируется на нейробиологическом уровне. Уведомления и лайки активируют систему вознаграждения мозга, схожую с механизмом наркотической зависимости.

Фундаментальные принципы цифрового минимализма

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

Осознанное взаимодействие с технологиями

Современные устройства и приложения разрабатывают с одной целью — максимально удержать наше внимание. В 2025 году алгоритмы стали настолько совершенными, что могут предугадывать наши действия. Осознанность — это первый шаг к цифровой свободе.

Практические методы осознанного использования:

• Перед открытием приложения задавайте вопрос: «Зачем я это делаю?»
• Установите временные лимиты для развлекательных сервисов через системные настройки.
• Используйте специализированные устройства для конкретных задач (электронные книги для чтения, камеры для фотосъемки).
• Включите монохромный режим экрана, чтобы снизить визуальную привлекательность интерфейсов.

Осознанность требует регулярной рефлексии. Раз в неделю анализируйте статистику использования телефона и корректируйте привычки.

Радикальная оптимизация цифрового пространства

Оптимизация в 2025 году вышла за рамки простого удаления ненужных приложений.

Современные подходы включают:

1. Ревизию подписок и уведомлений. Отпишитесь от рассылок, которые не читаете. Отключите push-уведомления для всех приложений, кроме действительно важных. Используйте функции сортировки входящих (например, «Умный inbox» в Яндекс.Почте).
2. Создание цифровых зон. Рабочий профиль — только профессиональные приложения. Личный профиль — мессенджеры и полезные сервисы. Развлекательный профиль — доступ по расписанию.
3. Автоматизацию рутинных операций. Настройте правила обработки писем (фильтры, шаблоны ответов). Используйте голосовых ассистентов для повторяющихся задач. Включите «умные» ответы в мессенджерах.

Оптимизация — постоянный процесс. Раз в месяц проводите цифровую «уборку».

Полный контроль над цифровой средой

Контроль означает не ограничения, а создание персонализированной экосистемы.

Технологии позволяют:

• Настраивать интерфейсы под конкретные задачи — например, минималистичные лаунчеры.
• Использовать «цифровые фазы» (утренняя, рабочая, вечерняя) с разными наборами доступных функций.
• Применять геозависимые правила — автоматически включать режим «Не беспокоить» на работе.
• Создавать временные ограничения для определенных категорий приложений.

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

Как технологии помогают бороться с цифровой зависимостью

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

Приложения для контроля экранного времени

Современные смартфоны оснащены встроенными функциями отслеживания времени использования, но сторонние решения предлагают больше гибкости.

Freedom

Это приложение позволяет блокировать соцсети и развлекательные сайты на всех устройствах, включая умные часы. Пользователи отмечают, что уже через две недели использования время, проведенное в соцсетях, сокращается в среднем на 28%.

Cold Turkey (Detox Lock)

Более жесткий инструмент. Он не просто блокирует отвлекающие сайты, но и позволяет создавать расписания, исключающие доступ в YouTube или TikTok даже после перезагрузки компьютера. Это особенно полезно для тех, кто работает удаленно и постоянно отвлекается. Аналог для пользователей Андроид из РФ — Detox Lock.

OneSec

Приложение, которое добавляет паузу перед открытием соцсетей. Когда вы пытаетесь запустить ВКонтакте или мессенджер, оно спрашивает: «А точно ли вам это нужно?» Простое, но эффективное решение, заставляющее задуматься перед бессмысленным скроллингом.

Автоматизация рутинных задач

Чем меньше рутины, тем меньше поводов брать в руки телефон. Современные инструменты автоматизации позволяют значительно сократить время, которое мы тратим на повторяющиеся действия.

Superhuman и Spark

Почтовые клиенты, которые автоматически сортируют письма по категориям. Вместо того чтобы вручную разбирать входящие, вы сразу видите только важные сообщения.

Focus Mode в iOS и Android

Встроенные функции, которые помогут настроить уведомления так, чтобы они не отвлекали в рабочее время. Можно, например, разрешить звонки только от избранных контактов.

ChatGPT-5 и другие голосовые ассистенты

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

Главное правило автоматизации: если действие повторяется чаще двух раз в неделю — его стоит делегировать алгоритмам.

Как создать цифровую среду, которая не отвлекает

В 2025 году цифровые устройства стали настолько умными, что начали предугадывать наши желания. Но эта «помощь» часто превращается в ловушку: бесконечные уведомления, рекомендации и персонализированный контент затягивают нас в цифровую воронку. Хорошая новость: те же технологии помогут выстроить здоровые отношения с гаджетами. Рассмотрим три ключевых направления оптимизации.

Визуальная гигиена: монохромный режим и не только

Цветовые схемы современных интерфейсов разрабатывают целые команды нейропсихологов. Яркие оттенки, анимации и контрасты стимулируют выброс дофамина, создавая эффект цифрового фастфуда. Исследование MIT (2023) показало: переход на монохромную палитру снижает время использования смартфона на 22% и уменьшает импульсивные клики.

Но визуальная гигиена — это не только оттенки серого. В 2025 году появились новые инструменты:

• Динамическая регулировка контраста — доступна в последних версиях iOS и Android. Автоматически снижает насыщенность цветов вечером.
• «Текст-режим» в браузерах (например, Mercury Reader) убирает рекламу и оставляет только основной контент.
• Минималистичные лаунчеры (вроде Before Launcher) заменяют иконки приложений на текстовые метки.

Как это работает на практике? После перехода на монохромную тему и текстовый лаунчер юзеры реже открывают телефон «просто посмотреть». Исчезает визуальный мусор — пропадает рефлекс постоянно проверять устройство.

Борьба с цифровыми «ловушками внимания»

Современные приложения — это сложные системы манипуляции вниманием. Автоподбор контента, бесконечная лента, персонализированные уведомления созданы для одного — удержать нас в экране как можно дольше. Но есть контрмеры.

В Telegram, который стал основной платформой для общения в русскоязычном сегменте, можно настроить режим «Только новые сообщения». Это аналог хронологической ленты — вы видите посты в порядке публикации, без алгоритмического ранжирования. Включается через Настройки → Конфиденциальность → Режим отображения постов.

YouTube теперь предлагает три варианта просмотра:

• стандартный (с рекомендациями);
• только подписки;
• «чистый» режим (поиск по запросу без побочного контента).

Особого внимания заслуживает система уведомлений. Появилась практика «цифровых зон»:

• рабочая зона: только почта и корпоративные мессенджеры;
• личная зона: звонки и SMS;
• тихая зона: полное отключение всех оповещений.

Возвращение к «аналоговому» цифровому

Самые продвинутые пользователи начинают сознательно ограничивать смарт-функции. Тренд на цифровой аскетизм проявляется в нескольких формах.

Электронные книги с E-Ink дисплеями (PocketBook, ONYX Boox) теперь поддерживают только базовые функции чтения — без браузеров и соцсетей. По данным ритейлеров, спрос на такие устройства вырос на 40% за последний год.

Умные блокноты (Remarkable 3, Rocketbook) стали популярны среди тех, кто хочет совместить удобство цифровых заметок с фокусом ручного письма. Нейробиологи подтверждают: рукописный текст лучше усваивается и запоминается.

Отдельный тренд — функциональные гаджеты. Вместо универсальных смартфонов люди начинают использовать:

• камеры Fujifilm (или аналоги) с ограниченным набором функций;
• MP3-плееры для музыки без стриминговых сервисов;
• электронные словари вместо мобильных приложений.

Пользователи отмечают, что при переходе на камеру Fujifilm X100VI они начинают чаще смотреть по сторонам, а не в экран.

Почему эти методы работают

Нейрофизиологи выделяют три механизма воздействия:

• Устранение триггеров — монохромные схемы и минималистичные интерфейсы не провоцируют дофаминовый отклик.
• Снижение когнитивной нагрузки — меньше визуального шума, больше ментальных ресурсов.
• Формирование новых паттернов — специализированные устройства создают четкие поведенческие сценарии.

Важно понимать: эти методы не требуют полного отказа от технологий. Речь идет о сознательном проектировании цифровой среды, где каждая функция служит конкретной цели, а не рассеивает внимание. Как показывает практика, даже небольшие изменения дают заметный эффект уже через 2-3 недели.

Долгосрочные стратегии: как не вернуться к цифровому хаосу

Цифровой минимализм требует системного подхода — разовых действий недостаточно. Рассмотрим три проверенных метода, которые помогают сохранить контроль над технологиями в долгосрочной перспективе.

Плановый цифровой детокс

Исследователи University of Pennsylvania доказали: даже кратковременное воздержание от цифровых устройств перезагружает когнитивные функции. Их рекомендация — 24-часовой детокс раз в месяц. Но как сделать его эффективным?

Подготовку стоит начинать за 2-3 дня. Постепенно сокращайте время в соцсетях, предупредите коллег и близких о временной недоступности. В 2025 году появились специальные сервисы для автоматического ответа на сообщения во время детокса, например, AwayMessage для Telegram.

В день детокса сосредоточьтесь на офлайн-активностях с четкой структурой:

• утренняя прогулка без гаджетов;
• чтение бумажных книг или специализированных e-ink устройств;
• настольные игры или встречи с друзьями.

Важно: не пытайтесь компенсировать пропущенные уведомления после детокса. Просматривайте только действительно важные сообщения.

Персонализированные правила цифровой гигиены

Универсальных рецептов не существует — каждый должен разработать собственные нормы взаимодействия с технологиями.

Вот как это сделать:

• Анализ цифровых привычек. В течение недели фиксируйте: время первого и последнего использования смартфона, частоту бесцельных проверок устройств, приложения, которые забирают больше всего времени.
• Постепенное внедрение ограничений. Начните с малого: первые 30 минут после пробуждения — без гаджетов, обеденный перерыв — без соцсетей, последний час перед сном — в режиме «Не беспокоить».
• Техническая поддержка. Используйте встроенные инструменты: фокус-режимы в iOS/Android, функцию «Цифровое благополучие», приложения для трекинга экранного времени.

Осознанное потребление контента

Алгоритмы предугадывают наши интересы, формируя зависимость. Чтобы не попасть в «пузырь фильтров», нужно сознательно формировать информационную диету.

Современные подкаст-платформы (Яндекс.Музыка, Spotify) предлагают режим «Без рекомендаций» — вы слушаете только выбранные выпуски. Аналогичные функции появились в YouTube («Только подписки») и новостных агрегаторах.

Для профессионального развития выбирайте контент с четкой структурой:

• подкасты с расшифровками (например, «Будет сделано!»);
• образовательные платформы с прогресс-трекингом (Stepik, Coursera);
• телеграм-каналы с аналитикой вместо кликбейта.

Ключевой принцип: каждый источник информации должен иметь понятную цель и ограниченное время потребления. Например, 30 минут утром на профессиональные новости и 20 минут вечером на развлекательный контент.

Главное — последовательность. Не пытайтесь внедрить все изменения сразу. Начните с одного элемента, закрепите привычку, затем добавляйте следующий. Помните, что на формирование устойчивой цифровой дисциплины требуется в среднем 66 дней.

Над цифровой зависимостью можно только смеяться. И это можно сделать в нашем тг-канале!

Что такое Cangjie

Cangjie — язык общего назначения, разработанный для HarmonyOS Next. Это та самая операционная система, созданная на замену Android после американских санкций.

По словам HUAWEI, язык подходит для разработки «во всех сценариях», включая мобильные приложения, распределённые системы и ИИ-сервисы.

Особенности Cangjie:

• Нативная поддержка ИИ
• Фокус на безопасности
• Поддержка приложений не только на HarmonyOS, но и на Android с iOS

Таким образом, Cangjie позиционируется как альтернатива Java (в экосистеме Android) и Swift (в iOS).

Как развивается экосистема

Язык разрабатывался почти пять лет и впервые был представлен в июне 2023 года. За несколько недель он привлёк свыше 10 000 заявок на участие в тестировании.

Уже в октябре прошлого года Cangjie стал доступен всем разработчикам HarmonyOS, а к июлю 2025 его используют крупные игроки:

• Meituan — пишет на Cangjie приложение для доставки, релиз которого ожидается в III квартале;
• JD.com — использует язык в мобильных решениях для собственной платформы.

Почему это важно

Cangjie — ещё один шаг в сторону технологического суверенитета Китая. Под американскими санкциями HUAWEI активно выстраивает собственную экосистему — от ОС и чипов до языков программирования и облачных сервисов.

Что дальше

С 30 июля исходный код Cangjie будет доступен всем. HUAWEI рассчитывает, что открытие языка ускорит его адаптацию и создаст альтернативу западным технологиям — в первую очередь в Китае, а затем и за его пределами.

Посмотреть документацию языка можно по ссылке.

Пользователь под ником u/TardisEngineer стал, по его словам, первым человеком, установившим Android-приложение на тренажёры Life Fitness.

Благодаря найденной уязвимости, он смог вручную установить Freedoom — свободную версию DOOM — на консоль беговой дорожки и запустить её прямо в меню тренажёра.

Как это вообще возможно

Многие современные тренажёры Life Fitness (модели SE, SE3 HD, SE4 и другие) работают на Android 5 и поддерживают обновление прошивки с флешки.

Автор новости нашёл на официальном сайте Life Fitness архивы с апдейтами и обнаружил в них открытые конфигурационные файлы.

В одном из них достаточно было добавить строчку:

…и положить в нужную папку APK-файл игры, чтобы та появилась в интерфейсе тренажёра как отдельное приложение.

После этого он аналогичным способом установил файловый менеджер и вручную перенёс WAD-файлы игры в нужную директорию.

Какие есть проблемы

Запустить игру — это ещё не всё. Управлять в процессе сложно: сенсорный экран не поддерживает мультитач, поэтому стрелять и двигаться одновременно нельзя.

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

Зачем всё это

Автор говорит, что взлом потребовал месяцев работы, тестов и экспериментов.

Но результат того стоит: теперь он может запускать DOOM на тренажёре в любом спортзале, где установлены модели Life Fitness с соответствующей прошивкой. И пусть это неудобно, но это DOOM. На. Беговой. Дорожке.

Инструкции он опубликовал на Reddit, а в теории подобный трюк можно провернуть и с другими приложениями. Например, с Doom II, эмулятором NES или даже файлообменником.

Так что если вам казалось, что DOOM уже запустили везде, то вот вам ещё один пункт в копилку.