Use partial trust by default for all WinUI 3 apps

[JaiganeshKumaran]

Today WinUI 3 apps use full trust. This is rather concerning since, in my opinion, not all apps need full trust but now every app needs it because of WindowsAppSDK. Use partial trust for all WinUI 3 apps and eventually deprecate full trust by making everything work under partial trust.

[DrusTheAxe]

Today WinUI 3 apps use full trust

A common misconception. Today WinUI 3 apps can choose to use full trust (MediumIL) or partial trust (AppContainer). You absolutely can choose to make a packaged app using WinUI3 and run in an AppContainer, if you choose. See this thread and especially this sub-thread for more information.

Use partial trust for all WinUI 3

That would be removing choice. We've heard from (many) developers that full trust (MediumIL) is a very strong need for their scenarios. We also heard from many how partial trust (AppContainer) is central to their needs. Some even use, need and like both.

This is rather concerning since, in my opinion, not all apps need full trust

Not every app needs elevation, but it's an important feature many apps require so we're supporting it. Windows App SDK is all about choice. In particular, your choice. Your freedom to choose the functionality you need. If you don't need MediumIL then by all means, don't use it. Ditto for AppContainer. And elevation. And WinUI 3. We also love ReactNative, and WinForms, and WPF, and Gtk and the myriad other UI technologies out there. WinUI 3 is a great choice for many, but if you have other needs or desires that's great too.

Now while removing MediumIL (and elevation) support wouldn't be helpful to many, if you find difficulties using WinAppSDK with AppContainer please share your feedback. Be it APIs, documentation, tools, samples or otherwise, developers should find AppContainer no more or less a viable an option than MediumIL (or elevation) - they're tools in your toolchest you should be able to reach for, when you desire. If there are gaps or weak spots please let us know. We highly value community feedback to help guide our work.

Rome wasn't built in a day, but it was built. Knowing where to lay those bricks sooner than later will help us bring to you more bang for the buck sooner.

[JaiganeshKumaran]

However full trust is the default in the templates. It should be partial trust instead.

[riverar]

@JaiganeshKumaran Disagree. I would say the majority of Windows developers don't care about AppContainer. Therefore, it doesn't make sense to tailor the template as such. That said, it might be a useful template to add to the list!

[DrusTheAxe]

However full trust is the default in the templates. It should be partial trust instead.

Why do you think so?

Are you desiring an easier development experience using AppContainer? In what way(s) do you find it not optimal?

We could add templates using AppContainer (instead of MediumIL). We've discussed more expansive ideas e.g. a 'wizard' style / template generation experience, providing choice over multiple knobs when creating a new project (new templates scale to few settings but explode exponentially as more options are exposed).

Are there things besides TrustLevel you'd like to more readily control during project creation?

[charlesroddie]

@DrusTheAxe partial trust is the right default because:

1. Most app installs out there are not made by the OS maker or employers (whom users might give high trust to) but by app developers for end users, and end users should not trust these apps with access to their files as a matter of basic security.
2. It confirms that both kinds of apps will work. E.g. partial trust just doesn't work at the moment if your app uses files because file pickers don't work. If partial trust had been the default this would have been fixed well before now.

[symbiogenesis]

Partial trust should be the default from the principle of least privilege. Also, apps with full trust are more difficult to get into the Microsoft Store. So the current approach eases the developer experience at the beginning, but just transfers the annoyance to the deployment stage.

And anyways, developer convenience should almost never come before the needs of users. Encouraging secure coding practices, even if it is more annoying for developers, is best.

https://en.wikipedia.org/wiki/Principle_of_least_privilege

[rinzwind5]

All these newer packaging technologies make a mess of what was once simple at worked fine with all win32 api's. Seems MS changes its mind all the time and deliver crazy win32 api level functions that do not function practically and/or consistently. Seems they absolutely do not like others to manage global application windows using API calls (you can't even manage modern Windows features like virtual desktops because.. uhm lack of a public API). UWP and WinUI3 are convoluted complex things with bad terminology and hacks (ie AppUserModelID which also does even not function consistently depending on how you look it up (api or window property)). You simply can't make efficient small apps anymore because of all bloat and layers. And they do not supply decent dev tools, documentation, examples and tooling. What happened since the Delphi & VB6 days... the heyday of native app development. MS does not even have a set of long lived and maintained modern UI controls. Apple does... Cocoa is a structured, consistent flashy dream compared to what modern Windows has become. On Windows, anything that can't be used from plain C is a no go IMHO. Which is the whole new WinUI3 too sadly. Reflection madness and lack of tools like designers.

