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.)

[david-risney]

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.)

You mean you'd rather see a new CoreWebView2PermissionKind for persistent storage than an origin setting in this new API? I don't have a strong opinion regarding persistent storage specifically. The biggest difference I suppose is this new API is intended to be setup once at app startup mapping origins to their settings, and the CoreWebView2PermissionKind is generally used with CoreWebView2.PermissionRequested event which can be done at the time of the event and handled individually with custom logic - although there's also the SetPermissionStateAsync method like you say which is similar to this new API. @evanstade what makes you favor CoreWebView2PermissionKind for persistent storage?

@chetanpandey1266 do you or other folks working on this feature have thoughts about when something should be a CoreWebView2PermissionKind versus an OriginSetting? The way this API exists now looks very similar to SetPermissionStateAsync. The three origin settings in this doc are all kind of security / privacy related and could also have a case made for being a CoreWebView2PermissionKind. I can imagine there could be origin settings that are not related to privacy and security and would be harder to justify including as a permission?

(cc @aluhrs13 )

[evanstade]

@evanstade what makes you favor CoreWebView2PermissionKind for persistent storage?

I would expect any capability queryable via Permissions.query() to have a corresponding value in CoreWebView2PermissionKind. I don't know why some permissions are not yet there, but I assume it's more to do with a lack of imminent need than there being a specific reason they are excluded. persistent-storage is one such permission, so unless there is some reason CoreWebView2PermissionKind and SetPermissionStateAsync are deprecated or insufficient (which doesn't appear to be the case here), it makes sense to keep extending the enum as necessary.

Granted I don't know off-hand if everything in CoreWebView2PermissionKind maps to a web permission, but the ones I'm familiar with (geolocation, clipboardread, mic, camera, window management, filereadwrite) are all web permissions. If one or more of the others don't map to web permissions, then I would say it is a mistake to have included them in that API, or to have used the name "permission" in that API. A web capability that is not integrated with the web permissions API, but is individually toggle-able by user or admin, is called a "content setting".

Beyond the argument that we should default to sticking with precedent unless there's a strong reason not to, doing so here removes any ambiguity about what "persistent storage" means, because it means the exact same thing for the WV2 instance as it does on the web.[1] The other two security controls proposed in this PR do not map to web permissions AFAIU so, naively, I would not expect them to be part of CoreWebView2PermissionKind.

[1] It does not actually gate access to any storage APIs; it just controls whether data in certain APIs may be automatically evicted without user consent, in Chromium's case on storage pressure. If this were to be added as part of some other API not related to web permissions, it could imply it controls something other set of functionality like availability of storage APIs generally, or removing quota limits, or whether storage lasts beyond the current session, etc.