Apple уберет из Safari функцию Do Not Track из-за нулевой эффективности

Apple уберет из Safari функцию Do Not Track из-за нулевой эффективности

Apple уберет из Safari функцию Do Not Track из-за нулевой эффективности

Apple планирует убрать опцию Do Not Track из своего браузера Safari. Напомним, эта настройка призвана запретить определенным сайтам отслеживать посетителей. Однако на деле реализация Do Not Track подкачала.

Опубликованные вчера заметки релиза Safari Technology Preview 75 говорят о том, что американская корпорация наконец признала факт бесполезности (а зачастую и откровенного вреда) функции Do Not Track.

По данным поисковой системы DuckDuckGo, этой опцией пользуются 24,4% американских пользователей. Поисковик также провел опрос, в ходе которого выяснилось, что половина пользователей даже не осознавали, что Do Not Track предназначена только для отправки сайтам запроса, в котором браузер «просит» не отслеживать пользователя.

«Работу функции Do Not Track можно сравнить по эффективности с огромным знаком перед вашим домом, на котором написано: “Пожалуйста, не заглядывайте в мой дом“. При этом, естественно, заглянуть туда не составит никакого труда», — пишет команда DuckDuckGo.

«На деле все еще хуже — корпорации вроде Google, Facebook и Twitter вообще никак не реагируют на включенную опцию Do Not Track».

Российские провайдеры начали глушить защищённые DNS Google и Cloudflare

Пользователи сразу нескольких российских операторов пожаловались на проблемы с защищёнными DNS-сервисами Google и Cloudflare. Под ударом оказались протоколы DNS over HTTPS (DoH) и DNS over TLS (DoT), которые шифруют DNS-запросы и не позволяют провайдеру запросто подсматривать, к какому домену обращается пользователь.

По данным телеграм-канала bypassblock, сбои затронули абонентов «Ростелекома», «Дом.ру», «Таттелекома» и петербургского SkyNet.

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

При подключении к Cloudflare по адресам 1.1.1.1 и 1.0.0.1 через порт 853 TCP-рукопожатие проходит успешно, после чего соединение принудительно сбрасывается с ошибкой ECONNRESET — ещё до завершения TLS-аутентификации.


С Google Public DNS картина другая. Соединение с dns.google, 8.8.8.8 и 8.8.4.4 через порт 443 устанавливается, но после отправки TLS ClientHello ответы прекращаются.

Сессия либо висит до тайм-аута, либо завершается ошибкой unexpected eof while reading. Такое поведение может указывать на вмешательство промежуточного оборудования и фильтрацию по сигнатуре.

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

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

RSS: Новости на портале Anti-Malware.ru