UWP was limited trust, then MS accepted full-trust because no vision and support and tools, then WinUI3 continues that. Meanwhile the GUI of Windows itself was and is a mixed bag of different ideas from different ages and the real native UI toolset never got updated past 2000.

If anything I would think that Flutter/Dart is the better alternative for modern looking Windows apps.

[rinzwind5]

Rant over

[softworkz]

@DrusTheAxe et. al.

I think less important than the default selection would be that the choice is supported by the tooling.
The appx designer in VS is totally outdated and doesn't support all these things that are really needed these days.

It shouldn't be required to do long research through GitHub issues and discussions to find out how to choose between full and partial trust when packaging a WinUI3 application.

[DrusTheAxe]

Thank you for your input. I (and others) agree, creating a packaged app to run in an AppContainer isn't as easy as it should be. Something I hope to see us improve, and regularly nudge people towards

@bpulliam @jeffstall @Scottj1s nudge nudge :P

[DarranRowe]

Speaking of, insert obligatory file pickers reference here.

[miegir]

I'm very new to WinUI and have never dealt with UWP. And the full trust in WinUI template confuses me. The rumors are that windows store is not accepting fullTrust apps. And I can't find clear documentation that it is not the case with WinUI apps. And what if developers didn't ever think about fullTrust when developing their app and use some features which are only work with fullTrust (such as accessing any file by path) and after several months of development they discover that such app will not be accepted by the store and should be completely reimagioned? Is this an intentional trap in the WinUI template? Or should we not worry about? Perhaps a one comment in the appxmanifest near the fullTrust element could explain all of this (or contain a link that explains).

[ghost1372]

i have 2 apps published in ms store with winui 3 and fulltrust, so you dont need to worry about it.

[DrusTheAxe]

Store accepts packaged full-trust applications.

They used to not accept unpackaged fulltrust applications, then they did with caveats, and I've since lost track what the current policies are.

[softworkz]

