 Another area in which the web is evolving is privacy as we seek to curtail third-party tracking practices while preserving important and critical capabilities that enable a vibrant global web ecosystem. To tell us more, I'd like to introduce my colleague, Barb. Thank you, Ben. We believe it's important for people to be in control of their information, including their online activity. Most users believe it's important, too, with privacy concerns increasingly driving choices about what people do online. We also see regulations around the world stepping up privacy requirements at a rapid pace. And yet it's difficult for developers to meet growing expectations for privacy when so many capabilities rely on third-party cookies and other cross-site tracking mechanisms that weren't designed with privacy in mind. We need new technologies for a modern, privacy-focused web, and that's what the Privacy Sandbox is about. We're working with the web community and industry stakeholders to develop new privacy-preserving technologies that can support a healthy, sustainable ecosystem. This includes purpose-built APIs to support advertising, which is a critical part of the ecosystem and funds much of the web's content, as well as many other capabilities that modern sites need, like fraud detection, identity, or content that's customized to a user's device. Now let's take a minute to clarify what we mean by purpose-built APIs. Many of the use cases that I just mentioned were never really built into the web platform, but layered over it using general-purpose technologies like third-party cookies. The browser has no way to tell whether you're using third-party cookies for something helpful, like providing a customized experience or keeping a user logged in or for cross-site tracking. By designing APIs for each specific use case, we can ensure appropriate privacy protections, give people more useful controls, and ideally make each API better at what it does over time. Once these new APIs are in place, we'll make sure that developers have time to adopt them so that we can safely phase out support for third-party cookies in Chrome, while continuing our work to mitigate other types of tracking so that cross-site tracking doesn't simply shift from third-party cookies to more covert methods. To make this complex project easier to follow, we're sharing progress in two places. PrivacySandbox.com explains the vision, goals, and concepts behind this initiative. It also includes a high-level timeline that we're updating every month. The timeline links to each of the technologies we're working to test and launch and lays out a stage plan for phasing out third-party cookies in Chrome. The second resource is the PrivacySandbox section at developer.chrome.com. Here you'll find more technical detail and implementation guidance, including a blog with the latest updates for developers. We've just added a post with all the links and updates from this session. Now, we talk a lot about the importance of collaboration in this project, and I'd like to show you what that looks like at each stage of development. I'll mention some APIs as examples, but the broader idea is to illustrate how ecosystem involvement is shaping this work. This process will be familiar to many of you in the web development community, but the PrivacySandbox is bringing a lot of newcomers to this process, including industry stakeholders who will use these purpose-built APIs and whose expertise is critical in their development. The first stage of the process is discussion, where anyone can propose and weigh in on ideas for new technologies. There have been dozens of privacy-preserving proposals offered by Chrome and others over the last couple of years. They're all online, so you can read them, ask questions, offer ideas to improve them, and see what others are saying. To find live conversations where all of the proposed solutions are being discussed and debated together, there are a number of W3C groups that you can join or monitor depending on the types of use cases you're interested in. Here's one example to illustrate how involved this discussion stage can get. FLEDGE is a proposal to support interest-based advertising without cross-site tracking. With valuable input from privacy advocates and many industry stakeholders, FLEDGE has evolved from two previous proposals with more than 100 organizations joining W3C meetings to help refine the current version and over 200 online discussion threads. There have also been more than half a dozen other proposals in the same solution space. Through continued incubation, we hope we'll reach consensus on a path forward. And at the same time, we're starting developer testing for the initial version of FLEDGE behind a flag in Chrome so that developers can get their hands on it. Not all of these proposals will go through such an intense incubation period. Some will move much more quickly. But there's a lot of innovation happening here. These are new ideas and it can take a lot of work to get them right. The next stage is testing. There are already a handful of proposals ready for developer testing today and you can expect more as we head into 2022. And don't be surprised to see some iterative cycles of discussion and testing. Testing is important precisely because it surfaces issues or gaps that may require more work. Testing in Chrome usually starts with a feature behind a flag for developers to test locally. This means you need to turn it on in your browser to try it out. This code is often very fresh so you can expect to find some issues. And then origin trials, each running for a limited time with a limited population of Chrome users. Origin trials are public and open to all developers. You just need to register to opt in your site or service. This is when we get actionable feedback from developers on what works, what doesn't, and where those gaps are. Success at this stage depends not only on developers doing hands-on testing, but on their being willing to share what they learn. For example, Yahoo Japan recently published a detailed analysis of their test of the Attribution Reporting API, highlighting areas for improvement like the need for a better way to deliver conversion reports, which has now been added. These are the sorts of things that turn up once developers can get their hands on an API. We also hope to see companies talking about their approach to testing and how they expect to use an API. During the origin trial for the first version of Flock, a proposal to support interest-based advertising and content, we were pleased to see companies like Cafe Media publishing their analysis and insights so that others could see what they'd learned. And Chrome tests aren't the only way to explore how new technologies might work. Some companies are also building simulations based on Privacy Sandbox concepts. Advertising platform Crudio recently ran a competition with more than 150 teams testing different machine learning models to evaluate how differential privacy concepts, such as noise insertion and aggregation, might impact advertising performance. It's helpful to examine these concepts since they underlie several of the Privacy Sandbox APIs. We are truly appreciative of the companies investing their time to test these new technologies and of their being willing to share their perspectives and learnings publicly. Now, once an API is tested and ready for general use in Chrome, we'll announce the launch and make sure public documentation is ready for scaled adoption. User Agent Client Hints, or UACH, launched in Chrome earlier this year and is now ready to scale. It's part of the Privacy Sandbox work stream to reduce covert tracking such as browser fingerprinting. But first, let's back up and take a look at the legacy mechanism it's replacing. Like cookies, the user agent string is an early web feature. By default, it provides a lot of information about the user's browser and device, making it a readily available surface for fingerprinting. It also has a format that can be a headache to parse. We recently announced plans to start reducing the granularity of information available in Chrome's user agent string, starting in April of 2022. To get that information in the future, you'll need to transition to user agent client hints. It'll give you some information by default which may cover most of your use cases with more detailed information on request in a straightforward format. We were happy to make this ergonomic improvement for developers while at the same time moving the majority of user agent information from an available by default model to an on request model. That way, you can request only the information you need, which is good practice today and the pattern we want to set for the future. So let's go back to the timeline I showed you a moment ago. Gradual UA string reduction starts in April of 2022. The replacement solution, user agent client hints, has been launched and ready for scaled adoption since March. So you can begin testing and migrating to it anytime now. To help with that, there's an origin trial to opt in to the reduced UA string early so that you can see what that future state will look like. And if it turns out that you need more time, you'll be able to opt in to keep using the user agent string as is through March 2023. The details of this plan are all online, and while the scaled adoption stage might not look exactly like this for other APIs, you can expect to see consistency in the overall approach. We'll continue to explain what's happening, provide as much visibility as we can, encourage your involvement, and hear your input. We appreciate all contributions to this complex and vitally important project. As we seek to create durable web features with broad utility and strong privacy protections for users, it's worth this effort to get the foundations right. And Ben, I will hand it back to you. Thanks, Barb. The Privacy Sandbox is one of the largest efforts we've seen to evolve the web. We believe that it's critically important to help ensure the web's continued health and success for decades to come.