Microsoft уличила Google в слежке за пользователями IE

Microsoft уличила Google в слежке за пользователями IE

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

Согласно записи в блоге вице президента Microsoft Дина Хачамовица, услышав о попытках Google обойти политики безопасности, используемых в Safari, команда разработчиков задалась простым вопросом: «А что если Google также обходит настройки безопасности в IE?» В результате выяснилось, что это действительно так.

По словам г-на Хачамовица для обхода имеющихся политик безопасности Google использовала нюанс в спецификации P3P, позволяющий обходить пользовательские настройки cookies. По умолчанию IE блокирует файлы cookies от сторонних сайтов, за исключением случаев, когда сайт предоставляет спецификацию P3P. К примеру, спецификация Microsoft выглядит следующим образом:

P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"

Как видно из спецификации P3P для описания политик безопасности пользователя используется  контейнер, состоящий из трех- или четырехзначных маркеров, каждый из которых имеет свое значение. К примеру, маркер “TAI” означает, что «пользовательская информация, собранная исключительно за одно посещение сайта, может быть использована для изменения содержания и дизайна сайта».

Однако если маркер не будет опознан, он все равно будет принят обозревателем. Этим и пользуется Google, отправляя спецификацию P3P, которая не сообщает браузеру об использовании им файлов cookies и информации о пользователях. По сути, спецификация P3P от Google утверждает, что она вовсе не является спецификацией P3P. Вот как выглядит спецификация P3P от Google:

P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info

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

В ответ на обвинения Microsoft Google возразила, что Microsoft поддерживает систему, которая является устаревшей и непрактичной.

сообщалось ранее.

" />

Баги в ядре Linux скрываются в среднем 2 года, а иногда и 20 лет

История с первой CVE для Rust-кода в ядре Linux, которая недавно привела к падениям системы, выглядела почти как повод для оптимизма. В тот же день для кода на C зарегистрировали ещё 159 CVE — контраст показательный. Но новое исследование напоминает: проблема не только в языках программирования.

Гораздо тревожнее первой Linux-дыры в коде на Rust тот факт, что многие ошибки в ядре Linux могут годами, а иногда и десятилетиями оставаться незамеченными.

Исследовательница Дженни Гуанни Ку из компании Pebblebed проанализировала 125 183 бага за почти 20 лет развития ядра Linux — и результаты оказались, мягко говоря, неожиданными.

 

По данным исследования, средний баг в ядре Linux обнаруживают через 2,1 года после его появления. Но это ещё не предел. Самый «долгоиграющий» дефект — переполнение буфера в сетевом коде — прожил в ядре 20,7 года, прежде чем на него обратили внимание.

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

Исследование опирается на тег Fixes:, который используется в разработке ядра Linux. Когда разработчик исправляет ошибку, он указывает коммит, в котором баг был добавлен. Дженни написала инструмент, который прошёлся по git-истории ядра с 2005 года, сопоставил такие пары коммитов и вычислил, сколько времени баг оставался незамеченным.

В датасет вошли данные до версии Linux 6.19-rc3, охватывающие период с апреля 2005 по январь 2026 года. Всего — почти 120 тысяч уникальных исправлений от более чем 9 тысяч разработчиков.

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

  • CAN-драйверы — в среднем 4,2 года до обнаружения бага;
  • SCTP-стек — около 4 лет;
  • GPU-код — 1,4 года;
  • BPF — всего 1,1 года.

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

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

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

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