 Hey, hello there. My name is Ron, and I lead the Chrome Developer Relations team for the combination of security, privacy, payments, and identity on the web. Now joining me today, I've got a panel across the implementation and integration aspects of all of those proposals. So let's say hello to them as well. In no particular order, first up, I've got Michael Kleber. Michael is the tech lead for privacy sandbox efforts, and he has authored a number of the proposals, such as Turtledove, and also defining a privacy model for the web that is underpinning a lot of the other proposals. Also joining is Kostupo Bovind. Kostupo's tech lead across will be cookie-related proposals on the road to eventually phasing out third-party cookies entirely. So this includes things like chips, which is one of our RAM proposals that does not have a verb name. And also, Bart Smith, who you may remember from the keynote before, Bart leads our global partnerships team and has been focusing on making sure that these proposals are actually going to meet the needs of real world developers and that they see some real world usage before they go stable. Now you've all been filling out some questions for us in advance, and we'll be watching for new ones as you go. So wherever that button is on your screen, you should be able to add in questions for us. But what I will highlight is that because we are an implementation-focused team, that means if you've got questions on the how of privacy sandbox, great, we can cover those. But as you may be aware, there are a couple sensitive legal topics on this. So if you have questions on when or how does this apply to regulations in your country, we're not going to be able to answer this for you in this session. But that said, we've got half an hour, I promise, that is not even going to be enough to scratch the surface of all of this. So enough waffling. We will dive in to get the ball rolling. We've got a couple introductory topics that we'll use to introduce you to the speakers. So Michael, I'm going to start with you. And I've got the questions down here for us. Could you explain a bit about the privacy model and how that relates to the other proposals? Yes, absolutely. So at the very outset, back in 2019, when we started out on this effort, that has now grown to a huge number of interrelated proposals called the privacy sandbox, we started by outlining what we thought was a better privacy model for the web. And the core tenant of the privacy model is that instead of there being one global notion of who you are, one sort of idea of your identity on the web, basic idea is that we're trying to transition to a web in which the site that you're in the middle of visiting might have its own personal notion of some information about you, like what you've done while you're visiting that site in the past, but there's not a way to take one site's notion of what it knows about you and another site's notion of what that site knows about you and join them together. So each individual site can have its own opinion, but there's not a way to form one giant web-wide view of all of your activity across different websites. This is what we refer to sometimes as partitioned identity or partitioning in a lot of different contexts. And then of course, there's a lot of stuff on the web that is all built on top of the ability for information to flow back and forth between different websites. And so all the rest of the privacy sandbox proposals are roughly trying to figure out what information we still can let move around in order to make the web more useful to people while not violating that partitioning between what happens on the different websites that you visit. Cool. And I guess actually like one of the things when we say identity, we don't mean like I'm literally signed in as the same person on both those websites. We mean like not enabling, not enabling cross-site tracking between those websites. Yeah, that's exactly right. Identity is a tricky concept, but you're right. What I mean is that every individual site that you go to might have some idea of what you've done before on that site. They might remember you from one visit to the next visit if you come back the next day or the next week and they might know whatever information you've told them about yourself. And if you've told them your name and credit card number so that you can buy something from them, then that's certainly information that they might know about you. But the information that they know about you is sort of limited to what you have told to that particular website. So that leads nicely on to our next question because for you, which is kind of around the main enabler of cross-site tracking which is cross-site cookies. Now we've said that we're on the path to phasing out support for third-party cookies. And we have these new like chips and first-party sets proposals. So looking at those, that does mean that we still have like some availability of a cross-site cookie but in these specific use cases. So could you tell us a bit about what's the difference with these use cases versus the like phasing out third-party cookies? Absolutely. And I think it's important to reiterate the principle the privacy model principle that Michael stated just earlier which is that the core principle that we're talking about here is that identity is partitioned by the top level site or the top level party. And really, I know we talked about like the term identity can be overloaded. I personally prefer the term session identifier but it might be maybe just a little too technical but that's what cookies were originally actually invented for, right? Like you need an ocean session, you lobbed into your bank, you're buying something, you have a shopping cart that's what cookies were meant for. And cookies are really useful, right? They, we've seen what the web can do with them today just the innovation that they've caused as a general purpose primitive. I think what we're doing with both the proposals that you talked about Rowan specifically first-party sets and chips is really helping conform to that principle and finding a way that developers can keep per top level first-party identifiers or session identifiers within the concept of that sense of charted identity or partitioned identity. So with respect to first-party set and typically traditionally on the web, the notion of site has actually only been defined by the registrable domain of the top level site but we know that in the modern web, actually that's just not enough because the sites have CCTV variants like you might have Google.com, Google.co.uk, right? That's one example. There are businesses that have vanity or branded domains where you might wanna maintain different brands because your domain name after all is kind of a brand identifier. It's a brand indicator. So businesses do like to keep those around, right? And there's, you know, for security reasons, sometimes you do want to separate content because things like cookies could be accessed by other applications that might be in the same domain. Sometimes you have tools like password managers that will actually scope user credentials to the same domain. So if you have multiple applications, there's always a chance that a different application in the same domain could capture your credentials. So we wanna make sure developers can keep doing that. Like if you have user uploaded content or untrusted content that you're hosting, it's important to still be able to continue to separate that into a different domain. So we know that there's a pretty diverse set of use cases where there's the same party that's, you know, hosting their site across multiple domains, right? For a variety of reasons. So what First Party Sets does is really allow you a really nice way to say, hey, these are all the same site. These are all the same party. So let me have the same notion of session identified across that entire party. So that's exactly what First Party Sets allows developers to do. And then moving on to the other proposal called Chips, which is my favorite proposal, of course, you know, we tried to rip off of cookies another snack. So it stands for cookies having independent partition state. And really those are cross-site cookies, the interesting thing is that it's partitioned to the top-level identity. So if you have a third party on your site, for instance, a SaaS service, what SaaS services typically need is actually just a session identifier that's scoped to the top-level site. So what Chips allows you to do is that that same SaaS service can say, hey, all I need is a partition, their partition cross-site cookie. They get a different copy of the cookie depending on what top-level site. And that's actually works for a lot of use cases on the web and it preserves the dynamic web that we have. That's highly composable where websites are able to delegate aspects of the website to other parties. Nice. So as in, if I want to like embed a widget from somewhere that maybe like saves some preferences or has a session, then I can still do that because it'll just be like respected to my site. Exactly. And that's a perfect example. Yes. Cool. Bob, so this one's for you then. We've got, this is slightly wider, the sort of what should I do to prepare for third party cookie obsolesion in Chrome? But I feel like that is a pretty broad question. So like first, I think we kind of need to talk about like what's the expectation for developer testing there who should be getting involved at these early stages and how? Yeah, that's a question that we get often and I hope that we are doing a good job of getting the word out about the opportunity to test these new APIs in origin trial and test locally. And it is important for the success of the capabilities and for individual developers and sites to participate in this early testing process both from an individual developer organization standpoint being able to start to through testing work through how these APIs might be integrated and work in your existing products but also for the success of the APIs of the ecosystem. We want to get a representative set of developers and companies testing the APIs, providing feedback while they are still in this relatively nascent stage. And also a lot of the developer testing at this stage helps inform not just the direction of the API but as you know, we're at our developer guidance and what we learn from different developers and companies in testing just makes the APIs better, more complete, more robust when they land. All of that said, we also know that there are a lot of companies who are being exposed to this process for the first time and we also want to make clear that you need to have an appetite for experimentation if you are participating in origin trial testing because the APIs that you test may be different from the final version that launches. They aren't fully baked, fully documented, fully ready to go live APIs. And so we also want to recognize that it is a perfectly rational choice for some companies to say, you know what? I'm gonna wait until they're a little firmer and a little more hardened. It's just, I think the main thing is to make sure that that is an informed choice. That is an organization, you're looking at the API, thinking about how relevant it is to your use case, perhaps whether you have a more unusual use case in which case it might benefit for making sure someone like you test it and then deciding whether it makes sense for you to invest in testing it now or just to track its progress and test it or implement a little bit further down the road. Nice. Well, that actually brings us on to the first of our live questions. So I hope you're all prepared. This actually leads on quite nicely. So this question is from James, asks, a lot of proposals focus on advertising, but what about the other ways that third-party cookies are used? So premium video embeds, single sign-on and so on. But, Christopher, do you want to jump in first on that one? And then we can also talk about a few of the other things we're aware of out there. Yeah, I can get started. So yeah, cookies have existed, I think, like 26 years now. I forget the code, but they've been around a long time. And like I said, they've enabled a lot of innovation in the web. And I know that there is a variety of use cases that use third-party cookies, and we are working through them to try to find the right solution for them. For instance, for embeds, I think the specific use case that was talked about was premium video embeds, which is you're signed into that video provider. And I think it's the term that I use for that specific category of use cases is actually authenticated embeds. So there's a couple of different proposals that I think could be at play here. One is how do you log in, right? Because when you're talking about a premium experience, you're typically talking about a longer experience. So we have a proposal called WebID that we're working on. It's a new API for federated login. And so that's one of because federated login is the notion where you have cross-side identity, you have this identity provider that needs access to that logged in state, where you've logged into that identity provider, being able to know who you are and then sort of delegate that identity to the relying party or the website that you're trying to sign into. So that's one API that I'd recommend looking into. The other API and specifically with the respect to embeds, the other, this is really, really early stage. And it's where inviting feedback and listening to feedback and trying to understand how folks use this is fence frames. So we're thinking about if there is a way to embed content in a way that the embedded content couldn't exchange user information with the top level site. But again, it's really early phase. It's called fence frames. And that's another one I'd recommend looking at. Do we have any other use cases we will now throw in that are sort of cookie dependent but not ad related at the moment? I think chips actually like partition cookies solves a lot of the ones where you have, you have a lot of sastel use cases that need that partitioned identity. So I think, yeah. Yeah, actually, I know when I've been like dealing with developer questions, like that was the one I was waiting for because that was kind of like, most of the things you're concerned about are actually going to be fine if you partition it to your site. But like you say, it's these ones where you really do want that relationship with a completely different site going across all those sites, like identity that it becomes an issue. Yeah, there are other examples certainly where there are use cases that are inherently things that go across a lot of different websites. One obvious one is, for example, paying for something where there is some notion of your account that you're going to use for paying things and you may want to use it on a wide range of different websites. And that like a lot of the other Privacy Sandbox APIs, the answer is the web should have a dedicated API that really understands the notion of you being in the middle of trying to pay for something that really takes the idea of what it is that you're trying to do and builds it into the browser as opposed to the kind of historical technique where cookies were used for everything and it was very hard for the browser to understand or help or restrict in any way the way in which they were used. So the web payments API is the work that's in progress in the W3C right now that is attempting to solve for exactly that sort of use case. And that's very much in line with the rest of the APIs that we've talked about in some cross-site use case and then figure out a way to directly support that deliberately. The other one that we've seen is anti-fraud right? Like there are payment providers that actually use third party cookies today to kind of build in anti-fraud solutions and a proposal that we're actually that's in Origin Childs that developers are experimenting with right now is this API called Trust Opens. It's a really cool like cryptographic back token which I don't think I'm qualified enough to honestly do a great job explaining but really it creates like unlinkable tokens where the party that authenticated you can issue tokens and then have the site redeem those tokens. You can redeem those tokens on a site and sort of prove that you're a human or essentially convey a sense of trust across sites without revealing user identity. Today that's done in an identifying way but Trust Opens reveals two and a half bits to be precise today as per the current design so it's a really, really small number of bits but it's enough in a lot of cases too, in a lot of anti-fraud use cases to convey that notion of a limited sense of like how much can I trust this user. Yeah and actually I guess that raises some of the work that I think Bob and I will be doing a lot of is that some of these APIs you can almost see how they're like a direct replacement for the cross-site tracking related thing but other of these APIs are sort of introducing like a more lower level component and there are ways that we're going to have to like explore the new use cases and the new user experiences that we build on top of those at the same time. So it's not always a direct like lift and shift replace this thing. Great, next up then sort of stay on some of the W3C topics so this comes from Alexi, what if other browsers won't support these functionalities like Rayman Vivaldi won't support Flock. Yeah so all of the functionalities that we are talking about as part of the Privacy Sandbox are going through an extensive discussion and evaluation process mostly in the W3C as you just mentioned as Barb said before these are all right now in a relatively early stage of development in which there's design decisions that are still happening right everything is in this stage or a lot of things are in this stage called origin trials in which we have a first proposal for how something might work that we're trying out in Chrome or maybe a proposal for how something might work that we're not even at the point of being able to write code for yet but there's ongoing discussion of fundamental changes to everything about the way these APIs could work and that is the stage at which we expect and hope that we get contributions both from members of the web developer community who can talk to us about what makes the new proposal more suitable or appealing for their use cases and from other browsers in which they talk to us about what sorts of changes to various proposals would be needed in order for them to gain wide cross browser support everything that we do is something that we do want wide cross browser support for eventually the web is one web and it's supposed to work on all different web browsers and nobody who develops any web browser whether it's Chrome or any of the other ones wants a web in which some things work on one browser and other things work in a different one it's definitely our goal to end up with something that works across the entire web as we go into the future right and I'd like to emphasize I think Privacy with Sandbox really is a collection of proposals it's not just Flock it's not just the APIs there's a whole bunch of things in there and we talked about partition cookies for instance in there and other browsers are also working on similar notions and we take the responsibility of being a browser renderer to your rate it's the web is large it's expansive there's all these sets of applications and businesses that depend on it so we are very engaged like the Privacy Sandbox developer team the engineers as well as partnerships developer relations all of us are very engaged with the community both in the W3C the IDTF you know and any public forums where privacy web and privacy are being discussed so we I think all of us do and you know sincerely all of us do want to move towards a web keep the web that's interoperable right across the so we are all having spirited discussions in the W3C but our hope is that we eventually converge on the solutions for the space I guess origin trials especially are a nice reminder that we're not coming to this with like fully formed polished product ideas we're coming with explicit experiments that we're trying to we're trying something out to see if this is going to fit the use case that we need okay next question this gets into the the ones that I warned about so I think we'll have a partial answer here and Bob I might hand this one to you this one comes from, oh this is from James could be the same James could be a different James what is the latest timeline for getting rid of third party cookies and wider adoption of these proposals thanks for pitching that one to me Rowan I'm happy to speak to it actually I think well I don't have we don't have an update to share today I think where we understand where this question is coming from and as we you know as we hear in broad public channels and also in the W3C and in partner conversations we understand that organizations are looking to plan and and this really comes from an interest on the part of developers and companies in having an understanding of what the future looks like and in the ability to plan their testing and implementation of the new solutions and so what I can say is that we are hearing that we're hearing that both in a general sense and we're hearing that from ecosystem stakeholders who are sharing input and feedback on what it's going to take for them to test implement and integrate the new solutions when they're available and so the reason that we have chosen to take the approach that we have which is implementing the new solutions making sure that they're working first before we phase out third party cookies in order to minimize disruption in the ecosystem is one that we take seriously and one that we wouldn't want to undermine and so what I can say is that we are as we're evaluating our progress as we're again because this is an open collaborative process we also don't control all of the timelines for when things will be ready and sort of what they'll look like and exactly what the future is we are very much keeping in mind this interest on the part of developers and of the ecosystem in getting information when we have a level of certainty with which we can communicate it and so we will definitely continue to provide updates on progress and timing as the work moves forward okay next up this is actually from James again we're doing a lot of James questions I'm going to assume that they're actually different James's so we're not playing James favorites here but this is a nice kind of carry on from that next one so are there plans to inform users about what's happening behind the scenes with these new proposals for example which traits their cohort might represent Michael I think this is in your territory yes this one seems to be about the proposal called flock which is one of the large number of proposals that's one specifically about ways to do add targeting when third party cookies and the profiles built based on them are not available anymore the flock proposal is some way that the browser can cluster similar people together and make it possible to understand something about a large group of people for add targeting instead of learning anything about individuals so again flock is an origin trial and we're just at the early stages of things and everything about how flock works is still very much subject to change one of the things that we don't have a code for in Chrome yet is something that explains what the flock means and that absolutely is something that is going to be part of the UX work that kind of improved user interface and user experience for how things are going to look once we have an answer to how should flock work and what technique will the browser actually use to cluster similar people together and what will they mean so the answer is yes it definitely will be possible there will be information available in the browser or in some other way to understand what it is that whatever proposals we use what information they're keeping and holding on to about you and information about how ads are able to be targeted to post third party cookie future but we don't have that ready yet because we don't even know what the answers are and so while we don't know what the answers are it's very hard to design a good user interface that effectively communicates those answers but it's definitely part of the ongoing experimentation. Let's move on to this is Christian asks a QM one up for you this is a bit of like understanding the current situation so how does social login work some identity providers do not only send cookies to authenticate the user but also tracking or advertising cookies so is sign-in still possible? Great question I think there's a few different layers to the question but the first is the mechanism that are used today to do login is actually third party cookies federated logins are possible because of third party cookies at the same time of course they do enable other things like personalization so WebID as I mentioned is the sign-in federated sign-in API that we're looking at right now so that should the intention is that that API will still sign in and the implementation as we are proposing it right now actually asks the user did you really need to sign in to site.com with this social login.com so that's absolutely still possible with this new API and we're making sure we're building the right set of privacy guarantees and so we can make sure that these are expectations so we're into our final few minutes I know we actually have had quite a few questions coming in I know we haven't answered all of them we do have the other Dory for other technical sessions that we'll be answering some questions on we also have a support repo that you can find us on there's a short link for that which is goo.gl psds so privacy sandbox developer support but to wrap us up I was going to ask one of my questions possibly the most important question out of all of this Michael why are all these proposals named after birds okay sure that is largely my fault not exclusively my fault but yes at the beginning it made really good sense when Flock started the idea of letting ads target not individual people but a large homogenous group of people kind of like a flock of birds was sensible and we came up with a slightly perhaps acronym that made sense it sort of took flight from there I'm afraid there were a few other proposals like pigeon kid it was a proposal I'm sorry pigeon was another early proposal that has gone away since then but at that point it sort of became table stakes and we put out another two bird name proposals and a flood of them followed so now it's just required stakes for coming to the game in the first place amazing well I have the production team telling me that we can't have any more of these puns going on or we will be taken off the air so I wanted to say thank you to all of you for answering this, thank you for all your questions coming into us as well and we will see you again soon so see you around