8000 Proposal: privacy.websites.thirdPartyCookiesAccessible by aselya · Pull Request #822 · w3c/webextensions · GitHub
[go: up one dir, main page]
Skip to content

Proposal: privacy.websites.thirdPartyCookiesAccessible #822

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Proposal: privacy.websites.thirdPartyCookiesAccessible #822

wants to merge 1 commit into from

Conversation

aselya
Copy link
Contributor
@aselya aselya commented May 5, 2025

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

@Rob--W
Copy link
Member
Rob--W commented May 7, 2025 •
edited
Loading

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 aselya force-pushed the thirdPartyCookiesAccessible_API branch from 602699b to b5e3f8f Compare May 7, 2025 17:19
@aselya
Copy link
Contributor Author
aselya commented May 7, 2025

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 aselya closed this May 7, 2025
@aselya aselya reopened this May 7, 2025
@xeenon xeenon mentioned this pull request Apr 24, 2025
Closed
@Rob--W Rob--W mentioned this pull request May 8, 2025
Merged
@aselya
Copy link
Contributor Author
aselya commented May 8, 2025

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.

@aselya aselya requested review from Rob--W, oliverdunk and xeenon May 9, 2025 14:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@Rob--W Rob--W Awaiting requested review from Rob--W

@oliverdunk oliverdunk Awaiting requested review from oliverdunk

@xeenon xeenon Awaiting requested review from xeenon

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@aselya @Rob--W
0