Hacker News Reader

Comment by ikekkdcjkfke | Hacker News Reader

Why does an installer need admin rights though

I don't think he's saying it requires elevated privileges. When binaries aren't signed Windows will throw up a warning that it isn't signed which makes users hesitant to install.

Unrecognized publisher warning in blue box (not UAC) comes up no matter what the software is when trying to install or run.

This is correct and it usually takes some combination of right clicking the installer or holding shortcuts to bypass. It's not obvious how to do so without Googling around.

Right clicking is a Mac thing. On Windows, most of the warnings can be bypassed without any special actions (there are two buttons), the SmartScreen warning requires clicking on "More info".

Moreover, a warning pops up even for signed binaries, until that binary has been installed enough times (?) and Microsoft is satisfied.

Not if you buy an EV certificate. Then you have positive reputation from the start.

How could it not? It is adding software to the system software set, accessible by all users of the system.

And many programs require some kind of integration into the OS, such as file type associations or context menu entries, which even a single user shouldn't have access to do.

Most software installers on Windows offer the user a "Install for this user"/"Install for all users" option, or will just install to the current user's appdata, which doesn't require admin rights.

Not the case for ImageMagick, there are some things that cannot be installed for current user, like Windows services or specific kinds of shell extensions.

It's definitely not "most". It does happen, but it's actually very rare. Most people nowadays who go to the trouble of making a native installer do so because they want some kind of OS integration, so it's a nonstarter anyway.

This way of working should have been left behind in the previous century.

Sandboxing should be default. Associating file endings should be a suggestion to the OS, accepted by the user, not something only configurable by delegating full super admin to third party app.

Slow loading context menus where every app tries to claim its presence. Thank you for reminding me why I don’t use Windows since years ago.

A image editor should only need to load and save images I ask it to, no other system integration. iOS, Android and the browser has proven it is possible. Now the desktop needs a similar journey.

> Sandboxing should be default.

Please no. There are valid reasons to NOT sandbox, and in Windows there is sandboxing in default (windows store apps) and there are often issues with those versions of the software. For example, Slack downloaded from the windows store uses 30-40% of your CPU while idle, but not when installed from their website.

Even in Linux and using the Snap sandbox (ubuntu), there are significant issues when trying to access globally available software, which can be extremely hard to support and diagnose.

The problem is that sandboxing is an afterthought on these platforms.

That is obvious. Like saying the "sun is yellow because it is about 4.5 billion years old."

Even if sandboxing was thought about back when Linus was porting Unix, it would have been extremely slow as processors and ram was very limited back then. If we could go back in time and give them ridiculously fast processors and effectively unlimited ram like we have today, I'm sure Linux and Windows (er, DOS) would look quite different, and be much slower.

Just look at how slow mobile OS's are, despite being on ridiculously fast hardware. My Palm Pilot in 1998 felt faster and more responsive than most devices today. Android devices essentially require a human to manage the memory because starting just a few apps uses almost all of it. Even iOS devices can only run a few apps before it starts killing things. Sandboxing has an extremely high cost (with not much to gain), so high that even on modern hardware you start running into physical limits very quickly: memory, disk space, and processing power.

Until we can properly share resources in sandboxed apps (or increase the physical limits of the hardware) to a certain point, it just doesn't make sense to only be able to run a few things on a desktop machine.

Performance has absolutely nothing to do with sandboxing.

Heck you could already apply many sandboxing techniques with Linux 0.x by chroot() to an empty directory followed by setuid() to "nobody". If that process needs file access, fork() a broker process before the chroot() that funnels file descriptors over an unix socket to the sandboxed process. The broker strictly checks file access permissions of course or could even present the file open dialog to the user.

This is next to no overhead in many cases (keep in mind you'll stat/open/mmap a bunch of .so's anyways on startup), except for the fork() maybe. And that can be fixed by proper sandboxing API's by the OS.

The problem is that these OS's give the processes to much permissions in the fist place (access to all the user's files, ...).

> Performance has absolutely nothing to do with sandboxing.

In theory, sure.

In practice, when Ubuntu added a sandbox to the calculator it started taking longer to start than Eclipse. Took them about 4 years to fix it.

More a matter of execution than the technology.

Sandboxing and virtualization existed in mainframes and micros already for decades, and were originally made available in UNIXes like Tru64 and HP-UX Vaults.

> Performance has absolutely nothing to do with sand boxing.

Even simple optimizations like shared caches fall afoul of proper isolation. In the past browser caches could be abused to find out if a user frequented specific sites just by checking how long it would take to request a site specific resource. Result: no more shared caching, all resources had to be loaded for each site separately.

Every time a user space program makes an syscall the OS already has to go through layers of indirection. The OS can provide a program with a virtual or restricted view of the filesystem instead of the real thing just as easily. The OS already prevents processes from accessing each other's memory. There are some difficulties with sandboxing peripherals and GPU access, but for the most part sandboxing has absolutely no performance impact. Sandboxing doesn't mean the OS has to spin up a virtual machine every time you want to run a program.

The sun is white though.

White is quite a flexible term. The suns (color) temperature is 5778K.

That's a weirdly precise measurement of the temperature of sunlight. Colour temperature isn't really a precise way of measuring colour since not even a body like the sun really acts as a black body emitter. All that said, colour temperatures around six thousand kelvins are certainly describable as white and not as yellow.

The Sun is an almost perfect black body emitter. Outside of our atmosphere, it's perfectly so, and the atmospheric distortion is imperceptible.

Any reasonable representation of its color would classify the Sun as white, except when comparing it to other stars, where the small differences matter a lot.

