Google выпустила первую тестовую версию Privacy Sandbox на Android 13

Google выпустила первую тестовую версию Privacy Sandbox на Android 13

Google выпустила первую тестовую версию Privacy Sandbox на Android 13

Google выпустила первую тестовую версию Privacy Sandbox для разработчиков приложений под Android 13. Нововведение должно повысить конфиденциальность пользователей мобильных устройств.

Этот же принцип — Privacy Sandbox — распространяется на браузер Google Chrome. Задача — обеспечить межсайтовое взаимодействие без использования сторонних файлов cookies и других видов трекинга.

«Privacy Sandbox будет тестироваться в рамках программы Android Developer Preview на протяжении всего 2022 года, а запуск публичной бета-версии планируется в конце этого года», — пишет интернет-гигант.

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

О своих планах реализовать принцип Privacy Sandbox в Android Google рассказывала ещё в феврале. Корпорация при этом пообещала учитывать потребности не только пользователей, но и рекламных компаний с разработчиками.

Два ключевых компонента являются неотъемлемой частью инициативы:

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

Опасная уязвимость в GNU Wget2 позволяет удалённо перезаписывать файлы

В популярном консольном загрузчике GNU Wget2 обнаружили серьёзную уязвимость, которая позволяет злоумышленникам перезаписывать файлы на компьютере жертвы — без её ведома и согласия. Проблема получила идентификатор CVE-2025-69194 и высокую степень риска — 8,8 балла по CVSS, то есть игнорировать её точно не стоит.

Брешь связана с обработкой Metalink-файлов — это специальные документы, в которых описано сразу несколько источников для скачивания одного и того же файла (зеркала, P2P и так далее).

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

Из-за ошибки в проверке путей злоумышленник может подготовить вредоносный Metalink-файл с «хитрыми» именами вроде ../. Это классическая уязвимость path traversal: она позволяет выйти за пределы рабочего каталога и записать файл практически в любое место в системе. Достаточно, чтобы пользователь просто обработал такой металинк — и дальше всё происходит без его участия.

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

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

Да, атака требует взаимодействия с вредоносным файлом, но с учётом последствий риск выглядит более чем реальным — особенно для тех, кто регулярно использует Wget2 в автоматизированных сценариях или CI/CD-пайплайнах.

Если вы работаете с Wget2 и Metalink, сейчас самое время внимательно отнестись к источникам загрузки и следить за выходом обновлений. В этой истории один неосторожный файл может стоить слишком дорого.

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