Dan: back and forth with Kaustuba.. should we get her on one of our calls to talk this through?

[general agreement - invite for second half hour of breakout A]

Peter: taking the minutes literally re: like button

Dan: they are really focussing on the 3p cookies thing. K's intention, if we are saying that a permission prompt should be required for a partitioned cookie, then we should also be requiring a permission prompt for partitioned js storage. Her view is that this isn't what safari is doing.

Tess: the website doesn't have to do something to get that storage

Dan: can you untangle that? I said we're talking about cookies, not js storage. Yes the requirements for prompting on js storage may need to be stronger if we want to push for a more privacy sensitive web. That is possible. However just becuase they're not as strong as we want them to be doesn't mean we shouldn't be trying to strengthen them on cookie based storage.

Tess: I'll try to catch up

Sangwhan: can you gate a http header behind a permission?

Tess: no. In this case what you'd have to do is [??] access to it after the fact in js. For other storage mechanisms where you can only get them from js it's because you might have serverside state that relies on them and the reason to need them at that earlier stage.. there's a number of things about cookies that make them weird compared to other clientside storage. That's how we ended up [??] in safari with permission by default and cookies are blocked by default

Dan: I'll reach out to K about breakout A

Tess: to the extent that third parties still exist in most browsers, they are partitioned. So what does having an opt in to partioning accomplish? Chrome is the only holdout on this. This API seems not useful for other browsers.

Dan: does that include Edge?

Rossen: not necessarily

Dan: the proposal talks about safari and firefox's partitioning of cookie jar as prior art

Tess: safari tried it then backed out

Rossen: experimentation ran by maybe google folks? Is this the result? A better path forward?

Tess: we just block them now which seems to work fine. All cookies used to be unpartitioned. If you have a facebook widget on newyorktimes.com, if a facebook user visits newyorktimes.com facebook then knows the user visited newyorktimes.com. In a world with partioned cookies, facebook in an iframe on newyorktimes.com only gets the cookies for facebook when its embedded on newyork times. Doesn't get facebook if you visited as a first party. It doesn't know who you are unless you log in using that like widget. Explicitly telling facebook you'r eon that page. Facebook can't track you across unrelated sites, so better. So trying to explicitly set a cookie as an opt in.. but also unpartioned cookies

Dan: who is opting in and how?

Tess: the facebook like widget sets a partitioned cookie using this new opt in. If it doesn't then I don't know what happens

Dan: in which case facebook does get to know which article? just passively if a like button appears?

Tess: no. If a like button appears, facebook with this api can set two kinds of cookies. Partiioned or unpartitioned. In a browser that supports both, facebook will know every time you go which page you're going to because its current session cookie is unpartioned. But if facebook were to opt in to using this partioning feature then t hey wouldn't be able to. But we assume they wouldn't opt in to that..

Dan: what's the incentive for them to opt in?

Tess: this is why the other browsers just did it for them

Dan: by..?

Tess: Safari initially tried to partion cookies by default, but ended up with a couple of thorny web compat problems. There are third party widgets that anticipate having first party cookies set, and when they don't they recreate them and then .. there was a weird flow that broke. We ended up just blocking them altogether in Safari. What happens in safari is you don't get cookies or any storage, have to use the storage access api. Facebook.com on newyorktimes.com calls the storage access a pi saying please user i would like to kno wthat you read nyt articles. User says no and moveson, or says yess and you're logged in and can press like button

Dan: looks like a permission prompt?

Tess: yes, "facebook would like to know that you're browsing nyt.com"

Dan: isn't that the right approach...?

Tess: yes. Prompting the user for permission sucks for so many well known reasons. Users get a barrage of prompts and say whatever sure. There's a real concern here that the storage access api is too in your face and too frequent. I tend to disagree, unsurprisingly I'm biased, the kind of access that you're getting via the storage access api is very powerful and creepy and i think users should get enough of an understanding of that for an informed decision. Currently I can't speak to rates of saying allow or deny but it seems like users are able to make an informed decision.

Dan: is this supporting a kind of user basic function of the web that is problematic anyway? Your description of how facebook can get information out of like buttons reminded me of a famous occassion from 10 years ago where the nhs put facebook like buttons all over their pages including lists of symptoms, the kinds of pages that you might... privacy advocates cried foul, now I have a potentially embarassing disease and search and facebook already knows I'm looking at this page and that gets factored into advertising. they had to back that out. That's what comes to my mind. Maybe we can find a reference to that. This is not a great thing to have on the web in the first place - push back on that basis?

