cookies
Ermöglicht Erweiterungen das Abrufen, Setzen und Entfernen von Cookies sowie Benachrichtigungen, wenn diese sich ändern.
Berechtigungen
Damit eine Erweiterung diese API nutzen kann, muss sie in ihrer manifest.json Datei die "cookies"
API-Berechtigung sowie Host-Berechtigungen für alle Seiten angeben, deren Cookies sie zugreifen möchte. Die Erweiterung kann alle Cookies abrufen, setzen oder entfernen, die von einer URL gelesen, geschrieben oder gelöscht werden können, die zu den Host-Berechtigungen passt. Zum Beispiel:
http://*.example.com/
-
Eine Erweiterung mit dieser Host-Berechtigung kann:
- Ein nicht-sicheres Cookie für
www.example.com
mit jedem Pfad lesen. - Ein sicheres oder nicht-sicheres Cookie für
www.example.com
mit jedem Pfad schreiben.
Sie kann nicht:
- Ein sicheres Cookie für
www.example.com
lesen.
- Ein nicht-sicheres Cookie für
http://www.example.com/
-
Eine Erweiterung mit dieser Host-Berechtigung kann:
- Ein nicht-sicheres Cookie für
www.example.com
mit jedem Pfad lesen. - Ein nicht-sicheres Cookie für
.example.com
mit jedem Pfad lesen. - Ein sicheres oder nicht-sicheres Cookie für
www.example.com
mit jedem Pfad schreiben. - Ein sicheres oder nicht-sicheres Cookie für
.example.com
mit jedem Pfad schreiben.
Sie kann nicht:
- Ein Cookie für
foo.example.com
lesen oder schreiben. - Ein Cookie für
foo.www.example.com
lesen oder schreiben.
- Ein nicht-sicheres Cookie für
*://*.example.com/
-
Eine Erweiterung mit dieser Host-Berechtigung kann:
- Ein sicheres oder nicht-sicheres Cookie für
www.example.com
mit jedem Pfad lesen oder schreiben.
- Ein sicheres oder nicht-sicheres Cookie für
Tracking-Schutz
Tracker verwenden Drittanbieter-Cookies, also Cookies, die von einer anderen Website als der, die Sie besuchen, gesetzt werden, um die von Ihnen besuchten Websites zu identifizieren. Zum Beispiel:
- Sie besuchen
a-shopping-site.com
, welchead-tracker.com
verwendet, um ihre Werbeanzeigen im Web bereitzustellen.ad-tracker.com
setzt ein Cookie, das mit der Domainad-tracker.com
verbunden ist. Während Sie aufa-shopping-site.com
sind, erhältad-tracker.com
Informationen über die Produkte, die Sie durchstöbern. - Sie besuchen nun
a-news-site.com
, diead-tracker.com
zur Bereitstellung von Anzeigen verwendet.ad-tracker.com
liest sein Cookie und verwendet die vona-shopping-site.com
gesammelten Informationen, um zu entscheiden, welche Anzeigen Ihnen gezeigt werden.
Firefox enthält zwei Funktionen, um Tracking zu verhindern: dynamische Partitionierung und First-Party-Isolierung. Diese Funktionen trennen Cookies, sodass Tracker keine Verbindung zwischen besuchten Websites herstellen können. So kann in dem obigen Beispiel ad-tracker.com
das auf a-news-site.com
erstellte Cookie nicht sehen, wenn Sie a-shopping-site.com
besuchen.
Ab Firefox 103 ist die dynamische Partitionierung die standardmäßig verwendete Funktion. Wenn jedoch der Benutzer oder eine Erweiterung die First-Party-Isolierung aktiviert, hat diese Vorrang vor der dynamischen Partitionierung.
Hinweis: Wenn privates Browsen dynamische Partitionierung verwendet, kann das normale Browsen möglicherweise keine Cookies partitionieren. Siehe Status der Partitionierung in Firefox für Details.
Speicherpartitionierung
Beim Verwenden der dynamischen Partitionierung partitioniert Firefox den Speicher, der für JavaScript-APIs zugänglich ist, nach oberster Website und bietet entsprechenden Zugriff auf nicht-partitionierten Speicher, um gängige Anwendungsfälle zu ermöglichen. Diese Funktion wird schrittweise eingeführt. Siehe Status der Partitionierung in Firefox für Implementierungsdetails.
Speicherpartitionen werden durch die URL mit Schema der obersten Website gekennzeichnet und, wenn die dynamische Partitionierung aktiv ist, ist der Schlüsselwert über die partitionKey.topLevelSite
-Eigenschaft in der Cookies API verfügbar, z.B. partitionKey: {topLevelSite: "http://site"}
.
Allgemein sind Dokumente auf oberster Ebene in nicht-partitioniertem Speicher, während Drittanbieter-Iframes in partitioniertem Speicher sind. Wenn ein Partitionsschlüssel nicht ermittelt werden kann, wird standardmäßig (nicht-partitionierter Speicher) verwendet. Beispielsweise können alle HTTP(S)-Seiten als Partitionsschlüssel verwendet werden, moz-extension:-
URLs jedoch nicht. Daher verwenden Iframes in den Erweiterungsdokumenten von Firefox keinen partitionierten Speicher.
Standardmäßig arbeiten cookies.get()
, cookies.getAll()
, cookies.set()
und cookies.remove()
mit Cookies in nicht-partitioniertem Speicher. Um mit Cookies in partitioniertem Speicher in diesen APIs zu arbeiten, muss topLevelSite
in partitionKey
gesetzt werden. Die Ausnahme ist getAll
, wobei das Setzen von partitionKey
ohne topLevelSite
Cookies in partitioniertem und nicht-partitioniertem Speicher zurückgibt. cookies.onChanged
wird bei jedem Cookie ausgelöst, auf das die Erweiterung zugreifen kann, einschließlich Cookies in partitioniertem Speicher. Um sicherzustellen, dass das richtige Cookie geändert wird, sollten Erweiterungen die cookie.partitionKey
-Eigenschaft aus dem Ereignis lesen und ihren Wert an cookies.set()
und cookies.remove()
übergeben.
First-Party-Isolierung
Wenn die First-Party-Isolierung aktiviert ist, werden Cookies durch die Domain der ursprünglichen Seite qualifiziert, die der Benutzer besucht hat (im Wesentlichen die Domain, die dem Benutzer in der URL-Leiste angezeigt wird, auch bekannt als "First-Party-Domain").
Die First-Party-Isolierung kann vom Benutzer aktiviert werden, indem die Konfiguration des Browsers angepasst wird und von Erweiterungen mit der firstPartyIsolate
-Einstellung in der privacy
API. Beachten Sie, dass die First-Party-Isolierung standardmäßig im Tor Browser aktiviert ist.
Die cookies
API stellt die First-Party-Domain durch das Attribut firstPartyDomain
dar. Alle Cookies, die gesetzt werden, während die First-Party-Isolierung aktiv ist, haben dieses Attribut auf die Domain der ursprünglichen Seite gesetzt. In dem obigen Beispiel ist dies a-shopping-site.com
für ein Cookie und a-news-site.com
für das andere. Wenn die First-Party-Isolierung ausgeschaltet ist, haben alle von Websites gesetzten Cookies diese Eigenschaft auf einen leeren String gesetzt.
Die cookies.get()
, cookies.getAll()
, cookies.set()
und cookies.remove()
APIs akzeptieren alle eine firstPartyDomain
-Option.
Wenn die First-Party-Isolierung aktiviert ist, müssen Sie diese Option angeben, ansonsten schlägt der API-Aufruf fehl und gibt eine abgelehnte Promise zurück. Für get()
, set()
, und remove()
müssen Sie einen String-Wert übergeben. Für getAll()
können Sie hier auch null
übergeben, und dies erfasst alle Cookies, unabhängig davon, ob sie einen nicht-leeren Wert für firstPartyDomain
haben oder nicht.
Wenn die First-Party-Isolierung ausgeschaltet ist, ist der firstPartyDomain
-Parameter optional und standardmäßig auf einen leeren String gesetzt. Ein nicht-leerer String kann verwendet werden, um First-Party-Isolierungs-Cookies abzurufen oder zu ändern. Ebenso gibt das Übergeben von null
als firstPartyDomain
an getAll()
alle Cookies zurück.
Typen
-
Stellt Informationen über ein HTTP-Cookie dar.
-
Stellt einen Cookie-Speicher im Browser dar.
-
Stellt den Grund dar, warum sich ein Cookie geändert hat.
-
Stellt den Same-Site-Status des Cookies dar.
Methoden
-
Ruft Informationen über ein einzelnes Cookie ab.
-
Ruft alle Cookies ab, die einem bestimmten Filtersatz entsprechen.
-
Setzt ein Cookie mit den angegebenen Cookie-Daten; kann gleichwertige Cookies überschreiben, wenn sie existieren.
-
Löscht ein Cookie nach Name.
-
Listet alle vorhandenen Cookie-Speicher auf.
Ereignishandler
-
Wird ausgelöst, wenn ein Cookie gesetzt oder entfernt wird.
Beispiel-Erweiterungen
Browser-Kompatibilität
BCD tables only load in the browser
Hinweis: Diese API basiert auf Chromium's chrome.cookies
API. Diese Dokumentation stammt von cookies.json
im Chromium-Code.