Ability to control who/what can use Remote

You offer a feature I have no use for called “Private Zone”. What I’d like is the ability to control -who- can use Roon Remote.

If we look at “Displays”, you give us the ability to display what’s playing on a multitude of devices - and they require us to enable each device before Display will work (which I find rather odd).

During the Holidays, I had a friend that realized he could download the Remote app to his mobile, and change the music to disco. After the third time, it wasn’t funny anymore.

Security is a big part of what I do on a daily basis; I find the lack of Remote Administration of Roon Remote surprising. By default, any device is granted access. But if (we) can enable this feature, then we would have the granular ability to select who/what can control Core.

1 Like

If security is of concern for you, how about providing a guest net for guest access? There is no need to let others sniff and mock around in your private network.


But we have to consider the average user, who has no idea what “guest network” is, much less how to configure one.

My emphasis on security wasn’t necessarily a personal concern as much as a comparison to “Display”, which does have security.

Thanks very much for the reply.

There have been a number of similar requests so you are not alone.

1 Like

If the average user doesn’t know what a guest network is or how it could be setup then he’s not interested in security. He would also ignore the setup of a hypothetical Roon built-in security feature for the sake of convenience/ease of use. No user I know of, no matter if average, below or above, is fond of entering passwords in each and any software he wants to use.

So you (we? Surely not me.) need a way to authenticate a/the user (usually by entering a password) in Roon for every Remote session and a auto-logout feature of some sort (or your “friend” is able to snitch one of your authorized remotes lying around in the house to change tunes).

If you take a step back, out of the world of Roon, you will see that (mostly) all of your networked AV consumer electronics comes with UPnP/DLNA support where the situation is the same. There’s is absolutely no security feature integrated. Your “friend” doesn’t even have to download a software prior to abuse your audio system because every nowadays mobile/desktop I know of comes with the needed software pre-installed.

You can already have security by applying/enabling security measures that already exist.

  • Use a strong password to protect your WiFi
  • Don’t let strangers/guests access your private network
  • Setup proper user authentication on your devices
  • Never leave your devices unlocked
  • Use the secure auto-logout/lock feature of your devices for the case you should forget to lock a device

I agree that Roon can make better use of the built-in user profiles, but access security is better handled on another level than in Roon itself. The most I can see here is a security PIN/password for some critical operations in Roon.

Or maybe initialising the client with the same ID as the roon service account.

BlackJack I appreciate your efforts, but I think you’re misunderstanding my point. I have no intention of suggesting passwords and logins. Again, if you refer to me comment about enabling “Displays”, you’ll see that it’s as simple as toggling a slider. In order to visualize this, I’ve made a crude and simple graphic to demonstrate the solution. Please excuse my Photoshop efforts; it’s late and I’m tired… but I did like the name I gave this feature. :slight_smile:

If (we) want to enable this feature, click the slider “Remote Control”. By default, all connected devices will be enabled (we don’t want to take the opposite approach). If we want to disable someone’s ability to change the music (control Core), simply click the slider for that person’s device. In my example, I’m showing myself and my daughters with me disabled.

remote_control_off remote_control_on

I’m sorry that I previously referred to your comment where you even emphasized that you want to control who has access.

So you want to allow your “friend” to change the music at least once and then, when you get aware of it, you go and disable his device. Understood. I hope for you, he hasn’t disabled your access to Roon beforehand, “just for fun” of course.

The IP addresses, I understand (we’ll get to those in a minute). But where do the names of these devices come from, and how the hell does Roon have access to them?

As to the IP addresses, most home networks assign them dynamically, with DHCP. As a consequence, if “you” disable access from and then, at some later point, your device get assigned that address, then you will be locked out.

Moreover, next time “Neil” visits, his device will get assigned a different IP address, so your previous block will have no effect.

Fundamentally, the problem you are trying to solve has a solution: users and authentication. If you’re not willing to go down that road, you’re not going to solve it.

As every Roon Remote is also able to act as a Bridge/Endpoint you should already be able to see those names in Settings|Audio.

It does seem to me that a single logon to your roon account on the remote app when you first install it would be a sensible feature. Every other app on my phone needs an initial registration, and roon remote should be no different.

