More granular controls for sharing playlists with other users

[rbjtech 4270]

3 minutes ago, TeamB said:

Nothing wrong with it, in fact if the Emby team was infinite I would be suggesting some of the craziest shit you have ever heard, but they are not. Because it might be overkill for a personal home media server when something as simple as a checkbox on the playlist share screen to limit admins users in the user list can solve for 90% of this edge case issue.

Yep - no disagreement here - that would certainly be a quick win.

[darkassassin07 423]

Security wise, I'd be happy with a 'hide admin users' checkbox; but I'd prefer granular control over who can see what users as a tool to cleanup clutter.

With a server of many users, particularly in groups that don't interact, there's no need to list everything when only a small subset of those options will ever be used. Less to scroll through.

[TeamB 2353]

5 minutes ago, darkassassin07 said:

With a server of many users, particularly in groups that don't interact, there's no need to list everything when only a small subset of those options will ever be used. Less to scroll through.

What I would like to see is user groups in general.

Create a Family group of users or a Kids group of users and assign that group, access or restrict that group's access etc

Once you have groups, you can then start to think how they could be used in all sorts of places in the server. But there is already an open request for that.

Edited February 5 by TeamB

[Clackdor 19]

59 minutes ago, darkassassin07 said:

Security wise, I'd be happy with a 'hide admin users' checkbox; but I'd prefer granular control over who can see what users as a tool to cleanup clutter.

With a server of many users, particularly in groups that don't interact, there's no need to list everything when only a small subset of those options will ever be used. Less to scroll through.

Having a tick box to hide admin accounts is definitely a step in the right direction. Additionally maybe another tick box to hide the default user for DLNA if that option is set. 

I still take the stance that a full implementation would be ideal from a usability and security standpoint, but I've already previously acknowledged that this may not be possible from a coding or time perspective. 

[ebr 14913]

16 hours ago, Clackdor said:

"I don't want my wife to know my mistress is on the server" That kind of wording is extremely dismissive despite numerous valid reasons that have already been provided as to why this would be useful in a variety of situations. 

I was just paraphrasing the scenario.  I'm not disagreeing that this would be useful. Just that it is more of a usability concern than it is a security one.

[rbjtech 4270]

1 hour ago, ebr said:

I was just paraphrasing the scenario.  I'm not disagreeing that this would be useful. Just that it is more of a usability concern than it is a security one.

It's a usability, a privacy and a security issue all rolled into one.   This is the only place in the entire emby system where all users get their existence exposed to other users.  There are so many examples where this is a breach of trust - a 'work' colleague seeing what nicknames you have for all your family, the fact you have family and their names is a breach of privacy.    I'm sure there are a lot more examples out there - so until the list is restricted somehow, I cannot fully use this feature.    As an Admin, I have a responsbility to ensure any personal data is kept personal unless it's explicitely categorised as Public. 

Edited February 6 by rbjtech

[Clackdor 19]

5 minutes ago, rbjtech said:

It's a usability, a privacy and a security issue all rolled into one.   This is the only place in the entire emby system where all users get their existence exposed to other users.  There are so many examples where this is a breach of trust - a 'work' colleague seeing what nicknames you have for all your family, the fact you have family and their names is a breach of privacy.    I'm sure there are a lot more examples out there - so until the list is restricted somehow, I cannot fully use this feature.    As an Admin, I have a responsbility to ensure any personal data is kept personal unless it's explicitely categorised as Public. 

Exactly this. 

I'll provide an easy example of how it could get abused. Imagine you as an admin are friends with 2 people who had a falling out and you share your server with both of them. Enabling this gives them each access to the other's unique username. So now one or both of them starts creating random playlists of content they know the other will find annoying and sharing them. Or better yet, let's say you're using ldap/ad for authentication with a lockout policy set for x# of failed attempts. One person decides it's funny to get the other's account locked out. I'd say it's pretty common to have people in friend, family, or coworker circles who simply don't like each other and would do things like this. 