Tess: my understanding is they're assuming unpartiioned third party cookies are going away. A lower friction way to get partioned cookies than using the storage access api. In safari that gets you access to unpartioned cookies. In current safari if the nhs still had those facebook like buttons, and I was searching symptoms, I go to the nhs website, there's a fecebook like button, facebook has no idea that i'm there because there are no unpartioned third party cookies in this world, but it could do partioned cookies. In this proposal doing partiioned cookies is frictionless, they can just do it. But those cookies are partitioned. They could know that there's some user who visited these five nhs pages because they get the same partitioned storage for nhs.uk. So they could know somebody thinks they have these five diseases. They can't associate that with a facebook account without you logging in using the like button widget. In that sense, it's better than the status quo in chrome. The status quo in chrome is you have access to your unpartioned third party cookies. I don't know what to do with this. It's an improvement for them. A step in the right direction for them. A regression for everybody else.

Rossen: who?

Tess: gecko and webkit

Rossen: reading issue 75 in storage access privacy repo and following johan hoffman's logic I'm not sure I agree with you. A little bit above there there was support for this expressed by eric anderson on behalf of Edge. I'm not sure it's as heavy sided as you're positioning it

Tess: talking about the status quo, not future. The deployed reality in other browsers. Experience Safari had that was backed out would be alleviated by this. The site would know about partioning and wrote code to know about it. Bugs we had were because sites didn't know about it and had issues about state being preserved across sites. This could be used to enable people to do partioned cookies ..

Dan: coming back to the case we've been talking about with facebook like buttons on pages and some pages may tell facebook stuff that I don't want facebook to know about what articles I read, etc, would in a world where third part cookies have gone, and there is this CHIPS proposal in place, what's to stop facebook now seeing me visit pages without me having to say yes that's okay?

Tess: gets information that somebody.. it has your IP address

Dan: it can correlate that information quite easily

Tess: can probably correlate things easily already.. but this does make it easier. THey might have additional partion information that with the IP address tells them somethin ginteresting

Dan: feels like there should be an additional user optin. Not a site opt in.. this is why I keep asking about the term opt in. We had this discussion last week with Mike... who is opting in? Opt in to me means a user.

Tess: issue 75 on storage access api is exactly that. What if there was a param to request storage access that says I'm okay if my cookies are partitioned. I would like partioned access. The user would get a prompt or the UA would have some kind of preference to say I don't care about partioned cookies. Good luck with a meaningful way to tel lthe user that. But this would allow a less potentially friction experience, but still with the user opt in. That requires this in tandem with storage access api. WHich the proposers have said they don't like and don't want to do

Hadley: what's their arguement?

Tess: comprehensibility of prompt and permission fatigue.. probably other argumenets

Dan: not that they don't like that api, but the idea of asking the user for permission? because it's happening again and again? Maybe their research shows people won't answer reliably?

Tess: yeah

Peter: not following a few key points... my understanding is with embedded iframes in safari and gecko, all cookies are double keyed?

Tess: that is sometimes true

Peter: sometimes..

Tess: double keying storage generally is that's true but cookies are a weird special case. Local storage, indexeddb are double keyed in gecko and webkit. Cookies are double keyed in gecko I think. a little fuzzy. Storage access api gets you.. I can't speak to gecko's behaviour. In webkit's case you just don't get cookies, cookies are blocked.

Peter: you just don't get them at all

Tess: then you can use storage access api to say prety please user let me have cookies. If the user says yes you get your unpartioned cookies

Peter: you get unpartitioned storage? cookies also?

Tess: the storage access api when it was initially released was only applied to cookies. Didn't apply to other storages. I don't remember the current implementation state. If you get user permission you get storage that's unpartioned. I don't know what the matchup is between what' sshipping and where that will go

Peter: in theory with user permission you get access to all storage including cookies and other storage too, that would have been double keyed, but that's okay becuase user opted in. So this proposal is saying I now this cookie is partion and I'm cool with that and the browser can not block it where before it would block it?

Tess: yeah..?

Peter: If I have a facebook frame in the nyt, and facebook sets a cookie now they won't get anything under any circumstances

Tess: without calling storage access api, yeah

Peter: not even on a subsequent visit to the same site? without this flag? a normal cookie in the frame in nyt?

Tess: they never get it at all

Peter: but the theory here is they set that cookie the first time with the partioned flag, i come back next week, they will get it? but only that cookie set on nyt page?

