 Welcome to the Chrome Enterprise Technical Community Hour. Today, we'll be talking about Policy API on Chrome OS. My name is Rich, and I'll be your host for today's presentation. Joining me today, we have our speaker, Ankur Mathur, who's a product manager for Chrome OS. For today's agenda, I'll start with a quick introduction of the Chrome Enterprise Recommended Program and the Technical Community Hour. After that, I'll hand it over to Ankur, who will cover today's topic and our call to action for our Chrome partners. Today's Chrome Technical Community Hour is brought to you by the Chrome Enterprise Recommended Program, which is Google's partner program for third party solutions that are optimized for Chrome OS or integrated with Chrome Browser. This webinar brings you the opportunity to engage with our team about new features and updates, enterprise development best practices, and our enterprise strategy. Now without further ado, I'll hand it over to Ankur and he'll kick us off. Ankur? Awesome. Thanks, Rich. Let me switch over to my view and we'll get started. Hi, everyone. As Rich mentioned, my name is Ankur Mathur. I'm a product manager here at Google since August 21. Prior to Google, I've spent time at Microsoft and Amazon and have experienced with a wide range of products. Today, I'll give you a quick overview of the Policy API and show how you can supercharge your apps and relationships with your and your customers Chrome OS fleets. The Policy API empowers administrators to manage Chrome OS devices. As next steps after this webinar, I'll show you how you can get some resources, documentation, and reference implementations to get started. Partners can utilize this Policy API to manage their customers' fleets. The Policy API by itself is very powerful. But when you combine it with some of our other APIs, such as the Admin SDK and the Telemetry API, you can do a lot more. The Admin SDK as a quick overview gives you the ability to manage, change your use, provision, deprovision devices, browsers, and printers. The Telemetry API lets you monitor the health and operations of the device. So putting all three of them together gives you a very powerful application at the end of the day. As I mentioned, the Policy API is for use internally within a Chrome customers' organization and then to build a commercial API client with it on top of this API, you'll need to submit a partner application, which you'll have done already, and then you can work with our partner escalation desk to get help in getting started with building your applications. So going into the API itself, I'll give you some of the key advantages and some of the key benefits of using this API. There's compatibility within the Admin console. So any changes you make within the API are reflected in the Admin console UI, advice versus any changes you make in the UI, and we'll update when you recall that API again. Any changes within the API are logged within our standard Admin console audit logs so you can track any changes that are being made. And then finally, we've taken a data-driven approach to building this API. So policies are represented as data elements and aren't referenced directly by the API. This lets you automate API clients for consumption of future policies without additional development. And we're constantly adding in new policies both from the Admin console UI and through the API for better benefits for our users. As a quick overview on how to use this API, there are a lot more details that we can go into through the partner escalation desk. You need to first create a Google Cloud project, enable the policy API as one of your endpoints, create credentials, you can test your app in the all-off playground and then verify that your app is trusted as you're going into production. Next, I'll go through some sample code requests and responses with the policy API to showcase its power and the capabilities that you can use with it. First up, let's read a policy. Let's read a policy for printers and see which users are allowed to use a particular printer. If you notice on the left-hand side, I've highlighted the additional target keys where I'm specifying a specific printer ID in this request that I'm making. I can also specify an organization unit or a group right before this to say, to really dive into where I want to see which users are allowed to use a printer or not allowed to use a printer. In my response, you'll notice the source key which again specifies the org unit or group value from where the policy comes from. And then here we have a couple of different possibilities which is really cool. If the source organization unit is the same as what was given in the request, it means the policy is locally applied to this organization unit. If it's different, it means the policy was inherited from this new source OU that's being provided. If there's no source key or the response is empty, it means the policy has not been set by the customer and has the default system values. For groups, the source key will always be the same group that was submitted in the request. This is an example for an org unit. A group request would be the same and instead of it being a org unit in a target resource, it would be a group instead of that org unit there. Next, we have the ability to modify the printer policy. So as you'd seen in the policy response before, the allowed for users had one field named allowed for users. This field in this example is a Boolean. It can either be true or false. In this specific case that I'm showing here, we only have one field. We only have one possible field for this policy. Other policies could contain multiple fields and you could set multiple policy items within it. In this example, we're setting the policy to false to prevent users from accessing this printer. And again, you can update for a specific org unit or for a group. Next, we also have the ability to control apps that are installed on a device and within an org unit. So this is an example of how you can force install an app on a specific org unit. Again, in this example, I'm specifying a unique org unit. You can specify a group here as well if you choose to. And you can provide through this additional target keys, the app ID and the specific app ID that's listed here on what you want to install. We can choose to force install this app as in this example in the second highlight or we can delete an app. We can get a list of all the installed policies for an app or all the apps within an org unit that are installed. And we can also clear auto launch kiosk apps as well. So there's a lot of control that we have over apps through this API. Next, another big ask and big task is controlling and defining networks. This API lets you define a network or a certificate, remove those networks or certificates or interact with saved networks to set which network a client and a device should be using. On the left-hand side in this example, you can set an Wi-Fi network and provide details in terms of the SSID, the security encryption and which devices and users are allowed to connect to the specific Wi-Fi network. On the right-hand side, we're showing how you can define a specific certificate to make it easier for a device to connect to that network and have greater authentication and greater control over it. I'll hide some of the plans for 2023. We've added in support for groups, which I was mentioning earlier, and added in some network policy capabilities that I just highlighted. We'll continue to enhance group support later this year with user groups and not just device groups as coming soon. We're also working to improve the schema improvements overall, which will provide you default and allowed values. So you can first retrieve what is possible with the API, what is the default and what is the allowed value. And then make another API call to set the policy correctly. So this gives you the ability as we add new policies to understand what's already there and then what you can actually set with it. So this is gonna be really powerful and really helpful as we continue to add more functionality within the API and to make your integration in your lives easier. And then finally, we've launched our partner escalation desk, which I mentioned earlier. This can be your first stop for questions. They can provide you with best practices. Support resources, documentation, and reference implementation. For more details, that's another starting point. You can take a look at the Chrome Policy API overview guide. You can use your, you have a QR code here and we can share out a link to this as well. It's on our public documentation site. And then as a recap, the Chrome Policy API gives you the power to manage your Chrome OS devices. As next steps, you can reach out to our partner escalation desk and they can help you with questions. They can provide you with best practices, support resources, documentation, and reference materials. I'll now pass it back on to Rich for our next steps. Thank you, Anker. In closing, please visit the Chrome Enterprise Developer website for additional information that will supplement your learning. This concludes today's presentation. We look forward to seeing you at the next webinar. Thanks for joining and have a great day.