Хранение и файлы cookie

Расширения могут хранить файлы cookie и получать доступ к API веб-хранилища аналогично обычному веб-сайту. Однако в некоторых случаях в расширениях эти функции работают иначе.

Информацию об API расширений см. в browser.storage .

Хранилище

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

Упорство

При очистке данных браузера хранилище расширений не очищается. Это относится ко всем данным, хранящимся с использованием API веб-хранилища (таких как Local Storage и IndexedDB ).

По умолчанию на расширения распространяются обычные квоты на хранилище, которые можно проверить, вызвав метод navigator.storage.estimate() . Хранилище также может быть освобождено при сильной нехватке памяти, хотя это случается редко. Чтобы этого избежать:

  • Запросите разрешение "unlimitedStorage" , которое влияет как на API расширений, так и на API веб-хранилища и освобождает расширения от ограничений квот и вытеснения.
  • Для защиты от вытеснения используйте метод navigator.storage.persist() .

Хранилище расширения используется совместно всеми компонентами расширения, включая службу расширения, любые страницы расширения (включая всплывающие окна и боковую панель) и документы, находящиеся за пределами экрана. В скриптах контента вызов API веб-хранилища обращается к данным со страницы-хоста, на которую внедрен скрипт контента, а не из самого расширения.

Доступ к работникам сферы услуг

API IndexedDB и Cache Storage доступны в сервис-воркерах. Однако Local Storage и Session Storage недоступны.

Если вам необходимо получить доступ к локальному хранилищу или хранилищу сессий из сервис-воркера, используйте документ, находящийся вне экрана .

Разделение

Разделение данных на разделы (партиционирование) — это процесс введения ключей для хранения данных с целью ограничения доступа к ним. Исторически сложилось так, что хранение данных осуществлялось по принципу «ключ — источник».

Начиная с Chrome 115, функция разделения хранилища вносит изменения в определение ключей разделения, чтобы предотвратить определенные типы отслеживания между сайтами. На практике это означает, что если сайт A встраивает iframe, содержащий сайт B, сайт B не сможет получить доступ к тому же хранилищу, которое он обычно имел бы при прямом переходе на него.

Для смягчения последствий этого в расширениях применяются два исключения:

  • Если страница со схемой chrome-extension:// встроена в какой-либо сайт, разделение хранилища не будет применяться, и расширение будет иметь доступ к своему разделу верхнего уровня.
  • Если страница со схемой chrome-extension:// содержит iframe, и расширение имеет права доступа к хосту сайта, который оно встраивает, то этот сайт также будет иметь доступ к его разделу верхнего уровня.

Печенье

Файлы cookie позволяют хранить пары ключ-значение, связанные с определенным доменом и путем. В расширениях их ценность ограничена, но понимание их поведения может быть полезно, если у вас есть конкретный сценарий использования или вы включили сторонний скрипт, который использует их в своей реализации.

Защищенные файлы cookie

Атрибут Secure cookie поддерживается только для схемы https:// . Следовательно, страницы chrome-extension:// не могут устанавливать cookie с этим атрибутом.

Это также означает, что страницы расширений не могут использовать другие атрибуты cookie там, где требуется атрибут Secure :

Разделение на разделы и поведение SameSite

Файлы cookie, установленные на страницах chrome-extension://, всегда используют SameSite=Lax . Следовательно, файлы cookie, установленные расширением на собственном ресурсе, никогда не будут доступны во фреймах, и разделение ресурсов не имеет значения.

Файлы cookie, связанные со сторонними сайтами, например, со сторонним сайтом, загруженным во фрейме на странице расширения, или с запросом, отправленным со страницы расширения на сторонний ресурс, ведут себя так же, как и веб-сайт, за исключением двух моментов:

  • Сторонние файлы cookie никогда не блокируются, даже во вложенных окнах, если страница верхнего уровня для данной вкладки является страницей chrome-extension:// .
  • Запросы от расширения к стороннему сервису обрабатываются как запросы внутри одной сети, если расширение имеет права доступа к этой сторонней организации. Это означает, что могут отправляться cookie-файлы с параметром SameSite=Strict . Обратите внимание, что это относится только к сетевым запросам, а не к доступу через document.cookie в JavaScript, и не применяется, если cookie-файлы сторонних сервисов заблокированы.

Обратите внимание, что настройки, касающиеся сторонних файлов cookie, затрагиваются работой в рамках «Песочницы конфиденциальности» и корректируются в соответствии с графиком ее реализации .

API browser.cookies предоставляет возможность управлять ключом раздела, используемым с каждым методом API. Для получения дополнительной информации см. справочник API .

