 Hey, hello there. So like I said, I'm Ron, and I'm part of the developer relations team looking after security, privacy, payments, and identity on the web. Now, what that boils down to is I'm here to give you a little flavor of the implementation detail for one of the advertising-related proposals under the Privacy Sandbox banner, specifically showing you where you and your dev team can get involved today. Now, we've got 15 minutes, so this is by no means comprehensive, but hopefully I'm going to set you up with a base for the patterns that you'll need to navigate the other proposals. Speaking of patterns then, one of the first challenges in this entire effort was defining what we mean when we talk about privacy. And specifically, it needs to be precise enough that it can be used in specifications and help us make decisions about what is in and out of scope for the work. So to do that, we've put forward this potential privacy model for the web, and the key aspect of this is sharding web identity. So let's take a look at what that means. The first concept is that identity is partitioned by first-party site. Now, what that translates to is this idea that your identity on site A is distinct and separate from your identity on site B and site C and so on. And this concept is what drives the work towards making this the default in web platform functionality, along with addressing the areas that allow joining of those identities, which in turn enables covert tracking. However, that doesn't mean total isolation. So composability is absolutely core to the web's success, and that's across enabling advertising, but also things like embedding videos, maps, running analytics, calling APIs, and so on. So first parties need a way to be able to delegate access to that first-party identity to third parties. However, the important point to note here is that it can be allowed access. So it's a privilege that a first party must explicitly grant to the third party. And likewise, that top-level identity is still sharded. So the embedded video on site A is not sharing information with the embedded video on site B. And so that leads on to the final concept, which is a per-first-party identity can only be associated with small amounts of cross-site information. And this is the pattern you'll see in many of the new APIs proposed for these existing use cases. So where previously, there would be a third-party cookie from site C that would be sent with the embedded content on site A and site B, and that would provide a single tracking mechanism or shared identity across all of the sites. And instead, the new APIs focus on using just the information required in each location and only sending the information required to complete the use case. And now, while I've drawn a direct arrow in the diagram there, that doesn't mean a direct real-time link between them. This can also be aggregate information that is separated from the individual identity on the sites. OK, so that was a little bit acrobic, but I need us to have this shared foundation. So now we can talk about how we go from the model to something you can actually implement against. Let's take a look at one of the proposed APIs then, the Event Conversion Measurement API, and see how that matches up with the model. So first a quick overview of the current process and where the issue comes in. I visit a site where I see an ad. The third-party provider has a cookie that they're using in order to track my interaction with the ad. In this case, I like the ad. It's probably one for yet another black t-shirt, so I'm going to click it, and I'm going to head over to the site where I'm going to buy it. Now, this site has a tracking pixel for the advertising service so that they can link my purchase of the t-shirt with my click on the ad and then make sure that all the right people get paid. They can check on performance of the campaigns and so on. Now, this motivation is fine. This is an important use case, and there's data that you need to make that work. The problem though, if we go back to the privacy model, is that we've lost that partitioned first-party identity. The cookie gives us a link that lets us fully join my identity on the site where I saw the ad with my identity on the site where I purchased the t-shirt and, of course, anywhere else I go with that cookie too. Now, let's see what we can do differently with the event conversion measurement API. First step looks almost exactly the same. Land on the site, display the ad, but there's no cookie involved. Instead, when I click on the ad, the API is going to record the click event and just store that on my device in browser storage. Now, when I convert on the target site, I still have the same tracking pixel there, but again, no cookie. Instead, the ad tech platform, when it serves that pixel, is going to issue a redirect with a bit of conversion data included, which is also picked up by the API and stored locally. Then, at some later point, the browser will send those reports over to the ad tech platform. So the key thing here is that the platform gets all the data they need to attribute the clicks, get people paid, measure performance, and so on. But they do it without an identifier for the individual. This also allows the API to build in additional privacy protection, such as delaying the sending of those reports, batching them, and adding a predefined level of noise to those reports. Now, I want to show you some code, because it is fairly simple and it fits on one slide. So you could see from the diagrams for the infrastructure for the whole process remains mostly the same as the cookie version. So what are we adding on the front end? Now, this code is hot off the press, because we've been updating the attribute names as the proposal evolves. But I want you to see the mechanisms involved. I've got an anchor tag there for an ad, so just a normal link. But I've got these new attributes for the conversion and reporting URLs along with a limited attribution ID. Then I've got my tracking pixel here as well. That is going to trigger the redirect to a well-known URL, which is where the service can add the conversion data. Okay. I said we were going to talk about stuff that's real and that you can try, so you should remember this journey from Hany's talk. Specifically, we're going to zero in on the prototype and experiment phase to talk about origin trials. That's the stage that event conversion measurement is at now, along with some of the others, and we've got more in the pipeline there. Origin trials are effectively Chrome's way of allowing an origin, which is your site, to opt into some functionality for testing and feedback. And what I really want to stress is the experiment part. We go to origin trial because we are depending on real-world feedback from developers to iterate on the idea. So this is not like a dev-complete beta feature that we're expecting to just roll through to stable. The feedback we get during the origin trial often significantly changes the API, and may even result in it going completely back to the drawing board as well. So this is where Hany talked about the implementer role, and that is very much our target audience here. Keeping with the conversion measurement example, if you provide a service that includes conversion measurement, or you have a first-party implementation, then you're an implementer. If you use a third-party service for conversion measurement, that's the customer role. So you don't need to take action for the origin trial, but you may still be involved, and I'll show you how. But the key thing here, it's a two-way relationship with effort and time investment. So you should be getting involved in origin trials because you want to give the feedback to shape the APIs, and you're expecting them to iterate and change rapidly. So with that in mind, see how you can get involved. Hopefully it's relatively light process. You can head over to the origin trial site here, and it is going to show you all of the active trials. You find the one you want, and you tap Register. You will need to fill out some information, unsurprisingly, about the origin that you want to register, along with some properties of where your token will reply and expected usage levels. Now, the token you'll get back is just a long string, which you then need to add to your site. This can either be in a meta tag in the page or an origin trial header in the response. Now, several of the privacy sandbox origin trials are a little bit different. So even if you've signed up for origin trials before, this bit may be new to you. This is also where the customer role is going to see some of these effects. So while I said many of these APIs are about providing those privacy-preserving approaches to cross-site use cases, which means that you are likely going to want that functionality in a cross-site context. However, you can't really get every single one of your customer sites to sign up, get a token, add it to their site, and so on. So third-party origin trials therefore allow implementers to enable the origin trial for their service when it is used in a cross-site context. That means for a conversion measurement, you'll see the little third-party checkbox. Check that. For third-party origin trials, we often do a little review before granting the token, so you may not receive it immediately. Once you do, though, and this is an important difference, your third-party script is going to be responsible for injecting the meta tag with your token on the first-party site. In other words, the site that is using your service. Do that, and you are good to go. OK, I told you it was real, so let's check it out. I am just going to show you slides, though, to talk you through it, but there is a link there, there. Yeah, there's a link there, and so you can feel free to follow along if you've got another browser window or a laptop. It is also linked from all the documentation, so you don't need to do it right now. You can jump in after the talk. So first up, a quick sidetrack into enabling flags. You don't need this for the origin trial, as the point is you can test on normal users, and you also need these particular flags, past Chrome 91, but I wanted to show you how we allow opt-in access to new APIs and behavior for developer testing. So this first flag here will allow you to specifically enable the API, and then we also have this second enable experimental web platform features flag, which we use as a wider bucket to get in progress features. Now, if you are following along, you probably shouldn't do this in the same browser you're using to watch the stream, because it will require restarting Chrome, and I don't want to lose you right now. OK, so the demo has three parts, and I tend to arrange them on my screen like this. It's a bit small to read. Don't worry about that. I just want to talk you through the process, and I'll zoom in on the important bits. We've got our example publisher site in green. If you open up DevTools, you'll see helpful instructions there from more to the demo together. There's also conversion internals in the top right. That's the internal Chrome page that shows you all the events the API is storing. And in red, we've got our demo ad tech server, where we'll be able to see the events coming in. So I see an ad for shoes here. I suspect some of us haven't had to wear them in a while, but I certainly feel like a bit of retail therapy is in order, so I'm going to go ahead and click that. That takes me to a product page where I can get ready to buy them. But before we do, I'm going to pop over to the internals page and click refresh. And that's going to show me the impression data from my click on the ad. So this is the on-device browser storage that I talked about before. You can see the extent of the data that's been collected. And if you remember the anchor tag I showed you earlier, it's those attributes that generated this. You can also always use DevTools in the demo to take a peek at the anchor tag before you click it. OK, so let's go ahead and get ourselves some new shoes. On our very lightweight confirmation page, you can see the pixel that we've got embedded from our ad tech provider. If you were to look in the network tab in DevTools, you'd also see that this is the request that goes to that dot well known URL via the redirect that I mentioned before. OK, over in internals, I also now have a pending report. You can see it's this report that is providing the link between the impression data collected earlier and the conversion data that our picks are added. So like I mentioned, sending of these is intentionally delayed to minimize tracking opportunities through timing, but the internal developer page allows us to trigger them all right away. So I'm going to go ahead and click that button, and there it is. The ad tech server receives the report with the impression and the conversion data. Now, I realize that sending two numbers from one screen to another is perhaps not the most exciting demo you've ever seen, but what's important here is the pattern. Instead of joining the identity across sites with a cookie, we've taken two cross-site events, stored them on the device, and then we've just sent the result to a third party. So that's the aspect to really take away from this. We start moving away from needing to join identity to link events, and instead create APIs that led the decision moved to your device, and it's just the result that gets sent on. OK, that's a little example of how we're looking to build our proposals that really do meet the use cases. And what I want to call out here is that the event conversion measurement API has already changed significantly. In fact, I think we may have changed the name for it as a result of the origin trial feedback. So we're really working in the open here to get something that is going to meet that balance of both capability and privacy. So if these use cases apply to your business and you can put developer time down to test them in real world scenarios, then origin trials are where we need you. We've walked through the conversion measurement one together, so I'm hoping you feel equipped to jump into some of the others. We'll continue to share details of those across our various developer channels. OK, that was quite dense, but that is if for me for now a lot to digest, but I will be back with you for Q&A soon. So let me know if there's anything that I need to clear up. And with that, I'll hand back over to Hanne. Thanks and see you later.