Hacker News Reader

Comment by herf | Hacker News Reader

Windows still has a situation where Chrome's updates use a special service to dodge around escalation issues, and Spotify and many others install in AppData for the same reason, and lots of uninstallers just don't work, leaving files and other things behind. MSI has required "chained signing" using an old key to sign the new one forever, but when you're maintaining updates over a decade that isn't very easy to do. I hope they can clean it all up!

View on HN

They install in AppData to get around IT admin blocks. Unless a sysadmin has the tech available to operate on a whitelist only basis (which not everyone does - it’s super expensive), you can be certain that at least some users have things like Spotify installed illicitly.

And this is why having a solid working relationship between all levels of IT and your users are so important. It really is customer service first, tech second. If your users trust you as the IT admin, they’ll know to ask first before downloading AppData installers like this before they become a job ending issue for them.

For reference chrome uses open source Omaha installer and update and the others noted use Squirrel. Both can exist in users app data (squirrel only can however as its philosophy is to be user installable without admin.)

It used to use Omaha. They recently rewrote it and Chrome now uses an installer framework fully maintained in their own tree. It's conceptually similar but cleaned up.

And since the Chrome fork Edge is part of Windows now, this updater already runs on all Windows machines (e.g. the MicrosoftEdgeUpdateTaskMachineUA scheduled task).

They did not even use Windows update for that one.

Can you force Edge to go through Windows Update? They have GPOs for download, but I didn’t see anything like that in there.

Are you sure the others use Squirrel? After it’s maintainer decided to crash out and abandon multiple libraries including Squirrel, I was under the impression it was abandoned?

Squirrel is abandoned for years and still used anyway, often by people who don't realize it's abandoned. It's the default if you use the Electron toolchain, so that's why. It has serious design problems too, like it breaks Windows networks by bloating people's roaming home directories with dozens of independent copies of Chrome which then get backed up, copied around on login etc. Admins loathe it as the whole point of this design is to bypass their ability to manage their own deployments, although they still get the blame when things break, of course.

There's a better way, which I am shamelessly self-promoting in this thread (as it's 100% on topic) - my company makes a tool that can ship self-updating Electron apps and beyond being not abandoned, it's got a lot of really useful features, like being able to do the build and upload of signed updating packages (using the tech MS is pushing here) from Linux CI workers, without needing a Windows license.

https://hydraulic.dev/

It can also do forced updates on launch, which can be helpful for apps where the protocol between client and server changes regularly. And it plays well with corporate Windows deployments. People can install apps locally without needing administrator access but it goes into c:\Program Files

That’s awesome, but keep in mind that the AppData thing is likely a feature and not a bug.

Think about it another way: if they install in AppData, they can likely bypass IT depts and other business bureaucracies and get a foothold somewhere in an organization. It’s absolutely malicious, both in terms of tech and business practices, but it works.

That might have been true a long time ago, but nowadays Windows makes it easy to black/whitelist executables from the home directory with stuff like AppLocker. Meanwhile, the MSIX subsystem lets users install apps safely without needing admin access into c:\Program Files.

So, what Electron does might have been a neat growth hack once, but now it's as likely to hit roadblocks as not (at least on any modern Windows network with a switched-on IT department).

For the leaving files around case, isn't that an impossible thing to really deal with from the installer stand point for non containerized applications that have root/admin access?

Because they can just create and write to random directories whenever they want. And any Uninstaller, either provided by the app or Microsoft could just miss these files, because they aren't recreating the full program control flow.

Yes. UWP/MSIX+AppContainer addressed this, but inherently impose limitations on what the app and installer can do.

This is why we invented distributions (Linux and friends): one package manager, common practices and shared code, to avoid everybody doing its own (sometime broken) thing

And now we also have flatpak, snap, etc. on top ofnthe "one package manager"

Why is it impossible if you can track where they write during the installation process? There are even apps that do that. For apps that run as admin that's harder indeed, but at least for the installation process the good-but-not-perfect design could still be added?

They don’t install into appdata to dodge escalation. They’re not hiding. Microsoft has recommended installing into appdata for nearly a decade. Maybe over a decade at this point. It’s how you’re supposed to install applications today, if those applications don’t need elevation to run.

What about multi user sharing of an app? I thought that was the main benefit (at least that's what app installers keep saying the difference is)

What about it? You have to install to a non-user location in order for the application to be used by multiple users.

To be fair, many GNU/Linux packages also leave garbage behind.

Do you expect things not in the package manifest to get cleaned up by thr package removal tools?

This surprises me, I would have thought usees would think package removal would only meant package removal.

Yes, if there is a script generating stuff at install time, there should be a script deleting the same stuff at removal time.

Most of the time there isn't one.

This is not what is generally expected at package removal, at least from my understanding.

Where do you draw the line at removal, configuration files, user created documents, config files on networked home directories.

I dont think you are being unreasonable, maybe we need better clean up depending on what the user needs..

It would mean tracking the creator of filws and tagging them appropriately, using this list during uninstall.

Reply on news.ycombinator.com