Maybe you are more forgiving than I am, but the spectrum of the sun even measured from nearby in space is distinctly different to a Planck spectrum[0].

[0] https://www.e-education.psu.edu/meteo300/node/683

Does this also affect non-store sandboxes? I think it's pro-only, but windows supports sandboxing for any kind of app.

> Sandboxing should be default

This is exactly how Qubes OS works. My daily driver, can't recommend it enough.

Windows has already made that journey years ago. The MSIX system works the way you suggest:

• Admin privs aren't needed

• Packages declare what integration points they need in an XML file

It's similar to the way macOS, iOS and Android work. You can also (starting soon in Win11) declare that the app will be sandboxed.

However, developers have to actually use this system and most don't know it exists or how to use it.

The ImageMagick developers can fix their problem by purchasing a cheap OV code signing certificate and then using Conveyor [1], which is a product my company makes. It can make these MSIX files along with all the new formats it requires for things like icons, and it can do so from Linux or macOS or whatever the developers prefer to use. So you can do releases locally without needing CI/CD or cloud signing.

Now, they'd like to have releases be done by GitHub Actions instead of using local hardware, and that would require a cloud signing service as they say. Conveyor can use those too. But that's not a technical requirement anymore, because it doesn't use any of the native toolchains so you don't need to release Windows binaries from Windows (or Mac from Mac). Conveyor can create all the files for installing and updates, and then upload them to a GitHub Release or ordinary web server, and it's free for open source projects. Given that they're initiating the release process from a laptop anyway, they can do it all locally.

Conveyor can also self-sign but that's more just to enable the tracking of permissions and things for all software. Self signed binaries still trigger warnings obviously.

[1] https://conveyor.hydraulic.dev/

> The ImageMagick developers can fix their problem by purchasing a cheap OV code signing certificate and then using Conveyor

By "cheap" you mean $500/year[0]? Then for anyone who isn't open source it's another $45/month on top for Conveyor. That's hardly "accessible".

That said, Conveyor looks awesome. We (thankfully) distribute our application via Steam/EGS/etc but when we were looking at bundling installers before that it was a nightmare and we probably would have just paid for Conveyor.

[0] https://order.digicert.com/step1/code_signing

Well, firstly, buying certs is optional. You can distribute via the Microsoft Store and they'll sign for you. That's a $19 one time fee, no subscription. It's by far the cheapest way to distribute signed software on Windows. Conveyor can prepare everything and do the upload for you.

So this stuff only applies if you don't want to go via the store.

Now you picked DigiCert and their cloud HSM solution. They're unfortunately quite expensive. SSL.com is a lot cheaper:

https://www.ssl.com/certificates/code-signing/buy/

So about $100 / yr, with a one off fee to buy a USB key.

And then ImageMagick is open source so they could use the tool for free.

Even commercially, $100/yr plus $45/month isn't particularly expensive compared to the labor cost of developing software commercially. The cost of the tool is like one hour of skilled labor at contracting rates per month. It'll save far more time than that given that as you said, doing deployment by hand is a nightmare.

And as you note, if your app is open source then you can use it for free. So then we're down to using the MS Store + Conveyor for free: $19, one off. Anyone can afford that.

$500 per year is nothing, that's $41.67 per month or $1.37 per day.

I'm going to ignore Conveyor because that post was just a sly advertisement.

> iOS, Android and the browser has proven it is possible.

Whatever woes Windows's UX and design choices cause, I'd still take it a million times over any of these three terribly improductive environments

Security is coming anyway, unless you stay on old Windows versions.

"BlueHat IL 2023 - Default Security"

https://www.youtube.com/watch?v=8T6ClX-y2AE

"Modernize your Win32 application for security and privacy"

https://build.microsoft.com/en-US/sessions/d2ad7043-223f-4bb...

The problem with sandboxing is that you're limited to the APIs that your vendor provides, which stifles creativity. For a vendor to open those APIs up, they have to realize that there's somebody out there wishing to use these APIs. If all platforms were properly sandboxed from the start, a lot of software we now know and love would never have existed, it couldn't be created because of the missing APIs, but the APIs wouldn't be added because the vendor wouldn't know that some software needs them.

Screen readers are a good example, proper accessibility APIs came later, as a response to screen readers' needs. The first screen readers used various tricks for injecting code into other processes and emulating GPU drivers to intercept GDI calls.

I disagree entirely. The only reason for creating native apps is to allow apps to interoperate and integrate deeply with the OS. Apps should be free to pass data around with each other, and this absurd level of security overreach, suggesting every app should be sandboxed, is actively hurting the computing world.

Sure, if you're making a game or some browser replacement, then go for sandboxing. But most productivity software shouldn't be confined to that. We need computing to stay open, not to all be closed down mobile OS style.

That made sense in the olden times of a decade or two ago. Now, when you can not trust any software on your machine to refrain from exfiltrating telemetry—no longer. Even FLOSS is not enough.

Thankfully open-snitch is now available on Debian.

When $HOME is exposed to the world it matters.

There's HKEY_CURRENT_USER for a reason.

> How could it not? It is adding software to the system software set, accessible by all users of the system.

User-only installs are possible:

> C:\Users\YourUsername\AppData\Local is intended for MSI installations for a single user but typically doesn't require Administrative privileges. This folder is normally hidden.

* https://superuser.com/questions/1327037/what-choices-do-i-ha...

This is the variable %LOCALAPPDATA%:

* https://pureinfotech.com/list-environment-variables-windows-...

See also perhaps CSIDL_DEFAULT_APPDATA and CSIDL_DEFAULT_LOCAL_APPDATA:

* https://learn.microsoft.com/en-us/windows/deployment/usmt/us...

Reply on news.ycombinator.com