Коммерсантъ сегодня пишет, что сайты десятков российских банков на стандартной CMS "1С-Битрикс" имеют уязвимость, которая позволяет злоумышленникам использовать ссылки с открытыми редиректами типа https://bank.ru/redirect.php?goto=https://rublacklist.net Безопасники из компании StopPhish взяли с сайта ЦБ список из 358 банков, прошлись скриптом по всем сайтам, из них 140 работают на "1С-Битрикс", а 27 поддерживают открытые редиректы. Идея в том, что злоумышленники могут делать такие ссылки, рассылать их пользователям, и пользователи будут по ним переходить на фишинговые сайты, потому что их научили сначала проверять домен в ссылках, а домен правильный.

Вот здесь казахские айтишники обсуждали эту же проблему у казахского банка в 2015 году. А история с редиректами касается не только банков, а всех сайтов на этой CMS, которых в российском интернете около 13.4%. В админке "1С-Битрикс" есть настройка "Защита редиректов", у кого она отключена, у того такие редиректы работают, причем в последней версии она включена по умолчанию. На форумах пишут, что пару лет назад по умолчанию все было выключено, клиенты жаловались, а техподдержка предлагала включать.

Ну что, если вы пользователь - проверяйте ссылки не только до перехода по ним, но и после)) Если вы админ "1С-Битрикс" и редиректы для вас вообще проблема - лезьте в админки проверять, и, кстати, убедите клиентов продолжать покупать обновления безопасности, которые у Битрикс платные по подписке. А если вы безопасник - это история о том, как безопасность продукта определяется не возможностями его настраивать, а тем, как разработчик выбрал настройки по умолчанию пять версий назад.

Bi.zone, дочка Сбербанка в сфере кибербезопасности, поговорила с РБК о статистике, как у их российских клиентов ломают аккаунты. На первом месте (46%) перебор паролей по словарю и последствия использования одинаковых паролей в разных сервисах, а на втором (34%) - фишинг, то есть вместе эти два способа дают 80% инцидентов.

Проценты немного странные, потому что всего четыре способа атак (атаки на пароли 46% + фишинг 34% + уязвимости ПО и сервисов 17% + инсайдерские атаки 3%), вместе дают 100%. Но это все-таки РБК, так что похоже, что в основе этого материала лежит настоящая статистика инцидентов, а не просто марекетинговая брошюра. Тогда это - ценная информация о том, что сейчас наиболее вероятно "в среднем по больнице". А дальше есть немного пользователей, которые понимают про себя, что их ситуация особенная и их угрозы другие. И есть очень и очень много пользователей, для которых в этом материале говорится примерно следующее:

Хочешь примерно в четыре раза снизить риск взлома своих аккаунтов?
• Используй для важных аккаунтов сложные уникальные пароли (снижает риск почти вдвое).
• Разберись, что такое фишинг и настрой двухфакторную (снижает риск на треть).

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

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

• у пользователя должны быть компьютер и смартфон, которые привязаны к одному и тому же аккаунту,
• смартфон должен быть либо Android (и тогда он умеет показывать их дефолтный Google Prompt/Уведомления от Google) либо iPhone c установленными приложениями, которые умеют показывать эти уведомления (то есть Поиск Google, Gmail или Google Smart Lock)
• и привязанный телефонный номер на который можно прислать одноразовые коды - Google обычно хочет два способа двухфакторной.

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

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

Исследователь безопасности nusenu выложил исследование о том, как выходные узлы сети Tor атакуют трафик пользователей. Если вкратце, единственный "нарушитель безопасности" в некоторые моменты контролирует до 27.5% выходных узлов всей сети Tor, потом эти узлы блокируют, а он добавляет новые и их количество на пике снова доходит до примерно 25%. В среднем за последний год таких выходных узлов в сети было примерно 14%. Этот кто-то использует email “Андрей Гвоздев <andrejgvozdev55@gmail.com>” и зарегистрирован в базе данных RIPE с московским адресом.

