Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Any sufficiently advanced uninstaller is indistinguishable from malware

devblogs.microsoft.com

Post reply on HN
Print view View original

321–330 of 556 posts

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#321

Post by cto_of_antifa »

mschuster91 wrote: post #294
TheNewsIsHere wrote: post #279

Earlier quoted context omitted.

I would also like this option. I see why Apple finds it undesirable though. Software installation safeguards are a game of whack-a-mole with (e.g.) support scammers who ask grandma/Lee-in-accounting/Cindy-next-door to naively click through all the warnings. The closest Apple comes to this capability is achieved via device Supervision and MDM, which might be comfortable for some of us here in this forum but obviously…

> Baddies keep ruining all the fun for the rest of us. IMHO the blame rather lies with our politicians who are unwilling to take the steps necessary to cut the baddies off from the Internet. Let's see just how fast India, Pakistan, Turkey and other scammer hotspots clean up their act when the US+EU threaten to cut them off from the Internet and SS7 unless the scam callcenters are closed down for good... the amount of…

they probably don't do it because it's a bad solution.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#322

Post by em-bee »

Hikikomori wrote: post #255
tetris11 wrote: post #234

Earlier quoted context omitted.

Isn't that very anti-linux though, to have a directory owned by root but populated with subfolders owned by other users? /home is the only exception I can think of that does this.

/tmp

also mail and cron

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#323

Post by Arch-TK »

danbruc wrote: post #318
crabbone wrote: post #309

Earlier quoted context omitted.

[flagged]

I see no reason not to allow this. That's why people at Microsoft made those decision and not you. The most obvious reason would be to use the executable itself to back the memory which the comment you replied to already hinted at. Instead of loading the entire executable into memory on application start, you just create some memory mapping entry. As the code executes and accesses different parts of the executable, t…

I think maybe you should familiarise yourself with how e.g. ext4 works.

You can unlink a file and have a process still hold a reference to the inode. This allows you to continue reading (or executing) a file which may not have been fully mapped yet even after its last filesystem reference is gone.

There really isn't that much of a good reason to disallow deleting the files (assuming NTFS is capable of supporting a similar situation) except maybe for the fact that loosening a guarantee is still breaking an API in this scenario (someone might be relying on an executable file not being able to be deleted for some bizarre program feature).

I do wish Microsoft allowed more tweakables like this (so you can disable legacy behaviour if you feel you don't need it).

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#324

Post by phh »

danbruc wrote: post #318
crabbone wrote: post #309

Earlier quoted context omitted.

[flagged]

I see no reason not to allow this. That's why people at Microsoft made those decision and not you. The most obvious reason would be to use the executable itself to back the memory which the comment you replied to already hinted at. Instead of loading the entire executable into memory on application start, you just create some memory mapping entry. As the code executes and accesses different parts of the executable, t…

As the original comment mention, this issues doesn't exist on Linux because the FS is inode based. The file content will be removed only when the last user has been removed.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#325

Post by crabbone »

danbruc wrote: post #318
crabbone wrote: post #309

Earlier quoted context omitted.

[flagged]

I see no reason not to allow this. That's why people at Microsoft made those decision and not you. The most obvious reason would be to use the executable itself to back the memory which the comment you replied to already hinted at. Instead of loading the entire executable into memory on application start, you just create some memory mapping entry. As the code executes and accesses different parts of the executable, t…

I have very little respect to people at Microsoft when it comes to technical side of things. Whenever I have to deal with their "creations" it's like they were motivated by malice, or part of their frontal cortex gone missing.

> The most obvious reason would be to use the executable itself to back the memory which the comment you replied to already hinted at.

Imagine that I've already read that, and I still see no reason to do that. So what? The code of the program will go missing? -- What's the big deal? Kill the process. User wanted to remove it anyways... Let the user decide what to do: system shouldn't second guess me.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#326

Post by gruez »

Tuna-Fish wrote: post #256
BoppreH wrote: post #245

Earlier quoted context omitted.

How could Windows handle it by itself? If it provides a framework for installers/uninstallers, it'll be fighting the inertia of decades of legacy software, programmer habits, and old tutorials. If it tracks file ownership by program, it might accidentally delete user files. How would it differentiate between a VSCode extension that should be uninstalled, and a binary compiled with VSCode for a user project? A false p…

The same way any linux distro does? Define a separate directory for program installations, that user processes cannot write to. Only program that can do so is the package manager, which other programs can call to install packages. Uninstall removes everything related to a program from this directory. > In the age of shared runtimes, auto-updaters, extension marketplaces, and JIT compilers, managing installed applicat…

>The same way any linux distro does? >Define a separate directory for program installations, that user processes cannot write to.

What about /usr/local/bin? Isn't that specifically for putting non package manager binaries into?

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#327

Post by nine_k »

pie_flavor wrote: post #304
jcarrano wrote: post #299

The guys at MS are smart enough to decompile assembly but still not enough to have a proper inode-based filesystem where you can delete files that are in use.

Allowing you to have inconsistently valid data, where a file can both exist and not exist depending on who's asking, is the opposite of smart.

A file exists for those who have the access rights, and does not for everyone else.

In that case, the file exists only for the process which has already opened it.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#328

Post by webstrand »

danbruc wrote: post #318
crabbone wrote: post #309

Earlier quoted context omitted.

[flagged]

I see no reason not to allow this. That's why people at Microsoft made those decision and not you. The most obvious reason would be to use the executable itself to back the memory which the comment you replied to already hinted at. Instead of loading the entire executable into memory on application start, you just create some memory mapping entry. As the code executes and accesses different parts of the executable, t…

This is exactly what linux does too, inodes just let users delete/move the file on disk while the executable is running.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#329

Post by MrYellowP »

jcarrano wrote: post #299

The guys at MS are smart enough to decompile assembly but still not enough to have a proper inode-based filesystem where you can delete files that are in use.

What do you mean, "smart enough to decompile assembly"?

That's not exactly rocket science. Anyone can do that, there's tools for that.

Re: Any sufficiently advanced uninstaller is indistinguishable from malware

#330

Post by argiopetech »

tenebrisalietum wrote: post #313
jcarrano wrote: post #299

The guys at MS are smart enough to decompile assembly but still not enough to have a proper inode-based filesystem where you can delete files that are in use.

NTFS was doing B-trees in the 90's far before btrfs was a twinkle in someone's eye; unless some other UNIX was doing it.

Apple's HFS used a B*-tree starting in 1985.
Post reply on HN