I don't think that all these permission concepts have ever been made and intended for desktop apps. They were needed for mobile platforms, Xbox and maybe some other devices. For mobile, it was about paralleling Android permission concepts and for Xbox it was about making sure that it won't get hacked (like the first one), to ensure monetization. The idea of having "universal" app that can run everywhere, required to introduce the same permission and containerization mechanisms including all the restrictions which apps need to deal with on mobile and xbox platforms. These things weren't created for desktop Windows.
After the mobile strategy had failed and the adoption of UWP for Windows Store apps had been catastrophically low, they started several attempts to increase developer adoption and acceptance: They came up with DesktopBridge (which allows putting apps into the store which are already executed in a - kind-of - fulltrust manner. Then there was a "UWP Desktop" app type with less restrictions, but it didn't get promoted a lot because then the plans went towards WinAppSDK and WinUI3 - which are desktop-only apps, and hence there's no need for all those security measures.

There's one "treasure" remaining which they are holding on to protect: XBOX.
For XBOX, you can only submit UWP apps (besides games), and of course, these cannot have fulltrust.

[softworkz]

This read as you stating that WinRT came first, then UWP and then finally the AppContainer was allowed outside of the WinRT environment.

Yes you are right. What I meant was not the AppContainer technology itself, but rather making it practically usable for app deployment through the packaing mechanisms. Thanks for the clarification.

I also feel that people and even the documentation conflate the concepts of the AppContainer and application packaging.

Very true, and you must not forget the tooling. That's even more important than documentation. If a template for some technology is included in Visual Studio, has even more impact on deloper awareness than a documentation article somewhere.
And unfortunately, even those toolings which are using AppContainer are entirely hiding it. There's not even a tiny selection in the appxmanifest designer where you can choose whether the application should run containerized or not. You need to edit the appxmanifest manually and look up the documentation. Then the terms of the attribute names and values are entirely confusing and finally, there's an old and a new declaration (for newer OS versions) which doesn't appear to work (at least not withing VS.

If there are any intentions to improve the situation, this would be the very first place to start...

[DarranRowe]

The all in one application packaging project certainly requires you to manually edit the manifest file. But the separate packaging project does have an option for the trust level if things are set up properly.

This and bundling are two of the biggest remaining problems.

The new declaration for this does also work inside Visual Studio, but Visual Studio complains about it. For example:

<?xml version="1.0" encoding="utf-8"?>

<Package
  xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10"
  xmlns:mp="http://schemas.microsoft.com/appx/2014/phone/manifest"
  xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10"
  xmlns:uap10="http://schemas.microsoft.com/appx/manifest/uap/windows10/10"
  IgnorableNamespaces="mp uap uap10">

  <Identity
    Name="Untrusted.Meh"
    Publisher="Me"
    Version="1.0.0.0" />
  <mp:PhoneIdentity PhoneProductId="018af85c-aefa-4980-807d-22535e856956" PhonePublisherId="00000000-0000-0000-0000-000000000000"/>

  <Properties>
    <DisplayName>Meh (Package)</DisplayName>
    <PublisherDisplayName>Darran</PublisherDisplayName>
    <Logo>Images\StoreLogo.png</Logo>
  </Properties>

  <Dependencies>
    <TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.19041.0" MaxVersionTested="10.0.22621.0" />
    <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.19041.0" MaxVersionTested="10.0.22621.0" />
  </Dependencies>

  <Resources>
    <Resource Language="x-Generate"/>
  </Resources>

  <Applications>
    <Application Id="App"
      Executable="$targetnametoken$.exe"
      uap10:RuntimeBehavior="packagedClassicApp"
      uap10:TrustLevel="appContainer">
      <uap:VisualElements
        DisplayName="Meh (Package)"
        Description="Meh (Package)"
        BackgroundColor="transparent"
        Square150x150Logo="Images\Square150x150Logo.png"
        Square44x44Logo="Images\Square44x44Logo.png">
        <uap:DefaultTile Wide310x150Logo="Images\Wide310x150Logo.png"  Square71x71Logo="Images\SmallTile.png" Square310x310Logo="Images\LargeTile.png">
          <uap:ShowNameOnTiles>
            <uap:ShowOn Tile="square310x310Logo"/>
          </uap:ShowNameOnTiles>
        </uap:DefaultTile >
        <uap:SplashScreen Image="Images\SplashScreen.png" />
        <uap:LockScreen BadgeLogo="Images\BadgeLogo.png" Notification="badge"/>
      </uap:VisualElements>
    </Application>
  </Applications>
</Package>

This is a sample project. If you notice, the MinVersion for the TargetDeviceFamily elements is set to 10.0.19041.0. It needs to be at least this for the manifest verification to succeed. The Application element also doesn't contain an EntryPoint attribute, but instead it contains uap10:RuntimeBehavior and uap10:TrustLevel. This will always produce the warning:

2>D:\Programs64\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\DesktopBridge\Microsoft.DesktopBridge.targets(260,5): warning : Could not find the '/Package/Applications/Application@EntryPoint' attribute. Please add it back to the app manifest file.

But yes, the manifest designer is something that feels like it hasn't had much done to it. The packaging functionality in Visual Studio is also problematic. To be honest, for the complex projects that I work on and package, I normally use makeappx directly to make the packages.

[softworkz]

The all in one application packaging project certainly requires you to manually edit the manifest file. But the separate packaging project does have an option for the trust level if things are set up properly.

A property on the project reference? That's pretty odd, isn't it?

Also, from a quick test, this doesn't seem to cause any change in the generated appx manifest when changing it..

[DarranRowe]

Also, from a quick test, this doesn't seem to cause any change in the generated appx manifest when changing it..

This changes the EntryPoint to Windows.PartialTrustApplication.

For example, Trust Level set to Full Trust gives:

  <Applications>
    <Application Id="App" Executable="Meh.exe" EntryPoint="Windows.FullTrustApplication">
      <uap:VisualElements DisplayName="Meh (Package)" Description="Meh (Package)" BackgroundColor="transparent" Square150x150Logo="Images\Square150x150Logo.png" Square44x44Logo="Images\Square44x44Logo.png">
        <uap:DefaultTile Wide310x150Logo="Images\Wide310x150Logo.png" Square71x71Logo="Images\SmallTile.png" Square310x310Logo="Images\LargeTile.png">
          <uap:ShowNameOnTiles>
            <uap:ShowOn Tile="square310x310Logo" />
          </uap:ShowNameOnTiles>
        </uap:DefaultTile>
        <uap:SplashScreen Image="Images\SplashScreen.png" />
        <uap:LockScreen BadgeLogo="Images\BadgeLogo.png" Notification="badge" />
      </uap:VisualElements>
    </Application>
  </Applications>

Trust Level set to Partial Trust gives

  <Applications>
    <Application Id="App" Executable="Meh.exe" EntryPoint="Windows.PartialTrustApplication">
      <uap:VisualElements DisplayName="Meh (Package)" Description="Meh (Package)" BackgroundColor="transparent" Square150x150Logo="Images\Square150x150Logo.png" Square44x44Logo="Images\Square44x44Logo.png">
        <uap:DefaultTile Wide310x150Logo="Images\Wide310x150Logo.png" Square71x71Logo="Images\SmallTile.png" Square310x310Logo="Images\LargeTile.png">
          <uap:ShowNameOnTiles>
            <uap:ShowOn Tile="square310x310Logo" />
          </uap:ShowNameOnTiles>
        </uap:DefaultTile>
        <uap:SplashScreen Image="Images\SplashScreen.png" />
        <uap:LockScreen BadgeLogo="Images\BadgeLogo.png" Notification="badge" />
      </uap:VisualElements>
    </Application>
  </Applications>

If you are already using uap10:TrustLevel and have removed EntryPoint, then it wouldn't make a difference. Just be aware that if you have both EntryPoint and uap10:TrustLevel, then they must agree.

[softworkz]

Probably I did something wrong (it was a fresh test project, though).
Thanks a lot for testing and confirming!

[softworkz]

I don't think that all these permission concepts have ever been made and intended for desktop apps

This is incorrect. You're thinking of types of apps1 when you should be thinking of security context. Runtime capabilities are (largely) designed for processes running in an AppContainer. UWP apps can only run in an AppContainer, whereas 'Desktop' apps can run in AppContainer and other contexts (e.g. mediumIL or elevated).

I didn't mean to say that there is no use or no benefit from leveraging those concepts for desktop apps. I said that they weren't designed and created for those applications. This is clearly evident when looking at the APIs and rules and how they have been changed over the years. This documents pretty well how much desktop application had been ignored in the beginning and how it has been successively attempted to fill all those gaps after realizing that no developer wants to develop desktop apps using UWP (except they had to develop for xbox or mobile and then published the app for Windows desktop as a bonus).

There is no 'kind of'. "FullTrust" means "runs with IntegrityLevel=MediumIL".

There are subtle differences between all those cases. You even get a different runtime behavior between WinAppSDK and UWP when both are containerized, packaged and declare runFullTrust, so I said "kind-of", as these things are nowhere documented (to my knowledge at least) and there are new surprises just around every corner...

WinAppSDK and WinUI3 - which are desktop-only apps, and hence there's no need for all those security measures

This is incorrect. Don't conflate the type2 of app with its security context - these are different and orthogonal

Sorry for being unclear, that's a misunderstanding. By "desktop-only apps" I meant to say that WinAppSDK/WinUI cannot target xbox or other "devices".

2 Much as it pains me to use this phrase. RuntimeBehavior=windowsApp, packagedClassicApp and win32app are all packaged processes but have different properties and behaviors and refering to them as 'types' of apps is a sometimes useful informal phrasing it's easily grossly misleading.

The reason for this confusion is that there's no good documentation available for all those use cases (detail subjects are documented spread over many places, but a comprehensive and complete overview is nowhere available. Instead you need to collect countless pieces of information from GitHub posts by yours and others and try to put them together like a puzzle.

Also, these things are not appropriately reflected in the tooling: The appxmanifest designer is still almost at the same state like it was 6-8 years ago and it doesn't properly and clearly support all the different possible execution modes. Documentation is sparse as well.
Neither do any project templates exist. Which brings us back to the original subject of this issue..

[softworkz]

It's good engineering practice to run your app as MediumIL instead of Elevated, if you can -- run with the permissions you need, and not more. AppContainer is just another tool available to developers to easily do so. After all, apps don't all run with admin rights for the same reason you don't routinely run everything as root on Unix.

"runFullTrust" doesn't make an app run elevated/with admin rights.

Do you want to know why our application needs to declare runFullTrust? It's because in cases it is required to access a local server (ours, but non-store) via local loopback, which is - of course - restricted. Also nice: you don't realize this during development because Visual Studio automatically removes this restriction locally - which makes a great surprise at a later time when you realize that it doesn't work once installed on other machines.
Now, there are manifest declarations for hundreds of things, including even a bunch of almost esoteric and hardly documented ones.
But there's no such declaration for enabling local loopback - a common, valid and widely used IPC technology (and in our case, it's even nothing more than http...).
Even running an app with runFullTrust doesn't allow you to use local loopback. But - hehe - when running full trust, you are allowed to call an API which lifts the restriction - for your own app - and even for any other app. So that's why we need to runFullTrust.
In this case the local loopback restriction is forcing us to run the app in a less secure way than it would actually need to.