,

Расширения могут хранить файлы cookie и получать доступ к API веб-хранилища аналогично обычному веб-сайту. Однако в некоторых случаях в расширениях эти функции работают иначе.

Информацию об API расширений см. в browser.storage .

Хранилище

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

Упорство

При очистке данных браузера хранилище расширений не очищается. Это относится ко всем данным, хранящимся с использованием API веб-хранилища (таких как Local Storage и IndexedDB ).

По умолчанию на расширения распространяются обычные квоты на хранилище, которые можно проверить, вызвав метод navigator.storage.estimate() . Хранилище также может быть освобождено при сильной нехватке памяти, хотя это случается редко. Чтобы этого избежать:

  • Запросите разрешение "unlimitedStorage" , которое влияет как на API расширений, так и на API веб-хранилища и освобождает расширения от ограничений квот и вытеснения.
  • Для защиты от вытеснения используйте метод navigator.storage.persist() .

Хранилище расширения используется совместно всеми компонентами расширения, включая службу расширения, любые страницы расширения (включая всплывающие окна и боковую панель) и документы, находящиеся за пределами экрана. В скриптах контента вызов API веб-хранилища обращается к данным со страницы-хоста, на которую внедрен скрипт контента, а не из самого расширения.

Доступ к работникам сферы услуг

API IndexedDB и Cache Storage доступны в сервис-воркерах. Однако Local Storage и Session Storage недоступны.

Если вам необходимо получить доступ к локальному хранилищу или хранилищу сессий из сервис-воркера, используйте документ, находящийся вне экрана .

Разделение

Разделение данных на разделы (партиционирование) — это процесс введения ключей для хранения данных с целью ограничения доступа к ним. Исторически сложилось так, что хранение данных осуществлялось по принципу «ключ — источник».

Начиная с Chrome 115, функция разделения хранилища вносит изменения в определение ключей разделения, чтобы предотвратить определенные типы отслеживания между сайтами. На практике это означает, что если сайт A встраивает iframe, содержащий сайт B, сайт B не сможет получить доступ к тому же хранилищу, которое он обычно имел бы при прямом переходе на него.

Для смягчения последствий этого в расширениях применяются два исключения:

  • Если страница со схемой chrome-extension:// встроена в какой-либо сайт, разделение хранилища не будет применяться, и расширение будет иметь доступ к своему разделу верхнего уровня.
  • Если страница со схемой chrome-extension:// содержит iframe, и расширение имеет права доступа к хосту сайта, который оно встраивает, то этот сайт также будет иметь доступ к его разделу верхнего уровня.

Печенье

Файлы cookie позволяют хранить пары ключ-значение, связанные с определенным доменом и путем. В расширениях их ценность ограничена, но понимание их поведения может быть полезно, если у вас есть конкретный сценарий использования или вы включили сторонний скрипт, который использует их в своей реализации.

Защищенные файлы cookie

Атрибут Secure cookie поддерживается только для схемы https:// . Следовательно, страницы chrome-extension:// не могут устанавливать cookie с этим атрибутом.

Это также означает, что страницы расширений не могут использовать другие атрибуты cookie там, где требуется атрибут Secure :

Разделение на разделы и поведение SameSite

Файлы cookie, установленные на страницах chrome-extension://, всегда используют SameSite=Lax . Следовательно, файлы cookie, установленные расширением на собственном ресурсе, никогда не будут доступны во фреймах, и разделение ресурсов не имеет значения.

Файлы cookie, связанные со сторонними сайтами, например, со сторонним сайтом, загруженным во фрейме на странице расширения, или с запросом, отправленным со страницы расширения на сторонний ресурс, ведут себя так же, как и веб-сайт, за исключением двух моментов:

  • Сторонние файлы cookie никогда не блокируются, даже во вложенных окнах, если страница верхнего уровня для данной вкладки является страницей chrome-extension:// .
  • Запросы от расширения к стороннему сервису обрабатываются как запросы внутри одной сети, если расширение имеет права доступа к этой сторонней организации. Это означает, что могут отправляться cookie-файлы с параметром SameSite=Strict . Обратите внимание, что это относится только к сетевым запросам, а не к доступу через document.cookie в JavaScript, и не применяется, если cookie-файлы сторонних сервисов заблокированы.

Обратите внимание, что настройки, касающиеся сторонних файлов cookie, затрагиваются работой в рамках «Песочницы конфиденциальности» и корректируются в соответствии с графиком ее реализации .

API browser.cookies предоставляет возможность управлять ключом раздела, используемым с каждым методом API. Для получения дополнительной информации см. справочник API .