Tess: yeah

Peter: what new behaviour is this enabling?

Tess: also hard to say too becuase the current behaviour in chrome is that there is no blocking of ordinary cookies, so the behaviour you see ends up being the same, regardless of whether you set this bit or not. When you go back you see the cookies

Peter: this proposal only makes sense when you're blocking 3p cookies. Scary where the browser isn't blocking 3p cookies and lets facebook sets a cookie that has all your user identifiable information

Tess: I'd hope they wouldn't ship this without having blocked, but I don't know what their current plan is.

Peter: there's a lot of detail in here.. I get lost trying to track what happens in every scenario reading this explainer

Dan: [writes feedback]. Should we talk about the fact that other browsers are going further? Safari and gecko seem to be blocking third party cookies.

Tess: safari is the only one blocking completely right now. Gecko does partioning by default.

Peter: safari tried double keying and that broke stuff but blocking is not?

Tess: Yep. Might be a quirk of the fact safari has always had a strictor 3p cookie policy, from the first version. The first version of the cookie policy was something like a site can only set cookies if it's been visited in a first party context. If you're a pure third party widget co and the user only ever sees you as a third party widget you never get to set cookies, even in safari 1.0. Sites were able to make assumptions like I don't have cookies, I'll never have them in safari, or I have my cookies so I have unfettered use of cookies. So we enabled partioning of cookies in embedded frames they were able to set cookies. So they assumed those cookies would be available in a first party context or another third party context, and they weren't. If they cleared cookies.. the most common case was you visit a thing as a first party, you hit "clear my cookies", and then you go to a site where it's embedded, it gets an inconsistent state. Where it either sets a cookie in a 3p cookies that it expects to see in 1p but it doesn't so it breaks. First party and thid party things were inconsistent. code paths trying to make sense of this were basically a UA check. The compat concern is probably primarily safari's. It was bad enough we had to roll it out. I don't now if we have public list of sites that broke but it was not fun for a year.

Peter: seems this is delivering a mechanism where safari could say set this cookie but double key it. I understand this is only a double keyed cookie. Which seems like an improvement? becuase it alllows you to double key all your cookies if everyone is opting into this

Tess: if it's used in conjunction with some kind of user agreement then maybe that's the case. Without a user agreement, without consent, you can't set them at all. So it would be a regression, I think, from ..

peter: Safari tried to do something to tighten up cookies, double keyed them, that broke because sites were making assumptions, so blocked them entirely

Tess: which had less of a compat impact becuase sites assume dthey weren't getting cookies in safari

Peter: if you'd had this in the beginning this would have let you double key the cookies

Tess: only for sites that opt in and nobody would have opted in. No reason to at the time.

Peter: wouldn't have opted in for you because they were still getting them everyone else.

Tess: yeah. If this was gated on the storage access api then it wouldn't be a regression. It would be an improvement. But if nit's not gated on storage access or a similar prompt its' a regression for us so it doesn't make sense.

Peter: anecdotal reports saying these sites will correlate you anyway so double keyig doesn't really help in the real world

Tess: IP address is a very high source of entropy

Peter: guessing there are other things they can do to correlate

Tess: fingerprinting, IP address..

Peter: consensus to invite someone to a call as best way forward?

Dan: yep

Hi @DCtheTall. We have been talking about this in [today's TAG call](https://github.com/w3ctag/meetings/blob/gh-pages/2021/telcons/07-26-agenda.md). We're a bit concerned that this proposal is reinforcing or enabling a web feature that we might want to be deprecating in the first place? We discussed some negative outcomes of data leakage to a 3rd party without user interaction / consent which are enabled by the current regime and which would continue to be enabled in a CHIPS world. We're also concerned about the roll-out plan. If partitioned and unpartitioned cookies are intended to be supported simultaneously for some period of time then that could enable 3rd parties to work around the privacy protections. Also we discussed how this could/should fit together with the storage access API. Could we bring one of you in to a TAG call at some point to discuss further?

Present+ Kaustubha

Dan: back and forth around the user needs.. And we wanted to delve into.. we were talking about a higher level of informed consent for that kind of information sharing. We posted about the scenario that happened with the NHS putting facebook like buttons on their pages which unintentionally leaked information to facebook which could have been damaging to users which could have shown up in ads or been leaked to insurers. The question came up are there other mechanisms where third parties might be able to do this anyway so does adding an additional consent step make sense. We had back and forth about cookies vs js storage. Does it make sense to add a consent req on cookies if it's already available without consent through js storage? That's the essence. We're trying to look at it from a user needs and ethical principles perspective and moving the web in general in a more privacy focussed way has been one of the things the TAG has been looking at. It is our role to ask these questions and say if the web is doing this thing should there be some additional consent barrier. If this capability is available with js storage in some browsers - maybe it shouldn't be. That doesn't necessarily mean we should link those two issues.

Kaustubha: the uses targeted with this proposal - in the explainer we talk about resource CDNs often will serve subresources on sites. CDNs like to use cookies for load balancing, it's available in the http request and they'll read a hash of the cookie for matching it to a server and the user ends up on the same server. The other use case is SAAS embeds. You have store locator widgets. The only service some businesses provide is store locator widgets. They don't need full unpartitioned 3p cookies (unpartitioned cookies, third parties get the same cookie no matter what top level site they're embedded on). The web is composable, a lot of sites delegate services to third parties. A business doesn't have to have everything, it is okay to outsource pieces of the experience. Eg. chat embeds and maps. Those are the ones where they don't intend to track across top level sites, just need some notion of session state, and fine with partitioned state. More the SAAS and CDN use cases we're targeting here.

