Кратко

  • В опубликованной 22 сентября редакции проекта Threat Model for the Web группа W3C Security Interest Group отдельно показывает среду документа и источника, управляемое браузером посредничество, запрос к API и возвращаемый результат, событие либо ошибку.
  • Днём ранее верхняя схема изображала пользовательский агент единым абстрактным процессом. Новая схема остаётся логической и не предписывает архитектуру Chromium, Gecko или WebKit.
  • По журналу вызовов страницы нельзя автоматически установить факт выдачи разрешения или место его принудительного исполнения. Это вывод для редакционного анализа, а не новое правило соответствия W3C.

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

Редакция проекта от 22 сентября меняет именно способ постановки вопроса. На верхнем уровне L0 процесс PO-02 обозначает документ и контекст исполнения, связанный с веб-источником. PO-01 — логическое посредничество под контролем браузера. Поток DF-05 несёт вызов API с параметрами от первого ко второму; DF-06 возвращает значение, завершение обещания, событие, состояние или ошибку. TB-02 обозначает абстрактное семейство границ между полномочиями источников и контекстов. Пользователь и удалённый сервис представлены отдельно от этого обмена.

Чтобы оценить степень новизны, следует сопоставить проект с версией 21 сентября. Тогда L0 показывал пользовательский агент как один процесс P0, браузерное состояние как S0 и более общие потоки к сайту, сети и операционной системе. Однако прежний текст уже объяснял необходимость подробной модели браузера для вопросов о разрешениях, хранении состояния и месте контроля. Поэтому нынешняя редакция не открыла новую категорию риска. Она перенесла обмен запросом и ответом через границу документа и браузера в первую схему, с которой начинается обзор.

Нижний уровень документа разбирает привилегированные функции браузера, исполнение недоверенного веб-контента, хранилища разрешений и пути к сети, хранилищу и ресурсам ОС. Такая разбивка помогает не приравнивать проверку внутри контента к проверке у компонента с реальными полномочиями. Но реализация различается между продуктами. Сам проект предупреждает, что L0 не утверждает фактических процессных границ Chromium, Gecko и WebKit. По нему нельзя удостоверить безопасность какой-либо версии браузера.

Статус источника также не следует расширять. Это проект групповой заметки, поддержанный Security Interest Group, но не одобренный W3C в целом и его членами. История публикаций начинается 26 мая 2026 года. Разделы анализа угроз и мер защиты ещё помечены как незавершённые. Проект не сообщает об уязвимости конкретного браузера, проведённой проверке или новой обязательной процедуре выдачи разрешений.

Практическое значение рисунка — в раздельном учёте попытки страницы, решения браузера, ответа странице и доказательств того, где решение действительно исполняется. Модель помогает увидеть пропуск в цепочке; заполнить его может только исследование конкретной реализации.

Источники