,

Расширения могут хранить файлы cookie и получать доступ к API веб-хранилища аналогично обычному веб-сайту. Однако в некоторых случаях в расширениях эти функции работают иначе.

Информацию об API расширений см. в browser.storage .

Хранилище

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

Упорство

При очистке данных браузера хранилище расширений не очищается. Это относится ко всем данным, хранящимся с использованием API веб-хранилища (таких как Local Storage и IndexedDB ).

По умолчанию на расширения распространяются обычные квоты на хранилище, которые можно проверить, вызвав метод navigator.storage.estimate() . Хранилище также может быть освобождено при сильной нехватке памяти, хотя это случается редко. Чтобы этого избежать:

  • Запросите разрешение "unlimitedStorage" , которое влияет как на API расширений, так и на API веб-хранилища и освобождает расширения от ограничений квот и вытеснения.
  • Для защиты от вытеснения используйте метод navigator.storage.persist() .

Хранилище расширения используется совместно всеми компонентами расширения, включая службу расширения, любые страницы расширения (включая всплывающие окна и боковую панель) и документы, находящиеся за пределами экрана. В скриптах контента вызов API веб-хранилища обращается к данным со страницы-хоста, на которую внедрен скрипт контента, а не из самого расширения.

Доступ к работникам сферы услуг

API IndexedDB и Cache Storage доступны в сервис-воркерах. Однако Local Storage и Session Storage недоступны.

Если вам необходимо получить доступ к локальному хранилищу или хранилищу сессий из сервис-воркера, используйте документ, находящийся вне экрана .

Разделение

Разделение данных на разделы (партиционирование) — это процесс введения ключей для хранения данных с целью ограничения доступа к ним. Исторически сложилось так, что хранение данных осуществлялось по принципу «ключ — источник».

Начиная с Chrome 115, функция разделения хранилища вносит изменения в определение ключей разделения, чтобы предотвратить определенные типы отслеживания между сайтами. На практике это означает, что если сайт A встраивает iframe, содержащий сайт B, сайт B не сможет получить доступ к тому же хранилищу, которое он обычно имел бы при прямом переходе на него.

Для смягчения последствий этого в расширениях применяются два исключения:

  • Если страница со схемой chrome-extension:// встроена в какой-либо сайт, разделение хранилища не будет применяться, и расширение будет иметь доступ к своему разделу верхнего уровня.
  • Если страница со схемой chrome-extension:// содержит iframe, и расширение имеет права доступа к хосту сайта, который оно встраивает, то этот сайт также будет иметь доступ к его разделу верхнего уровня.

Печенье

Файлы cookie позволяют хранить пары ключ-значение, связанные с определенным доменом и путем. В расширениях их ценность ограничена, но понимание их поведения может быть полезно, если у вас есть конкретный сценарий использования или вы включили сторонний скрипт, который использует их в своей реализации.

Защищенные файлы cookie

Атрибут Secure cookie поддерживается только для схемы https:// . Следовательно, страницы chrome-extension:// не могут устанавливать cookie с этим атрибутом.

Это также означает, что страницы расширений не могут использовать другие атрибуты cookie там, где требуется атрибут Secure :

Разделение на разделы и поведение SameSite

Файлы cookie, установленные на страницах chrome-extension://, всегда используют SameSite=Lax . Следовательно, файлы cookie, установленные расширением на собственном ресурсе, никогда не будут доступны во фреймах, и разделение ресурсов не имеет значения.

Файлы cookie, связанные со сторонними сайтами, например, со сторонним сайтом, загруженным во фрейме на странице расширения, или с запросом, отправленным со страницы расширения на сторонний ресурс, ведут себя так же, как и веб-сайт, за исключением двух моментов:

  • Сторонние файлы cookie никогда не блокируются, даже во вложенных окнах, если страница верхнего уровня для данной вкладки является страницей chrome-extension:// .
  • Запросы от расширения к стороннему сервису обрабатываются как запросы внутри одной сети, если расширение имеет права доступа к этой сторонней организации. Это означает, что могут отправляться cookie-файлы с параметром SameSite=Strict . Обратите внимание, что это относится только к сетевым запросам, а не к доступу через document.cookie в JavaScript, и не применяется, если cookie-файлы сторонних сервисов заблокированы.

Обратите внимание, что настройки, касающиеся сторонних файлов cookie, затрагиваются работой в рамках «Песочницы конфиденциальности» и корректируются в соответствии с графиком ее реализации .

API browser.cookies предоставляет возможность управлять ключом раздела, используемым с каждым методом API. Для получения дополнительной информации см. справочник API .