... Wrt to the facebook like button, that's a harm I studied a year or so ago. Yes 3p cookies make that possible, but an easier thing to fix at the time was change the default referrer policy where you cap the referrer. In every subresource request there's a referrer header. It used to be a full url by default. Then on the NHS site the symptoms or diseseas would be part of the full URL. That was the intention of that change - the 3p shouldn't get access to this. THe top level site can opt in to send the full URL. We talked at the time should we cap the referrer so in no situation can a cross site embed get access. There might be a discussion going on in privacy cg about this..

Tess: there is

Kaustubha: ruling out the default change wa shelpful from chrome's perspective becuase we learned about use cases that used it. In github you have the heroku run button - they look at the repo path and it navigates you to heroku and knows what repo to run the action on. There are payment merchants that look at the path and do anti fraud checks. SO for now we have to set the referrer policy and have the merchant top leve lsite opt in to send the full referrer header. Just to explain there are other mechanisms to improve privacy - the NHS case would have been avoided today becaues the NHS would have had to opt in to send the full referrer.

... The other thing was the permissions prompt. When we think about state in the browser there's js storage, cookies, and also httpcache - there are ways for devs to leverage httpcache as storage. It could be a couple of bits at a time, but there are ways. Generally we've been thinking of partitioning everything by the top level site. THat is what prevents the cross site tracking risk. When we created the issue we felt like the other browsers were aligned. Firefox rolled out this totall cookie protection enabled in private browsing and everything is partitioned by default, no permission prompts. Safari's storage is partitioned by default and John had an issue on the reuqest storage access repo about adding an optional param where without permission the site could request partitioned cookies - could be opt in becuase safari saw breakage with partitioned cookies by default, but not sure.

... From chrome's perspective we think we should have an opt in, that's why were proposing the attribute. 3p cookies today are used for different things. We're introducing different apis. In the ad space a big use case is conversion measurements or click attributions. In that case if we simply partition developers won't even know something broke becuase they're just seeing the cookie for that partition. Federated auth is the other one, IDPs typically use 3p cookieis, what they want is unpartitioned cookies. If we were to partition all 3p cookies by default here would be these silent failures. We're hoping to force a path of you need to opt into these new apis or partitioning so you can prepare your system sfor when chrome wants to deprecate

Tess: with safari we saw two classes of breakage - one you mentioned where they were safari specific code paths that assumed the original safari cookie policy that weren't ready to get cookies at all, and assumed they were in another browser and broke. The second is sites that would set a cookie in a partitioned state and then try to clear it as a first party. You'd visit it later and they'd cleared tehir cookies, then get into an inconsistent state where they are a third party again and see a stale cookie because they weren't clearing in a partitioned state. Some are specific to safari becuase of the historical cookie policy, some are endemic to the case at large

Kaustubha: the clear site data is an important one. If the site invokes clear site data in the partition we want to make sure we only clear the partition otherwise it's a side channel. That's another reason developers should opt in so they are aware when we call clear site data it's happening in apartition

... going back to permissions - does this need to be gated behind a permission prompt? And what is the actual syntax? Firefox is doing the partitioning by default. I think safari is nterested in opt in. Our preference is a cookie attribute becuase we don't want to force people to load js to get access to http cookies. If you have cookiies marked http only it's going to add roundtrips so we thought having a cookie attribute might be easier, everyone just deals with the set cookie header.

