 Welcome to Security and Privacy for the Open Web. I'm Mood and I'm a developer advocate for the Chrome team recording from Berlin. And I am Sam, coming to you live-ish from Tootingbeck in South London. Okay, first, Sam, let's travel in time a bit and understand what the Open Web means. Because the web is open by definition, right? Yeah, well, I mean, sort of. The web was originally designed to be open and transparent. In fact, Tim Berners-Lee envisaged the web as a kind of read-write medium. You know, the browser would be an editor as much as a reader. And right from the early days, the limited scope of what browsers could do helped keep them safe for, you know, anonymous, stateless document rendering. But then capabilities and expectations grew and, you know, we wanted to log in and then e-commerce and so on. And then we got phishing, malware, man-in-the-middle attacks and all the rest. Yeah, so in response, you know, we've had browser sandboxing, vicarters, HTTPS, protections against malicious sites, plugin, deprecation and all that stuff, which is great. However, some of the web technologies designed decades ago aren't being used in the simple way that was intended. You know, it was difficult in the 1990s to envisage how user agent strings and cookies would be used beyond their intended capabilities in the 2020s. And this evolution in how some web technologies are able to be utilized paired with the rising expectations from users to have more control and transparency over their personal data has led the whole web ecosystem to evaluate long-standing practices. And now, more than ever, I think, the web needs privacy and security, by default, for all users. I think we'll see an increasingly high proportion of people on the web who've never used a browser before or who are simply outside their normal browsing habits. People, you know, may be looking for information who may be in a crisis or just feeling vulnerable. And I actually think these are the hardest, most complex and most important problems to solve on the web right now. But of course, this is not easy, even in terms of user interface design. For example, how do you make quite complex concepts such as cookie management understandable for billions of users? Yes, so that's why users need transparency and control in their browsers. And it's not just browser features, right? Web standards and defaults also need to change. Yeah, that's absolutely true. I mean, cookies, for example, and data such as user agent strings that can be used for device fingerprinting and to covertly track individual users. Also features such as the referrer header that can reveal private browsing data. As developers, we need to rethink the way we handle user data. Do you really need all the data you access and is it clear to your users what you're doing with their data? Yeah, because as a developer, you're actually best placed to understand potential problems and help fix them. So, OK, let's run through today's sessions. We'll be talking about security, privacy, payments, and identity. Yeah, first up, our colleague, Rowan Meawood, has some recipes to help you manage your cookies. Whether or not you've heard about same-site and changes to cookie defaults, if you're using any kind of third-party content such as ads or you're doing anything with cookies on your site, you should definitely check out his session. Second, thinking about the cross-region web, you need to prevent information leaks, and that's where powerful protections like the COOP and co-app policy headers come in. To understand how this can protect your website, check out the great session from our colleague, Ajiki Tamura. OK, so that's all nice, but how do you actually debug that stuff like same-site cookies and co-op and co-app? Well, the new issues tab in Chrome DevTools is there to help you. The issues tab makes it much easier to find and fix problems. Instead of console message clutter, you get clear instructions on how to fix problems. So, with these sessions, you learn techniques to not passively leak your user's data, and there's a pattern here. Debugging is important, but how can you and your team develop a mindset around privacy and security and prepare for the future? Ron and I thought about this and put together strategies with concrete examples of web APIs and HTTP headers you surely know to help you make sure you're using just the data you need. And speaking of user data, a crucial entry point for this is the ubiquitous sign-in form. And this is particularly important right now when lots of sites need to be accessible to new users. Now, in my session, I'll show you how to use cross-platform browser features to build a simple email password login form that's secure, accessible, and easy to use. Just like the sign-in experience, you need payments flows to be clear and safe. So, what's new in web payments? IJ Kitamura will guide you through this. So, if your website uses payments, make sure to check this session out. Okay, so that's it for the sessions. But we'd also like to tell you about one really important initiative that we're all involved with, the Privacy Sandbox. Now, more than ever, people need to know that private data stays private. And on the other hand, people want to do stuff on the web that's private and personal. You know, you want to go shopping, use your bank online, communicate private information, and so on. Keeping data safe can't just be about constraints. We can't just say no to everything. The problem is keeping your users safe is not just about getting your own house in order. It's not just about first-party interactions because most websites use services from other companies to provide analytics or videos and do lots of other useful stuff. Most notably, ads are included in web pages via third-party JavaScript and iFrames. And ad views, clicks, and conversions are measured via third-party cookies and scripts. But when you visit a website, you may not be aware of these third parties and what they're doing with your data. And actually publishers and web developers themselves may not have visibility on the entire third-party supply chain. Ad targeting, conversion measurement, and other use cases currently rely on stable cross-site identity. Historically, this has been done with third-party cookies, but today browsers have begun to restrict access to these. Other mechanisms for cross-site user tracking are also being used such as covered browser storage, device fingerprinting, and requests for personal information like email addresses. And this is a dilemma for the web. How can legitimate third-party use cases be supported without enabling users to be tracked across sites? In particular, how can websites fund content by enabling third parties to show ads and measure ad performance, but not allow individual users to be profiled? How can advertisers and site owners evaluate a user's authenticity without resorting to dark patterns such as device fingerprinting? Well, this is where the privacy sandbox comes in. And just to avoid confusion, this is not the same as the browser sandbox architecture you may have heard of, so it does build on some of the same ideas of keeping your data safe. The privacy sandbox is a set of proposals to implement privacy-preserving APIs to support business models that fund websites in the absence of mechanisms like third-party cookies. Now, the privacy sandbox supports five core use cases for a world without third-party cookies, measurement for ads and other third-party content, relevance features for advertising, fraud detection, distinguishing real humans from bots and spammers, getting rid of covert tracking, and finally, secure and simple identity management across sites. So we need browsers to support third-party use cases in a future without cookies, but whatever happens, users need cookie security and choice right now. So how do the privacy sandbox proposals satisfy third-party use cases? So I'm not gonna go into the gory details of every single one of the privacy sandbox proposals here. Shameless self-promotion, but you really should read our article, Digging Into the Privacy Sandbox, which outlines all the proposals. But what we really need though is feedback on the proposals, in particular to suggest missing use cases and more private ways to accomplish their goals. The Chrome team is responding to feedback on the proposals on GitHub and in W3C forums, and we really hope you'll join the discussion. And this is especially true if you work for a publisher, advertiser, or an ad tech company. And if you have other questions, feedback, or ideas to share on today's sessions, ping us on Twitter at ChromiumDev with the hashtag WebDevLife. Yeah, thanks, Maud. And if you wanna get in touch, we'll be online to answer questions in the live chat during the Web.dev Live event, or you can just add a comment to this video. So thanks for watching. So let's get on with this and first, cookies.