,

Расширения могут хранить файлы cookie и получать доступ к API веб-хранилища аналогично обычному веб-сайту. Однако в некоторых случаях в расширениях эти функции работают иначе.

Информацию об API расширений см. в browser.storage .

Хранилище

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

Упорство

При очистке данных браузера хранилище расширений не очищается. Это относится ко всем данным, хранящимся с использованием API веб-хранилища (таких как Local Storage и IndexedDB ).

По умолчанию на расширения распространяются обычные квоты на хранилище, которые можно проверить, вызвав метод navigator.storage.estimate() . Хранилище также может быть освобождено при сильной нехватке памяти, хотя это случается редко. Чтобы этого избежать:

  • Запросите разрешение "unlimitedStorage" , которое влияет как на API расширений, так и на API веб-хранилища и освобождает расширения от ограничений квот и вытеснения.
  • Для защиты от вытеснения используйте метод navigator.storage.persist() .

Хранилище расширения используется совместно всеми компонентами расширения, включая службу расширения, любые страницы расширения (включая всплывающие окна и боковую панель) и документы, находящиеся за пределами экрана. В скриптах контента вызов API веб-хранилища обращается к данным со страницы-хоста, на которую внедрен скрипт контента, а не из самого расширения.

Доступ к работникам сферы услуг

API IndexedDB и Cache Storage доступны в сервис-воркерах. Однако Local Storage и Session Storage недоступны.

Если вам необходимо получить доступ к локальному хранилищу или хранилищу сессий из сервис-воркера, используйте документ, находящийся вне экрана .

Разделение

Разделение данных на разделы (партиционирование) — это процесс введения ключей для хранения данных с целью ограничения доступа к ним. Исторически сложилось так, что хранение данных осуществлялось по принципу «ключ — источник».

Начиная с Chrome 115, функция разделения хранилища вносит изменения в определение ключей разделения, чтобы предотвратить определенные типы отслеживания между сайтами. На практике это означает, что если сайт A встраивает iframe, содержащий сайт B, сайт B не сможет получить доступ к тому же хранилищу, которое он обычно имел бы при прямом переходе на него.

Для смягчения последствий этого в расширениях применяются два исключения:

  • Если страница со схемой chrome-extension:// встроена в какой-либо сайт, разделение хранилища не будет применяться, и расширение будет иметь доступ к своему разделу верхнего уровня.
  • Если страница со схемой chrome-extension:// содержит iframe, и расширение имеет права доступа к хосту сайта, который оно встраивает, то этот сайт также будет иметь доступ к его разделу верхнего уровня.

Печенье

Файлы cookie позволяют хранить пары ключ-значение, связанные с определенным доменом и путем. В расширениях их ценность ограничена, но понимание их поведения может быть полезно, если у вас есть конкретный сценарий использования или вы включили сторонний скрипт, который использует их в своей реализации.

Защищенные файлы cookie

Атрибут Secure cookie поддерживается только для схемы https:// . Следовательно, страницы chrome-extension:// не могут устанавливать cookie с этим атрибутом.

Это также означает, что страницы расширений не могут использовать другие атрибуты cookie там, где требуется атрибут Secure :

Разделение на разделы и поведение SameSite

Файлы cookie, установленные на страницах chrome-extension://, всегда используют SameSite=Lax . Следовательно, файлы cookie, установленные расширением на собственном ресурсе, никогда не будут доступны во фреймах, и разделение ресурсов не имеет значения.

Файлы cookie, связанные со сторонними сайтами, например, со сторонним сайтом, загруженным во фрейме на странице расширения, или с запросом, отправленным со страницы расширения на сторонний ресурс, ведут себя так же, как и веб-сайт, за исключением двух моментов:

  • Сторонние файлы cookie никогда не блокируются, даже во вложенных окнах, если страница верхнего уровня для данной вкладки является страницей chrome-extension:// .
  • Запросы от расширения к стороннему сервису обрабатываются как запросы внутри одной сети, если расширение имеет права доступа к этой сторонней организации. Это означает, что могут отправляться cookie-файлы с параметром SameSite=Strict . Обратите внимание, что это относится только к сетевым запросам, а не к доступу через document.cookie в JavaScript, и не применяется, если cookie-файлы сторонних сервисов заблокированы.

Обратите внимание, что настройки, касающиеся сторонних файлов cookie, затрагиваются работой в рамках «Песочницы конфиденциальности» и корректируются в соответствии с графиком ее реализации .

API browser.cookies предоставляет возможность управлять ключом раздела, используемым с каждым методом API. Для получения дополнительной информации см. справочник API .