Would stop random Guests just downloading the app and doing what they like.

I also have long liked the idea of a guest account. Perhaps one that doesn’t require login but has absolutely zero permission to make any library changes.

Sonos have long since had security on their remote app. If you want to make any configuration changes they force a login to an authenticated account. But basic music choice is open to guests.

To be honest I’m surprised roon doesn’t do this already, it’s a simple enough request.

1 Like

But this is exactly what this feature request does want to prohibit. At least for some guests.

I’d be happy for guests to do whatever they wanted with music but wouldn’t want them
Able to touch library in any way at all

No apology necessary.

BlackJack, you need to think this feature through. The simplicity escapes you for some reason. Yes, I realize that this person (“friend”, as you refer to them) may maliciously disable my access. My suggestion/graphic wasn’t a complete solution; I was trying to make a point so you could follow. There are many ways to implement this from Core as (possibly) an Admin permission, something Roon has yet to implement, intentionally I would guess. Most likely, in part to DHCP, but that can be overcome. Of course, in the situation where someone has disabled my access, I have access to Core and can easily remedy the situation. But defining an Admin that is the only one that can have access to certain features would solve this (that would most likely be the person that configured Core).

Perhaps it isn’t a “friend”… perhaps it’s a a child that has lost music privileges or a neighbor that picked up your unsecured WiFi. The circumstance is irrelevant - look at how many features Roon offers that we rarely or never use. If BlackJack has no use for this feature, move on and ignore it. But your efforts to manage this request in a forum where ideas are encouraged are unnecessary.

You must understand: Roon can’t be a hobbyist, weekend programmer or sys admin’s toy. Roon has to market to the masses who demand plug-n-play. This will require features you have no use for, and that’s fine.

1 Like

Simple things are usually insecure, secure things no longer simple.

I understand that very well. This is why Roon, UPnP/DLNA and other PnP products for the masses are like they are. No need to setup user accounts/defining roles first, just plug and play. They are not intended for use outside of private networks. Other products, like for example Plex, that are intended for use beyond the limits of a private network come with security features built-in.
The standards that make up networks and define how they operate and what features they provide tell us since decades now, that devices which are in the same network are trusted and that one has to take measures to keep untrusted devices outside of ones trusted network. Therefore Routers, Firewalls and techniques like network segmentation to name a few exist. If you want security but your skill level or interest in the matter doesn’t allow you to set this up yourself, you can hire professionals to do the job for you. But you must understand that there is no security for cheap/free.

That’s why I’ve taken the necessary measures for my home where I run different networks for different needs/trust levels. There’s no untrusted child, other untrusted family member or untrusted “friend” that has access to Roon and surely (c’mon really?) no unsecured WiFi here.

Here you’re trying to solve a problem that you self-inflicted with your not thought through feature request. But anyway, I already agreed that there is a need to protect some critical operations in Roon.
While you might have access to your Core, please keep in mind that many users run their Roon Core headless.

Hmm. That’s not what I see.

  • When I look at Settings→About, I only see one remote – the one that I am using to access the Roon Settings from.

  • When I look at Settings→Audio, I see

    • the ALSA interfaces on my Roon Core machine
    • the ALSA interfaces on all of my Roon Bridge machines
    • the Shairport-Sync services active on my LAN

    I don’t see any Remotes in that dialogue.

I must be missing something …

As the current Remote always shows up as This PC/iPhone/… you need at least two currently active remotes to see something like this:


Hmmm. I can get my phone to show up (as long as it’s awake, and Roon is the foreground App), but not my Mac.

Possibly, that’s a firewall issue. But, perhaps by definition, if I’m running a firewall on my Mac, I’m not in the target audience for this feature request.

Roon is no different from how Google Chromecast works. Any guest on your WiFi can cast to any Chromecast device on the same network. Having said that, I’m not opposed to Roon adding controls, as long as they don’t complicate the user experience.

Requiring Displays (and Output Zones) to be enabled is not a security feature I think, but rather a means to avoid cluttering selection choices. For example, my Mac has 3 output zones “System Output”, “MacBook Pro built-in” and “DisplayPort”, which I never want to use. Same thing for “Private Zone”.