Meeting minutes
lol the calendar event says slack
and links to matrix
which is not irc which is also on there
Johann Hofmann presenting
Cookie layering - want to specify a few major points
interop issues
We have a bunch of behaviors that sides are not willing to change
Chrome is not depreciating third party cookies and that won't change
so now we have to deal with interop issues
Ben brought this up in privacycg
It isn't a direct problem but we want to progress towards interop
John W: I just wanted to say that I've been saying to a few people that used to work on privacy sandbox that I don't think we've seen the last chapter here
it is very unf for the web platform
<niklasmerz> big +1 on third party cookie breakage. The situation is very weird on WebViews
such a fundamental piece of tech is significantly bifurcated
that is not a great outcome of whatever happened
The people who made us end up here got in the way of a web standards process
It should have been figured out here and it got disrupted.
Johann: did we want to discuss breakage and how we're dealing with it?
John W: Matthew has been dealing with site compatibility
The long tail of sites that require some sort of account you can't just sign up for that you can't easily get test accounts for. We just get reports it is broken b/c of third party cookies
Matthew: (webkit) I've had conversations with Johann and ben and we've tried to deal with situations where the browser doesn't handle these things by default
We've tried to accommodate per-site quirks and have had small success with webkit, esp with CHIPs for partition cookies which let you use cookies within a third party context but not use the user's actual cookies
we are exploring this
On: potentially developing a shared list of websites where we know 3p cookies are needed in some way (partitioned cookies or if the relationship is 1st party and the site should be relying on the storage access api and we can use quirks there) it could be useful to maintain that list
esp across UA providers
ErikAnderson: I think I asked this in some way before. Chrome Incognito has a partitioned behavior and there is still a 3p block cookie settings
Taylor: Chrome - blocking cookies in Chrome gives you partitioned cookies
This isn't the same as incognito where there are no third party cookies
those are blocked by default
CHIPS works though in incognito mode
ErikAnderson: given that there is no longer a change in default behavior and no longer inducing a change. Is it possible there's an option for chrome users to opt in to the same behavior as Firefox and Webkit? That would give more reason for people to move their sites to match that experience.
We still have convos about what are the limits of CHIPS etc... is it easier now for an aligned behavior ?
johannhof: we're willing to talk about what that mode does but can't change the default behavior.
ErikAnderson: incognito mode might make this harder since it has a different default?
Can we make it so incognito and no-3p mode has the same behavior?
johannhof: I will take that feedback. Also talking about a shared list is something tha thas come up before.
Partitioned cookies default behavior
bvandersloot: Firefox partition by default. Chrome incog and Safari block them. The challenge is that for us partition by default is a good compat mechanism that stops us from having to intervene with sites and for that reason changing is very hard for us to ship.
John W.: how many sites get unbroken?
bvandersloot: Not really - there are deeper behaviors like carts or sign ins or other cross site behaviors means it is very hard to get even a manual estimate.
Is there a resolution we see to this? interop issues don't get better over time. What's the realistic option towards convergence. Either Chrome switches to partition or block.
Matthew: we've heard that some sites would still like to opt out of 3p cookies if possible.
maybe we need a followup to CHIPS that allows for opt out of 3p
It would be on the header or for an iframe. Not the first party
???: This particular party might need to be for cross origin document - they need to know that they are being loaded cross origin and what their relationship is to the origin frame and then we wouldn't need to know about it
or rather the embedded entity wouldn't need to worry about partitions
John W: when dealing with same site lax by default any change to the cookie behavior will break some weird behavior and then there is a mad rush to unship changes. Don't touch that default cookie behavior
<Zakim> AramZS, you wanted to ask about opt out of third party cookies header
<miketaylr> AramZS: are we going to talk about the proposal to block 3P cookies?
<miketaylr> johannhof: yes
johannhof: stalemate situation and we can't move that much. Maybe we can explore partitioning
bvandersloot: we can consider blocking as well. it was scary last time
kleber: Have you considered trying to give the people who encounter breakage a partitioned cookie option?
Then you could collect data about the potential benefits of a more firefoxy model
John W: we did add a way for regular users to tell us if stuff is broken
the reports are hard to parse - sometimes people are just angry about something
Figuring out that it is cookies is hard.
johannhof: the most popular sites to get reported tend to be ones that just have basic network errors.
John W: ex of a deep investigation - US Census site. It turned out that one of their load balancers sent a double CSP header and we still had a legacy CSP header implementation and they had slightly diff policies
miketaylr: We tried to investigate that behavior and tried to figure out what broke and never really discovered it.
ErikAnderson: sites do sometimes hard code browser engine assumptions
John W: it sometimes solves that problem and introduces 10 others
johannhof: samesite lax by default how do we solve?
I think there was a possible way when chrome was still on the path with chrome going to samesite none by default and storageaccess headers
right now I don't know
both browsers wanted to go to lax by default at one point is there still an option?
John W: we did it and it was theoretically and improvement but then a bunch of stuff broke
We shipped and a bunch of enterprise sites broke and complained.
We liked the change in theory
Matthew: we can't detect the problem until we ship and then it hits us with a problem and it take a while to unship
johannhof: it sounds like it is really hard to find it in the ecosystem it is hidden to us and we can't crawl for it?
John W: when we made them samesite lax by default. When we go back in time the orig only had lax and strict and Chrome proposed and implemented None and when we didn't recognize the value we defaulted to strict so when servers started sending us None we did the complete opposite. Sites started to do 'if safari never set samesite to none'
so when we flipped to lax they refused to set to samesite none and it became lax
Do you remember that google deved server side code to know if they could start setting specific samesite settings?
<miketaylr> https://
because this was in our HTTP layer it took 3 years to get it out of our versions, totally different hting.
Why is chrome not willing to do samesite none by default?
johannhof: security boundary issue
If you were in touch with the people for whom this was broken for did they fix it?
ErikAnderson: they sniffed it
John W: the one or two people who did fix it were good but we realized it must have been a pretty long tail of people with issues
annevk: I have an idea - collective depreciation is something we do? can we depreciate cookies without samesite are depreciated?
bvandersloot: for a collective issue like TLS it might make sense
johannhof: would be good to make progress on this better than once a year
Edgar: from mozilla - +1 on hard to diagnose issues. We've also been theorizing partial cookie removal is an issue
how should we deal with the global cookie max
right now the current way in both specs is ordering by last access
then we are in a state where a host is purged partially
annevk: is anyone around who worked on this?
Seems like it goes back to netscape
<karlcow> For history https://
mt: a lot of websites tolerate cookies disappearing piecemeal ?
<karlcow> https://
annevk: just sort of deletes the furthest cookies set from the present
mikewest: might be ordered by security.
<miketaylr> AramZS: as a site owner, we have a whole suite around managing the fact that cookies randomly disappear
<miketaylr> AramZS: it's unpredictable and causes problems. we have 2 pieces: we try to reapply the important cookies
<miketaylr> ... and have a cookie monster that removes non-essential cookies for whatever reason. it sucks, but others probably do similar
John W: I think maybe a major use newspaper we got reports on seemingly random logouts and it was really just too many cookies for the cookie header and it was kind of random which ones got cut off
Mikewest: Within a lot of enterprises that have multiple subdomains and set a lot of cookies chrome has found it impossible to handle priority. Sites find it very valuable to prioritize cookies to be deleted. Chrome can't remove that process
When sorting the list of cookies to use we delete low priority before high priority but I don't recall exactly how it is set.
johannhof: It would have a good interop impact if we make a change on this one
mikewest: Changing to delete all the cookies would be something we could do. When we changed sorting to be on secure it broke websites.
I am reluctant to touch cookie sorting making it atomic would be safe but surprising.
<miketaylr> annevk: would you prefer atomic aram?
<miketaylr> AramZS: that doesn't seem like it would be any better
<miketaylr> ErikAnderson: you don't have the mystery of hunting for a missing cookie
<miketaylr> AramZS: maybe i'm the wrong person to ask
<miketaylr> AramZS: i'd be interested in seeing a proposal, unsure if helpful.
Ed: I am willing to write up a proposal
Isaac F -/Xander: From an ad tech perspective given the amount of time this happens it would be worse if it was atomic and everything was deleted
mt: if you don't have priority set it would be atomic and then if you do it would go down the list.
If you have priorities you'd go through and do the lowest priority one until you felt you hit the save amount.
Isaac F: Atomic means all cookies have to go away means all cookies are set. I like the priority idea maybe that would be a fine way to do that.
John W: actual atomic I don't think is possible cookies on memory and cookies on disk and you don't want to block all networking while deleting cookies.
mt: there's always a risk
johannhof: two proposals to discuss from Google
[slide] Origin Bound cookies
A really cool proposals that binds cookies to scheme and port by default
maps very closely to browser understood origin
split between insecure and secure context mapping is no longer needed it just understand default user security setting.
Scheme always applies there is a strong binding but you get TLD+1 binding for the domain
I think it is a really good proposal and would recommend someone check it out
mt: tested for breakage?
miketaylr: I've been running with these flags for month and good so far. There is also some real data we'll send with intent to ship
John W: Do you mean when it is bound to a secure scheme do we synthesize it or do we change behavior
?
What about deleting behavior?
johannhof: we would treat it like secure but not synthesize that setting I believe
the proposal is not explicitly removing it right now but that might be a followup.
[slide] Third-Party Cookie Allowlist Header
does not mean third party cookies are blocked by default by anyone - if you set none in this allowlist to disallow third party cookies access to specific children. Nothing is forced it is an expression of preference that the browser reads. For security reasons if you want to disallow a particular child the right allowlist settings might handle it
This is a name of an explainer and that name on the header might not be great
We struggle to follow up on cookies work. We have a bunch of places where we can discuss it but we should do more work to be systematic and public in meeting about this and discussing next steps.
John W: cookie community group?
Well scoped
johannhof: that is worth considering.
I am not sure there are any problems?
there are so many problems to solve
John W: might be able to get cookie only people in a dedicated CG who are not interested in the privacy stuff
johannhof: avoiding the privacywg for this will give us broader stuff to work on potentially.
I will follow up on that suggestion.
Thanks all!
RSSAgent, make minutes
rssagent, bookmark
<johannhof> RSSAgent, make minutes
<johannhof> RSSAgent make minutes
end the meeting
RSSAgent end the meeting
rssagent,, pointer
rssagent, pointer
rssagent, here
rssagent, on
rssagent set logs world-visible
rssagent, create minutes
rssagent, please create the minutes
rssagent, publish minutes
rssagent, help