The Roon app (running on a tablet is all I’ve tried) can walk through every directory and see every file’s name under directories, that the connected Roon server can see. That ability to see includes both local drives and network shares; this is true for Roon server under Windows and, for network shares, Roon server under ROCK (I haven’t tried to see what Roon server under ROCK might reveal of local drives, because ROCK probably limits the local directory structure). The ability is the result of the app being able to tell Roon server to monitor directories. Further, the Roon app can create new directories of any name under monitored directories. Do I have to spell out the implications of being able to create a new directories of any name?
Second, thinking control over admission to the local network as any sort of protection is naïve. Think about people with children: Can they say, Sorry, kid, you cannot use the local network because you might be running bad software? Think about people who have child-sitters, housesitters: Sorry, you cannot use the local network. Think about people who have devices that, for full function, need local network access. Sleep Number, for example, has a product called SleepIQ, which monitors a person’s sleep on an enabled mattress (the pump of which has a MAC address!), analyzes the data and reports summary information. A person can elect not to use SleepIQ, but how many people would recognize an exposure in a mattress app? In short, we are long past the time when control over local network access is a practical protection.
I suggest that Roon server 1) ensure authentication by a Roon app and 2) employ encrypted communication. (Please don’t think that the details of RAAT will be forever out of reach. It’s just a matter of time and effort, and the ability to read directory structure is an incentive to use Roon in a suite of hacking tools.)