Permissions Policy, возможности браузера и приватность

BotBrowser может повторить авторизованный браузерный сценарий в объявленном контексте и наблюдать видимый результат. Он не пишет и не разворачивает политику, не выдаёт разрешения, не создаёт устройство и не доказывает удалённую запись. Политика разрешений браузера ограничивает доступные документу возможности. Ответ верхнего документа задаёт предел, а allow у iframe делегирует функцию дочернему origin. Это граница возможности, а не разрешение пользователя, гарантия устройства или доказательство завершения операции. Руководство опирается на спецификацию W3C и справочник MDN.

TL;DR

Используйте минимальный список функций и origins, проверяйте конечный origin после redirect, согласуйте заголовок и allow, а затем сравнивайте собственные control/candidate fixture. Даже разрешённому frame могут быть недоступны API, безопасный контекст, жест пользователя, разрешение, устройство или подтверждение приложения. BotBrowser повторяет авторизованный браузерный сценарий и наблюдает видимый результат; он не пишет и не разворачивает политику, не выдаёт разрешения, не создаёт устройство и не доказывает удалённую запись.

Contents

• Что контролирует политика
• Разделяйте этапы возможности
• Различайте связанные политики
• Воспроизводимый fixture
• Практический вывод

Что контролирует политика

Permissions-Policy: geolocation=(self "https://widget.example") разрешает странице и указанному widget попытаться получить геолокацию. iframe всё равно нужен allow="geolocation", а каждый предок должен сохранять делегирование. Redirect на другую схему, хост или порт меняет конечный origin. Значения по умолчанию зависят от функции.

Не используйте allow="*" для удобства: функция будет делегирована любому origin в контейнере, включая неожиданный redirect. Храните явный allowlist, назначьте владельцев заголовка и разметки, удаляйте запись после окончания интеграции. Дочерний документ не может вернуть функцию, удалённую предком.

Допуск политикой не равен состоянию разрешения. navigator.permissions может быть prompt или granted, пока frame заблокирован. Возможны отказ, timeout, отсутствие устройства и ошибка браузера. Фиксируйте первый не пройденный этап.

Разделяйте этапы возможности

Этап	Доказательство	Что не доказывает успех
Конечный origin и контекст	URL, схема, порт, secure context	Наличие API
Возможность API	Узкая проверка интерфейса	Разрешение запроса
Политика разрешений	Заголовок, allow, предки, дочерний origin	Согласие или устройство
Решение пользователя/платформы	Разрешение, настройка администратора, устройство	Приём данных приложением
Результат приложения	Видимый статус или ограниченное подтверждение	Запись на сервере

Пусть дочерний frame сообщает собственный origin и состояние через тестовую страницу. Используйте стабильные синтетические разрешения; не собирайте координаты, медиа, учётные данные или содержимое аккаунта.

Различайте связанные политики

CSP управляет загрузкой скриптов, соединений, ресурсов и frame. COOP определяет отношения верхних контекстов. COEP задаёт условия для cross-origin ресурсов. Ни один из них не делегирует камеру или геолокацию, а политика разрешений не создаёт изоляцию cross-origin и не заменяет CORS/CORP.

Сначала проверьте сеть и CSP, затем конечный origin и нужное состояние COOP/COEP, потом цепочку политики разрешений и только после этого запрашивайте функцию, требующую действия пользователя. Сетевая ошибка, блокировка политики, отказ и ошибка приложения принадлежат разным владельцам. Ни один заголовок не заменяет серверную авторизацию, согласие, проверку входных данных или управление устройством.

Воспроизводимый fixture

Разместите на собственном host /fixtures/permissions-policy/control.html и candidate.html. Оставьте одинаковыми route, frame, кнопку и маркер; только candidate получает предлагаемый заголовок. После явного клика дочерняя страница показывает policy=blocked или policy=allowed. Это лишь маркеры приложения, а не самостоятельное свидетельство браузера: дополнительно проверьте доставленный заголовок Permissions-Policy, атрибут allow и конечный origin дочерней страницы.

import { test, expect } from '@playwright/test';
const cases = [
  { name: 'control', url: 'https://qa.example.test/fixtures/permissions-policy/control.html', expected: 'blocked' },
  { name: 'candidate', url: 'https://qa.example.test/fixtures/permissions-policy/candidate.html', expected: 'allowed' },
];
for (const scenario of cases) {
  test(`Permissions Policy ${scenario.name}`, async ({ page }) => {
    let response;
    try {
      response = await page.goto(scenario.url, { waitUntil: 'domcontentloaded', timeout: 8000 });
    } catch (error) {
      throw new Error(`NETWORK_ERROR до проверки политики: ${error.message}`);
    }
    expect(response?.ok(), `HTTP-ответ ${scenario.name}`).toBeTruthy();
    await page.getByRole('button', { name: 'Request location' }).click();
    await expect(page.getByTestId('policy-result')).toHaveText(new RegExp(`^${scenario.expected}$`), { timeout: 5000 });
  });
}

Ошибки DNS, сертификата, HTTP и отсутствующего route остаются NETWORK_ERROR, а не превращаются в успешный blocked. Timeout означает отсутствие свидетельства в заданное время, а не отказ браузера. Закройте context и удалите временные данные. Fixture доказывает только заявленные браузер и маршрут.

Для приватности используйте синтетические разрешения и временные значения, не записывайте координаты, медиа, cookie или содержимое аккаунта. Первый сбой определяет владельца: сеть и заголовок относятся к инфраструктуре, цепочка политики к владельцу embed, отказ к согласию пользователя, а ошибка после API к приложению. Сохраните прежние заголовок и разметку для отката; после изменения повторите тот же маршрут, состояние разрешений и проверку.

Итог: практический вывод

В контракте embed укажите origins, функцию, цель, действие пользователя, резервный путь и владельца. Повторяйте fixture после изменения host, redirect, браузера или вложенного frame. Сохраняйте только значения политики, origins, версию, маркеры и видимые результаты.

BotBrowser может повторить авторизованный сценарий в заданном browser context. Он не меняет Permissions-Policy, origins iframe, пользовательские разрешения, устройства, CSP/COOP/COEP, ответы поставщика и не доказывает удалённую бизнес-операцию. Авторитетом остаются доставленный ответ и серверные записи приложения. См. руководство CSP и руководство cross-origin isolation.

Источники

• W3C: политика разрешений
• MDN: политика разрешений
• MDN: iframe allow
• MDN: CSP
• MDN: COOP
• MDN: COEP
• BotBrowser: расширенные функции

Команда BotBrowser