[Feature]: Ability to declare the ComServer extension without the runFullTrust rescap

[ahmed605]

Summary

Add the ability to declare the ComServer extension without runFullTrust rescap

Pitch

Currently it's required to declare the runFullTrust rescap in order to use the ComServer extension, it would be great if MSIX allowed creating global containerized (AC and/or AppSilo) COM servers that do not require the runFullTrust rescap, this will unlock many things like the ability to create 3rd party Windows Widgets without having that rescap

There are multiple reasons why an app dev wouldn't want to declare the runFullTrust rescap, examples include:

• Microsoft Store currently incorrectly describes the rescap which leads to people making false assumptions of apps using this rescap, you can find more details about that here: With regards to the malware allegations TranslucentTB/TranslucentTB#350
• Using that rescap defeats the whole point of using Isolation/Containerization (for both AC and AppSilo) as the app can access all resources this way so the isolation isn't really effective here.
• After declaring runFullTrust, any prompt about privileges won‘t show, and it‘s permitted by default, despite the app being UWP, partial trust app or running in AppSilo. (thanks @AndromedaMelody)
• Non-Desktop SKUs/OneCore Device Families (Xbox, WCOS, HoloLens, etc...) will block runFullTrust without declaring Microsoft.deployFullTrustOnHost_8wekyb3d8bbwe SCC. So this feature also will help UWP developers. (thanks @AndromedaMelody)

[AndromedaMelody]

#24 (comment)

[AndromedaMelody]

After declaring runFullTrust, any prompt about privileges won't show, and it's permitted by default, although the app is UWP, PartialTrustApplication or running in AppSilo. Especially, I only want to add a COMServer for UWP, but the cost is that users can't manage privileges. It's not safe.
AppSilo is also a good way to extend UWP (such as write a IExploreCommand extension). Xbox/WCOS/… block runFullTrust without declaring Microsoft.deployFullTrustOnHost_8wekyb3d8bbwe. This feature also will help UWP developers.
By the way, will AppSilo support Xbox/Hololens/SurfaceHub/WindowsCoreOS? If AppSilo support Xbox/WCOS/…, not only UWP developers but also WASDK(WinUI 3) developers will benefit from it.

[ahmed605]

add a reason: after declaring runFullTrust, any prompt about privileges won‘t show, and it‘s permitted by default, although the app is uwp, partial trust app or running in appsilo. especially, i only want to add a com server for uwp, but the cost is that user can‘t manage privileges. it‘s not safe. app silo is also a good way to extend uwp（such as write a IExploreCommand extension for uwp）. xbox/wcos/… will block runFullTrust without declaring Microsoft.deployFullTrustOnHost_8wekyb3d8bbwe. this feature also will help uwp developers. and will app silo support Xbox/Hololens/SurfaceHub/WindowsCoreOS? if app silo support xbox/wcos/…,not only uwp developers but also wasdk(winui3) developers will benefit from it

Added, thanks!

[cchavez-msft]

Hi, @ahmed605. Thank you for your feedback. I appreciate your concerns regarding the runFullTrust capability, and I'd like to provide further clarification on the points you raised:

• The Microsoft store description has changed over time. It no longer describes apps as mentioned in the link you provided.
• It's important to note that the runFullTrust capability does not undermine the isolation and containerization provided by Win32 App Isolation. Even with the capability declared, the app remains isolated. We acknowledge that the naming of the capability may have caused confusion, but rest assured that the intended isolation remains intact.
• By including the prompt capability, your app will trigger file access prompts when required, ensuring a secure user experience. @AndromedaMelody, I recommend exploring the addition of the prompt capability to achieve the desired behavior.
• Currently Win32 App Isolation only targets desktops platforms. Win32 doesn't run on other platforms yet.

We do understand your concerns and the confusion caused by this capability so we are looking into it to determine its feasibility. We will keep you posted.

Thanks again for the constructive feedback, we strongly appreciate it.