Dan: a cognitive dissonacne for me is a discussion of "opt-in" - in my mindset it's the user opting in and when we're talking about opt in in this and other contexts it's about the top level site opting in. I also feel like the permissions when they exist should be understandable by the end user. SO when yo'ure talking about data potentially privacy infringing data being shared with a 3p that is something that should be gated potentially behind a permission, but some of the use cases like CDNs that is something entirely in the realm of how the service is architected in the backend, it doesn't have to do with the flow of information or privacy infringing information. I'm trying to think about this from the end user perspective.

... And question about multi browser / multi engine consensus. What's mozilla's view, what's the webkit view? We don't want to see further fragmentation when it comes to cookies, any privacy related web technologies. Fragmentation can result in worse situation for user privacy becuase developers make certain assumptions that match all browsers, or different code paths for different browsers.

Kaustubha: from a survey of things that use cross site cookies, i'd wager most could use partitioned cookies. Advertisers, federated login, payments, are use cases that need unpartitioned cookies. I suspect a majority could do with partitioned cookies. So nice to have a good cross browser story for partitioned stuff.

Dan: is there something we are asking the user permission for that makes sense to them? What does the permission and user flow look like in a world where this is gated behind a permission vs not gated behind a permission?

Kaustubha: I'm trying to understand the privacy leak wrt the permission. We think of unpartitioned state as what enables that cross site privacy leak. With partitioned cookies all facebook knows is that there is a user visiting the NHS site, top level url, but can't correlate that with their logged in state on facebook. For that they would need access to unpartitioned cookies. On safari those are gated behind request access api. Something like webid also has some kind of permission. If we think there is a risk of that cross site joining that warrants a permission. Is that what the TAG is thinking? What is the threat we're worried about here wrt user privacy?

Dan: that is the kind of threat. I don't know that th emitigate you described of making the referrer only top level is necessarily... I need to udnerstand if tha tfully mitigates the risk

Tess: it doesnt' fully but does partially. In the NHS example it does prevent the 3p from learning the specific medical conditions. But for others simply the origin is enoguh to share information about the user

Kaustubha: there are two mitigatiosn we are talking about. The referrer as well as the fact this is partitioned cookies only, and no unpartitioned cookie access

Tess: do you envision there being a period of time in which chrome would simultaneously support unpartitioned 3p cookies and opt-in partition 3p cookies at the same time?

Kaustubha: yeah, we want to make sure sites have enough tiem to migrate

Tess: so sites that are migrating can simultaneously get their unpartitione duser id and set a partitioned user id cookie and set themselves up in the future for when 3p cookies are turned off

Kaustubha: we're thinking about that... what if we do a one time clearing of all 3p state? partitioned and unpartitioned at the time that chrome rolls out 3p cookie blocking

Tess: are you willing to take the user hit of logging everyone out from everywhere and having everyone think chrome is broken?

Kaustubha: losing third party cookies is going to be pretty disruptive anyway. the one loop hole is that a lot of including ad tech companies have script embedded on top leve lsite, so access ot the top level site cookie jar. What's to preven tthem from doing the same there? We clear out all state including first party? I'm unclear. I was considering putting in a section for that, but wanted to think about how to prevent that. A one time clearing of all third party state is what i had in mind. Not perfect but dissuades people form trying to do stuff like that.

Tess: Relatedly there's also link decoration protection might have to come along with that in the same time frame for the same reason. The script embedded in the firs tparty that creates the iframe can pass informaation with link decoration as well as other means. Any plans there?

Kaustubha: we're thinking about it. And talked in privacy cg. There are a whole ton of use cases, federated auth, payments, does it mean cross site POSTs should go away? It's a wide range of things, we're going to have those discussions.

Dan: you're on a website where being on the website tells the third party a lot about you. Is that something that dserves to be behind a prompt? Is it okay for diquss.com (if we're talking about embedded chat) to know that you're on a website that may be sensitive. what other additional mitigations could we imagine to mitigate against that data leakage against the users expectations? or is there another thing in the proposal which wouldn't allow for that in the first place?

Kaustubha: are you thinking more about an ad script embedded on the sensitive site?

Dan: could be a chat widget or maps or location finder or any kind of third party content