"Плохие" выходные узлы занимаются тем, что пытаются расшифровывать SSL трафик пользователей при помощи стандартных утилит mitmproxy и sslstrip. В предыдущем исследовании nusenu рассказывал, что атакующий делает это в основном для того, чтобы заменять адреса bitcoin кошельков для вывода на биржах криптовалюты. То есть пользователь заходит на биржу через Tor browser, ему достается "плохой" выходной узел, который пытается расшифровать его SSL соединение, пользователь соглашается с предупреждением браузера, что с его SSL что-то не так, или просто заходит на криво настроенный сайт биржи в http-режиме, покупает крипту, а она потом уходит в другое место.

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

• Проверяйте, что сайт открывается в https.
• Не игнорируйте предупреждения браузера о том, что с сертификатом сайта что-то не так.
• Используйте расширения для браузера типа HTTPS Everywhere.

Лаборатория Касперского пишет, что на 36% компьютеров в России до сих пор стоит Windows 7. Если это правда, то это просто трэш, это миллионы машин, которые уже год не получают обновления безопасности через Windows Update. Понятно, что большая часть этих машин спрятаны за NAT своих роутеров хотя бы от удаленных атак, но вот навскидку поисковая система Шодан видит 3000 компьютеров из RU с торчащим в интернет протоколом удаленного управления RDP. А люди на "семерках" еще же файлы запускают!

Наверное есть какие-то способы (как был BypassESU) автоматом продолжать получать платные Microsoft-овские обновления безопасности для "семерки", которые будут выходить до 2023 года, или выкачивать обновления из Microsoft-овского каталога и ставить их руками. Но скорее всего большая часть из этих 36% - это просто непатченные машины, и из них куча странных "сборок" и компьютеров с отключенными обновлениями. А истории с уязвимостями типа EternalBlue и Bluekeep показывают, что выживает тот, кто может вовремя обновиться, а у пользователей "семерки" простой возможности делать это больше нет.

Понятно, зачем Microsoft сделал обновления почти неотключаемыми в Windows 10, и перешел на систему с крупными обновлениями два раза в год вместо новых версий.

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

Немного контекста: эта идея время от времени всплывает у нас в России, но это не только российская история. На английском эта проблема называется key escrow, и в последние пару десятилетий она обсуждается не только политиками в России, Великобритании и США, которые считают, что надо, чтобы гражданские опять не могли шифроваться от государства, как в старые добрые времена. Криптографы тоже думают, а как такое вообще сделать, и на сегодня хорошего практического решения просто нет.

Отношение сообщества к проблеме описывает коммент известного криптографа Мэтью Грина по поводу очередной такой инициативы в США в 2018 году: "Немногие из нас поддерживают идею масштабной системы хранения ключей шифрования потому, что мы думали об этом и мы считаем, что это не сработает. Мы взвесили модель угроз, модель использования и качество современного "железа" и ПО. Мы считаем, что не существует системы обнаружения кражи ключей, нет системы их обновления, криптографические модули ужасно небезопасны (и в компаниях [которые их производят] сплошь работают бывшие разведчики), и возможны инсайдерские атаки. Мы не готовы помещать данные нескольких миллиардов человек в такую систему, которая с большой вероятностью может отказать" (ссылка).

Даже если криптографы придумают достаточно хорошее решение, у подобных идей нет никакого опыта успешной имплементации, а есть только куча фейлов. Например, в середине 90-х американцы пробовали внедрить технологию, которая называлась Клиппер Чип, и ничего не вышло. Казахстан последние лет пять пробует внедрить "национальный сертификат безопасности" (а это система гораздо проще, это просто атака "человек-в-середине" на SSL), и тоже пока на уровне страны не получается. И так далее.

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

В России по решению суда сегодня заблокирован 4pda.ru, у нас на сайте вышел материал с подробностями. Сейчас открывается через VPN или на новом домене 4pda.to. Ответчиком в судебном процессе был не сам 4pda, а сервис по защите от DDoS-атак Cloudflare, которым в режиме обратного прокси пользуется 4pda и еще примерно 7.6 миллионов сайтов, поэтому владелец самого ресурса не был стороной в деле и не мог обжаловать решение. Типа пользователи заходили на IP-адреса Cloudflare, поэтому сервис создавал технические условия распространения.

У сайтов есть несколько традиционных вариантов решения проблемы блокировки и 4pda сделал вполне рациональный выбор:

