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 <[email protected]>
Update to reflect reviewer suggestion. Co-authored-by: Rob Wu <[email protected]>
Update to remove reference to Chrome Co-authored-by: Rob Wu <[email protected]>
Co-authored-by: Rob Wu <[email protected]>
Co-authored-by: Rob Wu <[email protected]>
Co-authored-by: Rob Wu <[email protected]>
Add use case
Added background information on x-site ancestor chain bit
Update language for cookies.remove()
Co-authored-by: Oliver Dunk <[email protected]>
Co-authored-by: Oliver Dunk <[email protected]>
Co-authored-by: Oliver Dunk <[email protected]>
Co-authored-by: Oliver Dunk <[email protected]>
Co-authored-by: Oliver Dunk <[email protected]>
Co-authored-by: Oliver Dunk <[email protected]>
Co-authored-by: Oliver Dunk <[email protected]>
Co-authored-by: Oliver Dunk <[email protected]>
Add description for getPartitionKey() api.
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 <[email protected]>
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 <[email protected]>
Co-authored-by: Rob Wu <[email protected]>
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 <[email protected]>
Co-authored-by: Rob Wu <[email protected]>
Co-authored-by: Rob Wu <[email protected]>
describe error conditions of new api
|
FYI I opened a bug to track the implementation of |
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.