Hacker News Reader

Comment by zelon88 | Hacker News Reader

"AppData" is where user specific application data is supposed to be stored.

"The Registry" is where application configuration is supposed to be stored.

"ProgramData" is where application specific data is supposed to be stored.

"Program Files" is where read-only application binaries and code is supposed to be stored.

It really is a simple concept from a Windows perspective. What ruins everything is overzealous and/or ignorant programmers who don't take any pride in their work, or lack all respect for the users environment. For example; an .ini file should not be a thing in Windows. That is what the registry is for. But the programmer writes the code for Linux, half-ass ports it to Windows, and leaves the .ini file because his code is more important to him than the end-users operating system.

There is nothing wrong with AppData permissions. The problem is with the users understanding of what it is for, and the developers understanding of how it should be used.

View on HN

As a Windows sysadmin AppData has been an unmitigated shit show forever.

Developers (including those inside Microsoft) don't give a damn about how Microsoft intends anything to work, and AppData has become a dumping ground of software installs to end-run IT departments. A lot of malware dumps into there but good luck limiting execution from that directory hierarchy because all your business-critical end user communication apps live there now too.

The functionality of roaming users profiles (i.e. registry settings "following" you to a different computer, which gives a really slick user experience when it works) was completely ruined by devs dumping piles of small files into "AppData\Roaming" (and completely not understanding that "AppData\Local" even exists, let alone what it's for).

In Windows 2000-land you could redirect AppData to a UNC path and mostly get around this behavior. That's not really "a thing" anymore because you've got apps like Microsoft Teams storing sizable databases in these locations and getting really, really cranky if network connectivity is interrupted.

Windows development betrays its legacy DOS parentage even for devs who never lived thru that era. There were no rules. There was no adult supervision. There was poor documentation of APIs so you just hacked something together that worked well-enough. Periodically Microsoft tries to start over (all the APIs w/ "2" at the end, et. al.) and the cycle repeats.

And converse, on Linux it's so hard to get every shitty tool to put files in XDG dirs, not spew them all over ~.

A maintainer can patch the package to store it configuration files into a XDG directory, then upstream the patch. If none of maintainers did this, then problem is deeper.

https://wiki.archlinux.org/title/XDG_Base_Directory#Hardcode... upstreams quite too often reject patches or let them languish

> was completely ruined by devs dumping piles of small files into "AppData\Roaming" (and completely not understanding that "AppData\Local" even exists, let alone what it's for

As someone who only occasionally uses Windows, I think `%AppData%` sending you to `~\AppData\Roaming` doesn't help.

>an .ini file should not be a thing in Windows

Hard, hard disagree there. Having config files available is vastly preferable to using the unmitigated shitshow that is the windows registry. That and a config file at least gives users a prayer at being able to provide some sort of troubleshooting information, and provides savvy users with a way to actually solve problems on their own.

>half ass ports it to windows

Redmond, themselves, do all sorts of seemingly 'wrong' things with their directory structure, which tells me the 'free for all' nature of it is intentional, and not wrong at all. It is a terrible structure, it does cause problems, but, that's the conditions you work under while using windows. It's mostly OK in practice, but as bitwarden found out, there are conditions that developers have to account for if you require security and safety.

And factually, your presumed solution of "put things in the right place" is doubly broken, because if one acquires the correct privileges, there is no location on a windows machine where cleartext data is safe. The solution is not "store it in the correct location" the solution is to encrypt sensitive data at rest, regardless of location, which is more or less what bitwarden did. That's the correct strategy, and it's operating system agnostic.

Agreed. The windows registry needs to be killed with fire.

There's no appreciable difference between the registry and a directory of config files except that instead of an INI parser you have to use the much, much worse WIN32 API.

Editing config files is fairly safe and user-intuitive. Sure you can break something by writing the wrong config file, but you do not risk breaking everything. But clumsy use of regedit does have a chance of totally borking the entire system.

And then you have maniacs who store user data in the registry. I know of at least one game which stores save files in the registry.

I get the intention of the registry, but it's just not fit for purpose. Maybe it was better back in the 90s, but it's just a hellscape now.

But it's so easy to export all my PuTTY profiles from the SimonTatham registry folder to a .reg file and use on the next computer...

There are real integration challenges with the "simple file approach":

  - File locking and concurrency
  - Atomic writes / moves
  - Realtime change observations

> clumsy use of regedit does have a chance of totally borking the entire system.

So does a clumsy rm -rf, which shows up in stories here far more often than stories of people breaking their registry.

Can you provide a recent reference to someone bricking their system with regedit?

I think you could even make the argument that nobody breaks their registry because nobody wants to mess with something so user-unfriendly. Even the developers making applications tend stick all their config in .ini files because files are easier for everyone to work with.

Then use SQLite.

That solves 1 out of the 3 issues... But at that point, why bother? The registry is a database already.

The point is that, nowadays, apps should by default be isolated from each other, rather than AppData and HKCU being a free-for-all.

Windows makes it hard to whitelist known-safe apps (there’s WDAC but it’s poorly documented and a PITA) and every program you run has access to everything of importance on your system.

Imagine how upset people would be if it turned out TikTok on your phone can access your entire iCloud Drive and Keychain. Yet we accept this security model on our desktops.

We accept it on the desktop because the desktop app model is from before the internet. There was only 'trusted' applications that had access to all the users data (and really most of the time the entire machine), and really there wasn't even the idea of an internet connection being built in at all. In addition desktop applications are based around the ability to read the users data files. Desktop users typically want all their excel files accessed, along with any embedded images from anywhere in their user directory.

For the most part the changes you'd want to implement for security would ruin the productivity most of the workflows desktop users have these days, and would take a massive amount of refactoring to get to work anywhere close to what they do now.

There’s a difference between reading user data (i.e. “My Documents”) and reading other apps’ application data (e.g. Firefox’s cookie jar).

macOS has started disallowing the latter (i.e. restricting access to other sandboxed apps’ files from both sandboxed and unsandboxed apps) more than a decade after the OS was introduced, yet I don’t feel like my productivity has been ruined.

Older desktop apps also tended to be more trustworthy.

There's so much commodity garbage out there now (e.g. I find it near impossible to find quality ad-free apps on Google Play)

Microsoft themselves don't understand that. Teams installs itself to appdata in its entirety. One full install of teams for each user profile. Keeping it updated across one machine is impossible. How can we expect anyone else to do it right when Microsoft allows its own employees to abuse it?

The original Teams was an Electron app and was stuck with Google's methods.

The new Teams is based on WebView2 and runs from C:\Program Files\WindowsApps\

Teams was kept in appdata like Chrome so that these programs can update themselves without admin privileges and I suppose that is how they keep users on a recent version.

Except it completely backfires when you have a workstation with multiple users who infrequently use it. Existing patching solutions, like microsoft's own system center have a hard time coping with applications that live in app data. So you end up with 8 instances of teams on a system. 6 of which are months out of date.

I just hope they kill teams with fire. It is hot garbage.

So what category does stored browser passwords fall? Because it sounds like " user specific application data " which is in AppData, which is the issue. But if that's not correct which of those locations is?

It should be in AppData. Gp is just a really weird unrelated rant.

ggp: unsandboxed AppData (unsandboxed filesystem in general, really) allowing everyone to read everyone else’s stuff is a security nightmare.

gp: stupid programmers don’t respect Windows’ simple scheme to place data in four different places!

What? Even if everyone places data correctly, they can still read everyone else’s stuff, as long as they belong to the same user. That’s the problem.

They belong to encrypted user credentials. https://support.microsoft.com/en-us/windows/accessing-creden....

"programmers won't use our poorly designed system therefore the programmers are wrong"

Windows registry is in itself insecure. Applications can't own perms to their own entries.

Look at what people are using and optimize for that. Clearly the intended system is wrong, and ego death is necessary to create real fixes.

The easy and expected fix being that applications get perms for their own folder, rejecting 3rd party by default.

The proper larger solution being open code signing. But MS and friends are making big cash so they don't care.

> Windows registry is in itself insecure. Applications can't own perms to their own entries.

I think registry entries support DACLs, and permissions can be restricted to SIDs or user accounts. I have no first-hand experience with this though; YMMV.

> The easy and expected fix being that applications get perms for their own folder, rejecting 3rd party by default.

Back in Windows 8, they launched an app model called UWP or something which does exactly this. Met with luke warm reception from the industry because (you guessed it!) back compat.

Restricting to user accounts is useless. Malware runs as your user.

https://xkcd.com/1200/

They absolutely support DACL's. For the longest time I prohibited my own user account from modifying a certain registry key to prevent Dropbox from constantly reinstalling unwanted green checkmark overlays.

UWP wasn't just lack of back compat, it enforced things like apps sleeping on minimize which is nuts. This was in an attempt to make Windows a universal OS that's tablet and phone worthy.

> "AppData" is where user specific application data is supposed to be stored.

> "ProgramData" is where application specific data is supposed to be stored.

Simple maybe. Coherent, no.

It's not really any worse than *Nix mess of /bin, /usr, /usr/bin, /usr/local/bin and /opt ... and probably a couple others I missed.

It was confusing for me too.

Basically:

- AppData = User (interactive) application storage - ProgramData = Service / Background (non-interactive) application storage

I'm not so sure I completely agree with you about .ini files. I rather miss them. Some people have regarded the registry as a mistake, or at least an over-reach. I like the ability to edit .ini files and make them understandable.

Maybe the compromise solution is to put the user-relevant portion of the .ini file in %AppData%.

Please don't use INI files. The registry is infinitely more manageable for sysadmins than INI files. I hate it when your app makes me write scripts to manage settings versus just using the built-in tooling in Group Policy for dealing with the registry. (Yes, yes-- there is tooling in Group Policy Preferences for dealing with INI files. It fails spectacularly on malformed INI files. It has never been reliable in my experience.)

The idea of a centralized grammatically-accessible configuration store was a good idea (albeit this isn't want the registry was "for" originally-- it was just a file-type registry originally). GConf was a similar idea.

Devs misusing the registry to store opaque binary values (especially gigantic ones), accessing it with too high a velocity, and having a less-than-stellar file format have hurt it, for sure. Having few good schema rules or APIs that limited arbitrary developer access didn't help either.

Okay, so that's the sysadmin perspective. Tell me about the user perspective.

Then, we should talk about, when they are in conflict, which one comes first.

A dev is going to include UI to manage the settings if non-technical users are expected to modify them. Whether those settings go in an INI or the registry doesn't matter at all for that UI.

Having said, that level of technical skill req'd to edit an INI or the registry is about the same. Either way you're talking about a non-technical user descending thru a hierarchy of strange-to-them named containers to get to an arcane-looking location where settings are saved.

The user is going to call me when they have problems. It's easier for everybody if I can just administer the software centrally so they don't have problems to begin with.

How is the registry going to make that administration any easier? The registry is its own micro cosmos, doesn't matter if some setting is in an INI file somewhere on the filesystem or somewhere in the registry

Sysadmins have great tooling to deal with the registry (Group Policy, Local Group Policy for non-domain machines). The tooling for INI files isn't very good.

I don't know one sysadmin that likes how the registry does things. INI files for configuration are vastly easier to understand and edit. Use the registry for permissions and keep your tooling.

You are speaking orthogonally to the topic you replied to. The parent wants sandboxing between different programs so that one cannot read another’s data without explicit configuration and consent.

But why split up the application like that? Why not have a folder for each application that just contains everything?

Everything being in one place by default also means that a user can just copy the entire application folder as a backup.

Because it'd be really nice to have a place with just application data to backup. no configs, no application state. Or alternatively it's nice to have a place to just factory reset all your app config, but keep all the data.

But would you trust that you would actually get all the app's configs? Ie window position and all that.

And would you trust that you would only affect that one application and not any others?

And wouldn't you just unusual and reinstall the application anyway?

Making it easier / less work for more devs to do the right thing doesn't seem like an inappropriate request. If users are misusing your system, there are other solutions than RTFM

Thank you! And Program Files is for x64 windows apps, Program Files x86 is for 32bit apps but vendors use both interchangeably and sometimes use both for the same app!

Don't forget about Wow64 and redirection ;-).

You forgot about "my documents", which is of course a great catch-all location for all four types of data you mentioned.

I actively avoid that dumpster fire. None of my actual documents live in any portion of My Documents.

I agree in a perfect world, but I believe the OS should have a design that “forces” the programmer to maintain the correct abstraction.

Or at least have the override for such abstractions be blatant and explicit if the programmer wants to circumvent them.

And of course, given the age of Windows OS/ecosystem, it’s a pipe dream to have a redesign that isn’t backwards compatible

How do you tell the program what belongs where? How does the OS know that the application is reading a file full of configuration entries that should be in the registry? What is the difference between reading a file full of data and reading a file containing your own configuration?

How does the OS know that the file you're writing to belongs in AppData or not?

To create the system calls for this you would break everything about windows file permissions. Currently, you interact as a user account. In order to accomplish the real time heuristics you're proposing you would also need an application user account in addition to the users user account.

At what point does the responsibility for knowing how to code fall on the programmer? How much capability are you willing to take away from effective programmers, to artificially protect the ineffective ones from themselves?

>What ruins everything is overzealous and/or ignorant programmers who don't take any pride in their work

uh you mean overzealous product managers and business owners who never let programmers take their time on anything because quality doesn't matter?

why would I take pride over my employer's property? lol if the code he buys from me is bad, that's his problem, especially since I have to stick to his timelines and am not given sufficient equity and agency to feel ownership over the project.

you know what makes programmers lose their desire to take pride in their work? getting blamed when we're ordered to cut corners, or implement bad designs. fuck right off with that, we're not the ones in power.

Is this post sarcastic and I’m just missing it?

4 different locations to store program data, some of which are hidden, is freaking stupid design. Like, beyond moronic design.

Everything, and I mean everything, about a program should be in a single folder structure and the OS should by-default lock that application to only accessing it’s own folder unless otherwise granted permission (in a centrally auditable/revocable location).

Applications/ExampleApp/

Should contain everything, and deleting it there should clean it as if it was never installed. If it needs to access something in documents/desktop/etc, the OS should ideally present a file picker to pass in a copy, but applications could request access to a specific path if absolutely necessary. You should also be able to “save to desktop” without the application having read/write access to the desktop/documents.

“Exporting” is the application taking the local copy nested in Applications/ExampleApp/ and passing it to a system save dialog, then the OS can store the file (therefore having permissions) wherever the user wishes in an context menu that’s outside the application’s control (it’s the OS).

The idea that every installed application has wide-open filesystem access to say, all my documents, by default is pure insanity.

That makes managing a user's application specific data difficult though. For one you have different user's data intermingling which potentially causes new problems. But on top of that you make managing and backing up that data more difficult. As it works now with appdata you can back up a user's profile folder under C:\users and get everything they have assuming they haven't gone out of their way to save data to a strange place. If all data for an app lived in program files then backing up and restoring that data becomes much harder.

Ideally a new instance of the application is installed for each user. This also provides better isolation if one user upgrades/removes/breaks their application instance. I, for one, have really come around to the AppImage model [0] in the last couple of years.

[0] https://appimage.org/

I don't like the solution being to just make containers out of everything. That introduces its own problems and lets developers be lazy in other ways.

I guess the OS keeping track of .../programs/NameOfProgram/user settings/NameOfUser is just impossible? Or having an app install create a link in /users/NameOfUser/program-config/NameOfProgram to the config folder is equally impossible magic ...?

That's asking a lot of windows. But as a former sys admin, that sounds like it would make things harder to manage. So its linked. But its not really there. So existing userdata backup automation wouldn't catch it. Sorry your Outlook psts are gone. User data should live with users. The problem isn't with that paradigm. Its that its abused and wide open.

Can't blame the programmer for that - Windows shouldn't allow the programmer to do stupid shit

The sheer volume of legacy software prevents this from being realistic. Microsoft's commitment to backwards compatibility has reaped rewards for them. Any restrictions would have a user-controllable toggle.

If APIs prevent programmers from stupid shit the devs would encourage the end users to blame Windows and, more than likely, turn off the restrictions. (Case in point: User Account Control and making users non-Administrator by default. I've dealt with so much shitty software that opens its install instructions up w/ "Disable UAC and make sure the user has admin rights.")

There has to be a point you draw the line and say "Dev, grow up and learn about the platform you're using." An app that required users to be root on a Linux machine wouldn't survive community outrage. Windows doesn't have that kind of community. (Try arguing with a vendor about idiot practices in their app and watch their sales gerbil attempt to end-run you to your manager...)

What if Microsoft limited these APIs to programs with "Compatibility Mode" enabled? (And—this may already be the case, I'm not sure—made it impossible to enable compatibility mode programmatically?)

I feel like this would create a strong incentive for modern software to do things "properly", while still allowing legacy software to run (albeit with a couple of extra clicks).

Look how long we're still dealing with software that requires Java 6/7/8, and all the security issues that come with that. Servers/Appliances with IPMI remote consoles that do not support HTML5. It's easy to say "Replace the equipment" but our budgets don't always allow for that.

I think Microsoft's commitment to backwards compatibility is awesome. But it would still be better to at least get newer apps working the right way. Even in the event those legacy apps remain in use for ~forever, at least there would be fewer of them.

My Steam Microsoft Flight Sim requires admin rights, so clearly this is a lost battle. We just need to have containers for every app.

We may just get that. Microsoft's attempt to introduce sandboxing with UWP/msix was ignored by developers. Since then MS has added Windows Sandbox to Win 10 Pro and up, essentially disposable VMs for running sketchy software. I wouldn't be surprised if a couple versions down the line we get the option for more permament app-specific VMs, with integration into the window manager similar to QubesOS. A lot of groundwork for that already exists for WSL2, like more efficient memory use between VMs and shared GPU access.

I don't think this is fair. Linux and Mac used to operate in generally the same fashion. Only recently have they started sandboxing stuff.

Windows doesn't have the same privileges because they are forced to maintain backwards compatibility.

It's just as bad there with everyone randomly shoving dot-files in my home directory instead of using ~/.config, ~/.local, ~/.cache, and friends.

Just to name a few in my home dir ... aws, cargo, dotnet, yarn, vscode...

All of these narcissistic tools are pretty annoying.

40% of those tools are majority controlled by Microsoft...

See, I disagree with that. The computer is an arbitrary command execution machine. It does what you tell it to do. Don't tell the computer to do stupid shit and it won't. There are plenty of valid use cases where you want to use the capability of the computer without some arbitrary OS policy preventing you from doing it "because some programmers are irresponsible."

In a world of various medium-trusted apps that I don’t love but still have to use to get my job (or a bank transfer etc. done), that model doesn’t really work for me anymore.

Users aren’t “telling the computer what to do” anymore for the most part, third party app developers are; this puts a lot of responsibility on the OS for protecting the interests of its user against that of a malicious or careless app developer.

Of course I want to be able to fine-tune that protection, but restrictive defaults make sense.

No way is that simple.

your rules would state "application specific data" would not reside in appdata even though those exact terms are there. it's the opposite of self-documenting

It really is a simple concept

At first I thought you meant that sarcastically.

Microsoft got overzealous showing off their long file names back when that capability was introduced to their filesystem, and any sense of organization in the OS fell apart after that.

I actually miss .ini files. It was nice being able to keep your software's data alongside it (in a simple folder like C:\Programs\3DS) and made it easier to clean up remnants. I understand what drove the design, but a more sparing and opinionated approach could have produced a much more elegant outcome.

Incidentally, even Microsoft software is wildly inconsistent in how it uses the registry.

Makes /bin/, /usr/bin/ and /opt/ seem simple

Reply on news.ycombinator.com