Hi, my name is David. I'm a technology evangelist in Apple's worldwide developer relations team. I cover privacy and security, and my job is to talk to developers about privacy and security, so I'm super happy to be here. Thanks for tuning in today to ask questions about privacy and security. You tuning in and being here with us is what is going to allow us to have a great conversation, Ask questions, upvote questions, and really when you chime in, it's going to help us talk to you about the things you want to talk about. Privacy and security is our favorite topic, and I've assembled an awesome panel to talk to you about it. I'm going to ask each panelist to introduce themselves and then tell you their focus and then tell you about their favorite privacy and security feature. But first, I'm going to tell you my favorite privacy and security feature. It's passkeys. I love Passkeys, how simple it makes, everything to log in, and how much it protects everybody from phishing. Thank you, David. I love Passkeys as well. My name is Yash. I am a security engineer at Apple. I work on a number of our platform security technologies. A common one that a lot of you may know about is code signing. And I would say one of my favorite privacy and security feature is developer mode. Developer mode. Good one. I'm Katie and I lead our privacy engineering quality and tools team and I think my favorite feature is advanced data protection. I'm Dan I'm a engineering manager in our security engineering team specifically our secure design team we make sure that all of the features that you use as users are secure when you use them in the same way that Katie's team helps make sure that they are private And my favorite security feature is stolen device protection. Thanks, Dan. My name is Rohith. I'm on the privacy engineering team, and my focus is on hardware and sensor privacy, so things like camera and microphone. My favorite security privacy feature is iCloud Private Relay. It's just an incredible technology, and I encourage anyone who doesn't really know about it to read up on it. It's quite impressive. Thanks, Rohith. Hi, I'm Emily. I'm a security engineer on the secure design team with Dan. My primary focus is private cloud compute, and coincidentally is also my favorite security feature. Easy peasy. All right. I'm going to jump right into the questions. Again, thank you for asking them. If they're important to you, click that upvote, and we'll talk about as much as we can today in the hour that we have. Some of us wish we had two hours. I hope we were talking about it. Our first question is from Tanya RNDT. I don't know. Tanya? Tanya, maybe. I don't know how to say that. Thank you for asking. How is Apple ensuring that models are not hijacked through prompt injection techniques? Who would answer that? I think I can probably take that. So firstly, it's important to note that with a lot of these new agentic technologies, It brings a whole new category of security and privacy risks. One of these is an attack called indirect prompt injection. So some of you watching may be familiar with prompt injection, which is where you can try and make a model do something that it's not supposed to do. Indirect prompt injection is an attack where an attacker can send, say, a malicious document, which contains some instructions or a message. And then when the user goes to use an agentic tool, it will read that into its context. And then it might cause that model to do something that the user wouldn't want to do. This kind of relates to a model that's been kind of discussed externally by researchers called the lethal trifecta. Like models are at the most risk when they have access to your private data, when they can perform actions, and when they have access to untrusted context. So when we were developing features like Siri AI, we spent a lot of time figuring out how we can best mitigate this. And this is a new area, so we did a lot of really fun and complex and innovative security engineering and privacy engineering. And there's a range of mitigation strategies we use, and we use these in combination. We use some deterministic mitigations, such as confirmation prompts that the user might have to tap on. And we also use probabilistic mitigations as well, such as spotlighting in a prompt, so highlighting where a prompt may contain some untrusted content. And we actually have a really great WWDC session on this topic. So if you go into the developer app, you'll be able to go and find a session. It's around securing agentic features in the apps that you are looking to build, and it covers a lot of these same topics. Excellent. Moving forward, another question from the same person. I'm not going to say the name this time. Ty Arnt. When my app sends user data to private cloud compute or to a third-party model like Anthropic or Google through the new language model protocol, what actually happens to that data? And what do I need to tell my users about it? I like this kind of secure and private there. I think this one might be for Emily. Yes, absolutely. So I can definitely talk about PCC, and I'll do that in just a second here. For any of the third-party AI APIs, though, our PCC guarantees won't apply to those. So if you send it off to Anthropic or Google or anywhere else, we can't guarantee that. But if you're using our PCC interfaces through the Foundation Model APIs and others, other interfaces that use PCC within our APIs, you get all the full backing of PCC. This includes our stateless computation guarantees as well as the non-targetability guarantees that we have with private cloud compute. So when a user's request goes into private cloud compute, we cannot target that user in any way. All of this is backed by our enforceable guarantees as well. So this is all cryptographically provable as well, which means that you as a developer or any security researcher out there could download all of our documentation and tooling and actually prove that we're actually backing up everything that we say we're doing for PCC. Well, and I think one other thing to talk about with PCC that all of the technologies Emily talked about enable us to guarantee is that when your data is sent to private cloud compute, whether it's with Siri or other features, that it's only used to fill that request, and it is not available to be seen by Apple or anyone else. Yeah, absolutely. Apple does not collect your data at all with PCC. It is on that node, and when we're done with that, it is removed from that node completely. And if the node reboots even, there's no possible way for that node to retain any of the data either. I was going to add, that's a little nice tidbit to add there, which is we run in this sort of ephemeral mode where every single time you reboot the system, the volume that can hold data persistently across reboots is always wiped away and clean. And again, provably attestable. We prove to everybody that it is that with the attestations that come from each of the nodes. Yeah. And Emily touched quite a lot on the first part of the question, but I just wanted to add for any developer who has decided to integrate with any third-party APIs to make sure you're reading and understanding what those companies might be doing with your data, but look at their terms, look at any other documentation that they have, because it's very important to make sure that you understand how your user's data might be treated. And then you also are clear to the users with anything that you find out when you look through that. So then they also understand and can make the right choice for themselves. Making it clear. All right, move to the next question from Claire Casey. Thank you. What distinction does Apple draw between data I collect versus data a third-party processor handles on my behalf? My voice and photo features in my app send data to outside services purely for processing. Do those count as my collection, theirs, both, other? I think this question might be around nutrition labels a little bit. And so maybe for people who are a little bit less familiar, we have a feature in the App Store called App Nutrition Labels. And just like a normal nutrition label, this is something that makes it easy for users to compare two different apps, get to see their privacy practices, what data they collect. So this question, whether it's linked to the user's identity or not, what are the different kinds of purposes that you use it for? So you are responsible for declaring all data that is collected from your app, whether it is sent to your servers or some other company service. So it really ties back to the thing that Rohith just said, where it's your responsibility to understand what are those third parties doing with that data, what are their uses, so then you can correctly represent the total picture of your app to your users. All right. Moving on to Scott G. AI models do not always do what you expect. What security risks are there when using the new agentic coding features in Xcode, and what are the best practices to mitigate them? I can probably spend a bit more time talking about on this topic. So this kind of relates back to the question that came up earlier around how we've protected against prompt injection risks. So whenever we design any of these features, so not just Siri AI, but also the features that we've added to Safari, the features that we have in Xcode, we look at implementing these in a secure by design approach. We look at the risks, and particularly with the features in Xcode, we have some additional mitigations, such as you can allow lists, certain common tools that you would allow Xcode to or things to call into Xcode using when you use Xcode as an MCP server. So we look on each of these use cases to figure out what is the right set of mitigations that make sense for the user experience. But yeah, we spend a lot of time figuring out what we need to do to secure things before they ship. All right. Yingxu asks, what is the core architecture behind private cloud compute for cloud AI processing? For privacy-sensitive apps, there's always an underlying worry about cloud safety. How does Apple mathematically ensure no one can see this data? And how do we verify that there are no hidden flaws? I think it's just more in-depth. Absolutely. We would love to go in-depth. I could speak for hours on this. But we can click a little bit more into that. First and foremost, I will start with the – we have our in-depth PCC security guide available on Apple.com. So I would highly recommend going and taking a read through that. It's really good. I second this. And I also think we have documentation that's at several different levels. So depending on whether you want to go to the six-hour lecture by Emily, which I know I do, but if you want it really in-depth that you have that information, but there's also ways to kind of like start if you're less familiar with these technologies. But go ahead. But absolutely, you know, in addition to everything we've talked about so far about the stateless compute, the verifiable privacy and transparency that we have with the platform, we go to great lengths beyond that. Even with the new Google Cloud platform that we have for PCC as well, to add additional layers of security to enforce the privacy in PCC beyond your traditional confidential compute. Things like for Google Cloud, we must have two verifiable attestations for every piece of hardware, not just a single attestation. From two separate vendors. From two separate vendors. Thank you, Ash. That's a very important point there. So that alone is a step above what most cloud platforms actually will enforce for their privacy guarantees. On top of that, when it comes to processing various types of data, for example, as we have the diffusion capabilities for spatial reframing and other things like that at this point, we just released this week. For things like that, we're parsing images in the cloud. It's a complex data format. We go to great lengths to isolate that parsing into separate nodes that have extra sandboxing around the processes that process that data. We believe this is really important for isolating all of that processing. And sometimes it adds a little latency in the stack. But that extra layer of protection makes a big difference for the overall security of the stack. I think that's a very interesting point that you're touching on, right? Which is there's this whole platform that we've built around the idea of attestation and cryptographic verifiability. But that doesn't take away the fact that we had to harden these systems at their core, right? Outside of this concept of transparency or attestation. Like these are hardened operating systems that are purpose-built to process user data in a very safe and isolated manner. And I think that's exactly why this as a platform is so critical for Apple. This is what enables us to actually process your private sensitive data in the cloud. Like a bunch of the functionality you would think would be part of it where it was removed to help harden that. Do you want to touch as well a bit on the security researcher story? Sure. So as part of the security guide that we release, we also release a virtual research environment as part of PCC. This is a virtual machine that is specially tooled for allowing researchers to verify our claims of each of our applications. So for every application that we've got in PCC, there's a way to execute that within the virtual research environment. I think that this feature is really cool because you could be an independent researcher. You could have your own laptop at home. And you can run the exact set of software that we are running on our server platforms on your Mac in a virtualized format. And that research, I must add, is eligible for Apple security bounty. And to be clear, it is not limited to just security researchers. Anybody can download this. It is fully public, and we do not limit who can download it. And so that means whether it's somebody that just wants to understand more about PCC or an enterprise that wants to help verify our claims so that they can make our capabilities available to their users. It doesn't matter who wants to research. It's the research for everybody. And it directly really addresses one of the key challenges that led us to create PCC, which is that when you send data to a server, you don't know even if this is like a company says that they're doing one thing. You know, like you don't know if it's going to change another day. It could change at any point. And so that's why I think this is such a like amazing step forward. Really good point is like this is continuous transparency. It's not just, oh, we came out with this today. And so you can verify it today. If the back end that we use to process something changes, that is noticeable to you. And you can take that. You can take the newest software deployment and verify that once again. It's all done in real time. And to be clear, if anybody would try to compromise one of the nodes and deploy rogue software to one of the nodes, the attestation will change. That's right. And your devices will just automatically reject it. Mm-hmm. So, you know, it's, again, enforceable guarantees. Yeah, I love that. The values that Apple has around privacy make me proud to work here, but that it's verifiable. Like anyone can say it's private, but like being able to prove it and being open about it. Love it. Don't have to just trust us. You can prove it yourself. Don't just have to trust it. Okay, so a few questions have been getting upvoted, so I'm going to focus on those next. MichaelRowe01 is asking security and Swift data things. Let's see how we do. Are there any new features to do security audits of my own app to ensure that my user's data remains private and secure? I've been using Swift data with CloudKit so far so that users own their own data, but would love advice on how to audit this privacy feature. And maybe just throw in there to tell folks a little bit about why those are secure in the first place, if someone has a moment to do that. I mean, I was going to talk about how I think there are a lot of great ways to do it, but I think we've all been experiencing a new way with Genre of AI. Like, it's a great – whatever model you have, it's a great tool to use to have it look at what are your privacy and security guarantees. What do you expect that your app does? And then use it as a tool to help check that. I think it's also one thing that I'm really excited about is, you know, there's a lot of great security and privacy features. We only named a few that I would love developers to have the chance to add to their app, whether it's out-of-process pickers to help users select photos, et cetera. And they're also a great tool to help you build these things in and identify where you might have the opportunity to use a more private or secure technology. So I would really like have a conversation with your coding agent is a great thing to do. I think we also have a lot of privacy and security WWDC talks that I would recommend also taking advantage of and like looking to find these things out. Dan, you have more ideas? Yeah, I think also going back to David's comment earlier, a lot of the frameworks that we provide to developers, our intent is to ensure that those are secure by default and where we can private by default as well, such as the out-of-process pickers. So like a good example here is like when you use the network framework to make a request to a web server, when that uses TLS, we've spent a lot of time, particularly in the last couple of years, ensuring that that request uses the latest like post-quantum like cipher suites. And so, like, when iOS 26 was released last year, you could actually, and we launched support for these cipher suites, you could actually see on various sites, like, a huge uptick in the amount of post-quantum TLS traffic over the internet. And it's really cool to see that happen when we as Apple have tried to make these things easy to use where developers didn't need to change anything if they used the default configuration of these APIs. The OS was just able to default to that more secure default. That's a big thing that we focus on when we're thinking about what can we make available as part of the SDK is to make it easier for you to make your app private and secure without having to tackle some of these things that are pretty difficult. So CloudKit's a great example of if you, it's a way to sync your data between your, or sync your user's data between your user's devices. And so that is something where Apple can take care of syncing that data securely, you know, and making sure all of the, all of that works without you having to manage a server where all that data is being stored. Because that can be a lot of risk for you to take on if you're not sure about how to implement that correctly. I think one thing I would add, though, is we provide frameworks and API tooling to make all of this easy. But as a developer, this is a great question because it's something that I want to touch on, which is as a developer, you are in part responsible for the privacy and security of the users who choose to use your applications. And so it is great that you're thinking about the different ways in which you can provide that. And one of the ways is to use sort of platform native methods of achieving that, like as such as the CloudKit APIs, right? And I mean, providing information about security architecture will take us a long, long, long time. But like the two things that I will add to that is think about inputs to your application. That is one of the best ways to think about security is what are the inputs coming into your application and how much do you trust them? And then for privacy, I would always say you're collecting a user's information. Think about where you vend that. Who do you give that out to? And those two questions are great ways to start thinking about how do you build the most secure and the most private application for our set of users. And I want to stress this part because it's very important. We're all developers. You're all developers. But we're also users. You are a user of someone else's app. someone else who's a developer, is a user of your application. Think about what kind of applications you want to use and how you want applications to treat your data. Great. On to another upvoted one, kind of both sides of privacy and security here. Patita, if we are starting our journey to develop apps for Apple platforms, what are the main tools or frameworks we should be focusing on from a privacy and security point of view? So maybe we'll tackle privacy first, Royce. What do you think? And then we'll do security afterwards. Yeah, I mean, I think we kind of touched on a lot of those frameworks that we 100% recommend any developer use. CloudKit is great for syncing data between users' devices. Take advantage of secure on-device things like Keychain. We have a great CryptoKit library. And, you know, encourage your users to use Passkeys. Like all those things are very fundamental to a lot of the protections that we can provide you as a developer to help protect your users' data. But I think another thing just to be mindful of is consider if you need to have access to users' data in the first place. Because if you don't ask a user for data, then you don't have to worry about if you're protecting it, if there's some sort of privacy or security concern that could come up in the future. So data minimization is always very important for any of these types of situations. I think that's a great point. And I think the one I would add is when thinking about data minimization is what amount of data do you really need to access? Because a lot of our protected data categories, like location, photos, contacts, you can choose to, instead of asking for all of the data, use an out-of-process picker, which allows the user to select exactly which pieces of data they want to, or think about for location, do you need the information just once? There's a lot of great tools to help you pick and think about exactly what data you need. I think that's really important to call out, too, that using Keychain or CloudKit or the other first-class SDK frameworks allows you to have the security tools for classifying what level of data protection you want to apply to each of these as well. So with the data protection classes that you get for free with Keychain, you can add the right ACL to your data to make sure that it's classified at that right level. So, for example, if it's available after first unlock and then subsequently, then you can set that versus making it always available, which would be not exactly a great thing. So having those tools available to you in those frameworks is also an added benefit. Is there some advice perhaps that we should share when it comes to telemetry? I think I would – data minimization, which Rohit said, is I think where you start, which is thinking about what is actually the question you want to answer. And one thing we emphasize is what are you going to actually do once you have that question answered? Like what are you going to make a code change? Are you going to make a different business decision? Kind of moving past the like I think this is interesting to let's make sure it's actionable. You want to chime in on a couple more like strategies to think about? I think another important thing with telemetry that a lot of people probably don't think about is that you should communicate to your users what data you're using and why. because you want to at least let them make the decision because it is ultimately their data that they're kind of donating to you for improvement of your app or whatever other types of business reasons you might have to collect it. And ultimately you want to make sure that they are in control of their data. And it's good to start by thinking about what kind of identifier do you need to collect this data with? Is it actually their identity? Is it Katie? Or is it just a user? Is this a rotating identifier where we can maybe do a session-based identifier versus a device-based identifier? So I think that's a great initial question to think about. And then there's lots of strategies out there to bucket your data, de-res your data, getting back to what's the right question. And then there's great exciting tools like private federated learning and differential privacy that can enable you to collect more sensitive data, but in a way that doesn't, math has a mathematical guarantee that it can't be connected back to the original person. So there's a lot of great ways to both make great decisions how to keep improving your app, but doing it in a way where users understand, feel in control, and it doesn't add a lot of risk of you storing that level of sensitive data. I'd also make one final plug, which kind of goes back to Rohit's first comment and David's here at technology. If you're going to have user accounts, don't bother with allowing them to set a password. Just adopt pass keys from the start. Don't bother with any of the password nonsense. Just pass keys from default. You'll be in a much better place for the future. Your users will be protected. Zero to pass keys. They're designed to be a complete replacement for passwords, not phishable. So they're syncable. You can share them if you really want to. And just not phishable. And it actually, as a developer, it will reduce the frictions of your password login. So often people forget their passwords and you have to do all these extra things that actually can even incur costs sometimes because you have to process all these requests. Making it really simple for someone to log in in a secure and phishable way means that they can get at the value of your app or your systems or your accounts or whatever it is that you're providing much faster. So it's way better. I see why it's your favorite feature. I like this question, so I'm going to surface it because it lets us kind of step into some of the iCloud things, specifically some of the encryption stuff that's available in CloudKit. If a user stores highly personal journal entries, readings, or history in Swift data, what are Apple's recommended approaches for protecting that data while still enabling search and synchronization? I can take a stab at that one. So as I mentioned before, we have data protection classes, first of all. So when the data is local on device, or even before then, in the key chain, you can create a key to encrypt the data. And you can set the data protection class on that key to, for example, for highly sensitive journal entries, I would recommend something like, you know, only when unlocked. Yeah. And you can even set an ACL that says only when biometrically unlocked. so that the user has to give their fingerprint or their face to actually unlock that key. Then when storing the data locally on the device, you can further set a data protection class for the files on disk to make sure that, again, highly recommend for something like this, that you would have it only when device is unlocked. And then when you want to extend this to Cloud Kit to store the data so you can synchronize across devices, you know, we would recommend then using the, like the CK record encrypted values to make sure that the data, advanced data, for people with advanced data protection, they are now end-to-end encrypted across all of the devices as well. So I think those are some of the key features that we have for protecting data when working with very sensitive data in your application. I think the question asked something about how do we make sure things like search and indexing would work. I'd like to add that I can't remember the exact name of the API, so I'd refer people to some of the developer documentation. But we have a class of key that allows you to lock your device but keep the data available for a certain period of time. I think it's not sure if it's configurable, but it's some period of hours. And so, you know, we have those mechanisms where a user inputs their sensitive data and then decides to lock their device. If that data is encrypted and stored with this class of the key that's only viable for the next few hours, you know, that is a great moment for your application to take some background processing and go index whatever it needs to build. And soon thereafter, you know, the key is locked and that data becomes not visible to anything. Great call out. Yeah. All this talk of data classes, I say it to people sometimes and their eyes kind of glaze over. An example I like to tell them is, you know, that time when you've rebooted your phone or maybe you lost power because you used it all day at WWDC or something. And you turn it back on and you go to look at your messages or just on the lock screen and all you see is phone numbers. And that's because all your contacts are a data class that don't become available until your phone is fully unlocked with a passcode. So that's the example I use so people are going to realize what's up there. Next up, evolving this design is the name of the person. I like your username. With the Xcode AI coding features, can Xcode be run inside a virtual machine on an air-gapped Mac walled off from the internet to help improve security and privacy? I like how this person thinks. Just imagining someone in a bunker with a MacBook. Yes. So firstly, for the existing code completion features, they're entirely on-device. They work offline. In general, though, like other features, particularly ones that might use or integrate with something like Claude Code or OpenAI's codecs, like those will inevitably require your device to go out to the Internet. So it is going to vary. but certainly like code completion itself should work offline. Gotcha. Thank you. Next up from CMD Dev. How does the new Siri AI ensure privacy and security? For example, avoiding sharing private context with apps. Knowing Apple, there's definitely something cool under the hood. I assume this is a combination of factors, sandboxing, TCC, and more. Let's talk about that. Sure. I can maybe start and then I think because it uses PCC, maybe we're going to go back to Emily again. So I do think one of the key technologies is Siri can do a lot of stuff on device, but it does want to call on larger models that are hosted within PCC. And so I think all the things we talked about are one of the big reasons why we can have the power of PCC models, but also take advantage of all of the personal information on your device. It's really that combination that I think makes Siri AI special. And it's really PCC that is key to that of the context, the information from your semantic index, being able to be processed to enable you to get done what you want, all while doing it in a way that is protected where PCC is. Before we get into the PCC part, because I didn't want to talk about that, there is a lot of protection built on device in the realm of entitlements and sandboxing to make sure that the process that has access to your user data, that's collecting all that user data before sending it off to PCC, not every process can do that. It's built in a very, very secure container where your prompts get processed, provided to this very secure daemon, processes things, collects them in a format, and then vends them off the PCC. So there's great use of platform technology, all of them. My team has done a really good job over the time we've been building some of these features to ensure we have an architecture that we feel comfortable and confident we can secure using a lot of those same platform technologies that are available to developers. And even when third-party apps are involved, we make sure that the data is minimized. When you have a directive for Siri to do something, send some data to a third-party app, it's not going to just give extra data that you were not intending to donate to that app. It's very directed based on the query. Well, I think the question maybe also, or maybe David said something about TCC. There's also user choice of if you want to use location with Siri, like you can choose whether you want to do that or not. So those same technologies apply to some of our third-party apps. Yeah, and I think it's important to note, too, we try to stay on device as much as possible. But it's that big Apple Foundation model that when you have to go to PCC to use that Foundation model, that's when we go to PCC. or any other operation is just too big to do on device. Obviously, we have very powerful devices that can do a lot. And in many cases, the call to PCC will happen, and then it'll come back to the device and get more contacts if needed, and we do multi-turn. So we'll go back and forth with PCC to fulfill the entire request. So sometimes PCC might need more contacts from your device, and it'll surface, and then all of the protections Dan was just referencing on device still apply where TCC might be prompted or prompting you to okay some access to additional data that hadn't been accessed before. And I sometimes talk about actually our silicon is, in a roundabout way, one of our privacy and security technologies because it enables us to do so much processing on device and be able to then have that be a place where we can have security boundary, like all of the technologies that everyone's talking about can apply there. It amazes me all the time what our AI ML team could do. I don't know if the Silicon team gets a cool talk like this, but shout out to them. They should. Between the Silicon team and our AI ML team and what they can do to optimize the models to run on device, I'm amazed every day. And the more they can do on device, the easier my job becomes too on PCC. And also to enable developers to run their own models using things like the core AI framework that we just released. It's incredible that we have a platform or a range of platforms that are such capable devices for using these models and technologies. All right. You have all convinced me. I'm changing my favorite privacy and security feature to Apple Silicon. Nice. So we all said TCC about six or seven times in there. So let's talk about it a little bit and tell everybody what TCC is. It's always good to just spell it out because it's really, really important. Rohith? Yeah. So TCC stands for Transparency, Consent, and Control. And it refers to various frameworks and protections that we have on device that allows for apps to ask users questions to get access to additional data. So if you, as a developer, want access to the user's photos or access to the microphone for some feature that you're building, the TCC framework allows you to prompt that dialogue, and the user can make a decision. And really, the benefit of this is that we can, as a user, have very high level of trust that an app does not have access to your microphone data if it has not prompted you for it and you've not said, yes, I want you to have my microphone data. Thanks. No, I don't think this one's going to take a long time to ask, but it's very upvoted. So Brandon7269, I hope that's not your pin. Will Siri AI have a new configurable policy in an MDM solution when released? Short answer is yes. The existing or there are already existing MDM controls available to control Siri. Those should still apply. I think this is a great one to think through, how you as an enterprise might want to configure some of these tools. Are there bits that you would want to use over others? And submit a feedback request if you have proposals or ideas of how you would want it to be configured to allow you to use some of the benefits in your enterprise environment. The new Safari feature to allow the automatic changing of passwords, for example. In a lot of businesses, particularly small businesses who don't necessarily have more complex single sign-on solutions available to them, this is a great enabler to enable you to uplift your security for sites that don't yet support passwords. Fantastic feature, by the way. Yeah, it's great. Speaking about some web stuff, expanding the things a little bit here, I wouldn't mind talking about this one, user Contil. Are there any new enhancements to the Safari ITP tracking preventions slash trackers on the new OSs? Anybody want to talk about that? Tracking. So I think, you know, ITP has been a technology that we've continued to invest in for a lot of years. It continues to evolve. And I think that while we don't have this year there aren't any specific things we want to reference, I think we really think it's a technology that we think is really important and we continue to invest in over the years. And if you want to learn more about it, then you can go find out on WebKit.org and figure out more about what it can do. Gotcha. Thank you. I like this one. M3Lixer. Maybe that's some sort of elite code one I should read. How do you effectively convey to users that your app is secure and privacy-preserving without it coming across as snake oil, security theater, or unverifiable marketing language? How do you make trust observable? I like it. It's a very high-level version of things. It's great. Katie mentioned earlier, but nutrition labels are one of the easiest ways before users even downloaded your app when they're thinking about, you know, maybe this is an app that I might want to use. It can just at a glance easily verify what is this app doing with your data. If you're collecting data and you're not linking it to a user, you can make that very clear saying, you know, saying just like as a claim, oh, we don't collect any identifiable data. People may not necessarily know how much credence to put into it, but with the standardization of nutrition labels, it can have a little bit more weight. We know users care a lot about nutrition labels. I have screenshots online. And within your app also, just having more transparency to the user. If you have their data, don't hide it from them. Have a way for them to see that you have that data in their app so that there's no surprise about, oh, wow, you've collected all this information about me and I had no idea. There's a lot of things that you can do in that way to build that level of trust without making it seem like it's some sort of security theater or something. One of the things we do internally, and I think you guys do similar, is we talk about privacy assurances. And for every feature that we build and we help ensure we build privacy across all of Apple is thinking about what are our kind of promises to the user that are like simple, understandable privacy promises. And then, and this isn't really usually a how, it's a simple statement. And that enables us to look at any architecture, any implementation, hold it up to that statement and see if it still applies. And so it can really be kind of like a North store guiding light for a whole feature that everyone can kind of focus on to make sure we can hit it. And I think that that kind of specificity helps then users feel comfortable because just like it's getting a little bit more into, yes, you care about privacy. Yes, you say the right things on your website. But the more it can be something that users understand what exact promise you're making, that can help. And then consistency, like keep it up because trust is something that's not just something you earn in one day. It's something that by continuing to show up, build these technologies, invest in them, like choose to be clear with your users about how you're using their data. You know, that's where that trust will grow. It's organic. Yeah. Yeah. When we start working, like same as on the privacy side, like when we start working on a new feature and thinking about the security of it, we do think about like what security story do we want to tell? What claims might we want to be able to make? And you see some of this coming through with technologies like memory integrity enforcement, maybe not the most understandable to the average user, or iMessages post-quantum encryption, PQ3. We think about how we want to be able to talk about this, what promise we want to be able to make, what guarantee we want to be able to make. Base ID is a fantastic example of this. We know what sort of protections we want to provide to the user, but it's done in a sort of beautiful way where like you don't have to concern yourself too much about what's going on underneath. But you build the trust with a user, you know, by by making them understand that, like, OK, this feature is something really that like over time you can realize it's not just going to work for anybody's face. It works for your face. And that's kind of how you build the trust is that organic methodology of doing the right thing again and again and again. You should, you kind of want to avoid a situation where you end up like going in the opposite direction and reducing trust, particularly around like security, like demonstrate that you care about security through the security features people expect being present when they expect them to be. So like when they go to create an account, have again, pass keys or sign in with Apple. Yes. Make sure that like you are only requesting the user data that you need, like use the various like APIs we provide to avoid needing to collect more data. Like, for example, if you sell like a Bluetooth accessory, rather than giving your app access to the entire set of Bluetooth APIs, we have an incredible API called Accessory Setup Kit, which actually gives a really good user experience for that setup process. And so give the user a better user experience rather than something more complex where they give up more of the same process. And also, never try and claim that you use something like bank-grade encryption or military-grade encryption. Most users don't know what that means. And if you're doing things by default, you will generally do the same or better. And taking a page out of our own book here, if you really want to demonstrate that you're doing everything right, transparency is key. We walk the walk with this one. And PCC, we make the full PCC transparent by sharing source code for part of it. Not saying you have to open source your application, but showing the world that, hey, I'm doing the things I'm claiming goes a long way as well. Right. And, you know, a lot of that quality and doing the right thing that you're trying, that you've conveyed is spot on. But Apple's already doing it for everybody. So the more you can be consistent and like the Apple experience, the more you can lean into it. There's a giant company conveying all of this trust to developers, to customers. So if you're like the Apple experience, if you're using the Apple technologies, if you're fully integrated, that's going to convey that sense of trust that some other giant marketing budget is doing for you. So I recommend you'd lean into that. And you also leaned into like, you know, what to pay attention to and how to pay attention to it. But what's really important sometimes is when you pay attention to it. Don't ask for all of the accesses up front when someone launches the app. That's not the right time. Do it when the moment is arriving. Like when you want a picture is when you ask for some access to photos, whether out of process or whichever level of access you want. When you do it's really important because you can provide a value exchange. Like someone understands what they're doing then and you're a lot more likely to convey that without doing that. Well, and I think you're heading towards the advice of have a great purpose string. So when you're asking the user for access to something like their photos, contacts, or a particular one, explaining why you need it and what you're going to do with it, people are more likely to say yes and then be able to experience the great features within your app. Because I think if you don't explain, they can just say no, and they might miss out on maybe one of your coolest experiences that you've worked really hard to provide. And then they've got to go to settings and find your app. Maybe they should give up at this point. People don't mind managing lists. I know I've given up on apps in the past. If they ask for a camera or something like that, it's like, why are you asking for this? You didn't tell me. One of the things that's an immediate no for me is when an app requests permission for my microphone or camera, but then we have sensor indicator lights on an iPhone. We've got this light, and one of them turns on without me expecting for it to turn on. That is a big no-no for me. If a user has granted you access to the sensors on their device, make sure that those sensors are only used when the user is expecting for them to be used. Okay. One of our viewers is providing a recruitment moment for us. Username Thumb Drive. I kind of like that as a security username, by the way. I am a CS studying, a CS, I guess that's computer science student maybe, studying cybersecurity. What Apple frameworks or security concepts would you recommend learning first in order to build a foundation that is relevant to both app and platform security and the broader field? This is a question a lot of us who work in security get. It's great to have students who are really interested in cybersecurity. Like we are often also hiring for cybersecurity and privacy roles. So do always keep an eye out. We have a range of really good sources. So there's the, like, I think for a student, the platform security guide is a really, really good starting point. It goes into a bit more depth than just our, like, standard documentation or, like, information about the OSs that we produce on, like, apple.com. It goes really deep into some of the security technologies, like data protection, the secure enclave, how that all works, how that all ties together. But we also, on the security side, we have a blog called security.apple.com, which is also where you can find details about our bug bounty program and how to report vulnerabilities to Apple. The security blog has had some really great blog posts. We had the one earlier this week about extending private cloud compute onto Google and NVIDIA's hardware. Shout out, Emily. Yeah. And we've had really good blogs in the past, again, around memory integrity enforcement, around iMessage, around changes to how we do memory allocation in the kernel of the operating system. There's a real range all the way from things that are very accessible and topics that most people who are interested in security would find interesting, down to the really in-depth details about how our operating system works. Yeah, and I would add, just on a very generic note there, if you're more interested in low-level security, you want to learn about things like binary exploitation. You want to learn about reverse engineering. When you're talking about a platform, it really comes down to how well can you understand how something works, and that is how you learn whether or how to break it or how to defend it, depending on which path you want to go into. For networking, focus on protocols, learn how TLS works, learn how the internet works. Security and to a large degree, privacy comes down to you need to have a very clear understanding of how something works, and based on that is how you choose to whether attack it or defend it. Nice. not super upvoted but I love pass keys so pass keys reduce a lot of password risk but they also introduce credential life cycle problems I don't know if I really think they're problems how is Apple approaching stale expired revoked or no longer valid pass keys in the passwords app and are there plans to surface that clean up safely to users anyone want to tackle this or do you want me to go? I think David. Well, this one has been solved. There's a new set of APIs called the Signal API and those will signal your app or website that things have changed and you need to do updates. This has been considered. Passkeys is part of a wide standard and if you watch what the standard is opting towards, Apple is part of that standard's governing body, and we're all working together across companies because pass keys don't work unless you can sync all over the place. So we're working across companies to make this work great. Answered my own question, so I have to look down here for a bit and find another one. D. Varevkin asks, I'm researching best practices for protecting sensitive data in memory. We cryptographic keys. Does Apple recommend encrypting secrets while resident in RAM, or are platform protections generally considered sufficient? I think this one might be for me. For macOS, we specifically provide functionality called hardened runtime, and we highly recommend everybody who is privacy and security conscious to enable this functionality. With hardened runtime, your application memory cannot be read by anybody else. Somebody can't try and map malicious or unsigned or unverified code into your process's memory. So we have a very, very secure operating system on macOS systems. And so there's many paths that you would say that an attacker would take when trying to read a process's memory. But the most common ones tend to be you spin up a thread in a process and then you attempt to read information from that. Or you attach a debugger and you try and read information from that. With hard and run time, those things become not possible. And the protection is guaranteed deep within the operating system for those things. So that is the first thing you should do. If you're even asking the question of how do I protect my in-process memory, well, you start with hard and run time. When it comes to things like encrypting in-process memory, you should really ask yourselves, is encrypting the right question versus destruction? If you have something that needs to stay in memory, but for a very short period of time, encryption is not the answer. The answer is you have a token for something, and once you've used the token, you should destroy the token because you don't need it anymore. When we consider extended periods of time where we want to encrypt something in memory, we're really talking about sort of DRM-level secrets. And in those worlds, we're not really in the realm of pure security anymore. So that would be the general advice is hard and run time, token destruction or memory destruction, and those should be the hard focuses. I'll add to that a plug for CryptoKit. When it comes to keys and other things that you're handling in memory, even if it's ephemeral keys, sticking with the APIs like CryptoKit helps ensure the lifetime of those variables. We've gone to great lengths to make sure that we zeroize the data that backs those keys when you use CryptoKit. If you try to go outside of that and do your own thing, we can't guarantee that the Swift runtime zeroizes the memory out when you say it's going to be zeroized. So definitely sticking with built-in frameworks. Don't do something that the platform does for you. Exactly. There's also something really cool that you can do with keys, which is we have our secure enclave. And one of the really cool things you can do with the secure enclave through our APIs is you can actually say, like, hey, I want this key that I'm generating on device to be bound to the secure enclave on the device. That means that if, say, an attacker compromises your app or your process or even the device, then that key won't be exportable off the device. It relies on the secure enclave hardware of that particular device to be usable. And so you can ensure that if the worst happens, that key can't be exported off the device and used elsewhere. And you can use our attestation interface as well to attest that that key is held by the secure on-clad on the device. All right. I think we're getting nearer to the end, so I'm going to ask one that can prompt a bigger thing, not to show favoritism, but maybe a privacy one to end. We've had a lot of security ones. So from KTH2, which approach do you take when balancing privacy and collecting telemetry that's useful for development? I think it's the basic thing, like we do need to track something, but how do we do it? What's the best balance? Katie, do you want to answer that one? Sure, I can start. I think one of the things that actually Craig said on stage a few years ago, which is kind of like a little bit of how we approach things in Argonaut is the idea of great features and great privacy. And we talk about that's what we're looking for is both, not one. And so sometimes to get both, you have to be a little bit creative. Sometimes do something that might take a little bit more, you know, creativity, work, et cetera. But we really can have both. And so we really use our privacy pillars as kind of a way to get there. So we think first about data minimization, which I think is really appropriate for this question, is thinking about, do you need all the data to answer whatever your question is, which we should be grounded in that question? And so do you need full-grain timestamps? Does it matter it happened at 1222 and how many nanoseconds? Or can you find out that maybe it's OK that it happened in the morning or that day? Are you trying to understand if the user did something over a week? Maybe you can aggregate. That's a great place to start. And that's really utilizing one of our other pillars, on-device minimization. And I mean, on-device processing. There we go. Smush two together. So on-device processing is really taking advantage of what can be calculated. So a lot of those aggregation and data minimization techniques can happen on device before you send it off to the server. I think then you maybe want to talk about control and transparency and then shout out our community friends. Yeah, I think first also just to like lean in on what you were saying. Aggregation is super important because not all data formats are the same. Even if you're fundamentally setting up the same type of data and you have not aggregated it, you might not realize that this time series that you're actually collecting has inherent to it some behavioral patterns about the user, for example, that you're not actually intending to collect. And so just really thinking hard about what ultimately is that question that you're trying to answer and getting the most distilled version of it can help protect users' privacy. But it also could just save on, let's say, the networking bandwidth that your app is incurring. You don't have to send it in real time. You don't have to send all that extra data that goes along with it. I mean, like one of my favorite examples of this is if you were collecting telemetry about setting alarms and do they go off. Like if you collect it with a fine-grained timestamp, you might be like collecting what time people wake up in the morning. And that's not actually like maybe what you were trying to look for. Right. And then, yeah, so transparency control, which is the next direction you're going, is just making sure users have control over whether, you know, you're collecting their data or not. You know, fundamentally it is their data. And I think I said this earlier, but it's best to make sure that users have control over their data ultimately and show them what it is that you're actually collecting. You don't want to hide all this data that is being sent to your server. Give them a little bit of an insight into what actually is being collected. I think the last thing is when you're collecting data, make sure you're taking the security and the protections of that data seriously. So I think security, shout out in two ways here. One, if the user has control and they say no, making sure that's technically enforced and you're not still collecting the data. And secondly, if you're collecting the data, how are you making sure that that's not something that attackers can get access to, et cetera? Because that's a big, big difference. And even I think we had a couple of conversations about thinking about when do we delete the data? And that's a great, you know, security technology as well. Privacy and security fundamentally have to work hand in hand to protect users. Yeah. I think that we all work so closely together on these kinds of things, and it really is like you need the technologies to be able to create these guarantees, promises that all of us and all of you want to create. What a great way to end. Privacy and security work together. I did try to type to our scheduler and try to get extended to six-hour windows. but they said no. Well, that's all the time we have for today. We're really thankful. Those are great questions. You have to let us go all over the place, explore everything. If your question didn't get answered, make sure you ask it on the forums. We all visit the forums. We have experts that answer questions on the forums. And when you ask questions on the forums, we all uplift each other because you are answers. Other people don't want to know the same thing. And that's how you go find answers that other people have asked for as well. So that's great. If you have bug reports or feature requests, go to feedbackassistant.apple.com and let us know about them. The more you tell us, the more examples you have, sample code, screenshots, cyst diagnosis, the more that's in there, just like when you work on bugs, the more we can do about it. So make some great bugs for us, bug reports for us. And speaking of feedback, there's going to be a survey afterwards for everybody. Fill in the survey about your WWDC experience, about this group lab. We're really open to feedback. We want to make a better and better WWDC experience for you, for every one of them in the future. And finally, thank you, panelists. I really appreciate just how much passion you have for all of this. It's really evident, and I'm proud to work with you all on privacy security at Apple. And thank you, David. Thank you for having us. Thank you, everybody, for tuning in. Bye.