Proposal: add hasCrossSiteAncestor value to partitionKey in Cookies API #581
Conversation
Add initial proposal
Updates for clarity
Update formatting of url
Updates in phrasing and document organization.
Additional details
Additional content and formatting
|
I'm adding myself as a reviewer because I designed the partitionKey part of the cookies API that has been implemented in Firefox a few years ago, before the WECG existed (at privacycg/CHIPS#6, which is already linked from the proposal doc). |
Update pr to incorporate reviewer feedback. Co-authored-by: Rob Wu <rob@robwu.nl>
Update to reflect reviewer suggestion. Co-authored-by: Rob Wu <rob@robwu.nl>
Update to remove reference to Chrome Co-authored-by: Rob Wu <rob@robwu.nl>
Co-authored-by: Rob Wu <rob@robwu.nl>
Co-authored-by: Rob Wu <rob@robwu.nl>
Co-authored-by: Rob Wu <rob@robwu.nl>
Add use case
Added background information on x-site ancestor chain bit
Update language for cookies.remove()
Co-authored-by: Oliver Dunk <oliver@oliverdunk.com>
Co-authored-by: Oliver Dunk <oliver@oliverdunk.com>
Co-authored-by: Oliver Dunk <oliver@oliverdunk.com>
Co-authored-by: Oliver Dunk <oliver@oliverdunk.com>
Co-authored-by: Oliver Dunk <oliver@oliverdunk.com>
Co-authored-by: Oliver Dunk <oliver@oliverdunk.com>
Co-authored-by: Oliver Dunk <oliver@oliverdunk.com>
Co-authored-by: Oliver Dunk <oliver@oliverdunk.com>
Updating language for getAll() to align it with the other APIs, where a partitionKey with no topLevelSite and a value for hasCrossSiteAncestor returns an error.
Update language to specify that `{hasCrossSiteAncestor: false}` and `{hasCrossSiteAncestor:true}` are invalid keys.
Add table containing valid partitionKeys. Update language in the background section to be more consistent.
Clarify language surrounding the empty partitionKey
Co-authored-by: bvandersloot-mozilla <90582190+bvandersloot-mozilla@users.noreply.github.com>
Update language to specify the domain of the cookie's url
Return {} to the table of valid partition keys
| > `frameId` | ||
| integer. The ID of the frame in the given tab. | ||
|
|
||
| ##### Return value |
There was a problem hiding this comment.
Could you specify:
- Does this method always return a partition key? If not, when?
- Are there any (origin) permission requirements? Cautiously we could opt for requiring host permissions for the target frame, because that permission is also required to execute a script there, which in turn could query the top level origin via
location.ancestorOrigins. I am also willing to consider not requiring origins if we deem the return value to not be too sensitive. After all, extensions can already observe partitioned cookies for non-document subresources in frames through the cookies API. - Are there error conditions? E.g. frame does not exist, permission denied.
There was a problem hiding this comment.
Does this method always return a partition key? If not, when?
It should always return a partitionKey unless an error occurs.
Are there any (origin) permission requirements?
In the chromium implementation, cookies.get(), cookies.set() and cookies.remove() all require host permissions so I think it makes sense to be consistent here as well.
Are there error conditions?
Both the frame does not exist and permission denied would be an error.
Do you have any thoughts on if a mismatch between the documentId and any tabId/frameId combination should be treated as an error?
There was a problem hiding this comment.
Does this method always return a partition key? If not, when?
It should always return a partitionKey unless an error occurs.
SGTM.
Are there any (origin) permission requirements?
In the chromium implementation,
cookies.get(),cookies.set()andcookies.remove()all require host permissions so I think it makes sense to be consistent here as well.
cookies.get, set, etc. only require host permissions for the URL where the cookie is set. Not for the partition key. An extension can therefore try to set cookies for a subresource (img, etc.) without having host permissions for the iframe. In the interest of getting to a resolution quicker, let's require host permissions for the document whose partitionkey is getting queried. If there is a compelling use case we could consider relaxing this, and that would be backwards-compatible since it is always possible to go from strict to less strict.
Are there error conditions?
Both the frame does not exist and permission denied would be an error. Do you have any thoughts on if a mismatch between the documentId and any tabId/frameId combination should be treated as an error?
Yes, this should be an error. When extensions use all combinations to describe a target, and there is no target matching it, then it should be an error.
There was a problem hiding this comment.
This thread was marked as resolved, but the updated PR does not mention anything about permission requirements or errors. Did you forget to push a commit with the updated text?
There was a problem hiding this comment.
Yes, pushed the commit
Co-authored-by: Rob Wu <rob@robwu.nl>
Co-authored-by: Rob Wu <rob@robwu.nl>
Add table describing inputs for getPartitionKey()
|
Friendly ping: with the AncestorChainBit being enabled by default in Chrome, we're beginning to get reports of breakage related to extensions not being able to handle partitioned cookies. |
| > `frameId` | ||
| integer. The ID of the frame in the given tab. | ||
|
|
||
| ##### Return value |
There was a problem hiding this comment.
Does this method always return a partition key? If not, when?
It should always return a partitionKey unless an error occurs.
SGTM.
Are there any (origin) permission requirements?
In the chromium implementation,
cookies.get(),cookies.set()andcookies.remove()all require host permissions so I think it makes sense to be consistent here as well.
cookies.get, set, etc. only require host permissions for the URL where the cookie is set. Not for the partition key. An extension can therefore try to set cookies for a subresource (img, etc.) without having host permissions for the iframe. In the interest of getting to a resolution quicker, let's require host permissions for the document whose partitionkey is getting queried. If there is a compelling use case we could consider relaxing this, and that would be backwards-compatible since it is always possible to go from strict to less strict.
Are there error conditions?
Both the frame does not exist and permission denied would be an error. Do you have any thoughts on if a mismatch between the documentId and any tabId/frameId combination should be treated as an error?
Yes, this should be an error. When extensions use all combinations to describe a target, and there is no target matching it, then it should be an error.
Co-authored-by: Rob Wu <rob@robwu.nl>
Co-authored-by: Rob Wu <rob@robwu.nl>
Co-authored-by: Rob Wu <rob@robwu.nl>
describe error conditions of new api
|
FYI I opened a bug to track the implementation of |
The webextensions proposal add hasCrossSiteAncestor value to partitionKey in Cookies API (w3c/webextensions#581) added a new API getPartitionKey to cookies API. This CL contains the implementation of the API described in the proposal. Bug: 373361899 Change-Id: I79120f6297c38814949ed1612a9dd1094cb00b84 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5930063 Commit-Queue: Aaron Selya <selya@google.com> Reviewed-by: Devlin Cronin <rdevlin.cronin@chromium.org> Cr-Commit-Position: refs/heads/main@{#1378528}
To allow for correct interaction with partitioned cookies that include the cross-site ancestor chain bit, the Cookies API should be updated to include a parameter that corresponds to the value of the cross-site ancestor chain bit.