Введение
Веб-упаковка предлагает значительные изменения в веб-платформе в способе доставки и аутентификации контента.
С технической точки зрения изменения являются тщательными и продуманными. Существуют некоторые технические затраты, связанные с безопасностью, эксплуатацией и сложностью, но в спецификациях предпринимаются шаги для ограничения большей части этих затрат.
Наиболее разрушительная особенность предложения, замена источника, описывает фундаментальные изменения в архитектуре безопасности Интернета. В дополнение к значительному увеличению сложности, замена источника создает новые углы атаки, которые должны учитывать операторы сайтов, прежде чем они примут эту технологию. Изменения в работе сайтов могут привести к нетривиальным угрозам безопасности.
Основной проблемой является использование веб-упаковки для изменения динамики мощности между агрегаторами и издателями. В настоящий момент мы не понимаем достаточно, чтобы однозначно сказать, что это наносит ущерб системе. Как эта технология используется, имеет значение. Развертывание без систем подотчетности, надзора и ограничений на использование может быть вредным. В предложениях нет ограничений по развертыванию, многое зависит от того, как используется технология и стимулы для ее использования.
В качестве большого набора механизмов существуют отдельные части веб-упаковки, которые могут быть полезны сами по себе, например, разработка общего формата объединения ресурсов. Существуют также способы, с помощью которых использование веб-упаковки может способствовать повышению безопасности и производительности на сайтах.
В целом и, в частности, для замены источника, пока не будет доступно больше информации о влиянии на веб-экосистему, Mozilla приходит к выводу, что для Интернета было бы нецелесообразно развертывать веб-пакеты.
Оглавление
Что такое веб-упаковка?
Почему веб-упаковка?
Автономное распространение
Сторонний дистрибутив
Преимущества веб-упаковки
Опасения по поводу веб-упаковки
Злоумышленник скомпрометировал подписанные биржи
Настройка контента
Уменьшенная персонализация
Вспышка не персонализированного контента
Интересы меньшинств
Создание и использование вариантов контента
Конфиденциальность
Cложность
Производительность
Однородность происхождения
Централизация и контроль
Ресурсный состав атак
Является ли веб-упаковка полезной для Интернета?
Что такое веб-упаковка?
Веб-упаковка — это сочетание технологий:
- Средство подписи HTTP-запроса / ответного обмена. (https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html)
- Формат для объединения нескольких обменов запросами / ответами в один файл. (https://wicg.github.io/webpackage/draft-yasskin-wpack-bundled-exchanges.html)
- Изменения в выборке, поддерживающие возможность обработки подписанного контента как определенного источника. (https://wicg.github.io/webpackage/loading.html)
В сочетании это позволяет сайту создавать пакеты, которые могут быть распространены среди клиентов любым способом. Клиенты смогут отображать ресурсы, содержащиеся в этом пакете, как если бы они были живыми ресурсами в источнике. Эта идея, которую мы называем «заменой источника» — способность представлять контент для источника, не связываясь с этим источником — является центральной проблемой, которую стремится решить веб-упаковка. Замена происхождения также является источником всех возникающих проблем и компромиссов.
Почему веб-упаковка?
Было много дискуссий о двух вариантах использования для веб-упаковки. Веб-упаковка поддерживает распространение контента двумя основными способами: в автономном режиме и сторонними организациями.
Документ вариантов использования описывает много других потенциальных применений, но изучение этих двух случаев является наиболее важным.
Автономное распространение
Первоначально сторонники утверждали, что это в первую очередь для предоставления возможности офлайнового обмена онлайн-контентом. То есть люди смогут загружать веб-страницы (или прогрессивные веб-приложения) и обмениваться ими в автономном режиме одноранговым способом. Получатели этих пакетов могут затем использовать их, не выходя в интернет, ожидая, что, если они действительно перейдут в онлайн, контент будет плавно переходить к полностью подключенному взаимодействию.
Хотя использование сайтов в автономном режиме является достойной целью, более скромная цель сделать контент доступным в автономном режиме, но в отдельном источнике — и, следовательно, без истории перехода к онлайн-опыту, — скорее всего, будет более плодотворным подходом в краткосрочной перспективе. срок, даже если он только инкрементный.
Этот аспект функции рекламируется как возможность распространения цензурированного или нелегального1 контента. Учитывая, что этот вариант использования, как правило, не зависит от привязки к источнику, инкрементальный подход, скорее всего, будет более эффективным.
1На всякий случай, если кто-то считает, что включение подписи может отговорить кого-либо от предоставления нелегального контента в этой форме, помните, что подписи не обеспечивают непризнание. Таким образом, связывание пакетов с подписями не обеспечивает значимого приписывания нелегального контента его источнику.
Сторонний дистрибутив
Второй вариант использования — «распространение контента». Это гораздо более сложный для понимания вариант использования, поскольку он включает в себя сложные отношения между объектами, которые обслуживают страницы, которые ссылаются на контент (агрегаторы, такие как поисковые системы и социальные сети), и теми, которые публикуют этот контент (издатели, такие как сайты журналистики). Ускоренные мобильные страницы Google (AMP), мгновенные статьи Facebook, MIP Baidu и формат новостей Apple — все это примеры агрегаторов, использующих аналогичные методы. Все эти сервисы объединяют контент, опубликованный другими.
Агрегаторы поощряют издателей предоставлять контент, который агрегатор может обслуживать, используя определенные стимулы, такие как лучшее размещение в поиске или варианты представления. Это дает агрегатору ряд существенных преимуществ.
Исходящие ссылки, которые иначе могли бы ссылаться на издателя, а не на контент, размещенный агрегатором. Это позволяет агрегатору предоставлять этот контент пользователям без необходимости связываться с издателем. Агрегатор обычно ограничивает тип и формат контента, который они будут принимать, чтобы они могли более эффективно обрабатывать и размещать контент. Например, это позволяет агрегатору проверять, что контент не содержит вредоносного Javascript, который может представлять опасность для их службы.
Для пользователей агрегатора все это означает, что контент загружается быстрее. Это также означает, что информация об их действиях в агрегаторе передается издателям только при переходе по ссылке. Технически агрегатор имеет полное усмотрение о том, какая информация публикуется, но отказ от таких возможностей, как аналитика, может сделать любую технологию, подобную этой, совершенно нежизнеспособной. Повышение производительности и конфиденциальности являются значительными, но стоимость заключается в том, что источником конечного контента является тот, который контролируется агрегатором, а не издателем.
Основным недостатком этих методов является то, что местом назначения ссылки является страница о происхождении агрегатора. Это приводит к несоответствию между источником контента и идентификацией хоста. Веб-упаковка направлена на решение этой проблемы, предоставляя стандартизированный способ размещения этого контента агрегатором, но представленный в источнике издателя.
Хотя теоретически браузеры могут осуществлять предварительную загрузку непосредственно от издателя для достижения того же прироста производительности, существует несколько причин, по которым предварительная загрузка может быть сложной или менее эффективной. Предварительная загрузка контента от издателя менее эффективна, чем загрузка из агрегатора, поскольку для этого требуются новые подключения, что может значительно увеличить задержку. Браузеры также менее способны автоматически определять кандидатов для предварительной загрузки по множеству ссылок, которые могут быть представлены на странице.
А если серьезно, браузер будет вынужден обменивать прирост производительности на конфиденциальность. Если браузеры предварительно загружают без предоставления информации об источнике ссылки, предварительная загрузка может быть недействительной и непригодной для использования. Попытка обеспечить точность информации может привести к нежелательным побочным эффектам, таким как то, что может произойти при нажатии на ссылку в рекламе. Предотвратить утечку в той же степени, которая обеспечивается размещением контента на агрегаторе, невозможно, поскольку даже самая ограниченная форма предварительной загрузки предоставляет информацию о браузере, включая IP-адрес и характеристики его сетевого стека.
Целью веб-упаковки является предоставление преимуществ в плане производительности и конфиденциальности без смещения источника контента от источника агрегатора. Это достигается тем, что издатель подписывает контент, который может доставлять агрегатор. Этот контент приписывается издателю, но издателю не нужно участвовать в доставке контента.
Непонятно, что выигрывает издатель от этой схемы, кроме снижения затрат на пропускную способность. Мы разберемся с этим вопросом более подробно ниже.
Преимущества веб-упаковки
В документе «Примеры использования» приведен ряд интересных приложений связывания и замены источника, как отдельных примитивов, так и составленных в целом. Самые большие преимущества — это те, которые касаются уже рассмотренных вариантов использования, хотя есть некоторые потенциальные вторичные свойства, которые могут быть полезными.
Возможность связать снимок состояния обменов HTTP предлагает интересные приложения для архивирования, но существующие инструменты предоставляют эту возможность. Подобные критические замечания могут быть направлены на основную часть предложенных вариантов использования.
Отдельные примитивы, замена происхождения и связывание, являются мощными инструментами. Эти инструменты могут быть составлены многими способами, которые могут обеспечить преимущества. Например, возможность иметь происхождение в совокупности свидетельствует об одном совместно используемом контроллере без предварительного контакта с каждым совместно используемым источником, обеспечивает некоторые интересные свойства2.
С точки зрения архитектуры сайта требование идентификации и разделения статического и настраиваемого содержимого может иметь дополнительные преимущества для сайтов, которые берут на себя работу по предоставлению подписанных пакетов. Более четкое разделение статического, сгенерированного пользователем и персонализированного контента может повысить устойчивость к целому ряду атак, включая подделку межсайтовых запросов и атаки на контексты сжатия.
2Эти свойства кажутся ограниченными попыткой убедить браузеры не ограничивать доступ к определенным возможностям, поэтому многое зависит от того, в какой степени контент из разных источников необходим для законных сайтов, в отличие от таких вещей, как отслеживание.
Опасения по поводу веб-упаковки
Первоначальные проблемы Mozilla с веб-упаковкой были сосредоточены на аспектах безопасности при замещении происхождения. То есть способность источника предоставить блоб, который можно получить из любого места, но приписать этому источнику.
Замена происхождения является ключевым элементом этой технологии. Это то, что позволяет автономному контенту плавно переходить в онлайн-контент, и это позволяет агрегатору размещать контент для другого источника.
По своей сути, замена источника позволяет фундаментально изменить работу Интернета. Контент больше не обязан следовать соединениям с источниками, где этот контент создается и где он получается, может полностью отделиться.
Замена источника может быть привлекательным предложением, поскольку она позволяет создавать новые интересные топологии развертывания. Хотя CDN, как правило, проявляют больше презрения, чем интереса к этой идее, CDN может размещать контент для клиентов, не имея возможности выдавать себя за этих клиентов. Ограничение привилегий, которые CDN получает таким образом, может быть привлекательным для клиентов, которые могут захотеть использовать технические меры для сохранения строгого контроля над своим происхождением.
Сосредоточиться на вопросах безопасности сравнительно легко. Согласиться с фундаментальным изменением модели безопасности и доставки контента в Интернете — более сложная задача. Этот документ пытается пойти дальше и исследовать другие потенциально проблемные части в технологии.
Злоумышленник скомпрометировал подписанные биржи
Возможность для злоумышленника скомпрометировать ключ сервера или обманным путем получить сертификат и использовать его для создания поддельного контента для источника жертвы — это новый риск, который добавляет этот дизайн.
Текущий дизайн предусматривает, что только некоторые сертификаты могут быть использованы для подписи бирж. Это означает, что сайту, который не выбирает использование веб-упаковки, не нужно беспокоиться о атаках, использующих веб-упаковку, за исключением возможности ошибочной выдачи сертификата с расширением сертификата.
Целью этих защитных мер является незначительное изменение профиля риска для сайтов, за исключением тех сайтов, которые используют этот механизм. Сертификат, используемый для создания подписанных обменов, может быть отделен от онлайн-ключей, используемых для разрыва соединений3, что означает, что для этих сертификатов может быть возможна более надежная защита. Трудно понять, насколько это будет полезно, поскольку практика использования этих ключей и сертификатов не исчерпана.
3Ничто не мешает использовать этот сертификат для разрыва соединения, так как расширение не является критичным.
Единственной предлагаемой защитой от компрометации или неправильного использования является отзыв сертификата. Для офлайнового потребителя этого контента это вряд ли достигнет их, но, в сущности, ничего нельзя сделать без средств связи. Та же проблема существует для сервисных работников или любой другой технологии, которая может использоваться для перевода контента в автономный режим.
В общих чертах, если злоумышленник получит возможность скомпрометировать пакеты, срок действия пакета ограничивает любую уязвимость. Веб-кеширование и вышеупомянутые сервисные работники уже могут использоваться для выполнения подобных постоянных атак. Там, однако, требования к постоянной повторной проверке ограничивают продолжительность атак. В этом случае атаки могут продолжаться до тех пор, пока получатель не будет знать об отзыве сертификата. 7-дневный лимит на период действия, который соответствует текущим рекомендациям о временах жизни OCSP, может ограничить это, но не обязательно для чисто автономного случая, где эффективной продолжительностью может быть период действия OCSP плюс период действия пакета (при условии использование сшивания).
Обратите внимание, что те же соображения применимы к попыткам искажать старое содержимое как текущее. Это может быть использовано для скомпрометированного контента, такого как контент, который содержит уязвимость, для которой было развернуто исправление, принятый получателями.
Во всех этих случаях онлайновые получатели могут иметь возможность сверяться с источником, но это либо сводит на нет преимущества в производительности и безопасности, либо предоставляет злоумышленнику возможность обойти эту попытку проверки своей атакой. Важным соображением здесь является то, что временное воздействие атаки может быть превращено злоумышленником в постоянную угрозу. Источник может прекратить постоянные атаки, если они осознают необходимость, но он требует, чтобы браузер связался с ними.
Для этих проблем безопасности, несмотря на то, что предлагаемые меры эффективны в рамках ограничений, наложенных требованиями, это представляет собой небольшую регрессию в эффективной безопасности. Получатели пакетов будут уязвимы дольше, чем при использовании прямых подключений к источникам, но этот эффект в значительной степени согласуется с эффектом кэширования или обслуживающего персонала. Сайты, которые не используют этот механизм, не подвержены влиянию ключевых компромиссов, но подвергаются риску из-за ошибок при неправильном использовании. Расширение CAA, определенное в спецификации, частично смягчает это, заставляя злоумышленника перезаписать запись CAA.
Эти недостатки все относительно незначительны. Предлагаемые меры по смягчению имеют большое значение для ограничения потенциальной масштабности и степени серьезности атак, гарантируя, что проблемы примерно эквивалентны другим технологиям, которые уже существуют или находятся в разработке. В целом, они могут быть разумно представлены как компромисс. Сайты согласны использовать этот механизм, и при этом необходимо помнить, что это сопряжено с некоторыми рисками, но при этом они включают новую функцию.
Тогда для безопасности многое зависит от ценностного предложения. Если бы ценность, которую можно было бы реализовать с помощью веб-упаковки, была значительной, это могло бы перевесить эти недостатки.
Настройка контента
Веб-упаковка зависит от вида контента, который является относительно статичным. В идеале, одна страница может быть представлена одним статическим пакетом контента. Для полностью автономного случая это жесткое требование, пакет должен быть готов к использованию всеми потенциальными аудиториями.
Уменьшенная персонализация
Сайты регулярно настраивают контент для отдельных лиц. Многие сайты производят различный контент в зависимости от используемого браузера, форм-фактора устройства, предполагаемого местоположения запрашивающей стороны и таких вещей, как плотность пикселей на экране. Можно создавать пакеты со всеми возможными вариантами содержимого и использовать механизмы на основе браузера, такие как медиазапросы CSS, элемент <picture> или скрипт, для управления выбором правильных вариантов содержимого. Однако это может увеличить размер пакета, что может уменьшить или обратить вспять любой потенциальный выигрыш в производительности.
Степень, в которой отдельный пакет может поддерживать персонализацию, будет зависеть от количества и разнообразия, которые могут быть включены в пакет, не вызывая слишком большого его размера. Если целью является минимизация размера пакета по соображениям производительности, то степень вариации, которую может поддерживать пакет, будет ограничена. Более широкая персонализация может потребовать использования нескольких пакетов. Однако использование нескольких пакетов ограничивает область применения методов адаптации контента на стороне клиента негативными способами. Это дает издателям компромиссы в том, как они создают пакеты.
Уменьшение количества вариантов пакета будет целью по нескольким причинам. Каждый вариант должен быть сгенерирован и подписан отдельно. Это ограничивает количество вариантов, которые можно генерировать, хранить и обслуживать. Поэтому поставщик веб-пакета ограничен в том, какие виды настройки возможны. Хотя некоторые настройки возможны благодаря доступу к хранилищу браузера и предоставлению логики и ресурсов, необходимых в каждом пакете, модель настройки меняется.
Например, издатель может обычно предоставлять различный контент для разных размеров экрана. Если один пакет не может поддерживать адаптацию на стороне клиента, пакеты, предоставляемые агрегатору, должны быть построены на основе того, как агрегатор обслуживает контент в зависимости от размера экрана. Агрегатор должен иметь возможность получать информацию о размере экрана от клиентов и применять эту информацию при выборе правильного пакета. Если издатель взаимодействует с несколькими издателями, то он должен убедиться, что он предоставляет различный набор пакетов для каждого издателя в зависимости от возможностей издателя.
Для масштабируемых ресурсов, таких как изображения, объединение наивысшего качества и использование клиентами возможности масштабирования ресурса для более ограниченных устройств, вероятно, лучше, чем предоставление нескольких копий одного и того же контента. Для этого требуются затраты производительности, если не требуется самый большой размер.
Вспышка не персонализированного контента
Возможно, что проблему персонализации можно частично решить, избегая упаковки содержимого, которое может быть персонализировано. Онлайн-ресурсы используются для предоставления персонализированного контента, когда это возможно, и резервные объекты используются в автономном режиме. Например, может быть предоставлена небольшая версия изображения с любым большим вариантом, запрашиваемым позже, если это возможно. То же самое может быть сделано для видов настройки, которые мы видим в рекламе: может быть предоставлен заглушенный контент с активными соединениями, используемыми для размещения пользовательской рекламы.
Риск создания страниц без настройки заключается в том, что добавление персонализации после загрузки страницы может вызвать неприятные ощущения. Восстановление сведений о пользователе, который вошел в систему на сайте, может привести к необходимости добавлять и удалять элементы страницы или предоставлять новый стиль. Обновление изображений до подходящих, вероятно, менее разрушительно.
Существует множество инструментов, которые можно использовать для управления переходом от общего контента к персонализированной странице, но это представляет собой сложную задачу для тех, кто предоставляет веб-пакет.
Интересы меньшинств
Давление на сокращение количества вариантов контента может привести к вредным вторичным эффектам. Наибольшую обеспокоенность вызывает то, что сайты могут быть приспособлены для меньшинств. Например, до недавнего времени формат изображения WEBP не был широко поддержан браузерами, но он поддерживался браузерами со значительной частью рынка. Сайты, производящие веб-пакеты в такой среде, могут решить, что предоставление изображений в формате JPEG неудобно, поскольку большинство пользователей могут читать более эффективные WEBP.
В некоторой степени это ничем не отличается от существующего давления на представителей меньшинств, но ограничения формата делают давление более острым. Как и в других областях, в той степени, в которой эти недостатки актуальны, отчасти зависит от значения, которое мы могли бы отнести к преимуществам упаковки. Дополнительное наблюдение в этом случае, это ситуация, когда исчисление для браузеров с доминированием на рынке сильно отличается от других.
Создание и использование вариантов контента
Существует проблема при выборе того, что выбирать, когда представлено альтернативное представление ресурсов, или даже если предоставленное представление вообще приемлемо. Нажим сервера HTTP / 2 страдает от меньшей версии той же проблемы. В HTTP / 2 сервер решает, как может выглядеть запрос, когда он генерирует push-запрос сервера. Там у сервера есть другие запросы в том же соединении, чтобы смоделировать эту информацию, поэтому предположение можно настроить.
Создатель веб-пакета не имеет такой информации и поэтому должен полагаться на прогнозы ожидаемых получателей. Таким образом, сайты не могут реагировать на принятие решений, поэтому необходима более высокая осведомленность о технических возможностях их целевой аудитории.
Принимая контент, браузер, который обнаруживает, что пакетный обмен содержит запрос, который существенно отличается от того, что он мог сгенерировать, вынужден сделать трудный выбор: сделать новый запрос или найти способы быть более снисходительными в своих критериях принятия. Работа с вариантами должна помочь этому, предоставляя информацию, которая может позволить браузеру определить, будет ли другой запрос давать другой ответ.
Трудоемкость этого аспекта трудно оценить без опыта. Поскольку это похоже на проблемы, возникающие при принудительном развертывании сервера HTTP / 2, вполне вероятно, что отрасль будет бороться с этим аспектом.
Конфиденциальность
Взаимодействие по HTTPS обеспечивает конфиденциальность как для идентификации ресурса, так и для контента, который в конечном итоге предоставляется. Это свойство не распространяется на веб-упаковку. Сущность, которая предоставляет веб-пакет, получает обе части информации.
Очевидным ограничением является то, что поставщиком контента во многих случаях является также тот, кто предоставляет ссылку. Исходя из этого, поставщик контента не более привилегирован, чем они были бы в противном случае. Уже возможно с помощью обработчиков onclick, переопределения целевых ссылок, перенаправления и API sendBeacon для сбора информации о том, какие ссылки на странице следуют. Контент, который они изучают, будет таким же, как и тот, который они получат, если перейдут по ссылке сами.
Существует небольшой риск утечки из персонализированного и конфиденциального контента, но спецификации накладывают ограничения на использование подписанных обменов, которые ограничивают это. Важно отметить, что они запрещают использование файлов cookie, что является наиболее очевидным способом запроса конфиденциального содержимого. Они также советуют серверам использовать только те ответы, которые имеют значение поля заголовка Cache-Control public. Здесь, наибольший риск, вероятно, от встроенной генерации пакетов, то есть самопроизвольной генерации пакетов в ответ на запросы, содержащие личный контент. Подобные проблемы возникают только в том случае, если сайты не реализуют достаточно очевидные и хорошо документированные меры безопасности.
Исходя из этого, использование веб-упаковки не представляет значительно повышенного риска для конфиденциальности, если издатели осторожно применяют ее.
Cложность
Значительные усилия были вложены в создание простой веб-упаковки, что отражено в дизайне. Проекты во многом улучшены по сравнению с более ранними итерациями.
Тем не менее, это представляет собой полностью параллельную систему для защиты веб-контента. Хотя для аутентификации здесь используется инфраструктура Web PKI, средства доставки контента совершенно новые. Это естественно означает дополнительную сложность платформы.
Это общее дизайнерское пространство не ново. SHTTP был предложен примерно в то же время, что и HTTPS. Хотя есть некоторые аспекты дизайна SHTTP, которые, вероятно, в настоящее время являются избыточными (например, оставляя некоторые метаданные незащищенными), он имеет определенное сходство с веб-упаковкой. Частью привлекательности HTTPS через SHTTP была простота HTTPS: вы просто добавили слой TLS (или SSL) в стек, который обрабатывал все сложные биты безопасности, такие как аутентификация, шифрование, анти-воспроизведение, проверки живучести и все тот.
Веб-упаковка нацелена на более ограниченный набор свойств безопасности, чем SHTTP, но тем не менее она наследует большую часть своей сложности.
Как и с другими соображениями, сложность не является сильной основой для отклонения функции. Но это говорит о необходимости тщательного рассмотрения. Сложные функции создают больше ошибок и расширяют профиль риска для проблем безопасности.
Производительность
Подписанные обмены требуют значительно больше вычислительных усилий, чем типичный ресурс. Как правило, стоимость более дорогих криптографических операций, таких как подписывание и обмен ключами, амортизируется на нескольких биржах. Здесь каждый ресурс требует независимой проверки подписи.
Подписи также добавляют нетривиальное число байтов к каждому подписанному обмену. Наименьшая известная схема подписи добавляет 32 байта к каждому обмену, хотя большинство из них, по крайней мере, вдвое больше, плюс накладные расходы. Для контента, который подходит для подписи, можно предположить, что это все общедоступный контент, и поэтому обычные проблемы смешивания общедоступных данных с секретными данными при сжатии не применяются. Это позволяет использовать сжатие через обмены в связке, так что фиксированные накладные расходы могут быть значительно уменьшены.
Ожидается, что подписание будет нечастым и офлайн. Следовательно, затраты на производительность для издателя амортизируются по многим видам использования одного и того же пакета, поэтому добавленная стоимость является приемлемой. Единственным потенциальным источником дополнительных вычислительных затрат является подписание и поддержка различных вариантов пакетов.
Более значительными являются издержки хранения для издателей и агрегаторов. Если имеется несколько страниц, для каждой страницы потребуется один или несколько пакетов, в зависимости от количества вариантов, предоставляемых сайтом, которые потенциально могут быть увеличены для агрегаторов с различными возможностями. Каждый пакет будет содержать копии общих ресурсов, таких как CSS, скрипт и изображения. Без дедупликации это может увеличить стоимость хранения контента. Преимущество данной схемы заключается в том, что дедупликацию такого рода относительно просто выполнить, а затраты на дополнительную сложность в основном несут агрегаторы.
В целом, увеличение вычислительных затрат для клиентов, вероятно, терпимо, но должно быть проверено. Увеличение размера ресурсов может быть нейтрализовано более эффективным использованием сжатия. Стоимость для издателей незначительна, и мы будем предполагать, что в этих целях участие будет дискреционным.
Однородность происхождения
Дизайн веб-упаковки предполагает, что происхождение является единым. Невозможно развернуть подписанные обмены с ключом, который свидетельствует только о подмножестве ресурсов в источнике. Это может быть несовместимо со стратегиями развертывания сайта, которые полагаются на централизованный контроллер (объект, на котором работает HTTP-сервер), чтобы управлять тем, кто подписывает различные ресурсы.
Если есть взаимно недоверчивые сущности, которые имеют одинаковое происхождение — плохая идея, но тем не менее все еще практикуются — тогда на подписанных обменах не будет средств контроля, которые бы препятствовали заявкам заявлять о ресурсах, которые они не контролируют. Это, вероятно, вопрос для операторов серверов для управления; если существуют взаимно недоверчивые сущности, имеющие общий источник, было бы неразумно разрешать обмены с подписью. Автономный ключ подписи может все еще использоваться для некоторых ресурсов.
Централизация и контроль
Вполне возможно, что эта технология дает агрегаторам лучшие средства управления контентом. Существующие технологии демонстрируют, что эта мощность уже существует, поэтому вопрос в том, изменит ли это каким-либо образом динамику мощности.
Можно утверждать, что существующее использование хостинга агрегатора строго хуже, чем предлагаемая система. Предлагаемая система может позволить агрегаторам накладывать меньше ограничений на то, что они могут размещать, поскольку контент больше не размещается в их домене. Это может дать издателям больший контроль над тем, какой контент получает доступ к лучшему обращению от агрегаторов.
Маловероятно, что агрегаторы будут размещать произвольный контент для этой цели из соображений безопасности (например, перехват контента представляет определенные риски), репутации или из-за более практических проблем, таких как объем требуемого хранилища.
Это, пожалуй, самый сложный вопрос для оценки во всем этом пространстве. Представляет ли эта технология пользу для издателей? Или же они могут получить выгоду от стимулов, которые могут предложить агрегаторы (например, улучшенное размещение или видимость)?
В какой степени это является применением силы, которой обладают агрегаторы, власти, которая основана на их способности контролировать, видит ли и как их аудитория ссылку на издателей?
Ясно, что агрегаторы имеют право отказа. Они могут отказаться от ссылки на сайт или отказать в размещении контента, который не соответствует их стандартам. Без веб-упаковки этот отказ может основываться на необходимости предотвращения вмешательства вредоносного контента в источник агрегатора и источник других издателей. Но может ли агрегатор отказаться от обслуживания контента, который, например, не соответствует определенным критериям производительности?
Какие элементы управления гарантируют, что эта сила используется ответственно? Мы уже видим способы, которыми поисковые системы осуществляют политическую власть, уменьшая видимость определенных результатов или полностью исключая их. Например, сайты с плохой производительностью или безопасностью лишены приоритетов в результатах. Хотя мы можем рассматривать эти конкретные варианты как добродетельные, они не являются нейтральными в отношении ценностей. Они являются проявлением власти над другими пользователями сети.
Мы не знаем, что люди думают об этом конкретном аспекте этой технологии. Многое может зависеть от того, как оно используется.
Ресурсный состав атак
Фундаментальное изменение архитектуры безопасности в сети меняет способ построения систем. Добавление этой функции требует, чтобы сайты учитывали новые варианты атаки.
Контроль над составом ресурсов создает некоторые возможности для злоумышленников, которых нет в текущей системе.
Рассмотрим случай, когда критическая проверка безопасности перемещается из ресурса A в ресурс B как часть изменения в системе. В результате существует набор ресурсов, где проверка безопасности вообще не существует (версия 2 A с версией 1 B). Если эти ресурсы являются частью подписанных обменов, злоумышленник может заставить браузер использовать эту конфигурацию системы.
Аналогично, контент с уязвимостями безопасности, который подписан, может быть предоставлен клиентам после того, как проблема будет устранена. Это позволяет злоумышленникам расширять доступность ошибок нулевого дня, позволяя использовать эту ошибку в течение всего срока действия содержимого.
Для них ответ сторонников веб-упаковки, как правило, заключался в том, чтобы определить, каким образом эти проблемы существуют в нынешней системе. Например, несовместимые версии ресурсов могут обслуживаться существующими системами во время обновлений. Кэширование может сделать это больше, чем временная ситуация. Кеширование также может привести к тому, что контент, содержащий уязвимости безопасности, будет сохраняться дольше, чем это было бы идеально.
Критическое различие между существующей системой и предлагаемой системой подписанных обменов заключается в степени влияния злоумышленника на ситуацию. В текущей сети источник может контролировать время развертывания и настройки кэша, чтобы избежать наличия несовместимых / несовпадающих ресурсов. Подписанные обмены дают злоумышленнику полный контроль над составом ресурсов, тогда как степень влияния злоумышленника на состав ресурсов ограничена.
Важно отметить, что автономный получатель не имеет права использовать подписанный контент. Системы отзыва работают только для онлайн-клиентов. Представленный аргумент заключается в том, что кэширование — и, в частности, работники сферы обслуживания — может привести к сохранению этой ситуации способами, очень похожими на веб-упаковку. Этот аргумент говорит о том, что ограничения на валидность для кэширующих и сервисных работников более слабые, чем в предлагаемой системе, поэтому она потенциально хуже. Теория заключается в том, что характеристики согласия в основном схожи, если злоумышленник может запретить активный доступ к серверам.
Веб-упаковка позволяет перейти от практически случайного воздействия на злоумышленника. Для клиента с активным подключением уязвимости безопасности сохраняются только до повторной проверки уязвимых ресурсов (или до вызова данных сайта). Таким образом, мы приходим к выводу, что это меняет профиль риска для сайтов, которые подписываются на подписывание ресурсов.
Такой стиль атаки может побудить сайты перейти на более эффективную модель управления составом ресурсов. Например, перемещение новых версий контента на новые URL-адреса не позволяет злоумышленнику контролировать состав, как описано. Хотя это может потребовать значительной реструктуризации сайтов и противоречит давним советам относительно стабильности идентификатора, оно имеет некоторые преимущества для производительности и безопасности, даже если подписанные обмены не используются.
Является ли веб-упаковка полезной для Интернета?
С веб-упаковкой можно многое рассмотреть. Многие из технических проблем относительно незначительны. Есть проблемы с безопасностью, но большинство из них хорошо управляемы. Есть эксплуатационные проблемы, но они могут быть преодолены. Это сложное дополнение к платформе, но мы можем оправдать усложнение в обмен на значительные выгоды.
Остается вопрос о том, представляет ли это фундаментальное изменение в способе доставки контента в Интернете проблематичное изменение баланса сил между участниками. Мы должны рассмотреть, могут ли агрегаторы использовать эту технологию, чтобы навязать свою волю издателям.
Несомненно, веб-упаковка оказывает давление на консолидацию доли рынка несколькими тревожными способами. Это дает стимул для поддержки большинства клиентов за счет меньшинств. Это увеличивает стоимость предоставления исходящих ссылок на небольших сайтах за счет повышения производительности и конфиденциальности исходящих ссылок на сайтах, которые выполняют агрегацию на основе пакетов.
Сайты получают значительный стимул для развертывания технологии. Однако этот стимул снижает затраты на сопутствующую деятельность и повышает вероятность возникновения новых проблем безопасности, связанных с развертыванием. Существуют некоторые инструменты, которые помогают в создании функции веб-упаковки, но они также не способны обеспечить какие-либо структурные изменения в архитектуре сайта, которые потребуются для поддержки перехода к безопасному обеспечению замены источника.
Большие изменения нуждаются в сильном обосновании и поддержке. Это конкретное изменение больше, чем большинство и представляет ряд проблем. Повышенная подверженность проблемам безопасности и неизвестное влияние этого на динамику мощности достаточно значительны, поэтому мы должны рассматривать это как вредное, пока не появится больше информации.
Мы активно работаем, чтобы лучше понять эту технологию. Совет по архитектуре Интернета организует семинар, целью которого является сбор информации по более важным вопросам. Этот семинар специально организован для сбора информации от издательского сообщества. Технические детали предложения также будут обсуждаться на предстоящих заседаниях IETF. Основываясь на том, что мы узнали через эти процессы и на собственном исследовании, мы могли бы пересмотреть эту позицию.
В дополнение к этому, любая оценка должна учитывать не только вред, но и сопоставлять выгоды с затратами. Это технически сложный набор изменений в веб-платформе. Оценивая ценность, мы должны видеть, какие выгоды реализуются, кем и чтобы лучше понять, кто несет расходы.
