In my case, with Roon running on a dedicated Win10 x64 Pro system, under an Id with Administrator membership, I can use the Roon app on a different system to see the C:\ directory (Settings/Storage/Add Folder/Folder Browse), and that’s true even though the music directories are on a different drive letter.
(Maybe it’d work to run Roon under a non-administrator Id so as to prevent access to C:\ or at least to C:\Windows, but once again, that kind of knowledge ought not to be necessary to have a safe Roon installation.)
WAN (wide area network) is (in many cases) the internet and LAN (local area network) is your intranet. What you would want is grant access to the WAN and not LAN. This approach usually creates different WLANs for different uses, one with LAN access and one without.
But yes, security requires expertise. Just using a computer requires expertise. Demands that clueless people should be allowed to set up computer based systems “securely” leads to very limited sort of computer systems. I guess iOS has done it the best. Not everyone wants that.
But if you are prone to creating unsecure computer systems, it doesn’t help that every single app requires a separate password. It might give you a (false) sense security, but if you don’t have a clue what you are doing it will not be secure. I don’t feel that cluelessness about security is a good place to start making specific security related demands either. But then again, that’s just me.
We are not only speaking about security here, its not controlling Roon a matter of security alone, here we are speaking about that somebody can be bothered by the fact that somebody in the same wlan can control Roon in a so very easy way.
And Roon is not an app like another, it’s a audio media server.
My issue in regard to “controlling Roon” is that Roon (the server part, not the app) can look at (and write new directory names to) any locally attached or network attached disks. My issue is 1) lack of authentication and 2) lack of encryption in RAAT. Here I am assuming that RAAT is what is used to convey directives from the app (or something acting like a Roon app) to the server.
I do understand that you want to let just about anyone to access your local networks and don’t care for configuring a secure environment for you and your family to operate in. You understand that your unsafe practises allow people to play music, spy at your music library layout and create directories with deviant names (and much more, but that does not seem to be a problem because it’s unrelated to Roon). For some reason you seem to feel that it’s Roon’s fault and that it’s their responsibility to fix it.
You also know there is a protocol called RAAT. You are not quite sure what it does, but you want it encrypted.
Where as my point has been that because atm Roon is not accessible remotely, you could simply 1) create a secure local network 2) allow access only for people that you trust to play music and create directories with nice names 3) give the untrusted people access only to the internet, if even that. Sure, they might do something actually illegal that can be traced back to your internet account, but luckily that doesn’t seem to be as much of an issue as directories with deviant names.
But you can’t accept that, because it would require you to do something, maybe even understand something and it’s way less fun than throwing around demands about random things you might or might not have a clear understanding about. And thus it starts all over again.
I see I was unclear. My concern with RAAT and encryption is based on my assumption that RAAT is used to convey commands from the Roon app to the Roon Server (“server” is what is doing the scanning/reporting of local/attached devices and is doing the directory creation with possibly “bad” names). Going through the Roon knowledge base, I cannot find a statement that it is RAAT that conveys commands (eg, scan a local/networked drive) and their responses (eg, list of discovered directories and files under said directories). If it is not RAAT that conveys commands and responses, I don’t need encryption. Where I do need encryption is in the transport layer that conveys commands and responses.
I don’t actually trust people who use my local network. And “people” includes myself: Despite my efforts, I’ve run malign software a few times in my life (to my knowledge). My practice for security is to rely on things like Windows Defender to protect my Windows systems, and to check the reputation of new software (especially no-charge software that I download). I sometimes run new software on a virtual machine to minimize the chance of something bad happening.
I do not want Roon to add exposures that could be exploited through me or others on my local network, where the exploitation is unknown to me because the exploiter was picked up without my/others’ knowledge. I can be as vigilant and careful and well-informed as possible, but I don’t think I can catch everything. So there is no need to be adding exposures.
Forget for a moment about security… we just are bothered that everyone including trusted users could see our Roon server when they want, just installing an app.
My worry is that Roon could be exploited by a kit, where the exposures are just part of a bag of tools to sniff around and maybe exploit. A trusted user could unknowingly harbor malicious software that uses the bag of tools. It is this possibility that makes me not put much faith in, say, a guest network to prevent local access: Even users trusted with local access are a reason for worry.