Kaustubha: if you're not signed into to disquss and they don't know who you are would you still consider.. all they kno at this point is there is a user and they are visiting that site, they don't know you your email, or that you're the same user who visited sensitivesite2.com. In a world where you only have partitioned state by default, and no unpartitoined cookies, that cross site correlation isn't possible any more. If you signed in or gave storage access then they could do that if they wanted to. But that is going to be gated behind some kind of permisson. Is it sufficient that we have a permission gated to when that site requests access to unpartitioned? but as long as they can't do that sort of cross site correlation, only have partitioned state, is it fine to give them without user permission?

Dan: we are talking about the right issues here. How do we take this forward?

Tess: we should continue this conversation

Dan: schedule a special session

Kaustubha: if you have specific questions in the meantime I can help answer them.

Dan: I feel like we're talking about problems difficult to talk about, or using terminology differently... there's value to trying to write down some of these scenarios eg. where third party content is embedded in a website where we understand what privacy infriging data might flow to that third party, and how the CHIPS proposal mitigates against that kind of harm or whether it does or whether it needs to. i feel like that's missing from the current explainer. Maybe we could work on that together.

Kaustubha: yeah. And the privacy threat model - chrome had put out a privacy threat model. Partitioned identity is okay, as soon as you have identity travelling across parititons we need guard rails in place. This is based on that principle. If there is a paralell discussion going on that might be a good place ot have it in the task force

Dan: maybe there's an issue that could be raised in that repo.

Dan: comments not responded to. Plenary.

Blocked behind First Party Sets

Blocked behind first party sets

Dan: we haven't had any movement since Aug last year. It's been blocked by FPS. But I understood there was a call in the Privacy CG to unlink this proposal from FPS. leaves comment

Amy: looks like one of the things they've brought up in the thread is that some browsers already have some implementation of cookie partitioning. Worth digging into to make sure they have looked at the prior art. I think this is in the explainer, just need to re-read.

Dan: maybe we can progress this at plenary.

Hadley: K has said they are looking to disentangle this from FPS

Yves: I think we should wait...

Hadley: same thought process. They've changed their explainer 5 days ago... has a look I think what they're saying is essentially : if a site is part of a first party set then the double keyed cookie is double keyed to the first party set rather than the specific domain but if it's not then everything operates according to domain / origin. So it works with first party sets but not dependent on them. So we can ask her if it's stable.

Sangwhan: I think it's better for the fate of CHIPS to be apart from FPS.

Hadley: it's opt in. have we talked about why people would opt in? Content authors?

Dan: is it that it will be required?

Sangwhan: regulation might require it?

Hadley: they're aiming for it to be the only 3rd party cookie there is - because more privacy respecting. But not clear on how we get from here to there.

Dan: seems familiar like discussion with fenced frames. Maybe worth asking that Hadley?

Hadley: alright.

Hadley: from K's comment from 2021 it sounds like they are expcecting browsers to enforce this. Do we know anything about buy in from other browsers?

Sangwhan: it seems like this functionality has been explored by multiple browsers - firefox and safari - similar behaviour.

Hadley: safari has double keyed cookies

Sangwhan: I think they had to revert and do a lighter version... Part of ITP...

Amy: it's in Chris Wilson's private repo right now...

Dan: Chrome status lists Safari and Firerox as having "positive" consensus.

Dan: disentangled from FPS.... new explainer merged. The issue before was too dependant on FPS. Now we can rereview.

Amy: changes are mostly removals of paragraphs...

Dan: partitioned means...

Hadley: cookies double keyed to both sites involved...

Dan: I think that's good.. Does it suffer from the same problem of why would people use this?

Hadley: I think we asked them that

Amy: 'when 3rd party cookies go away...'

Yves: opt in (by the developer) - a system could keep some state. But with the restriction that cross site tracking won't be available.

Hadley: I think we're on board with the aim - disrupting the model of an ad in an iframe being able to track you is a good thing for the user. I think we're fairly happy with how this is written out... However some info on CDN / load balancing that i haven't revived. But I haven't seen any red flags.

Rossen: last time I looked it I was positive.

Peter: in a world without first party sets what's the benefit?

Hadley: standardizes the double keying...

Yves: with demise of 3rd party cookies - its a way to not entirely get rid of them but to limit their invasiveness...

Peter: so it's a way for authors to opt in to what they get by default in Safari & Firefox.

Hadley: I read it as a half step by Chrome towards where the other browers are.

Yves: opt in per site.

Dan: they envision need for developer opt in even after the phase in.. sounds up in the air, we could ask about that

Hadley: we could encourage moving towards not being opt-in. Example