API Review: Trusted Origin APIs

[chetanpandey1266]

This pull request introduces a new specification for Trusted Origin support in WebView2, enabling applications to apply different security and feature policies based on the trust level of content origins. The changes provide APIs for designating trusted origins and configuring feature access and security settings per origin, addressing previous limitations around uniform policy enforcement.

Trusted Origin API and Feature Management:

• Added APIs to CoreWebView2Profile for creating, setting, and retrieving feature settings for trusted origins, allowing fine-grained control over security and feature policies.
• Defined new interfaces and enums (ICoreWebView2StagingProfile3, ICoreWebView2StagingTrustedOriginFeatureSetting, and COREWEBVIEW2_TRUSTED_ORIGIN_FEATURE) to represent origin-specific feature configurations, including AccentColor, PersistentStorage, and EnhancedSecurityMode.

Usage Examples and API Details:

• Provided C++ and .NET/WinRT code samples demonstrating how to set and get trusted origin feature settings, including support for wildcard origin patterns.
• Documented API details for both C++ and .NET/WinRT, specifying method signatures and usage for managing trusted origin features.

Background and Motivation:

• Explained the need for Trusted Origin support, highlighting challenges with uniform security policies and the benefits of selective feature enable

[billxc]

Are we considering supporting an API that allows updating a single feature at a time? There are scenarios where users don't want to update the entire feature list, but rather just toggle one specific feature on or off.

In the current API design, all other features are kept at their default state. This forces users to set the entire list, which means they must first retrieve the current state of all features to safely make updates. Since our API is asynchronous, this adds further complexity to the user's code.

Ideal sample code:

profile.SetTrustedOriginFeature("https://*.contoso.com", CoreWebView2TrustedOriginFeature.AccentColor, false);

[shrinaths]

The API does not mandate setting all features. However if you do want to set more than one, that is allowed.

[david-risney]

This sample code for getting the origin features doesn't really do anything and is incomplete. You get the variable and do nothing with it.

I think its fine to just remove this part of the sample code and not call the get method. Normal use case will be to setup the origin features during startup and the getter shouldn't be necessary for that. If you have another scenario that involves the getter you want to add a complete sample for that's fine too.

[chetanpandey1266]

Given the cpp sample displays the result obtained from GetTrustedOriginFeatures, will keep it as it is and will remove it only from C# sample.

[evanstade]

Were there alternatives explored here? I'm not sure what constraints are at play here, but this seems to be reinventing policies more or less from scratch. (A much more limited version of policies.)

Would it make sense to give apps full policy support for their WebView instances? i.e. just be able to provide a json file that is parsed as policy. The advantage is that (a) the new API is very minimal (b) the new API is as powerful as it likely ever needs to be (c) new capabilities are added "for free" as policy permissions/content settings/etc support is added to Chromium in the future.

(Granted, I don't think that you can actually set storage persistence via a policy, but it should be easy to add since there is a content setting for it. I think it's an oversight and/or never really became necessary for enterprise policies.)

[david-risney]

Were there alternatives explored here? I'm not sure what constraints are at play here, but this seems to be reinventing policies more or less from scratch. (A much more limited version of policies.)

Yes including a version closer to policies. Ping me if you'd like to learn more

Would it make sense to give apps full policy support for their WebView instances? i.e. just be able to provide a json file that is parsed as policy. The advantage is that (a) the new API is very minimal (b) the new API is as powerful as it likely ever needs to be (c) new capabilities are added "for free" as policy permissions/content settings/etc support is added to Chromium in the future.

(Granted, I don't think that you can actually set storage persistence via a policy, but it should be easy to add since there is a content setting for it. I think it's an oversight and/or never really became necessary for enterprise policies.)

WebView2 team didn't want to try to support all policies but rather expose, validate, and document them as they are required.

[evanstade]

WebView2 team didn't want to try to support all policies but rather expose, validate, and document them as they are required.

Thanks. I'll focus my feedback then on persistent storage as that is my area of expertise, and I assume why I was looped in. It is a web permission, so it seems like a perfect fit for SetPermissionStateAsync. (The fact that in the general browser case it is decided silently/heuristically rather than via user decision does not seem too important.)