Can this be used without MSIX?

[rgwood]

Hi, are there any plans to enable sandboxing without requiring MSIX? I'd like to enable sandboxing for plain old EXEs.

I’m excited about this functionality, but MSIX is a non-starter for most developers for several reasons:

1. MSIX requires code signing. Not practical for open source projects or even many companies (cost aside, setting up code signing infrastructure is a massive pain).
2. Distributing MSIX apps outside the store is impractical+broken, because App Installer is buggy. This is widely known among people who have tried to use MSIX outside the store; see the top comment on Hacker News. I spent a month trying to adopt MSIX for an enterprise application in 2022, and I'll never get that time back; installation would just fail on users' machines with no useful info in event logs.
3. MSIX has bugs on ReFS, which means the new Dev Drive feature will run into problems.
4. Users and administrators don't want MSIX/AppX:

I am really excited about better sandboxing tools, but I'm worried that they will be dead on arrival if they're tied to MSIX.

[robmen]

I have the exact same question out to David Weston.

[ddsilva-msft]

Thank you for your feedback on MSIX, we will get that routed to the appropriate teams and come back with a more detailed response. Out of curiosity have you tried https://learn.microsoft.com/en-us/windows/apps/desktop/modernize/grant-identity-to-nonpackaged-apps and had the same experience? As you're aware, currently this technology is only available with MSIX as it relies on the application identity provided.

[rgwood]

Thank you for the reply! I have spent a bit of time with sparse packages, but gave up because 1) they are quite complicated, 2) they require code signing. As far as I can tell, there is still no practical and easy way for most developers to use package identity.

I would urge your team to read through the Hacker News discussion of app isolation. As promising as this technology is, it’s likely to see very little uptake unless the MSIX team gets their house in order. Some excerpts:

Microsoft has been trying for 7 years various methods to get developers to please package their apps in some way. Almost nobody has ever bit - to the point the Microsoft Store only has been having some recent success by promising packaging isn't required

I have spent weeks of my life trying to get windows packaging to work. Twice with APPX, twice with MSIX. Mostly with greenfield C# apps, sometimes with existing WPF apps. Every year I think: surely it'll work now, they just published another blog post touting the new features? No. Every time I run into something that's not documented how to be done, something that's not implemented, or something that's broken, often with a detailed bug report that nobody at Microsoft has bothered responding to

[Microsoft’s] own internal developers don't [use MSIX], so why would ISV's?

IMO it's not a coincidence that very few first-party teams distribute their software using MSIX outside the Store. MSIX outside the store is broken, and for whatever reason the team responsible for it doesn't seem to be addressing that.

[rgwood]

I'd also suggest looking at what happened when a major third-party app (Affinity Photo) tried to adopt MSIX:

• A 474-reply thread complaining about the MSIX installer; eventually the Affinity devs gave in and said they'd offer MSI too
• 610 search results for "MSIX" on the Affinity Photo forum, nearly all bad

I cannot overstate how impractical it is to adopt MSIX as the sole distribution mechanism for a Windows application in 2023.

[Trinitek]

That 474-reply Affinity thread has a lot of noise about "apps are not for 'serious' computer users," etc. It would be helpful to lay out the issues. I've identified three in that thread:

