Dan: Yves, I think this is the one I took liberty of assign you even though you weren't on the call.

Yves: I still have a few questions, need to read a bit more about the definition of session for non-secure cookies. But I think really tying cookie to scheme used is a good thing. Might break a few things, but worth it. Dangerous to have cookie that's set in http and reused in https. I still need to read the fine details, but it looks right to me.

Dan: Other people (TAG alums) who we should get opinions from on this? e.g., mnot?

Yves: It will be discussed in IETF HTTPbis anyway. I wonder if Mozilla or Apple has a position on it.

Tess: I don't think we have a public position yet.

David: Very cursorily I thought it seemed reasonable but possibly risky. Didn't look in detail.

Dan: Bump a week, or to plenary? Would be good to get input from Apple and Mozilla.

Yves: A week at minimum. Positive but want to get more details

Ken: definitely support an incremental approach.

Dan: totally agree. we also need to ensure it's subject to wide review – TAG can help.

Ken: this seems very sensible. Gives more incentive to move to https.

Dan: agreed.

Ken: We talked about schemes with microsoft. If you open something with a protocol handler, that has to be a different scheme. How does that tie in?

Ken: why does this need to be specified? Interop? Not really a whole new thing – just about moving people to https. If there's something else here than it needs to be pointed out – something more fundamentally different

Dan: Started looking at this couple of weeks back (summarizes the GH conversation between him and Mike West) Is there a standards position from Mozilla on this?

David: Don't know but there are a number of folks interested and looking at it.

Dan: It would be great to have an official standards position on it

Yves: It could be worth experimenting and see how it goes. The fact there are 2nd ... cookies it will require some coding from the site side. Otherwise I'm all for it.

Dan: Should we keep this open or record positive feedback from TAG?

Yves: Lets do that, record positive position and keep open to track feedback.

Dan: So we can put Pending External Feedback

Yves: Tess, can we get Apple's position on this?

Tess: I can ask around.

Dan: Yves, can you make these changes to the issue please?

Yves: ack, will do later today

Dan: Peter, can you bump couple of weeks again?

Peter: ac

For discussion: in general with the evolution of cookies, what is happening to manage developer complexity, what cross-browser compat discussions are being held and does the proposal adequately address existing content (especially and medium sized developers rather than only "big web").

Dan: increases the overall complexity of how to build?

Mike: I think this overall decreases complexity by aligning cookies with the other capabilities of the web - cookies are right now the only thing that spans state, scheme, origin ...

... the proposals are somewhat overlapping. But because cookies span a site - network attackers that have access to the data flow can influence their state on secure and non-secure site. They can set cookies - they can use the fact that cookies & state are available over http in order to track - and because they can influence everything that goes over plain text the network attacker...

... in order to deal with these kinds of things, we use things like origin as a boundary. Because cookies and document.domain, we have to draw a broader line. I posted something in schemeful same-site review. Difference in definition between rfc6265bis and html. HTML defines schemeless samesite. The proposal for schemeful same-site is to align the rfc's def with HTML's def. So http and https are no longer considered same site when delivering cookies.

... same site strict cookies will not be delivered, same site lax cookies will be delivered.. nested frames will no longer be considered same sites. That does have implications. We originally defined the samesite attribute for cookies to bind http and https together as as mechanism to make samesite more useful for developers. At that time, it was more common for sites to [straddle] secure and insecure. https transparency report backs that up.

https://transparencyreport.google.com/https/overview?hl=en

... other claim: it is an anti-pattern for non-secure sites to maintain state of a user. It's actively dangerous - network controls everything - it has access to everything the site has access to. The network is the site. If you're using the pattern of a http page talking to a https page then you're using this antipattern.

... the goal of these proposals is to harden these boundaries.

Dan: difference between the two proposals

... schemeful samesite is meaning of samesite and the samesite attribute...

... scheme bound cookies is a deeper change as it changes the assumption of cookies that data flows freely across any domain (across schemes)

... broader strategy we were talking about http state tokens - i got a lot of feedback that a radical shift is difficult to justify. more likely to be successful to take small steps - migrate cookies towards what http state tokens suggest.

https://mikewest.github.io/cookie-incrementalism/draft-west-cookie-incrementalism.html

... these two proposals are part of a set of proposals that move cookies to a place that makes more sense.

... a number of characteristics of cookies that are undesirable. We introduce these over time. I still think we should introduce [http state tokens] as well. I recognize that isn't a popular opinion. And changing cookies could be a path to success. the path we're taking is to introduce these kinds of small changes as the ecosystem can accommodate.

Dan: first thing is: we in the TAG should introduce a new label for our reviews "cookie incrementalism" -

Peter: I'm in favour of these changes. Cookies are part of the web from early days before people thought about security.

Tess: I like that this - aligns cookies with the samesite concept in html.

Peter: this will break lots of sites. I have concerns. I want to make sure there is a clean path - people who don't have the opportunity to transition completely - something they can do to mitigate.

Mike: it might be a good idea to talk about 2 pieces fo scheme bound proposal - one piece seems uncontroversial - separate plain text and enc text. That change will break some sites. There will be ways in the short term to transfer info from one to another. Unfortunately - those look a lot like ways to xfer info x-origin, which browsers are trying to mitigate against.

Peter: wouldn't it still be possible to set http and https versions of cookies at same time?

Mike: No - you would have to be on http to set a http cookie and on https to set a https cookie. Right now if you are on https you can set a http cookie. so that is a change.

Mike: 2nd part of the proposal - suggests it's bad for non-secure sites to save state about users... More impact : there are sites today that are not secure that maintain state about users. Those sites if they want to have long-lives sessions will have to change. My claim is that that's OK. It should allow continued use of those sites - not break - but it will make users sign into those sites on a more frequent basis. Persistence associated with non-secure sites will...

Peter: the scenario you mentioned - non-secure sites doing their sign-in on a secure page - there probably a lot of sites out there operating that way - and nobody who can update that code. And that will break this site.

Mike: yes - possible. We could decide that it's not a big deal. Another option - more carve-outs. E.g. same-site time limit cookie creation - outlined in the incrementalism draft.

Peter: we need to be concerned about these sites that will not be updated.

Mike: I also want feedback on redefinition of session - this document tries to create a different heuristic that seems like it would be more aligned with users' expectations. Seems like a good time to agree on one thing. Section 3.6 of incrementalism.

Dan: what about cross-browser support?

Mike: Mozilla has suggested that scheme-bound cookies is good in their standards position repo. I haven't heard anything specifically from webkit. There was good feedback in general at last http workshop.

Dan: The one thing that I would say is that there is a discussion from Anne about HTTPS. I don't think this is worth discussion, in particular because we are under unanimous agreement that HTTPS is the future.

Dan: The TAG is on record as being in favour of the move to HTTPS, so we can take that off the table in this discussion.

... May want to schedule a special breakout to talk about this.

[special breakout needed]