Once again - YAY!

And that's a good example for what I mentioned earlier: so many work days are getting burned for stuff like this.

[softworkz]

1. Is it possible in a UWP app to ovverride/replace a Windows API component (Windows.Media.ClosedCaptioning.ClosedCaptionProperties) with a custom implementation
2. Is it possible in a UWP app to unregister a COM (WinRT) class (ClosedCaptionProperties) so that an attempt to instantiate/activate it during runtime would return E_CLASS_NOT_REGISTERED?
3. Is it possible in a UWP app to achieve that the registry entries in this .reg file (WindowsCaptionsUser.zip) are being set when the app is running. The app doesn't need to change them, they just need to be set this way when the app is running - no matter how it is achieved).

Those are just different ways to achieve the same thing (work around the bug I referenced), so a single only one of them would suffice.
A 4th option would be to get the actual issue resolved, but AFAIU, fixes for UWP aren't worked on anymore and team appears to be overloaded anyway (sparse responses to issues, important bugs aren't fixed , my PRs (1, 2 aren't being responded to).

Under these conditions, any possible way to work around this would be a great and much appreciated rescue.

I'll gladly provide all information that is needed. Thank you.

[softworkz]

(You should not be targeting UWP for any new development.)

What should I be targeting for XBOX, then?

[riverar]

Are you writing an app for Xbox or are you just nitpicking? Haven't seen any real non-partner apps for Xbox yet.

[softworkz]

Are you writing an app for Xbox

Yes.

Haven't seen any real non-partner apps for Xbox yet

What is a "real" non-partner app?

We have an app in the store for years already, which is targeting xbox and desktop, but it is still based on WinJS. It also works on Windows Desktop but with a couple of drawbacks, which is why we used to provide and recommend a separate non-store application for use on Windows.

The plan was to replace both with a single newly developed store application, but it still turned out to be too limited, so the plan has changed now and we have a WinAppSDK app for Windows and a UWP app for Xbox in a late stage of development.

We are also using WebView2 in both cases, which btw. has been initially released for XBox/UWP just 3 months ago - which doesn't quite align with "You should not be targeting UWP for any new development" (wrt "any")..

[riverar]

In the WebView2 on Xbox scenario, the "UWP" app is just a shell, while the app and app developer is targeting the web. If you don't agree, that's fine, it's not important. My point was just that no one is working on "UWP" on the Microsoft side and folks should avoid it as much as possible.

Have you tried putting your own registration information for *.ClosedCaptionProperties into your registry hive? e.g. REGISTRY\Machine\Software\Microsoft\WindowsRuntime\ActivatableClassId\Windows.Media.ClosedCaptioning.ClosedCaptionProperties? I can't remember if the activation factory for Windows.* types still forces you into \System32 or not, but if you run into problems there we can patch that at runtime.

[softworkz]

In the WebView2 on Xbox scenario, the "UWP" app is just a shell, while the app and app developer is targeting the web.

It's good that you mention this, because it's exactly that way of thinking in "scenarios" being a primary source source of evil, negatively affecting design and architecture of platform and framework strategies (see "hybris and ignorance" above).

If you don't agree, that's fine, it's not important.

I don't think it's a matter of agreement or disagreement, it's about how this kind of "thinking in scenarios" is leading to misconceptions and lack of understanding developers' needs when developing for a certain platform, which is why I think this is actually a matter of substantial importance.

To set the records straight: Our software is known by Millions. A single release of the server comprises more than 70 (sic!) installation packages for all the supported platforms and I don't even have the figures for all the client apps (no synced release cycle) which we have for any platform you can think of (plus those you wouldn't think of). Hence, I do not only have a history in Windows development over decades but also a pretty good picture of appplication development on various platforms and UWP is ranging at the very low end of favorable platforms from my point of view, surpassed only by things like Roku Scenegraph/Brightscript for example.

