8 ms·

"AppData" is where user specific application data is supposed to be stored. "The Registry" is where application configuration is supposed to be stored. "Progr

"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.

burnte 3y ago
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!
- rkagerer 3y ago
  Don't forget about Wow64 and redirection ;-).
EvanAnderson 3y ago
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.
- SSLy 3y ago
  And converse, on Linux it's so hard to get every shitty tool to put files in XDG dirs, not spew them all over ~.
  - oneshtein 3y ago
    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.
    - SSLy 3y ago
      https://wiki.archlinux.org/title/XDG_Base_Directory#Hardcoded https://wiki.archlinux.org/title/XDG_Base_Directory#Hardcode... upstreams quite too often reject patches or let them languish
- vladvasiliu 3y ago
  > 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.
jasonjmcghee 3y ago
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
- deleted 3y ago
  [deleted]
dingnuts 3y ago
>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.
at_a_remove 3y ago
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%.
- EvanAnderson 3y ago
  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.
  - at_a_remove 3y ago
    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.
    - EvanAnderson 3y ago
      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.
bhdlr 3y ago
Can't blame the programmer for that - Windows shouldn't allow the programmer to do stupid shit
- EvanAnderson 3y ago
  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...)
  - Wowfunhappy 3y ago
    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).
    - dessimus 3y ago
      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.
      - 3y ago
hinkley 3y ago
> "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.
- voidfunc 3y ago
  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.
- lysp 3y ago
  It was confusing for me too. Basically: - AppData = User (interactive) application storage - ProgramData = Service / Background (non-interactive) application storage
hattmall 3y ago
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?
- oefrha 3y ago
  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.
- JackeJR 3y ago
  They belong to encrypted user credentials. https://support.microsoft.com/en-us/windows/accessing-credential-manager-1b5c916a-6a16-889f-8581-fc16e8165ac0#:~:text=Credential%20Manager%20lets%20you%20view,select%20Credential%20Manager%20Control%20panel https://support.microsoft.com/en-us/windows/accessing-creden....
cameronh90 3y ago
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.
- pixl97 3y ago
  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.
  - lxgr 3y ago
    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.
  - rkagerer 3y ago
    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)
newZWhoDis 3y ago
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.
- thereddaikon 3y ago
  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.
  - whoisthemachine 3y ago
    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/ https://appimage.org/
devwastaken 3y ago
"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.
- trympet 3y ago
  > 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.
  - sneak 3y ago
    Restricting to user accounts is useless. Malware runs as your user. https://xkcd.com/1200/ https://xkcd.com/1200/
  - rkagerer 3y ago
    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.
  - coffeeling 3y ago
    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.
Aerroon 3y ago
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.
- johnny22 3y ago
  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.
  - Aerroon 3y ago
    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?
thereddaikon 3y ago
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?
- FuriouslyAdrift 3y ago
  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\
- JackeJR 3y ago
  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.
  - thereddaikon 3y ago
    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.
- Khaine 3y ago
  I just hope they kill teams with fire. It is hot garbage.
dingaling 3y ago
Makes /bin/, /usr/bin/ and /opt/ seem simple
spacephysics 3y ago
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
- zelon88 3y ago
  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?
jabroni_salad 3y ago
You forgot about "my documents", which is of course a great catch-all location for all four types of data you mentioned.
- rkagerer 3y ago
  I actively avoid that dumpster fire. None of my actual documents live in any portion of My Documents.
jtriangle 3y ago
>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.
- calamari4065 3y ago
  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.
  - axus 3y ago
    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...
  - 3y ago
callalex 3y ago
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.
rkagerer 3y ago
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.
dvngnt_ 3y ago
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

burnte 3y ago

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!

rkagerer 3y ago
Don't forget about Wow64 and redirection ;-).

EvanAnderson 3y ago

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.

SSLy 3y ago
And converse, on Linux it's so hard to get every shitty tool to put files in XDG dirs, not spew them all over ~.
- oneshtein 3y ago
  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.
  - SSLy 3y ago
    https://wiki.archlinux.org/title/XDG_Base_Directory#Hardcoded https://wiki.archlinux.org/title/XDG_Base_Directory#Hardcode... upstreams quite too often reject patches or let them languish
vladvasiliu 3y ago
> 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.

jasonjmcghee 3y ago

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

deleted 3y ago
[deleted]

dingnuts 3y ago

>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.

at_a_remove 3y ago

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%.

EvanAnderson 3y ago
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.
- at_a_remove 3y ago
  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.
  - EvanAnderson 3y ago
    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.

bhdlr 3y ago

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

EvanAnderson 3y ago
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...)
- Wowfunhappy 3y ago
  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).
  - dessimus 3y ago
    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.
    - 3y ago

hinkley 3y ago

> "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.

voidfunc 3y ago
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.
lysp 3y ago
It was confusing for me too. Basically: - AppData = User (interactive) application storage - ProgramData = Service / Background (non-interactive) application storage

hattmall 3y ago

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?

oefrha 3y ago
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.
JackeJR 3y ago
They belong to encrypted user credentials. https://support.microsoft.com/en-us/windows/accessing-credential-manager-1b5c916a-6a16-889f-8581-fc16e8165ac0#:~:text=Credential%20Manager%20lets%20you%20view,select%20Credential%20Manager%20Control%20panel https://support.microsoft.com/en-us/windows/accessing-creden....

cameronh90 3y ago

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.

pixl97 3y ago
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.
- lxgr 3y ago
  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.
- rkagerer 3y ago
  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)

newZWhoDis 3y ago

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.

thereddaikon 3y ago
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.
- whoisthemachine 3y ago
  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/ https://appimage.org/

devwastaken 3y ago

"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.

trympet 3y ago
> 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.
- sneak 3y ago
  Restricting to user accounts is useless. Malware runs as your user. https://xkcd.com/1200/ https://xkcd.com/1200/
- rkagerer 3y ago
  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.
- coffeeling 3y ago
  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.

Aerroon 3y ago

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.

johnny22 3y ago
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.
- Aerroon 3y ago
  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?

thereddaikon 3y ago

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?

FuriouslyAdrift 3y ago
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\
JackeJR 3y ago
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.
- thereddaikon 3y ago
  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.
Khaine 3y ago
I just hope they kill teams with fire. It is hot garbage.

dingaling 3y ago

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

spacephysics 3y ago

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

zelon88 3y ago
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?

jabroni_salad 3y ago

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

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

jtriangle 3y ago

>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.

calamari4065 3y ago
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.
- axus 3y ago
  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...
- 3y ago

callalex 3y ago

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.

rkagerer 3y ago

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.

dvngnt_ 3y ago

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