1. You can't acquire packages from the MS Store if the store is disabled by the organization via Group Policy. (Is this an MSIX problem? I feel like users need to communicate this with their IT departments. There is also AppInstaller.)
2. People want to install store apps to a non-C drive. (Also not strictly an MSIX problem. There is an option to set the default location for new MSIX installs as explained later in that thread, but it is somewhat difficult to find in the settings. The Store app could be improved to allow easier access to this option.)
3. People need to integrate with tools that invoke Affinity as an EXE file. (The manifest already declares App Execution Aliases as explained in https://forum.affinity.serif.com/index.php?/topic/170529-extremely-disappointed-that-this-installs-as-an-app-and-not-regular-software-program/page/2/#comment-980997.)

There are things here that could be improved, but I don't see any that are directly related to MSIX as a packaging technology.

[emergencynap]

Even if you get past using sparse packages and package identity with win32 apps things that work for UWP apps that you'd expect to work with win32 apps configured this way do not and there is really no recourse or support mechanism for getting things working. As an example, if you configure Windows Firewall rules using app package identity (the same Edge does), you would expect Windows Firewall to apply the firewall rules to the executing application. This absolutely does not work and even though Microsoft somehow uses these technologies in-house, between lack of documentation, forums, support make the technology unusable. In our world win32 apps are still the majority of what users use/expect and no real path forward if we don't want to repackage the apps, update installers/updaters, CICD and all kinds of logic most modern win32 apps have today. Even winget decided to add support for "classic" win32 installers, it's time for Microsoft to really hear what developers are telling you.

[robmen]

This is exactly why I want to understand if we can use this functionality outside of MSIX to tackle the above DX issues in the WiX Toolset.

[rgwood]

even though Microsoft somehow uses these technologies in-house

The funny thing is, they often don't!

The Office team was an early adopter of MSIX but they gave up on it. And I think I can count on 1 hand the number of other first-party teams that distribute their software outside the Store using MSIX.

The decision to require MSIX/package identity after a decade of nearly zero uptake by developers is perplexing.

[MezMedicianoIntelligentMedia]

Very interesting discussion, I have wondered about much of this myself for years.

[louis-br]

Hi, this is my first time in a GitHub discussion/issue. I'm not sure if this is the right place. For now, requiring signing is probably the most important aspect of the things that would me keep me from using this. I'm just starting Python development on Windows, coming from an initial background of running Python on Linux, Jupyter, Conda ecosystem (in a devcontainer sometimes). As rgwood said:

1. MSIX requires code signing. Not practical for open source projects or even many companies (cost aside, setting up code signing infrastructure is a massive pain).

My use case: I'm starting to package a python app for windows, a desktop app that runs a web server, which is aimed for not so tech savvy users, hence Windows. I'm considering the packaging options that these docs mention Python Packaging User Guide: Bringing your own python executable.

I met this repository many times before, however this time from this blog post: https://blogs.windows.com/windowsdeveloper/2024/03/06/sandboxing-python-with-win32-app-isolation/ .

Ideal app requirements:

1. No administrator rights needed.
2. No monetary cost, specially for packaging. (Hopefully)
3. Not modifying registry, folders or files not in the application folder. (Or try as much as we can not to. )

Signing would break 2. Self signing would likely break 1 (security-wise, hopefully you must have admin rights to do that). Other issues may include the windows version and compatibility with this isolation.

After much work, PyInstaller + Inno Setup seems to meet the requirements, not so sure for requirement 3. This isn't without compromises, for example, multiple processes can be a pain to setup, can't invoke a python interpreter to run another script. The room for growth seems a lot smaller, for a moment I'm considering an approach that would mirror a conda environment or python environment, even though these would likely break requirement 3 (such as writing to %USERPROFILE%), not ideal but I might accept, still exploring.

Funnily enough, as a thought experiment, maybe someone could make a Linux VM small enough that it would be lighter and more contained than packaging a windows app, at least for this use case, but I'm not willing to try right now. (For example, Python on Windows for beginners recommends for that use case of web development using Linux would be a better choice. For the others, installing Python from the Microsoft Store probably is not worth the hassle, such as described in this Stackoverflow question, I haven't confirmed this. Overall, the language choice, Python, may not be the best for targeting Windows... I haven't started on CI/CD, as I don't know much about it yet, but likely requires spinning up ephemeral VMs)

Unfortunately, other windows features related to isolation aren't useful either, such as Windows Sandbox (I can't package my app in a Windows Sandbox, it wasn't intended to be used that way, and only allows 1 running each time), or Windows Containers (mostly aimed at Windows Server, no UI, likely needs virtualization overhead).

Considering the user side and the developer side of this project, as a developer I would worry about my app being contained so that it is compatible and reproducible no matter how many times you uninstall and install it. I probably wouldn't rely on it for the privacy aspect, as I could implement related features in the app. As for the security aspect, it is tied to portability but I'd rather my app be portable.

As the user, I'd like the privacy and security features this project proposes but I wouldn't benefit if the developer doesn't use this, it could be very likely if the developer has other goals than what the user wants, they could just use normal win32 apps. For example, for quick testing I would use Sandboxie for apps I don't want to risk with unintentionally modifying my system.

[lb90]

You can enable App Container sandboxing for unpackaged apps, too. That's documented on MSDN:

• https://learn.microsoft.com/en-us/windows/win32/secauthz/appcontainer-for-legacy-applications-#unpackaged-apps
• https://learn.microsoft.com/en-us/windows/win32/secauthz/implementing-an-appcontainer

[HotCakeX]

1. Distributing MSIX outside of store is totally practical. (I do it myself)
2. Every problem with MSIX installation is properly logged. (I use the logs myself to detect problems and fix them)
3. If a system is having problem installing MSIX, make sure the app installer is up to date first. (in the Microsoft store, do not disable auto app updates, the default behavior already keeps everything up to date)
4. All of my non-OS drives have been ReFS for a long time, i can debug my WinUI3/C#/MSIX packaged app from ReFS drives without any problems.
   I use the latest Windows 11.
5. Installing MSIX packaged apps from ReFS drives also works just fine. (I've done this at least 200 times)
6. If deploying MSIX internally, you can use self-signed certificate or certificate generated from your internal CA. As long as the certificate is trusted in the Trusted Root Certification Authorities store of the Local Machine, you can install your MSIX without any problem.

This post is old and issues get fixed, so what was an issue a year ago might not be anymore.