• Спрятаться "за спиной" кого-нибудь большого, кого не станут блокировать, как, например, сделал Грани.ру со своим зеркалом на Appspot. (https://grani-ru-org.appspot.com/).
• Разделить разные части сайта на разные домены, как, например, сделал белорусский портал Tut.by, который вынес все обсуждения на отдельный домен Talks.by, а то вдруг пользователи что-нибудь напишут, а потом весь сайт заблокируют за распространение.
• Рассчитывать, что пользователи сами найдут способ обходить блокировки и будут приходить через Tor, VPN и прокси-сервера.
• Регистрировать новый домен и сообщать об этом пользователям, как это сегодня сделал 4pda.

Помните, как недавно Signal "бодался" с израильской компанией Cellebrite, которая производит программно-аппаратные комплексы для анализа изъятых телефонов?

Теперь Matt Bergin представил (pdf) на конференции Black Hat Asia результаты своего анализа функционала того же продукта Cellebrite UFED для сбора доказательств со смартфонов и концепт утилиты LockUp, которая может этому противодействовать. Программно-аппаратные комплексы Cellebrite разных версий исследователь купил на ebay, они там продаются. А его утилита отслеживает попытки считать данные через через USB-шнурок теми способами, которыми это делает Cellebrite, и сбрасывает смартфон к заводским настройкам.

Утилита не предназначена для серьезного использования, она написана в качестве идеи для других людей, которые пишут софт для повышения безопасности смартфонов. В этой истории интересно другое. Если Мокси Маклинспайк из Signal подавал историю с уязвимостями Cellebrite как "вы нас ломаете, мы вас взломаем", то Matt Bergin явно делает акцент на том, как недостатки конкретного продукта Cellebrite делают результаты анализа непригодными для использования в суде, хотя американские суды их сейчас принимают. Понятно, что правоохранители и дальше будут изымать смартфоны и им нужно будет скачивать с них файлы и анализировать, и понятно, что сейчас Cellebrite постарается "допилить" недостатки своего продукта. В прошлый раз после известного поста Signal исправления вышли чуть ли не в течение недели (хотя те, предыдущие проблемы были гораздо проще, там были просто старые версии библиотек). Суть в том, что хакеры берут на себя функцию общественного контроля, чтобы кто-то в обществе понимал, что вообще делают правоохранители и как, и например, чтобы при помощи этих продуктов нельзя было недоказуемо подложить или изменить файлы на телефоне.

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

В чем идея: базовый способ следить за тем, куда пользователь ходит в интернете, - это отслеживающие cookie. Кроме этого у сайтов есть возможность собирать кучу технической информации из браузера пользователя и создавать из нее "цифровой отпечаток", который получается уникальным, потому что разной информации много (проверить себя можно здесь). Но как сайт может понять, что Chrome и Firefox принадлежат одному и тому же пользователю? Для этого исследователи из FingerprintJS придумали взять 32 популярных приложения, у которых есть свои собственные ссылки типа skype://, steam://, zoom://, и открывают их со стороны "плохого" сайта в новых окнах javascript-ом по очереди. Если приложение установлено, браузер рисует окошко с вопросом, надо ли его открывать, и сайт это фиксирует. В результате сайт понимает, какие из 32 приложений установлены у пользователя (если пользователь этому активно не противодействует, например, запрещая javascript), и этого часто достаточно для сопоставления разных браузеров, пишут, точность 90% с маленьким хвостиком. FingerprintJS сдали результаты своего исследования разработчикам популярных браузеров, скоро те что-нибудь придумают.

Атаку тестировали и она пока что работает в этих браузерах.

• Chrome 90 (Windows 10, macOS Big Sur)
• Firefox 88.0.1 (Ubuntu 20.04, Windows 10, macOS Big Sur)
• Safari 14.1 (macOS Big Sur)
• Tor Browser 10.0.16 (Ubuntu 20.04, Windows 10, macOS Big Sur)
• Brave 1.24.84 (Windows 10, macOS Big Sur)
• Yandex Browser 21.3.0 (Windows 10, macOS Big Sur)
• Microsoft Edge 90 (Windows 10, macOS Big Sur)

Демка здесь: https://schemeflood.com/, работает только на десктопе, можете себя проверить.

Компания Cloudflare думает, чем бы заменить свою CAPTCHA, потому что она всех достала, занимает 32 секунды, каждый пользователь интернет в среднем решает ее раз в 10 дней, у Cloudflare - 7.6 миллиона сайтов-клиентов, в общем годы времени и геморроя. В их официальном блоге вышел пост, где предлагается использовать вместо капчи USB ключи U2F, работающие по протоколу FIDO, типа пользователь пришел на страницу с челленджем, вместо CAPTCHA нажал на кнопку своего USB ключа и таким образом доказал, что он не робот. Тестовая страница выложена на https://cloudflarechallenge.com/, если у вас есть U2F ключ, сходите протестировать. Другие сервисы, например Google и Facebook, уже используют такие ключи как способ двухфакторной аутентификации, поэтому у людей на руках они уже есть, а еще поддержку FIDO начинают встраивать прямо в устройства, например, в телефоны.

Похоже, что Cloudflare опубликовала эту идею, чтобы таким образом обсудить ее с исследователями безопасности, которые "шарят" в проблеме, и исследователи отвечают, что это плохая идея. Вот отличный пример аргументированного ответа. Основной тезис в том, что стандарт U2F просто не решает проблему, которую сносно решает CAPTCHA, - как отличить человека от робота. U2F - отличное решение, но другой проблемы - как доказать сервису, что у пользователя есть доступ к физическому объекту, ключу. Кроме этого:

• Нажатия ключа легко автоматизировать, например, при помощи Arduino.
• Можно сделать так, чтобы всплывающее окно U2F не показывалось в браузере, чтобы легче было автоматизировать процесс.
• Один ключ можно нажимать 30 раз в минуту. В посте приводится базовый расчет стоимости "фермы" из ключей, которые будут обходить такой аналог CAPTCHA с производительностью 20 000–40 000 попыток в минуту.
• При использовании ключей возникает небольшая проблема приватности: партии по 100 000 (или меньше) ключей используют один и тот же сертификат, а поскольку со стороны сервера, как правило, сидит Cloudflare, пользователь перестает быть таким же анонимным, как после решения CAPTCHA.

И так далее. В общем, идея избавиться от CAPTCHA - правильная, а решение пока что так себе.

Ардуинка нажимает ключи U2F, доказывая Cloudflare, что она не робот.

В Беларуси заблокирован мегапопулярный там портал tut.by, в редакцию приходили силовики, у нас об этом вышел материал с подробностями. Основной сайт не работает, работающее сейчас зеркало - https://www.tutby.news/.

В этой истории есть интересный момент: сервера Tut.by держал на площадке "Белтелекома" в Минске. Почему? Помимо очевидного ответа про скорость доставки контента до пользователей, есть еще один ответ: существует указ президента Беларуси №60 от 2010 года, по которому сайты, обслуживающие "деятельность по реализации товаров, выполнению работ, оказанию услуг на территории Республики Беларусь", то есть, которые, например, крутят белорусскую рекламу и берут за нее деньги, должны быть физически размещены в Беларуси. Это позволяет государству действовать не как в России, где сайты можно хостить за рубежом, а потом РКН блокирует их для россиян "снаружи-внутрь", а наоборот - позволяет государству блокировать "изнутри-наружу", из Беларуси для всех.

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

Google представил Android 12 c новыми функциями защиты приватности. Главное, что там появилось:

• Privacy Dashboard - список того, какие приложения получали доступ к геолокации, камере и микрофону за последние 24 часа.
• Системная иконка уведомления, когда приложение использует доступ к камере и микрофону.
• Возможность предоставлять приложению не точную, а примерную геолокацию.
• Окно запроса, когда одно приложение хочет читать буфер обмена другого.

Ничего революционного, но все потенциально полезное.

New York Times выпустил (ссылка через Google Translate, чтобы обойти их пейволл) большой материал о том, как Apple переносит данные iCloud на сервера в Китай, чтобы соответствовать требованиям тамошнего закона о локализации данных.

Если вкратце, сервера iCloud для китайских пользователей принадлежат китайской государственной компании Guizhou-Cloud Big Data (GCBD), находятся в ее дата-центрах и обслуживаются ее сотрудниками в Китае, и ключи шифрования хранятся там же. В соглашении с китайскими пользователями написано, что Apple и GCBD имеют доступ ко всем данным, которые хранятся в сервисе и могут обмениваться этими данными. Китайские сервера изолированы от остальной инфраструктуры, обслуживающей iCloud для пользователей других стран. В этой ситуации Китай может запрашивать данные пользователей не у Apple, а у местной компании GCBD, которая по закону обязана их выдавать, и такие запросы не имеют отношения к Apple и не попадают под американскую юрисдикцию. А во второй половине материала авторы рассказывают, как Apple тысячами блокирует в App Store приложения, которые в Китае считаются нежелательными.

Авторы не знают, как фактически пользуется этой системой китайское правительство. Также не понятна история с ключами шифрования, потому что часть информации в iCloud зашифрована end-to-end и не должна быть доступна со стороны сервера. Зато вот вам пример того, какие технические возможности может дать государству законодательство о локализации данных.

К предыдущему посту - скрин из презентации криптографа Matthew Green, собранной из эппловского мануала. Сверху - список информации, которая не шифруется end-to-end и к которой Apple имеет доступ.

Facebook выпустил новый отчет о прозрачности с данными за вторую половину 2020 года с данными по Facebook и Instagram. Рассказывает, что контент по российским запросам блокирует, но информацию о пользователях не "сдает".

Россия запрашивала данные о пользователях FB и Instagram 20 раз, Facebook говорит, что ничего не выдал, то есть получается, что в 2016-2020 году они вообще ничего не выдавали.

По запросу Роскомнадзора во второй половине 20 года было 1868 блокировок, из них 792 за экстремизм, 537 за показ самоповреждающего поведения, 85 оргпреступность, 71 за оборот и использование запрещенных товаров, 46 за показ сцен насилия (graphic content), одну за дезинформацию о COVID, одну по решению суда, и 335 по "нарушениям в ведении Росмолодежи". В основном блокировали посты, но кроме этого под блокировку попали 59 страниц и групп и 9 профилей в FB и 126 аккаунтов в Instagram.

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

Что измеряли исследователи? В айти есть стандартный способ публикации информации об уязвимостях, который называется CVE. Часто (хотя не обязательно) к моменту официальной публикации CVE производитель успевает выпустить обновление, исправляющее уязвимость. Но хакеры рассчитывают на то, что производитель не успеет выпустить обновление, либо пользователи или админы не успеют его установить.

Так вот, исследователи с января по март мониторили 50 миллионов адресов, принадлежащих 50 крупным компаниям, чтобы понять, как быстро после официальной публикации нового CVE хакеры начинают сканировать интернет и искать жертв новой опубликованной атаки. Получилось в среднем от 15 до 60 минут с момента публикации и еще меньше 45 минут на то, чтобы отсканировать весь интернет (в смысле все IP v4 адреса) и собрать список потенциальных жертв. Если уязвимость особенно "вкусная", как было с мартовской дырой в почтовом сервере Microsoft Exchange, сканировать начали через пять минут после официальной публикации CVE. Устанавливать обновления безопасности с такой скоростью крупные компании не успевают, поэтому у тех, которые попали в выборку исследования, получилось в день в среднем две новые серьезные дыры.

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

Сегодня в Госдуму внесли законопроект, обязывающий крупные иностранные IT-компании открывать представительства в России. Если его примут, за отказ предполагается наказание вплоть до блокировки. Блокировать фактически могут двумя способами: через реестр Роскомнадзора, либо на DPI-оборудовании РКН, установленном у провайдеров по закону о "суверенном рунете". Про это новое оборудование Роскомсвобода в последний раз писала в апреле, когда оно вызвало сбои у крупных операторов.

Поэтому сейчас - отличный момент, чтобы попробовать бесплатное расширение для браузеров от Роскомсвободы Censor Tracker (https://censortracker.org/). Это расширение:

• Позволяет обходить блокировки, то есть пользователь ходит на доступные сайты напрямую, но если сайт заблокирован, то расширение пускает пользователя через прокси. Обход блокировок работает как для сайтов, заблокированных через официальный реестр, так и для внереестровых блокировок.
• Сообщает пользователю, если сайт входит в реестр запрещенных сайтов (https://reestr.rublacklist.net/) или в список организаторов распространения информации. Последние обязаны хранить и без решения суда предоставлять органам любую информацию о пользователях.
• Помогает нам собирать информацию о внереестровых блокировках. То есть если сайт фактически заблокирован, а в реестре его нет, разработчики расширения получают об этом минимум данных, необходимый, чтобы начать разбираться.

Ссылка на версию для Chrome - на оффсайте и в интернет-магазине Chrome. А еще у Censor Tracker есть экспериментальная версия для Firefox, и мы просим пользователей помочь нам ее тестировать. Если у вас есть по ней отзывы - можете писать в комменты на этом канале, разработчики их там увидят.

И раз полноценно пользоваться интернетом в России без VPN становится все сложнее, советуем присмотреться еще к одному проекту, который сделан с помощью Роскомсвободы. Это Amnezia VPN - продукт с открытым исходным кодом, созданный для того, чтобы быстро и просто поднять личный VPN на своем собственном сервере. На сегодня у Amnezia VPN есть приложения для Windows и Mac OS и пока нет приложений для смартфонов, но скоро будут.

В Китае в мае вступил в силу новый Закон о защите персональной информации, который вводит ограничения на сбор персональных данных мобильными приложениями. Теперь разработчиков начинают предупреждать за сбор лишних персональных данных, и на прошлой неделе предупреждения получили 105 приложений, в том числе TikTok, Microsoft Bing и Linkedin. На устранение нарушений дают 15 дней, а в перспективе перспективе закон предполагает огромные штрафы (до $7,7 миллионов).

Закон основан на простом списке из 39 пунктов, в котором написано какие категории приложений имеют право собирать какую информацию (вот список на китайском), все остальное собирать запрещено. Например:

• Карты и навигация: геолокация, начальная и конечная точка маршрута.
• Мессенджеры: номер телефона и список контактов.
• Онлайн-сообщества, блоги, форумы: номер телефона.
• Знакомства: номер телефона, пол, возраст, семейное положение.

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

В Китае почти миллиард пользователей, и "забить" на закон у корпораций наверное не получится, и что им теперь делать? Они быстро научатся собирать разные персональные данные на разных рынках, или нам с вами достанется немного китайской приватности за компанию? А что будет с корпорациями, чья бизнес-модель была просто основана на слежке за пользователями и сборе лишних данных? А что, если в официальном списке - неточность и какой-нибудь категории ПО правда нужно больше данных? Очень интересно.

Сотрудник компании F5 написал в блоге и рассказал на конференции RSA, как ради эксперимента работал в компании https://2captcha.com/, одном из коммерческих решений по обходу CAPTCHA. Там все, оказывается, грамотно устроено: клиенты запрашивают и получают решения по API, в компании есть техподдержка и документация, куча людей сидит онлайн и решают в реальном времени за совсем небольшие копейки, причем несколько людей одновременно получают одинаковую задачу, а клиенту уходит ответ, который выбрало большинство. Обычная CAPTCHA стоит клиентам $0.75 за 1000 правильных решений, а reCAPTCHA - $2.99 за 1000, причем это еще не самое дешевое на рынке предложение. Все легально.

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

Иногда всплывают истории об отдельных российских интернет-провайдерах, которые блокируют лишнее. Вот свежий пример: у тульского пользователя заблокирован сайт https://protonvpn.com, хотя в реестре запрещенных сайтов нет его доменных имен и IP-адресов и другие провайдеры в России его не блокируют. Само приложение ProtonVPN работает, но не скачиваются автоматические обновления и геморрой с авторизацией пользователя, то есть не работает все, что фактически обращается к веб-приложению.

Он пишет в поддержку своего провайдера, который называется АЙ ТИ (http://home.it-service.club/), ему отвечают, что блокировка - по письменной просьбе РКН и ссылаются на вот эту новость начала 2020 года. Действительно, в январе прошлого года ProtonVPN на очень короткое время попадал под блокировку "за компанию" с Protonmail, который до сих пор официально заблокирован через официальный реестр запрещенных сайтов. Но тогда компания Proton Technologies быстро поняла, как вывести свой VPN из-под блокировки, и отписалась, что у пользователей из России он должен работать (https://protonstatus.com/incidents/58). В общем, выглядит эта история сейчас как внереестровая блокировка самим провайдером. Перестарались(

Что делать пользователю? Если это единичный локальный случай, то разумное решение — пользоваться другим VPN и попросить у Proton вернуть деньги, если это платная подписка. Юристы говорят, что еще можно написать жалобу на такое в Роскомнадзор)