Cookie Layering

[johannhof]

Session description

We will share and discuss progress on the Cookie Layering effort, our new Cookies Internet Draft and how we can proceed to specify and standardize new Privacy features on the web such as third-party cookie blocking, cookie partitioning, and the Storage Access API in WHATWG and IETF.

Session goal

Progress updates and planning next steps

Additional session chairs (Optional)

@annevk

Who can attend

Anyone may attend (Default)

IRC channel (Optional)

#cookie-layering

Other sessions where we should avoid scheduling conflicts (Optional)

#20, #16, #32

Instructions for meeting planners (Optional)

No response

Agenda for the meeting.

No response

Links to calendar

• 2024-09-25, 11:15 - 12:15

Meeting materials

• Slides
• Minutes

[tpac-breakout-bot]

Thank you for proposing a session!

You may update the session description as needed and at any time before the meeting, but please keep in mind that tooling relies on issue formatting: follow the instructions and leave all headings and other formatting intact in particular. Bots and W3C meeting organizers may also update the description, to fix formatting issues or add links and other relevant information. Please do not revert these changes. Feel free to use comments to raise questions.

Do not expect formal approval; W3C meeting organizers endeavor to schedule all proposed sessions that are in scope for a breakout. Actual scheduling should take place shortly before the meeting.

[johannhof]

cc @annevk @sbingler @DCtheTall @cfredric @krgovind @bvandersloot-mozilla @johnwilander

[johannhof]

Thanks everyone for joining our session. Slides are here. Minutes are here.

[myonlinematters]

I cannot access the minutes - keeps asking for a pad.w3C login - my normal w3C login isn't working. Is the problem on my end or are there permissions on the doc that need to change?

[annevk]

It should be the same login as for W3C Member space, but the minutes ought not to be behind a login so let me copy them here. I used https://euangoddard.github.io/clipboard2markdown/ and didn't spend too much time looking through the result, but it looks mostly reasonable.

---

Intro:

Johann and Anne intro working on cookie layer and giving an update on what is the progress in the past year.

We would like to invite people to give feedback about standarization, things that have been missed, etc

=== Recapping what is cookie layering + what it is doing

• Problem statement from TPAC 2022: can't standardize 3PC semantics, SAA, etc without fundamental layering changes to how 6265bis and browser speces intergrate.

• TPAC 2023:  Agreed overall goals

• This year: 

• current cookie draft 6265s is moving out of HTTPWG to become and RFC that free us space to write a cookie spec to address the things we miss (layering)

• Wrote a draft Fetch PR: [Cookie Layering] WIP Requests whatwg/fetch#1707

• Reviewd all intergrations points wit hthe cookie spec in browser land, filled issues. Primary concern on Cookie Store  API

• What is the motivation for revising the spec? 

• Layering violations: wrong location for certain implementations

• Has many deferred issues

• Partitioned attribute is getting traction

• It's hard to build on for

• cookie store api 

• fetch 

• html

• storage access API

• Many non-standard cookie-related implementations that need revision :

• 3PC blocking, same-site computation that arent specified in fetch that come up in the edge cases which result in implementation diff and web compat issues

• Without a concrete processing modelling excisting it's hard to find ??? 

• can be difficult to follow where implementations and certain edge cases relating to new apis such as SAA are implemented and resulting issues (?)

• Audience Q: Does the cookie store api have different issues than the document.cookie issues? 

• Anne: We don't handle changing events really well. We need to know if the cookie is stored or tossed away.

• Johann + Anne it's unclear when these events are fired and there are not properly specified

• Audience Q: document.cookie outside the network engine content vs networking process may add more confusion? 

• Anne:  Right, in the implementation we would use cache even though we would specify as **** 

• Johann + Anne: Writing WPT is another location that help is needed, if there is not spec undertested in WPT so need to add WPT to root out differences in different browsers and 3PC blocking differences

• Some of the existing tests are also need to be done

• What did we change:

• concept of the cookie store ; our new cookie draft exposes. Specifically for browsers to interact with cookies store (deleting, storing, getting). Browser specifications need to plug in to this and at the same time provide implentation for non browser user agents. browser user agents have an extended set of functionality and features

• We would love to get more feedback on things like same site, partitioned, what would server want to have for those fields when storing/getting but maybe we could get better advice on that

• Browser user agents can define their impl in fetch, html, cookie store, and the browser parts

• is the cookie partitioned? same-site?  pass to cookie spec, need network specific info such as dom that is handled by the browser

• plug in fetch spec/html which have knowledge of the SA state, allow standardization of these that the browser has knowledge of (??) 

• Draft: https://johannhof.github.io/draft-annevk-johannhof-httpbis-cookies/draft-annevk-johannhof-httpbis-cookies.html

• Draft repo: https://github.com/johannhof/draft-annevk-johannhof-httpbis-cookies 

• Trying to be a little more specific in the algorithm compare in the previous cookie spec. Have a bit more determenistic outcomes

• find quick cookie store concepts

• define cookie struct

• take this through IETF for feedback and refine

• Next Steps/Open Questions:

• Ready for adoption (not minting) ietf, http wg

• refine it after getting feedback

• cookie store: make events work

• incorporate CHIPS/ Paritioning

• SameSite=Lax by default (ideally the spec should consolidate this different browser behavior and find a way forward)

• have spec that reflects what browsers do today

• Finish Fetch PR

• Create HTML PR

• Create cookies store API PR

• Intergrate Storage Access and 3PC Blocking semantics

• Write Web Platform Tests

• (still a lot to do :D :) 

• Back next year :)) and at IETF hopefully w a lot of progress 

• Dublin 

• Audience: ideally the cookie spec would be ready but we can process IESG feedback at the same time 

