Closed finnbear closed 11 months ago
- it would be nice if you ran
cargo fmt
. I spent more time undoing my accidentalcargo fmt
on the whole codebase than it took to write the original changes.
rustfmt
is very incomplete, so I prefer not to use it until it reaches a gofmt
-like level. I would encourage you to disable rustfmt
when you interact with public projects and only run it when you're sure the project is using rustfmt
.
The
Secure
attribute is automatically formatted whensecure
isNone
andpartitioned
isSome(true)
I believe this would violate the spec. (Edit: sorry, that statement is correct, but I believe the implementation didn't quote do this. Perhaps it did? In any case, the nested logic was fairly cryptic, so I've cleaned it up a bit, which makes it clear we're following the docs.) It reads (https://developer.chrome.com/docs/privacy-sandbox/chips/#security-design):
Partitioned cookies must be set with Secure.
https://github.com/privacycg/CHIPS#secure-attribute also implies this.
I've made this change to your branch.
We also need to add text to everything that refers to this attribute that notes this is entirely experimental (is there even a draft RFC?). See the note on SameSite
. We need one of those but even more stressed.
I would encourage you to disable rustfmt when you interact with public projects and only run it when you're sure the project is using rustfmt.
Good advice for the future :+1:
I believe this would violate the spec
I intentionally made it so setting secure
to Some(false)
and partitioned
to Some(true)
would violate the spec as I thought it would adhere to the pattern set by SameSite::None
; that spec reads:
Note: Standards related to the Cookie SameSite attribute recently changed such that:
- Cookies with SameSite=None must now also specify the Secure attribute (they require a secure context/HTTPS).
I was under the impression that this crate would allow you to create invalid cookies if you tried hard enough. Ignoring secure
being Some(false)
when partitioned
is Some(true)
seems good, though.
We also need to add text to everything that refers to this attribute that notes this is entirely experimental (is there even a draft RFC?). See the note on
SameSite
. We need one of those but even more stressed.
I synthesized the doc document on the SameSite
type with the doc comment on the draft
module, and added it to the three new API's :rocket:
hi I just want to add that it will start phasing out the third party cookies in less than 2 month: https://developer.chrome.com/docs/privacy-sandbox/third-party-cookie-phase-out/?utm_source=devtools#partitioned, could you please push out a release ?
hi I just want to add that it will start phasing out the third party cookies in less than 2 month: https://developer.chrome.com/docs/privacy-sandbox/third-party-cookie-phase-out/?utm_source=devtools#partitioned, could you please push out a release ?
This isn't implemented. I'm not sure what you mean by "phasing out the third party cookies in less than 2 month."
As part of the Privacy Sandbox project, Chrome is phasing out support for third-party cookies and proposing new functionality for cookies along with purpose-built APIs to continue supporting legitimate use cases while preserving user privacy. The phase out will be gradual and starts from Q1 2024 with disabling third-party cookies for 1% of users to facilitate testing.
Merged in 273e3970ca597017d973330514c98cb0aeaf97b8. Thank you!
I'd like to use the
Partitioned
cookie attribute (in anticipation that third-party cookies are deprecated). This PR adds support and tests for it, and I have successfully used it (via my branch).Note: The
Secure
attribute is automatically formatted whensecure
isNone
andpartitioned
isSome(true)
(in addition to the old condition ofsame_site
beingSome(SameSite::None)
).Context:
Also, these are unrelated, but:
impl PartialEq for Cookie
doesn't compare thesame_site
field.cargo fmt
. I spent more time undoing my accidentalcargo fmt
on the whole codebase than it took to write the original changes.