In fact, our core application is html/js based, but that doesn't mean that the native part of the application is "just a shell". There's a range of tasks which need to be done at the native side in order to make the application work as expected and designed on each platform. In case of Windows/Xbox platforms this includes: application info, settings storage, logging, diagnostic features, UDP network discovery, exit handling, window management, theme awareness/synchronization, full-screen switching, link execution , shellopen handling, volume control, remote control, plugin management, http redirection/mapping, local loopback exemption, splash/startup coordination, WakeOnLan control, app restart, system sleep and reboot control, system events interaction for sleep and suspend, background audio playback, refresh rate switching, HDR mode activation, webview/video overlay and finally the most involved part: video playback (html video is too limited and Windows.Media is still too limited, so there are custom solutions in place, even different ones for Xbox and desktop windows).

So, "shell" => yes, "just" => no

My point was just that no one is working on "UWP" on the Microsoft side and folks should avoid it as much as possible.

I know, and if you can show me a way to avoid it, I'd gladly ditch it right away. 😉

Have you tried putting your own registration information for .ClosedCaptionProperties into your registry hive? e.g. REGISTRY\Machine\Software\Microsoft\WindowsRuntime\ActivatableClassId\Windows.Media.ClosedCaptioning.ClosedCaptionProperties? I can't remember if the activation factory for Windows. types still forces you into \System32 or not, but if you run into problems there we can patch that at runtime.

