cookies.get orders cookies according to RFC-6265 #36193
Conversation
github-actions
bot
added
Content:Firefox
| @@ -51,10 +51,10 @@ Trackers use third-party cookies, that is, cookies set by a website other than t | |||
| 1. You visit `a-shopping-site.com`, which uses `ad-tracker.com` to deliver its adverts on the web. `ad-tracker.com` sets a cookie associated with the `ad-tracker.com` domain. While you are on `a-shopping-site.com`, `ad-tracker.com` receives information about the products you browse. | |||
| 2. You now visit `a-news-site.com` that uses `ad-tracker.com` to deliver adverts. `ad-tracker.com` read its cookie and use the information collected from `a-shopping-site.com` to decide which adverts to display to you. | |||
|
|
|||
| Firefox includes features to prevent tracking. These features separate cookies so that trackers cannot make an association between websites visited. So, in the preceding example, `ad-tracker.com` cannot see the cookie created on `a-news-site.com` when visiting `a-shopping-site.com`. The first iteration of this protection was first-party isolation which is now being superseded by [dynamic partitioning](/en-US/docs/Web/Privacy/State_Partitioning#dynamic_partitioning). | |||
| Firefox includes features to prevent tracking. These features separate cookies so that trackers cannot make an association between websites visited. So, in the preceding example, `ad-tracker.com` cannot see the cookie created on `a-news-site.com` when visiting `a-shopping-site.com`. The first iteration of this protection was first-party isolation, which is being superseded by [dynamic partitioning](/en-US/docs/Web/Privacy/State_Partitioning#dynamic_partitioning). | |||
There was a problem hiding this comment.
@Rob--W for this and the next para, has first-party isolation to dynamic partitioning been completed?
There was a problem hiding this comment.
Both features are present.
In the Tor browser that is based on Firefox, first party isolation is enabled.
In Firefox, dFPI is enabled by default, but the behavior can be changed by users. This is documented at https://developer.mozilla.org/en-US/docs/Web/Privacy/State_Partitioning#status_of_partitioning_in_firefox
Interestingly, the fact that it is enabled by default is not documented on that section of MDN.
The bug where it was enabled by default (in Firefox 103) is https://bugzilla.mozilla.org/show_bug.cgi?id=1776760
Tagging pbz - @Trikolon - do you know why the support status of dFPI is not reflected in the MDN documentation at https://developer.mozilla.org/en-US/docs/Web/Privacy/State_Partitioning#status_of_partitioning_in_firefox ?
There was a problem hiding this comment.
The MDN article is simply outdated.
There was a problem hiding this comment.
Sounds good. Generally, while still supported via the extension API, we don't want to encourage users to use first party isolation in Firefox. It doesn't hurt to mention in in a technical article though.
…h://github.com/rebloor/content into cookies.get-orders-cookies-according-to-RFC-6265
github-actions
bot
added
the
Content:Other
| Firefox includes features to prevent tracking. These features separate cookies so that trackers cannot make an association between websites visited. So, in the preceding example, `ad-tracker.com` cannot see the cookie created on `a-news-site.com` when visiting `a-shopping-site.com`. The first iteration of this protection was first-party isolation which is now being superseded by [dynamic partitioning](/en-US/docs/Web/Privacy/State_Partitioning#dynamic_partitioning). | ||
| Firefox includes two features to prevent tracking: [dynamic partitioning](#storage_partitioning) and [first-party isolation](#first-party_isolation). These features separate cookies so that trackers cannot make an association between websites visited. So, in the preceding example, `ad-tracker.com` cannot see the cookie created on `a-news-site.com` when visiting `a-shopping-site.com`. | ||
|
|
||
| From Firefox 103, dynamic partitioning is the default feature used. However, if the user or an extension turns on first-party isolation, it takes precedence over dynamic partitioning. |
There was a problem hiding this comment.
Is it Firefox 103 or Firefox 133? Here and in a few other places.
If it’s 103, it would be good it update 103 release notes as well.
There was a problem hiding this comment.
103 per another comment on this PR: #36193 (comment)
|
This pull request has merge conflicts that must be resolved before it can be merged. |
Co-authored-by: Vadim Makeev <[email protected]>
Co-authored-by: Vadim Makeev <[email protected]>
| @@ -9,7 +9,12 @@ browser-compat: webextensions.api.cookies.remove | |||
|
|
|||
| The **`remove()`** method of the {{WebExtAPIRef("cookies")}} API deletes a cookie, given its name and URL. | |||
|
|
|||
| The call succeeds only if you include the "cookies" [API permission](/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#api_permissions) in your [manifest.json](/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json) file, as well as [host permissions](/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#host_permissions) for the given URL specified in its manifest. | |||
| The call only succeeds if you include the "cookies" [API permission](/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#api_permissions) in your [manifest.json](/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json) file, as well as [host permissions](/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#host_permissions) for the given URL specified in its manifest. | |||
There was a problem hiding this comment.
The call only succeeds if you include the "cookies" API permission…
This phrasing feels odd to me. If the developer does not declare the browser.cookies namespace in the extension manifest, the entire namespace will be undefined. Trying call this method without requesting the permission will generate a TypeError at runtime, preventing the call from event being made in the first place.
Also, it's not quite accurate to suggest that the operative requirement is including the "cookies" permission in the manifest. That's a prerequisite, but the hard requirement is that the extension has a "cookies" permission grant. Today, this is relevant in two case: declaring "cookie" in the "optional_permissions" field and when enterprise policies block an extension from receiving a permission grant.
I'd suggest rephrasing this paragraph along these lines:
Original
The call only succeeds if you include the "cookies" [API permission] in your [manifest.json] file, as well as [host permissions] for the given URL specified in its manifest.
Suggestion 1
This method requires that you have the "cookies" [API permission] and [host permissions] for the given URL.
Suggestion 2
This method requires that you request and receive the "cookies" [API permission] and [host permissions] for the given URL. These permissions must be declared in your [manifest.json] file.
This also applies to the same line in files/en-us/mozilla/add-ons/webextensions/api/cookies/set/index.md
There was a problem hiding this comment.
@dotproto Sorry, I didn't review or change this para - its long standing text - I'll take a look.
There was a problem hiding this comment.
@dotproto I've modified the statement here and in set to follow the prototype from the API main page. Given the overarching statement, should we also add this to get(), getAll(), and getAllCookieStores()? Or indeed - remove from here and 'set'?
Description
Addresses the documentation needs for Bug 1818968 cookies.get() should return the cookie with the closest matching path but also makes grammar and format corrections across all the cookies API docs.
Related issues and pull requests
Related BCD changes in mdn/browser-compat-data#24634