Hacker News Reader

Comment by AshamedCaptain | Hacker News Reader

I am guessing that they'd want you do distribute your program through their "App Store" as a UWP, which is likely subject to sandboxing and will never show the SmartScreen prompts.

Making raw Win32 .exe distribution as user-unfriendly as possible is very likely to be a goal of MS.

View on HN

Honestly I am all for sandboxing by default and scary prompts for anything that doesn't subject itself to strict sandboxing or that tries to break out of it. That doesn't mean apps necessarily have to come from a MS curated store either, just that by default the run in a sandboxed context with access to dick squat on my system.

I absolutely hate when I install something like Adobe Acrobat and it installs 18 schedule tasks, a startup job to ensure those task exist, a tray icon to monitor it's services and all the other crap. No thanks.

I also don't want to have to worry about installing some random app I found on SourceForge that purports to do what I want but might come with the SF equivalent of News Gator side loaded.

Lock it all down by default in a virtual sandbox by default and if it needs legitimate access to my files, prompt me to grant it access.

> That doesn't mean apps necessarily have to come from a MS curated store either, just that by default the run in a sandboxed context with access to dick squat on my system.

This is absolutely possible. You can distribute your UWP app as an MSIX package[0], which allows side-loading without having to go through the store. The whole experience is actually quite nice and straightforward, UI-wise.

[0]: https://docs.microsoft.com/en-us/windows/msix/

You can also distribute classic win32 apps with MSIX as well

Does that mean they're Sandboxed by default. I personally don't care if the package is MSIX, MSI, EXE, or whatever. I just want Sandboxed by default.

I really hate worrying what an App like Chrome is doing to my system and I'm reminded every time I launch it because all my Thunderbolt connected monitors black out for a second when it starts up.

Win32 MSIX packages are minimally sandboxed by default. Mostly just in that it virtualizes some file system and Registry changes to ensure the package is clean to uninstall.

It doesn't stop Win32 apps from doing crazy Win32 things (unfortunately), but it's still a step up from MSI/EXE installs in general.

MSIX only enforces a sandbox if an application doesn’t elect to use the restricted capabilities that allow it to run without. File system and registry virtualization can be disabled quite easily with a few lines in the package manifest, as well as a host of other isolation features.

This is a good thing, and it makes MSIX a usable packaging format for pretty much any application under the sun - but nobody should assume a MSIX package is safe just because it’s a MSIX package.

Now with Project Reunion making it official that both worlds are getting merged, I look forward that with time the minimal Win32 sandbox acquires full sandboxing capabilities.

I see current MSIX limitations for Win32 just as means to incrementally steer developers into it, while not introducing too many breaking changes (as WinRT happened to be).

MSIX tries to be exactly that. It supports the gamut of Win32 so long as they can be minimally sandboxed. Win32 apps in MSIX still have access to everything and can't be entirely trusted, but the installer will warn you about that a lot less "scarily" than the SmartScreen Defender prompt this author doesn't like.

MSIX can be sideloaded by default in every supported version of Windows (in addition to or rather than Store installed) (supported versions of Windows include 7, 8, 8.1, and 10 after the Anniversary Update). MSIX support auto-updating even when sideloaded, all it takes is an HTTPS server with some simple manifests (for those that remember ClickOnce it is reminiscent but a lot easier/cleaner), or for Enterprises a file share will do.

The only caveat is that MSIX requires Code Signing Certificates for sideloading. (Note that makes Store install is a "cheaper" option with the $99/year and Microsoft handles the package signing for you as a part of the approval process.)

My biggest gripe with WinGet as a project (and no, the article is wrong it's not intended to replace the Store) is that it isn't doing way more to bootstrap MSIX packages instead of "downloading and running EXEs like always before".

> MSIX can be sideloaded by default in every supported version of Windows

Is that true? I thought MSIX sideloading was only enabled by default in the recent Win10 2004 release (better late than never!). https://www.windowslatest.com/2019/08/12/windows-10-20h1-imp...

APPX sideloading has been enabled by default since at least the Anniversary Update. Not every MSIX will sideload if just renamed to APPX, but many will (including many Win32 applications). Microsoft has stated that every actively supported Windows 10 feature update from the Anniversary Update forward will receive updates to enable the rest of MSIX and the MSIX file extension, including sideloading.

You're both partly right - it was enabled by default in Home and Pro editions since 2016, but is just now being enabled by default in the Enterprise edition in the new version 2004 update.

Not the case at all. It's about the fact that they build reputation off installation data from all Windows users, and the catch-22 that can create for new developers just starting out with their first app.

Reply on news.ycombinator.com