Thanks a lot for the idea. I'll try this in a moment and report back.

[softworkz]

Hi,

so, first of all this registry key would be the right place: When I remove (rename) the key, it has the desired effect (option 2 above).
I think, removing is practically not feasible because those keys are owned by TrustedInstaller and even admin rights do not allow changing (by default), neither does the registry.dat mechanism allow key removal, but let's look at that for trying modifications.

I have a Registry.dat and a User.dat file. Registry.dat is prepared as follows:

user.dat has some values for the key Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ClosedCaptioning (which does option 3 from above and is working with the WinUI3 app)

When I create an MSIX with those files and install the package, I can run RegEdit in the context of the app package and I see that both, Registry.dat and User.dat have been merged and are overriding the regular values as intended.
(this is also how the WinUI3 app is seeing the registry when doing so)

But when I run the installed UWP, none of those registry overrides are applied. The app just gets the regular values from registry calls (double-confirmed by the fact that the option-3 overrides have no effect and by manual advapi registry reads).

Last time I tried, I think I had come to a situation where Registry.dat (but not User.dat) was picked up, but it was only possible to add non-existing values/keys but not change existing ones. I think I got there after changing execution modes and/or enabling runFullTrust.

Such things are not enabled, it's all default currently:

[softworkz]

@riverar - Does this match your own expericence?

You said:

I can't remember if the activation factory for Windows.* types still forces you into \System32 or not, but if you run into problems there we can patch that at runtime.

How would this work? Or do you have any other idea?