• Mark (cloudflare?): If it's ready we can do the call for adoption and get feedback from the community . I anticipate most of the discussion will be in issues

• Mike Taylor: Not having read the draft, do we have all the tech in place to test of new wpt capabilities

• Johann: Firefox safari can test 3PC blocking by default and kinda weird for chrome, and its called set storage access API (?) but we would maybe need to look at that 

• Ben Vandersloot: Maybe default behavior for chrome WPT to be to block 3PC 

• Anne: do we have something for flipping the bit for request SA? 

• Ben: yes, theres a window prior to setup to get interaction but yes implemented

• Anne: We have Cross side cross origin to test 

• Ben: Set, read cookie exists

• Johann: didn't we add it in chrome a few years ago to specifically test cookies,

• Anne: we might not actively need this to test cookies, might make it easier to w/r failing tests

• Johann: easier way to test and cleanup without hacking around DOM to clear cookies that could be easier for people 

• Mike: maybe thru cookie store, today cant tell if attribute was setand w cookie store might be possible? 

• Anne: that is kinda related, mozilla and safari are in the process of doing something with the cookie api. Not interested in returning the attributes. What does the WebDriver cookie get return, a byte sequence or a string?

• Ben: not specified in webdriver spec

• John Wilander: As a previous spec editor, site concept not clear because used past browsers (?) and we need to be careful not irk people to be browser only, should make sense in non browser context. SmaeSite=Lax by defaulkt not web compatible because not setting in Safari, only setting in chrome so servers because of user agent sniffing, Firefox had to unship it and figure out why this was an issue, both mozilla and apple cannot do this currently

• Dan: did you unship it as well?

• John:Not unshipped yet, dealing w the situation Our http stack is not staged(?? ), 

• It would be hard for developers because there is going to be a biforcation in the web platform

• Artur Janc: Wondering if there is collectively we can do to solve that problem. How do we tackle it? Is it a lost cost do the server side logic it might be imposible or we can come up with a technical sollution?

• John: we dont know the extent of problem, no telemetry to know, only based on bug reports and self-discovery QA, now believe that the long tail of problems cannot be handled, smaller sites that dont have developers to change server config, enterprise no testing capability to test themselves. make it not viable to fix

• Mike Taylor:  do you have a ballpark estimate? even bug reports 

• John: No we don't collect telemetry, we don't have real data. When bug reports start to ramping up you need to make a call.

• Dan: majority of the issue was a bug in our impl that caused massive breakage and even after that addl bugs that werent fixed and it would be a long trail of bugs

• Ben: Including websites like education, goverment, banking = things you don't want to break

• John: part of what was said of security-> mozilla and safari block 3PC by default, popups and navigation helping but CSRF invisible navigations arent helped by the Lax by default as they are in Chrome

• Johann: for top level POST, right?

• Artur: From a security perspective the SameSite=Lax by default model it protects you from iframes. ifi you have an iframe you can send credentials to a top level website

• John: Is that the ABA case?

• Anne: No, an ad can make requests to a top level site and include the cookies of the top level site

• Ben: inside advertisers iframe set cookies would be partitioned and not be sent (Cross  site request)

• Anne: 

• Dan: the Key shoud be: top level top level and not top level

• John: I don't think it would be blocked. Request to A: authority allows for cookies to be sent, then cookies are sent

• Dan: frame is navigating top site or trying to include top site CSRF treated diff from naviation

• John: sites can protect by setting SameSite=Lax

• Artur: default matters, important q if could solve. Any other way to change default model for cookies Lax, lax allowing unsafe, doesnt really make a lot of sense, set that tries to walk a line between restrictions and not breaking websites. Maybe addl heuristic to determine breakage in chrome there is a 2min post that

• Dan: That's the thing written in the spec, right? no clue didnt read the spec yet oof

• Dan :Other problem we had is when we had telemetry on cookies that rejected, we didn't know if the website would break or not.

• Johann: on the security disc, pls come to the web app sec standardizing discussion on Thursday morning, biased from Chrome side and we would love input specifically safari and also kinda firefox to get , want to get a note out from webappsec to capture cross browser consensus on how 3pc blocking should work on a. security level and looking at ABA, naviation

• John: schemeful site really new impl in webkit which also matters for security

• Johann: if there is anything we might diverge on , please bring it up. On the SameSite=Lax there is timebooked on thursdays session to discuss it

• Anne: non browser clients handled in the spec, mentioned how partitioned etc. but open to discourse, reaching out to the networking folks. Might end up as impl defined. How layering works: ????

• browsers: 

• non browsers: specific section non browser hooks and when to invoke and there will be a spec

• John:  document.cookie will be broken up? No HTTP=only? 

• Anne: http only also a impl defined feature and might be restr or not. 

• Johann: We have a parameter in the store in the spec for non browser usage

• Dan: when you say non browser what do u mean? other issues for servers too

• John: Clients

• Johann: We largely left the server guidance alone

• Anne: There is also guidance for the producers of the cookie header but not much for consumers

• Dan: Theres chapter 4 for syntax and how it should happen and chapter 5 is more about that? 

• Johann: left this alone largely and the syntax is all in place, aspirational as it explains a lot such as how max age should be interpreted

• Anne: it's not covered: What happens if you get a weird cookie in the browser

• Dan: it doesnt matter what you are going to say servers are going to be servers

• Mike: ther are issues from people wanted better guidance in the servers 

• Anne:  we should address that, hopefully will be reiterated

• Ben: circling back webdriver endpoint does return the bytes

• John: Apple not opposed to CHIPS, dont know where that came from, just increase of memory use but thats the main concern

• Johann: thanks, reach out for qs