Proposal: privacy.websites.thirdPartyCookiesAccessible

[aselya]

Proposal defines a new API that will allow extensions to determine a frame's access to third-party cookies.

[Rob--W]

This PR looks strange with the many unrelated commits. Could you clean it up as follows:

git fetch upstream main:main
git checkout -B thirdPartyCookiesAccessible_API upstream/main
git cherry-pick 806bd5e68021e4a903cc600bff4b99ce81c4dcb0
git push origin thirdPartyCookiesAccessible_API -f

In this example of the code snippet :

• upstream would be the remote for this repository - https://github.com/w3c/webextensions
• origin would be your fork - https://github.com/aselya/webextensions
• (to double-check if this is correct, run git remote -v locally to print your repositories)
• 806bd5e is the commit where you added the file for which you're requesting review. In this case there was only one, but you can have more in general
• git checkout -B branchname upstream/main replaces branchname with a new branch branched off the current upstream/main (and since I added git fetch upstream main it is the latest up-to-date branch).
• git push origin branchname -f the -f is --force flag to forcibly overwrite the branch with the new branch.

[aselya]

This PR looks strange with the many unrelated commits. Could you clean it up as follows:

git fetch upstream main:main
git checkout -B thirdPartyCookiesAccessible_API upstream/main
git cherry-pick 806bd5e68021e4a903cc600bff4b99ce81c4dcb0
git push origin thirdPartyCookiesAccessible_API -f

In this example of the code snippet :

• upstream would be the remote for this repository - https://github.com/w3c/webextensions
• origin would be your fork - https://github.com/aselya/webextensions
• (to double-check if this is correct, run git remote -v locally to print your repositories)
• 806bd5e is the commit where you added the file for which you're requesting review. In this case there was only one, but you can have more in general
• git checkout -B branchname upstream/main replaces branchname with a new branch branched off the current upstream/main (and since I added git fetch upstream main it is the latest up-to-date branch).
• git push origin branchname -f the -f is --force flag to forcibly overwrite the branch with the new branch.

Thanks for catching this. Fix has been made.

[aselya]

Why should this be an extension API and not just part of the web platform?

To determine if an individual frame has access to third-party cookies, an extension can attempt to set and read a cookie or use the API document.hasStorageAccess(). This information is sufficient for most cases on the web but there are some subtleties to unpartitioned (third-party) cookie access that extensions could benefit from having knowledge of but should not be exposed on the open web because it reveals information about the users choices and settings that could potentially be abused by a malicious site.

Storage Access effectively has three distinct states, granted, denied and inactive. document.hasStorageAccess() does not differentiate between an explicit denial or the state being inactive (where the user or user agent hasn’t made a choice) and returns false for both of them. This distinction is hidden to hide the user’s choice from malicious sites, since extensions are allowed to have more information exposed to them, this information can be revealed. Extensions would benefit from this more granular information because it would allow them know if they should use content script to call document.requestStorageAccess() to prompt the user for permission or if the user (or an agent working on their behalf) has already explicitly denied access to unpartitioned cookies for the frame and they should display a message to ask the user to change the settings.

The existing means of determining third-party cookie access requires a frame to already exist. This API would provide a means of allowing an extension to determine access to cookies for frames that don’t already exist. This could be useful for an extension without <all_url> host permissions because it would be able to check after initialization if the sites it needs to have unpartitioned cookie access would be eligible for it. This capability should be confined to extensions because storage access grants can only be given to frames that exist but user settings such as Firefox’s “Exceptions for Enhanced Tracking Protection” and Chrome’s Enterprise policies do not rely on a frame existing and shouldn’t be exposed on the open web.

[Rob--W]

Is this still relevant since Google has announced the intent to cease work on Privacy Sandbox?

[aselya]

I believe so. Since the underlying issue, the existing API privacy.websites.thirdPartyCookiesAllowed() only returning the browser level setting, wasn't caused by or potentially solved by any of the Privacy Sandbox technologies.

Through mechanisms like the Storage Access Api and Enterprise policies, individual frames or domains can access third-party cookies even when the browser level setting blocks them. This issue might further be exacerbated as a result of other work being done in the cookie realm such as third-party-cookie-allowlist-header which would allow sites the ability to restrict third-party cookie access.

[Rob--W]

Apologies for the late review. If you're actively pursuing this effort, let me know and I can prioritize accordingly.

Although the lack of granularity for browser.privacy.websites.thirdPartyCookiesAllowed is the motivating factor for this proposal, the addition of a new method browser.privacy.websites.thirdPartyCookiesAccessible() feels like a bad fit for that namespace. The browser.privacy.websites namespace exposes a way to query (and sometimes change) browser settings, through a common API shape. Note that Chromium is the only implementation of this, Firefox and Safari do not expose thirdPartyCookiesAllowed. Firefox has cookieConfig as a global alternative.

The functionality you are describing sounds like a better fit for the cookies API namespace.

The one mentioned use case queries for access and prints an error otherwise: chrome.privacy.websites.thirdPartyCookiesAllowed.get({}, (function(L) { L.value || (Object(X.m)(T, "Cannot launch Visual Editor\n\nThird party cookies must be enabled to use the visual editor. Please disable the blocking of third party cookies and try again."), C(!1))

With the new API, I imagine that the best that an extension can do is to query and return the same error. A difference with the current state is that the proposed API would account for other ways that enables an opt in to extensions. Especially with the reality in Firefox and Safari that third-party cookies are "disabled" (partitioned) by default, I don't see much value in the introduction of an API that just queries the state. The Storage Access API already exists, but the extension is not using that to provide granular messages today. To me that is a signal that there is no demand for more granular query methods.

If I think of a minimal way to expand the existing APIs to support the use case, I imagine that perhaps we can expand the cookies.getPartitionKey method that we (you and I mainly) specified in https://github.com/w3c/webextensions/blob/main/proposals/hasCrossSiteAncestor.md#cookiesgetpartitionkey. Right now it returns the partition for a frame, but a new option could be introduced that tells whether a partition is required for cookie access:

• if cookies are disables -> throw reasonable error
• if a partition is required -> return it
• if a partition is not required -> return an unpartitioned value

I'm open to alternative API shapes, but I just wanted to express a thought as an example of how it can fit. By relating the API to existing primitives, it becomes more obvious how an extension can act on the result.