Many people use laptops, and those laptops tend to appear on public wifi hotspots (coffee shops, etc). Based on Roon remote security and recent experience, connections from Remotes to Cores are totally unauthenticated, and no confirmation/approval is required on the Core, and users can’t change either of those settings.
I agree with some of the comments on the above community post that Roon’s choices here are at best irresponsible, and at worst they’re just waiting to become a bad press event when someone releases an exploit based on the Remote protocol that plays loud NSFW audio through every enabled Output (while the Roon user is at a coffee shop, no less). While that wouldn’t be disastrous, it seems unnecessarily embarrassing for users and Roon.
The most basic alternative is a simple one-time popup on the Core to approve or reject a new Remote, and this would nearly totally solve the problem with almost no impact to the user experience. Users who are on totally trusted networks could disable that. Another approach would be per-SSID or per-gateway-MAC trust settings, so users could trust any Remotes that connect while the Core is connected to their home SSID.
I think that’s an incredibly high return on the implementation effort. However, this feature request/bug report is for an even simpler change: warn users that their Cores are insecure. I almost guarantee that right now, a Roon user is sitting in a coffee shop, on public wifi, with Roon Core running on their laptop. There’s no reason for this.
The Architecture and Knowledge Base should both be updated to cover authentication or the current lack thereof, and to explain Roon’s thinking on the matter. Right now, searching Roon’s docs for “password” and “authentication” will turn up nothing authoritative. One needs to dig pretty deep on the community site to find the post above.
The feature request: If you’re going to intentionally omit authentication on devices that at least some users will use on public networks, it seems like the absolute minimum is to make users aware of that fact in the docs and setup.
Finally, if this request mischaracterizes Roon’s current Remote-to-Core authentication, please say so. My summary is based on what’s in the docs (almost nothing), firsthand experience (no shared credentials or tokens), and the other community thread.