There are too many reasons why having a full list exposed is a bad thing, and too many possible scenarios where having more control over who can see who in that list would prevent unwanted clutter, interaction, security/privacy concerns and general headaches for both the server admin and the userbase of their server. 

 

 

[unmovable 11]

As this issue will most likely share the same fate as other issues emby team ignores for years to come, if you're running emby behind nginx reverse proxy, just put this location directive, disabling user list completely:

    location ~* ^/emby/Users/ItemAccess {
        deny all;
        return 403;
    }

I would expect emby team to take these kind of matters more seriously, as this is a very serious security issue, but then again, I wouldn't expect that, so here's a workaround for you.

[unmovable 11]

Also, to make it more evident why this is not a feature request but a vulnerability report that has to be taken seriously and not put on a back-burner, there's an API endpoint which lists all users on the server:

GET /emby/Users/

This endpoint is restricted to admin users only, as it should be. The response for non-admin user:

User does not have admin access.

So Emby team should answer the following question:

Is it okay for non-admin user to see all users on the server? If yes, then I would consider Emby software as a whole as a security breach waiting to happen, because this speaks about Emby dev team's general competence.

If no, then why is /Users/ restricted and Users/ItemAccess is not, when they return the exact same piece of information?

[Luke 37071]

Remember that users are not granted access to this feature by default.

[unmovable 11]

42 minutes ago, Luke said:

Remember that users are not granted access to this feature by default.

That's accurate. However, it's also worth pointing out that the toggle for enabling or disabling this "feature" is buried within each individual user's profile, which means that server administrators will have no way of knowing unless they go through each user's settings for some reason. Additionally, the language used for the toggle is not appropriate given the potential risk it poses. It should clearly state, in large, red, bold letters, along with a CAUTION warning, the implications of enabling it.

Case in point, I had it enabled for some of my users without realizing it.

[TeamB 2353]

1 hour ago, Luke said:

Remember that users are not granted access to this feature by default.

another option for this might be manually adding names, this would be much less user friendly, but you would have to know the usernames of the people you wanted to add.

on the playlist enable screen have a checkbox 'enter users manually'

this would not display a list of users on the share playlist screen but an entry box you could manually enter a user name then add it. you could have it so a comma sep list also worked for users to set a list of users for access.

 

[Clackdor 19]

23 minutes ago, TeamB said:

another option for this might be manually adding names, this would be much less user friendly, but you would have to know the usernames of the people you wanted to add.

on the playlist enable screen have a checkbox 'enter users manually'

this would not display a list of users on the share playlist screen but an entry box you could manually enter a user name then add it. you could have it so a comma sep list also worked for users to set a list of users for access.

 

I'll say this could be a valid option, however it's still highly flawed in that it greatly impacts usability, and this approach puts the power in the end user's hands rather than giving the server admin the control of who can interact with who. It's still susceptible to guessing a username and having a correct guess confirmed. A lot of people use the same username/screen name practically everywhere. A username on emby could also just simply be a person's real name. 

[TeamB 2353]

3 minutes ago, Clackdor said:

however it's still highly flawed in that it greatly impacts usability,

Love the language people use

 

@Lukejust add groups, I know it would be a big change to the auth system, but it would be a good step forward.

[Luke 37071]

Yes groups could work well for this.

[Clackdor 19]

13 minutes ago, TeamB said:

Love the language people use

Grammar has never been a strong point of mine lol. Glad I could be of some amusement 

33 minutes ago, Luke said:

Yes groups could work well for this.

My suggestion would be to add another top level tab/page called "Sharing" when you edit a user's profile.

It would make sense to have the existing social media sharing option and the personal content/playlist option on this page. If the personal content option is enabled have an access control list of other users that user can share playlists with. Maybe provide a toggle to either allow or deny the selected users. This could also be handled with tags similar to parental controls. 

This might require less of a rework than fully implementing groups right now. I'm not sure what other function groups would serve in other areas of emby regarding authentication etc. Once groups are added they could be integrated into the sharing page. 

Just a few ideas. I know the team is small and resources are limited.