Яндекс - 69,9% поискового рынка РФ, 110+ млн пользователей в месяц, десятки сервисов: поиск, браузер, карты, маркет, такси, музыка, почта, диск, алиса, еда, погода, кинопоиск, плюс... Если у вас андроид - Яндекс.Поиск и Яндекс.Браузер почти наверняка стоят с завода. На Samsung, Xiaomi, Honor, Realme...
Мы взяли два APK Яндекса и отреверсили их.
Там прям плохо. Настолько, что MAX и РУСТОР на их фоне выглядит как детский сад.
В одну статью все это не влезает, придется разделить на несколько, а конкретно на 3.
Кстати подарочек - нейросеть от яндекса для т9 в виде GGUF.
Что там было
Аудио-претриггер буфер - микрофон пишет звук до того как вы сказали Алиса, и этот кусок звука улетает на сервер. При этом размер окна управляется с сервера - может быть 3 секунды, а может и больше.
WiFi-сканирование - Яндекс сканирует все точки вокруг, собирает BSSID/SSID/RSSI и шлёт на свой сервер для геолокации.
Платёжные данные (PAN + CVV) до токенизации - до того как карта затокенизируется, PAN и CVV уходят на
mobpayment.yandex.net.94 JavaScript Bridge метода - 17
addJavascriptInterface()мостов. XSS на любом поддомене yandex.ru = компрометация устройства.Адресная книга в реальном времени -
ContentObserverна всё устройство, любые изменения контактов улетают на сервер.Logcat эксфильтрация с AES шифрованием - костыльный код.
Remote config (70+ флагов) - сервер может включить сохранение карт, форсировать Алису, отложить запрос разрешений на 3 года.
АУДИО-СЛЕЖКА PRE-TRIGGER БУФЕР
Голосовой помощник Алиса работает так: микрофон пишет звук постоянно, но не отправляет его пока не услышит «Алиса». Когда вы говорите «Алиса» - вы уже сказали это слово. То что было до слова «Алиса» - попадает в буфер.
И Яндекс этот буфер забирает на свои сервера.
Называется pre-trigger buffer. Кольцевой буфер куда микрофон пишет звук непрерывно. Когда wake word срабатывает - приложение вычитывает буфер и отправляет всё что было ДО ключевого слова вместе с командой.
Казалось бы ну ладно, что с того, может быть это для дебага или серверной валидации, только вот почему то ( а почему нам ответят в коментариях разработчики яндекса на что я очень надеюсь ) размер этого окна не фиксирован. Он управляется с сервера через параметры HasPreroll, buffer-size-ms, loggingSoundLengthBeforeTriggerMs. по умолчанию оно стоит 3 секунды, если бы так и было я бы не добваил пункт в статью... только вот его можно регулировать с сервера, сервер может выставить любое. Или вообще выключить pre-trigger.
Буфер по умолчанию 48000 сэмплов (3с)
Смотрим utw.java:42 - там конфигурация буфера Алисы. 48000 семплов при 16kHz = 3 секунды. Это дефолт.
В BaseAudioSource.java:303 создаётся объект захвата с микрофона. audioSource = 1 = MIC, 16kHz, моно, 16 бит.
BaseAudioSource.java:345-367. Работает пока сервис жив. Читает пачки звука, пробрасывает подписчикам.
Куда улетает аудио
Шаг 1: Микрофон -> AudioRecord (PCM 16kHz) Шаг 2: Кольцевой буфер 48000 сэмплов (pre-trigger) Шаг 3: Wake word -> PhraseSpotter триггер Шаг 4: Opus/AAC кодирование Шаг 5: WebSocket.sendData() -> wss://uniproxy.alice.yandex.net/uni.ws Шаг 6: Сервер Яндекса (расшифровка + биометрия + хранение)
Для контекста
Разумеется без pre-trigger буфера современный голосовой помощник не может нормально работать - ему нужно слышать контекст до команды. Но моя претензия не к этому, а вот к чему:
Размер буфера управляется с сервера - а не фиксирован кодом. Сервер Яндекса в любой момент может выставить 30 секунд, минуту, сколько угодно.
Pre-trigger включает биометрию - голосовой отпечаток строится в том числе по pre-trigger контенту.
Пользователю не сообщается что pre-trigger активен, какого он размера, и что запись уже идёт.
Наверное вы даже не знали что pre-trigger там вообще существует.
WIFI FINGERPRINTING
Яндекс сканирует все WiFi точки рядом, собирает MAC роутера, имя сети, силу сигнала и отправляет на сервер. У Яндекса есть база расположения WiFi точек - зная какие рядом, вычисляет ваши координаты с точностью до 10-50 метров. Работает внутри зданий, где GPS не ловит. Заходите в торговый центр - Яндекс знает в какой вы магазин зашли.
Куда шлётся
BuildConfig.java - основной endpoint: https://startup.mobile.yandex.net. Резервные: startup-mobile.ap.yandex-net.ru, startup.mobile.webvisor.com.
G2.java - SynchronizedDataCache с именем "wifi". Данные кэшируются и отправляются пачками.
Для контекста
В пользовательском соглашении (ToS) всё это официально прописано - мол, это нужно для обучения их алгоритмов, ( на деле для рекламы ). Да и не стоит забвать Google занимается ровно тем же самым. Становится ли от этого легче? Вообще ни капельки.
Решать тут вам, но я думаю у вас есть право знать что делает приложение на вашем телефоне ( не стоит забывать что ваша геолокация моментально уходит сторонним компаниям, а базы данных сливают до сих пор ) .
ПЛАТЁЖНЫЕ ДАННЫЕ (PAN + CVV) ДО ТОКЕНИЗАЦИИ
Когда вы вводите карту в приложении Яндекса, PAN (номер карты) и CVV летят на сервер до токенизации. Но не волнуйтесь, это абсолютно легально и соответствует PCI DSS. Яндекс же сертифицирован, все под контролем - примерно так же, как в 2023 году под полным контролем находился их исходный код до того, как утек на торренты.
АРХИТЕКТУРА БЕЗОПАСНОСТИ
Проблема в том что весь цивилизованный мир уже давно использует архитектуру на порядок элегантнее и безопаснее:
Client-side токенизация (iFrames / Hosted Fields, как у Stripe Elements или Braintree): Данные карты вообще не касаются ваших серверов. Поля ввода физически изолированы на стороне провайдера, приложение видит только готовый токен. Поверхность атаки на вашей стороне = ноль. Радиус поражения при взломе бэкенда = ноль.
Device-level токенизация (Apple Pay / Google Pay / EMVCo): Пользователь вообще не светит картой. Девайс генерирует одноразовую криптограмму на уровне железа (Secure Enclave). Даже если хакер перехватит этот токен по пути, он будет абсолютно бесполезен для любых других транзакций.
И, для сравнения, Server-side токенизация (как у Яндекса): Данные карты послушно летят через твой бэкенд, API-гейтвей, балансировщики, проходят через SIEM, ELK-stack и вообще через всё, что может в один прекрасный момент упасть с ошибкой и радостно плюнуть
{pan, cvn}в файлик с логами.
Какие есть риски?
Логи. Сервер упал с 500-й ошибкой ровно в момент передачи карты? Поздравляю,
{pan: "4276..., cvn: "123"}уже в логе. А лог читают 150 человек. Откуда мы это знаем? из 7e0ac90b489baee8a823381792ec67d465488fefПромежуточные сервера.
startup.mobile.yandex.net- это не крепость, это обычный бэкенд с кучей эндпоинтов, аналитикой, экспериментами.Инсайдер. Охранять один микросервис легко. Охранять всю инфраструктуру приложения, через которую транзитом проходят PAN+CVV - нужно, чтобы 100500 разработчиков, devops'ов и тестировщиков были в PCI DSS scope.
Для контекста
Юридически легально. Есть сертификат, есть изолированный CDE-контур.
Но архитектурно это код образца 2012 года. Stripe, Braintree, Adyen уже 10 лет назад доказали, что можно сделать так, чтобы сервер приложения вообще не видел карту.
Если mobpayment.yandex.net взломают - всё, данные утекли. Яндекс взламывали. VK взламывали. АНБ взламывали
VPN DETECTION
За это их уже забуллили все, но грех упустить
Приложение проверяет наличие интерфейса tun0 (стандартное имя для VPN). Если найден - блокирует авторизацию.
Думаю не секрет что Яндекс заставляет отключать VPN и светить реальный IP, потому что полностью прогнулся под требования Роскомнадзора и Кремля по тотальной слежке и цензуре.
DNS HARDCODED
Приложение использует 77.88.8.8 и 77.88.8.1 в обход системного DNS, VPN DNS, DoH и Tor. Это DNS Яндекса. Даже если вы настроили Cloudflare DoH или используете Tor - Яндекс делает запросы к своим DNS напрямую.
Проще говоря, они видят абсолютно все домены куда вы ходите, и есть огромная вероятность, что вся эта «история браузинга» по первому требованию улетает прямо в нужные руки - ну а выводы делайте сами.
NATIVE SURVEILLANCE ENGINE
Самое сладкое разработчики спрятали в native-библиотеке libquarkenstein_daemons.so.
Внутри зашито всё: пайплайны записи аудио с микрофона (с прямой отправкой на сервера), манипуляции с процессами в обход security-модели Android, нативная геолокация и шифрование. Это полноценный движок слежки, заботливо упакованный в один тяжело читаемый файл (в котором, кстати, по классике забыли затереть внутренние debug-пути сборки, денис опять ты?) вообщем это я так, чтобы вы не забывали о том что выйдет 2/3 часть, новости есть тут.
JAVASCRIPT BRIDGE
21 addJavascriptInterface() мостов. 94 @JavascriptInterface метода. Файл assets/api.js - 30+ функций.
Для контекста
Любая XSS-уязвимость на поддоменах yandex.ru - это мгновенный билет к контролю над вашим устройством. Злоумышленникам нет смысла пробивать лбом неприступные главные серверы с их WAF и круглосуточным мониторингом. Достаточно найти одну незапертую форточку на заднем дворе экосистемы.
XSS - неизбежнен:
Кладбище поддоменов: У IT-гигантов их сотни, если не тысячи. От заброшенных промо-акций пятилетней давности до дев-песочниц, где выполнение пользовательского кода - это вообще основная функция.
Человеческий фактор: В инфраструктуре такого колоссального размера забытого, устаревшего или криво написанного кода невозможно избежать ( без формальной верификации ) . Уязвимый эндпоинт, позволяющий исполнить произвольный веб-скрипт, появится со стопроцентной вероятностью ( или уже тихо существует и ждет своего часа, без намека ).
Слепой Фейсконтроль" Как только хакерский скрипт запускается на таком уязвимом поддомене, мобильное приложение видит знакомое окончание
.yandex.ruи после чего радостно распахивает перед ним все 94 JS-моста, пропуская веб-пейлоад прямиком к нативным функциям.
КОНТАКТЫ
Приложение читает полную адресную книгу (имена, телефоны, email, почтовые адреса, организации, фото), а также журнал звонков. Установлен ContentObserver на ContactsContract.Contacts.CONTENT_URI - любое добавление, удаление или изменение контакта вызывает перечитывание данных. Контактные данные сериализуются через protobuf и отправляются на сервер Яндекса через HTTP POST (с OAuth-авторизацией).
VoIP / мессенджеры
Читает не только обычные телефоны, но и номера из WhatsApp, Telegram, Viber через фильтр MIME-типов phone_v2, viber, telegram, whatsapp.
Отправка на сервер
Ссобирает все контактные данные в UploadContactsRequest - протобаф-структуру с полями:
ContactInfo(ID контакта, id, lookup, displayname, account_type, account_name, times_contacted, timestamps)PhoneInfo(номер, тип, приложение-источник)LookupInfo(lookup-ключи)
Затем данные сериализуются через ae10.b(serializer, request) и отправляются HTTP POST на сервер Яндекса с заголовком Authorization: OAuth <token>.
ПАССИВНАЯ ГЕОЛОКАЦИЯ + СОТОВЫЕ ВЫШКИ
Приложение регистрирует пассивного провайдера геолокации - это позволяет перехватывать координаты, полученные другими приложениями на устройстве. Дополнительно собираются данные о сотовых вышках: MCC, MNC, Cell ID, LAC/TAC, что позволяет триангулировать положение устройства с точностью до 100-500 метров даже в помещениях. Пассивный провайдер доставляет обновления от любого приложения, уже имеющего координаты.
LOGCAT ЭКСФИЛЬТРАЦИЯ
Под капотом дёргается Runtime.getRuntime().exec("logcat -d") - попытка снять полный дамп системных логов. Дальше всё это пакуется, шифруется AES и летит к ним на сервер.
Для контекста
В теории, Logcat - это проходной двор, куда пишут логи вообще все приложухи на телефоне. То есть Яндекс должен пылесосить логи вашего банка, VPN, секретных чатов, историю URL-ов и краши
ситуация тут прям как с RuStore, повторяться не буду. Звучит страшно, но по факту это так только для юзеров старых ОС (ну или если вы сидите с кастомным рутом и выдаете права направо и налево).
Современный Android давно прикрыл эту лавочку на уровне песочницы: без системных привилегий (READ_LOGS) приложение может читать только свои собственные логи. Так что на актуальных прошивках Яндекс через этот логкат успешно соберет данные только о том, как забаговал сам Яндекс.
Если бы в Яндексе работали тру-профи, они бы изначально на уровне кода ограничили сбор логов только своим приложением. А попытка тянуть logcat -d целиком, в расчете на то, что «ОС сама обрежет лишнее» - это просто наглядный показатель того, как там пишется архитектура
APP INVENTORY
Приложение собирает полный список установленных пакетов на устройстве через два механизма: PackageManager.getInstalledApplications() и, как fallback, Runtime.getRuntime().exec("pm list packages"). Список приложений позволяет идентифицировать банки, VPN, мессенджеры, магазины, антивирусы и другие приложения пользователя.
Основной метод: getInstalledApplications()
Собирает все packageName установленных приложений.
Fallback: shell-команда
Резервный механизм при TransactionTooLargeException или DeadObjectException:
Парсит вывод package:com.example.app, извлекая имена пакетов.
Детектор контент-блокеров
После сбора всех пакетов v000.x() проверяет каждый на наличие meta-data:
"com.samsung.android.sbrowser.contentBlocker.interfaceVersion"- если"API_1.0", проверяется ContentProviderДля подходящих приложений собирается
signatureHashиdisplayLabelРезультат - список
ej40{packageName, displayLabel, signatureHash}
СБП ( платежи, все вроде легально )
использует getInstalledApplications() для поиска установленных банковских приложений. Сверяет packageName со списком известных банков, результат показывается в UI оплаты.
VK Push SDK
При отсутствии master-host приложения шлёт аналитический ивент "vkcm_sdk_client_no_master_host_found" с параметром "installed_apps", содержащим список packageName всех установленных приложений. Этот ивент уходит на серверы аналитики VK.
CLID-детекция
Сохраняется в SharedPreferences и используется для аналитики/аттрибуции.
не особо легальный обход ограничений Android
«Но покроет ли это ограничения Android 11+, где Google ввёл Package Visibility и запретил приложениям просто так видеть чужие пакеты?»
Ещё как покроет! Разработчики Яндекса не дураки, чтобы просить у Google Play опасное разрешение QUERY_ALL_PACKAGES (за которое их выкинули бы из стора). Они поступили технически изящнее: захардкодили гигантский список целевых приложений прямо в тег <queries> своего AndroidManifest.xml.
В Android 11+ если пакет явно объявлен в <queries>, приложение имеет полное официальное право проверять его наличие через PackageManager.
Что именно Яндекс внес в свой список «разрешённого наблюдения»:
Вся экосистема Яндекса и дочек: Такси, Карты, Лавка, Диск, Почта, Еда, Маркет, Дзен, Плюс, Яндекс Банк, Кинопоиск, Драйв, Мессенджер.
Абсолютно ВСЕ конкурентные браузеры: Google Chrome (включая Beta/Dev/Canary), Mozilla Firefox, Opera (Mini/Beta/Touch), DuckDuckGo, Vivaldi, Samsung Internet, UC Browser, Via, Mi Browser.
Все популярные мессенджеры и соцсети: Telegram, WhatsApp (+ Business), Viber, VKontakte, Instagram, Twitter, Reddit, Facebook (+ Lite/Messenger), ICQ, OK.ru.
Все почтовые клиенты: Gmail (+ Lite), Mail.ru, Outlook, Spark, MyMail, Yahoo Mail, Samsung Email, BlueMail.
Измерители аудитории и трекеры: Mediascope AppMeter (com.cifrasoft.mpm.mediascope.appmeter) - главная российская система панели аудитории и телеизмерений.
Полный список
com.yandex.browser.alpha, com.yandex.browser.beta, com.yandex.browser.broteam, com.yandex.browser.canary, com.yandex.browser, com.intertechservices.browser, com.yandex.browser.corp, kz.aitu.browser, com.yandex.searchapp.beta, com.yandex.searchapp.canary, com.yandex.searchapp.nightly, com.yandex.searchapp, ru.yandex.searchplugin.beta, ru.yandex.searchplugin.canary, ru.yandex.searchplugin.nightly, ru.yandex.searchplugin, com.yandex.yazeka, com.intertechservices.searchplugin, com.yandex.browser.lite, ru.yandex.yandexmaps, ru.yandex.taxi, ru.beru.android, ru.beru.yandexnavi, ru.yandex.music, ru.yandex.translate, ru.foodfox.client, ru.foodfox.courier.debug.releaseserver, ru.foodfox.vendor, ru.yandex.taximetr, ru.yandex.taximetr.x, ru.yandex.taximetr.beta, ru.yandex.disk, ru.yandex.disk.beta, ru.yandex.money, ru.yandex.mail, ru.yandex.mail.beta, ru.yandex.weatherplugin, ru.yandex.metro, com.yandex.mobile.drive, ru.yandex.market, ru.yandex.rasp, com.yandex.mobile.realty, ru.yandex.mobile.gasstations, com.yandex.uslugi, com.yandex.lavka, ru.yandex.androidkeyboard, ru.yandex.radio, com.yandex.mobile.job, ru.yandex.key, com.yandex.launcher, ru.yandex.mobile.avia, ru.yandex.fines, com.yandex.yamb, com.yandex.yamb.canary, yandex.auto.mobile, com.yandex.courier, ru.yandex.direct, ru.yandex.med, com.yandex.maps.mrcpublic, com.yandex.widget, ru.yandex.mobile.metrica, ru.yandex.mobile.appmetrica, ru.yandex.mobile.telephony, ru.yandex.checkout.release, ru.yandex.yandextraffic, ru.yandex.subtitles, ru.yandex.edc.driver, ru.yandex.nokiasystemservice, ru.yandex.mobile.ofd, com.yandex.launcher.externaltheme.ny, com.yandex.zen, com.yandex.zen.logged, ru.yandex.svetofor, ru.yandex.telemed.doctor, ru.yandex.driverapp, com.yandex.bus.driver, ru.yandex.newperseusapp, ru.zen.android, com.yandex.bank, com.yandex.bank.dev, com.android.vending, com.google.market, com.huawei.appmarket, com.sec.android.app.samsungapps, com.android.chrome, com.chrome.beta, com.chrome.dev, com.chrome.canary, org.mozilla.firefox, org.mozilla.focus, org.mozilla.fenix, com.opera.browser, com.opera.browser.beta, com.opera.mini.native, com.opera.mini.beta, com.opera.mini.touch, om.microsoft.emmx, com.UCMobile.intl, com.ucturbo, ru.mail.browser, com.duckduckgo.mobile.android, com.mi.globalbrowser.mini, com.sec.android.app.sbrowser, mobi.mgeek.TunnyBrowser, com.transsion.phoenix, mark.via.gp, privacy.explorer.fast.safe.browser, com.vivaldi.browser, com.google.android.gm, com.google.android.gm.lite, ru.mail.mailapp, com.microsoft.office.outlook, com.samsung.android.email.provider, com.my.mail, com.yahoo.mobile.client.android.mail, com.readdle.spark, me.bluemail.mail, com.facebook.orca, com.facebook.mlite, com.facebook.katana, com.facebook.lite, com.viber.voip, com.google.android.apps.messaging, com.whatsapp, com.whatsapp.w4b, org.telegram.messenger, com.icq.mobile.client, ru.ok.messages, com.twitter.android, com.instagram.android, com.reddit.frontpage, com.tumblr, com.vkontakte.android, ru.vk.store, ru.vk.store.qa, com.android.printspooler, com.cifrasoft.mpm.mediascope.appmeter, com.samsung.android.mapsagent, com.idamob.tinkoff.android, ru.tinkoff.mb.kids, ru.rostel, com.yandex.mobile.gasstations, ru.rostel, com.whatsapp, com.whatsapp.w4b, com.idamob.tinkoff.android, ru.tinkoff.mb.kids, com.yandex.bank.dev, com.yandex.bank, com.huawei.appmarket, ru.yandex.music, ru.vk.store, ru.vk.store.qa, com.facebook.katana, com.instagram.android, com.facebook.lite, com.samsung.android.mapsagent
Пытаясь втихую обойти приватность Android 11+, Яндекс сам же выдал себя: захардкодив в <queries> сторонние браузеры, мессенджеры и Mediascope, они открыто выложили доказанный факт целенаправленного шпионажа за пользователем - были бы там только банки и сами Yandex-приложения, вопросов бы не было.
REMOTE CONFIG (70+ ФЛАГОВ)
Приложение управляется с сервера. Сервер может включить сохранение карт, форсировать Алису, отложить запрос разрешений на 3 года, включить pre-trigger на полный буфер, отключить валидацию TLS.
Все 70+ флагов
alice_proxy, alice_reader, CommittedOriginTracking_fix, delay_notification_first_permission_request, default_search_promo_on_serp, geo_settings, mobile_ads_sdk, morda_feed_ads, send_bidder_token_to_morda, features_onboarding, tab_folders, morda_force_alice, video_summarization, video_tutorial, common_mobile_menu, manage_cpu_affinity, flex_ntp, morda_modes, ssdk_searchapp_buttons_theme, ssdk_theme, alice_solver, turkish_redesign, force_show_neuro_entry_points, video_translation, video_translation_alice_shortcut, alice_videotranslation, video_translation_international, video_translation_target_kz, video_translation_direct_upload, yandex_href_translate, alice, website_reviews, feature_suggest, div_sovetnik, trust_cards_autofill, save_trust_cards_to_yandex, smart_camera, alice_language, alice_pro, image_search, book_reader, readability_ajax_delay, new_default_popup, turbo_apps, morda_update_on_start, tweak_searchapp_controls, search_2_bro, thumbnail_database, searchapp_user_agent, voice_search_2024, facebook_sdk, books_div_banner, modern_voice_search, voice_search, summarization, div_stories_tutorial, external_applinks, sections_v2, omnibox_visibility, ssdk_serp_line, ai_chat_alice, alice_v2, custom_nav_bar, context_search_serp, safe_browsing_delay_verify_local_database, transsion_widget_promo, xiaomi_widget_promo, widget_promo_environment, image_translator, searchapp_profile_login
Для контекста
Remote config - это стандартная технология. Но набор флагов говорит сам за себя. Это не A/B-тестирование кнопок. Это удалённое управление механизмами слежки и разрешениями. Сервер Яндекса может раздать разный набор слежки разным пользователям - одним 3 секунды pre-trigger, другим 30, третьим off.
ИТОГИ
Давайте подведём цифры того, что нам удалось раскопать ( многое в статью не влезло, но я подведу итоги того что будет в 2/3 частях ) :
60+ механизмов слежки (из них 11 критических и 38 высокого риска).
387+ сетевых эндпоинтов, 1500+ JNI-точек, 94 JavaScript Bridge API, 587 доменов.
Яндекс собирает абсолютно всё:
Звук вокруг вас - ещё до того, как вы произнесли «Алиса» (через pre-trigger буфер).
Звонки и контакты - через ContentObserver адресной книги.
Локацию - через сканирование Wi-Fi сетей, GPS и триангуляцию по сотовым вышкам.
Окружение - полный список ваших приложений (банки, VPN, мессенджеры).
Платежи - данные карт (PAN/CVV) до токенизации.
И самое ироничное: вы за это ещё и платите, покупая подписку «Яндекс Плюс». Оплачивая из своего кармана тотальную слежку за собой же.
О наболевшем
Яндекс, если вы это читаете (а вы точно это читаете) - я провёл для вас
бесплатный публичный аудит! На одну только лицензию IDA для
реверс-инжиниринга я потратил $1 000 из своего кармана. Так что искренне жду от
вас занос за выявление архитектурных дыр!
Если вы хотите поддержать автора и развитие подобных расследований
Рубли (СБП, Карта): https://pay.cloudtips.ru/p/28c476e5
Крипта (USDT TRC-20): TR7XFzMiRXjwFw62gUQRQ4p3oDjdRbea6n
Крипта (BTC): 1FfaKocNVMFqiTfm9V1RvricomZ8GTcvzW
ЧТО ДАЛЬШЕ?
Это была только первая часть из масштабного цикла из 3 статей про экосистему
Яндекса. Впереди ещё много интересного.
Обязательно подписывайтесь на мой Telegram-канал openlibrecommunity - именно
благодаря поддержке сообщества этот материал увидeл свет.
Комментарии (58)
Groramar
03.08.2026 06:01Я бы был очень сильно удивлен если бы было как-то по-другому. Имеющейся ситуации не удивлен ни разу. Выводы делаем сами. Для себя же выводы сделал уже очень давно: ни одного сервиса Яндекса без крайней необходимости нет и не будет на телефоне. На ПК тоже стараюсь минимизировать доступ.
IIIIIIIIIIIIIII
03.08.2026 06:01+1
Большинство сервисов работает в браузере. А без я.пэй или навигатора можно обойтись
sintech
03.08.2026 06:01Разумеется без pre-trigger буфера современный голосовой помощник не может нормально работать
А почему не сможет работать? Команда ведь передается после активационного слова, что дадут 3 секунды до него?
zarazaexe
03.08.2026 06:01нормально работать
современный
там же калибровка, очистка шума, cклеивание слитной речи, серверная верефикация
achekalin
03.08.2026 06:01Вспомнил сразу историю про Алису, которой человек отключил микрофон, а потом, через время, забывшись, шёпотом спросил "Алиса, ты меня слышишь?" - "Нет, у меня же микрофон отключен" - так же тихо ответила Алиса )
musicman3
03.08.2026 06:01Все эти Алисы, Сири и прочие якобы голосовые помощники - они помогают только дядькам в кожаных плащах с маузером в кармане. Для этого их и делали изначально.
Завтра к тебе придут и скажут что ты кричал на ребенка, затем угрожал убить тёщу, а затем и на самого царя наговорил на 2 пожизненных. И подкрепят аудиозаписями.
Причем Алиса знает и ваши паспортные данные, и номера телефонов, и кто есть кто по голосу по именам, и пароли, и где ключи от сейфа. Все это пробегает в бытовых разговорах, и быстро структурируется на сервере. Остается шепотом, и никаких политических анекдотов...
И это уже по всему миру, цифровое рабство прямо перед нами.
kukovik
03.08.2026 06:01В вашем алармистском комментарии есть и отличный рецепт избегания репрессий: не кричать на ребенка, дружить с тёщей, избегать разговоров о царе (хвалить тоже нельзя, вдруг что -- и те, кто хвалил, попадут в опалу). Еще хорошо не иметь сейфа. Паспортные данные, имена и голоса остаются в зоне риска, но тут уж ничего не поделать, они и так всем доступны.
40kTons
03.08.2026 06:01Думаю не секрет что Яндекс заставляет отключать VPN и светить реальный IP, потому что полностью прогнулся под требования Роскомнадзора и Кремля по тотальной слежке и цензуре.
Как и любой бизнес в любой стране, поскольку государство априори выше в иерархии любой компании? Были ли у него варианты не прогнуться? Ну то есть можно сказать "мы это делать не будем", но у любого действия или бездействия есть последствия. Могут организоваться внезапные проверки из условной налоговой, которые найдут нарушения, может топ менеджер компании с двумя пулевыми отверстиями в черепе и запиской "я роскомнадзорнулся" организоваться, ещё много чего может быть
hssergey
03.08.2026 06:01Был вполне вариант просто проверять свой ip адрес. Если он внезапно зарубежный и принадлежит хостингу (при использовании впн), то ругаться и не давать зайти. Если российский, то все в порядке. Так поступили многие, формально требования властей выполнены, претензий нет.
А яндекс именно прогнулся тем что пошел дальше в своих проверках. То есть сознательно усугубил требования властей.
Angle_Tightener
03.08.2026 06:01В позднем СССР довелось покупать породистого щенка у человека, который работал надзирателем в тюрьме строго режима. Так получилась, что у его собаки случилось ложная беременность, и щенка пришлось ждать еще 6 месяцев. За это время мы познакомились и подружились. Он потом даже помог с дрессировкой. Для служебных собак это непросто.
Так вот вот он очень хорошо объяснил про сотрудников органов. Они принципиально делятся на два типа:
1. мент ленивый (делает то, что от него требуют обязанности, и - только)
2. мент служивый (пытается выслужиться)
Между этими категориями есть даже некоторый антогонизм, хоть и не слишком сильный.
Легко догадаться, какую роль играет Яндекс.
P.S. Интересно, что эти два типажа присутствуют во всех органах, не только МВД. А если посмотреть шире - во всей вертикали власти...
sotpiy
03.08.2026 06:01Аж несколько раз повторяется возмущение к изменяемому размеру буфера, а на деле - это очевидное решение, и имхо не самое удобное для какой то тотальной слежки - можно следить только если пользователь вызывает алису
От возмущений по поводу слежки я как будто вернулся в 2007 год, сейчас сбор данных для таргетирования рекламы это совсем база, и кто до чего дотягивается тот то и собирает, понятно что тут хотелось сгустить краски, но гораздо более зашкварным моментам уделено меньше внимания, а из сбора гео и SSID-ов прям слона раздул. Видно что большая и недёшевая работа проделана, но вот что именно со мной станет от xss с js мостами? Ведь эта уязвимость гораздо грубее и опаснее чем сбор всякой инфы для рекламы, которой уже никто всерьёз не боится лет как 10 - почему бы ее не раскрыть? А это как возмущаться камерам, мол следят они - это так, но уже все давно смирились. Имхо про рустор гораздо мощнее статья
OwenEwansSweetGifts Автор
03.08.2026 06:01Аж несколько раз повторяется возмущение к изменяемому размеру буфера, а на деле - это очевидное решение, и имхо не самое удобное для какой то тотальной слежки - можно следить только если пользователь вызывает алису
я без шуток правда не понимаю зачем размер этого буфера нужно регулировать динамически с сервера, а не статично в код? ты знаешь?
От возмущений по поводу слежки я как будто вернулся в 2007 год, сейчас сбор данных для таргетирования рекламы это совсем база, и кто до чего дотягивается тот то и собирает
но ведь то что этоо делают все не делает это нормой, если все начнут прыгать с крыши - это станет хорошей идеей? То что кому то ( возможно тебе ? ) нечего скрывать - это круто, но информация о том, кто и как собирает твои данные, лишней точно не бывает - пользователь имеет право знать что именно делает программа на ЕГО телефоне
но гораздо более зашкварным моментам уделено меньше внимания
справедливости ради это не так, эти моменты просто стоят ниже по тексту, Мы все читаем вдумчиво только начало а дальше скроллим по диагонали, если вчитаться там выжаты максимальные детали просто я старался не превращать статью в куски кода
а из сбора гео и SSID-ов прям слона раздул
гугл в свое время за сбор SSID-ов жестко бойкотировали и таскали по судам, в 2007 люди еще возмущались, а щас просто смирились и забили на то, что телефон за ними шпионит
что именно со мной станет от xss с js мостами? Ведь эта уязвимость гораздо грубее и опаснее чем сбор всякой инфы для рекламы
это реальная уязвимость и если я начну в статье расписывать подробные векторы атак и боевые применения эксплойтов то это будет граничить с мануалом для взлома
которой уже никто всерьёз не боится лет как 10
масса != все
А это как возмущаться камерам, мол следят они - это так, но уже все давно смирились
не стоит обобщать, смирились то далеко не все
Имхо про рустор гораздо мощнее статья
да че уж, это только первая часть из трех, дальше больше
kukovik
03.08.2026 06:01Вовсе не обязательно для этого обращаться к алисе. Достаточно, чтобы ей "показалось", что обращение было. А величину этого "показалось" тоже можно настраивать (и может такая настройка там есть).
si_12345
03.08.2026 06:01это же про мобильный яндекс ?
интересно, а на дестопе что ?OwenEwansSweetGifts Автор
03.08.2026 06:01есть интересные вещи, например лик айпи через вебртс, но это в других частях будет
Last26
03.08.2026 06:01На десктопе под виндой все гораздо хуже..можете не сомневаться ..там вообще простор ещё больше для spyware)
VladSmir
03.08.2026 06:01Безусловно, была проделана отличная работа. Но о том, что на андроиде любое приложение может делать все, что захочет, этим уже никого не удивить. Тем более такое. Было бы интересно узнать, что они могут на ios
aax
03.08.2026 06:01Приложение использует
77.88.8.8и77.88.8.1в обход системного DNS, VPN DNS, DoH и Tor. Это DNS Яндекса. Даже если вы настроили Cloudflare DoH или используете Tor - Яндекс делает запросы к своим DNS напрямую.Интересный вопрос как именно - если допустим у меня DoH предусматривает DROP прямого обращения по любым стандартым портам DNS, то что Яндекс прячет запросы к своим DNS например обращаясь к своим DNS-серверам "не особо легальным способом", например втихаря по 443/TCP хе-хе как и типичный скриптовый
троян"неформальный диагностический модуль" в вебстраничке?OwenEwansSweetGifts Автор
03.08.2026 06:01ну, если у тебя стоит дроп на
77.88.8.8то яндексу придется фейлить / лукапить через систему, а вот если просто лок всех DNS запросов кроме разрешенных - он пойдет через DoH на77.88.8.8aax
03.08.2026 06:01У меня дроп по портам любых стандартных DNS запросов прямо в роутере(на WAN-интерфейсе) и пренаправление DNS запросов из LAN в роутер как едиственный доступный DNS-сервер(и далее в мой DoH), тоесть например скрипт Яндекса на вебстраничке что бы это обойти должен действать как троян, используя неформальный альтернативный тоннель к своему DNS-серверу.
zarazaexe
03.08.2026 06:01У меня дроп по портам любых стандартных DNS запросов прямо в роутере(на WAN-интерфейсе) и пренаправление DNS запросов из LAN в роутер как едиственный доступный DNS-сервер
проблема что существует DOH, работает на 443 порту и не отличим от обычного трафика, и его ты никак не заблокируешь не заблокировав сами айпи днс серверов
aax
03.08.2026 06:01Да ты прав тут надо заморочится, 2026 год это не 2010-й, но я бы не играл в кошки мышки по адресам тоже(если уж заморочусь).
Поскольку трафик идет по принципально доступному порту 443, единственный способ понять, что за ним скрывается (запрос к сайту или DoH-запрос) — расшифровать его.
На шлюзе (роутере/сервере) разворачивается прокси-сервер (например, Squid или mitmproxy).
На клиентские устройства устанавливается корневой SSL-сертификат этого прокси, чтобы устройства ему доверяли.
Прокси расшифровывает HTTPS-трафик на лету и анализирует HTTP-заголовки (MIME-типы). Как только скрипт пытается отправить DNS-запрос, прокси видит заголовок
Content-Type: application/dns-message(илиapplication/dns-json) и мгновенно сбрасывает соединение. Обычный веб-трафик (текст, картинки) пропускается беспрепятственно. И адресатроянскихнежелательных DoH-серверов больше не имеют значения(неформальные порты, в том числе для DNS-запросов порезаны и так). Свой DoH работает только по легитимной паре адрес:порт.
Гемморой конечно, но на дворе 2026 год и замечельные метрики почти в любом контенте...
AlexandreFrolov
03.08.2026 06:01Когда только появились смартфоны, с удивлением обнаружил, что по умолчанию пользователю не предоставляется доступ root. Уже не смогу вспомнить, куда-то писал статью про то что смартфон - это не вполне ваше устройство, и ему не стоит доверять хоть сколь-нибудь важные или критичные с точки зрения безопасности данные. С тех пор ничего не изменилось!
kenoma
03.08.2026 06:01Для меня до сих пор некомфортная мысль, что у пользователей на смартфоне нет никаких механизмов типа iptables из коробки.
Enceronagh
03.08.2026 06:01Всё однозначно так, но есть один тонкий нюанс, который мы, как «айтишники», часто забываем. А именно довольно большой разрыв в компьютерной грамотности между нами и обычными людьми, среднестатистическими, скажем так.
Ну вот давай на минутку представим, что у любой бабульки, которая с трудом тыкает пальцем в светящуюся дощечку и совершенно не понимает, что она делает, из коробки будет root на телефоне? Если речь идёт про 2010й год, то, в принципе, и не страшно, наверное. А вот в 2026, когда на телефоны помимо очевидных банковских приложений с доступом ко всем счетам и сбережениям, стали ставить всякое непотребство типа «Госключа», которым можно подписать аж продажу квартиры... Разумно ли так делать?
Я вот думаю, что нет. Чем меньше у такой бабульки будет возможностей по незнанию наворотить дел, тем лучше. И в этом плане современный телефон для обывателя, который даёт только возможность смотреть котиков без глубокого проникновения вглубь системы, это прям мастхэв, иначе количество преступлений, связанных с телефоном, было бы в сотни раз выше.
Причем это всё страшное на самом деле. Я не могу ничего сказать про «как там у них», на родине Google и Apple, в плане повсеместной глубокой «цифровизации», но в наших реалиях всё совсем печально. Не так давно наблюдал в МФЦ, как какому-то дядьке, который в телефон тыкал с явным непониманием ни лице, добродушная девочка на ресепшене ставила парковочный мессенджер и просила его продиктовать пришедший туда код. И он ставил и диктовал. Бездумно, не понимая вообще что делает (это прям видно было). И такое там каждый день сплошь и рядом, судя по всему. Или в банках, где для подписания договоров также навязывают «электронную подпись» вместо классического подписания документов. Всё это увеличивает количество потенциальных дыр безопасности в телефоне, который из средства для звонков и изредка сообщений становится воротами в твою личную жизнь с совершенно не огороженным ничем доступом.
Maxmyd
03.08.2026 06:01Надо запланировать четвертую статью - что можно сделать кожаным мешкам, чтобы отбить атаки роботов, хотя бы часть.
KamioTor
03.08.2026 06:01Статья правдива в фактах, но автор умело манипулирует выводами. Проведена хорошая работа по декомпиляции кода, но зачем преподносить стандартные (хоть и агрессивные) инструменты маркетинговой аналитики и телеметрии как «шпионский»?
Объективно, мета, гугл, эплы, самсунги и многие прочие делают то же самое в своих экосистемах.
MountainGoat
03.08.2026 06:01мету, гуглу, эплу и самсунгу не может понадобиться срочно посадить в тюрьму хоть кого-нибудь в своём районе, чтобы закрыть норму по поимке иностранных шпионов.
KamioTor
03.08.2026 06:01Думаете, тем, кто хочет посадить, нужно что-то доказывать? Уголовное дело состряпают за пару дней по любому поводу - например, за упоминание какого-нибудь запрещенного сочетания слов ГорныйКозёл на английском языке (сарказм). Как говорили раньше? Был бы человек, а статья найдется.
zarazaexe
03.08.2026 06:01Думаете, тем, кто хочет посадить, нужно что-то доказывать
ну, надо найти того кого надо посадить
zarazaexe
03.08.2026 06:01Объективно, мета, гугл, эплы, самсунги и многие прочие делают то же самое в своих экосистемах.
не поверишь, но ровно это я в своей статье и написал, чем читал?
Статья правдива в фактах, но автор умело манипулирует выводами. Проведена хорошая работа по декомпиляции кода, но зачем преподносить стандартные (хоть и агрессивные) инструменты маркетинговой аналитики и телеметрии как «шпионский»?
получается стоит умолчать то что сервис знает твое гео, твои приложения, твои переписки, сайты куда ты ходил? это слежка, не телеметрия
KamioTor
03.08.2026 06:01Статья предвзята, ты не находишь? На 100 строк хейта в адрес Яндекса и одно скромное упоминание Google. На самом деле сейчас это печальный общемировой стандарт. Глупо винить корпорации. Проблема в самих государствах, которые загнали людей под тотальную слежку и позволяют экосистемам собирать досье на каждого
wepp
03.08.2026 06:01Смешно, что для тех, кто не в курсе, это гуглится..=)
Откуда мы это знаем? из 7e0ac90b489baee8a823381792ec67d465488fef
Last26
03.08.2026 06:01Хз я уже давно отказался от использования приложений российских разработчиков и при необходимости использую веб версии личных кабинетов .. Те мой рецепт для выживания и сохранения хоть какой то приватности в нашей стране это пиксель+графен ос + полное отсутствие приложений и сервисов считай spyware от российских компаний. Т.е. я даже банковские приложения не использую не говоря уже о всяких колонках умных и прочей паксоти.
Daess
03.08.2026 06:01Не для защиты Яндекса, а кругозора для: автор, не могли бы вы поподробнее раскрыть суть претензий к реализации платежей?
Из перечисленных подходов представленных, как более прогрессивные, один недоступен в РФ на текущий момент (ApplePay, GooglePay), а второй (аналог Stripe, Braintree) все равно будет отправлять платежные данные в чистом виде, только на сервер провайдера. Т.е. вопрос в том, что вы доверяете условному аналогу Stripe больше, чем Яндексу? А если этот аналог тоже имеет РФ происхождение? Это я все к тому, что PAN и прочие чувствительные данные в любом случае не должны оказаться в логах в открытом виде (в Яндексе или нет), поэтому что касается этой секции в целом (про платежи) - это скорее вопрос уровня паранойи (что в целом имеет место быть в текущих реалиях, что уж тут).
zarazaexe
03.08.2026 06:01поэтому что касается этой секции в целом (про платежи) - это скорее вопрос уровня паранойи (что в целом имеет место быть в текущих реалиях, что уж тут)
ну дело тут не в паранойе а в сокращении площади атаки
один недоступен в РФ на текущий момент (ApplePay, GooglePay)
Apple Pay и Google Pay я привел просто как примеры, есть много аналогов
второй (аналог Stripe, Braintree) все равно будет отправлять платежные данные в чистом виде, только на сервер провайдера. Т.е. вопрос в том, что вы доверяете условному аналогу Stripe больше, чем Яндексу? А если этот аналог тоже имеет РФ происхождение?
дело не в доверии к бренду ( там ну я ндексу или условному платежному шлюзу ) а в изоляции контура
Это я все к тому, что PAN и прочие чувствительные данные в любом случае не должны оказаться в логах в открытом виде (в Яндексе или нет),
ну... в нормальной архитектуре сырые данные твоей карты вообще не касаются бэкенда приложения, ты вводишь карту в изолированном окне провайдера, она летит напрямую в банковский шлюз а само приложение Яндекса получает в ответ только безопасный токен
а в реализации Яндекса сырые PAN и CVV идут транзитом прямо через их общие сервера, балансировщики и API-шлюзы которые как раз могут это сделать ( и делали, стоит почитать слитые сурсы яндекса 23 года, поможет понять как там все халтурно )
Daess
03.08.2026 06:01Apple Pay и Google Pay я привел просто как примеры, есть много аналогов
Для iPhone, кроме разрешенных рынков, типа ЕС, вроде как еще ничего не придумали. Для Android да, HCE существует уже давно.
дело не в доверии к бренду ( там ну я ндексу или условному платежному шлюзу ) а в изоляции контура
Не понимаю. В условном Stripe все равно данные уйдут на сервер Stripe, или типа если данные ушли не на мой сервер, то это и не моя проблема? Ну, в целом подход имеет право на существование, но мы же тут вроде про сохранность платежных данных говорим? BTW, есть в РФ сейчас провайдеры, которые это делают, и за которых вы готовы дать руку на отсечение, что у них внутри все сделано как надо и комар носу не подточит?
ну... в нормальной архитектуре сырые данные твоей карты вообще не касаются бэкенда приложения, ты вводишь карту в изолированном окне провайдера
По мне выглядит так, что Яндекс, обладая лицензией ЦБ РФ, в целом и выступает провайдером платежей. Было бы странно банку встраивать к себе в контур какой-то поддержку стороннего провайдера? Ну то есть как если бы (условно) при оплате в Сбере данные вводились в Stripe.
OwenEwansSweetGifts Автор
03.08.2026 06:01Для iPhone, кроме разрешенных рынков, типа ЕС, вроде как еще ничего не придумали. Для Android да, HCE существует уже давно.
да но к форме ввода карт это отношения не имеет
Не понимаю. В условном Stripe все равно данные уйдут на сервер Stripe, или типа если данные ушли не на мой сервер, то это и не моя проблема? Ну, в целом подход имеет право на существование, но мы же тут вроде про сохранность платежных данных говорим? BTW, есть в РФ сейчас провайдеры, которые это делают, и за которых вы готовы дать руку на отсечение, что у них внутри все сделано как надо и комар носу не подточит?
да никто не говорит про идеального провайдера которому нужно слепо верить суть в изоляции контура и площади атаки если данные уходят в изолированный шлюз их обрабатывает узкоспециализированная система а не прогоняет через себя вообще весь основной бэкенд экосистемы
По мне выглядит так, что Яндекс, обладая лицензией ЦБ РФ, в целом и выступает провайдером платежей. Было бы странно банку встраивать к себе в контур какой-то поддержку стороннего провайдера? Ну то есть как если бы (условно) при оплате в Сбере данные вводились в Stripe.
если у Яндекса есть свой банк это не значит что архитектурно правильно пихать ввод карт в общие сервисы мобильного приложения
да и если вообще посмотреть на все что тут написано более детально поймешь какой же это говнокод
Daess
03.08.2026 06:01Предположим, что Яндекс имеет свой сервис клиентской токенизации (не знаю на 100% так это или нет). Если Яндекс в своем приложении будет использовать его, это устранит исходную претензию? Если нет, то почему? Если да, то какая принципиальная разница, через какую дырку данные карты полетят на сервера Яндекса - через сервис клиентской токенизации или через форму данных карты?
select26
03.08.2026 06:01не могли бы вы поподробнее раскрыть суть претензий к реализации платежей?
В статье уже подробно описаны существующие альтернативные системы токенизации на клиенте. Как человек из PCI DSS, я с выводами автора статьи согласен.
Daess
03.08.2026 06:01Как "человек из PCI DSS" вы же наверное должны понимать, что если Яндекс прошел валидную сертификацию, то вопросы к тому, что в логах будут лежать PAN и CVV в открытом виде не должны стоять?
zarazaexe
привет