Emby Web - Temporary Share Link

[tekfranz 6]

I was just trying to share a song with an internal Emby user and the link contains no identifier for the track. Just a link directly to the emby server. Am I missing something?

Edited November 28, 2019 by tekfranz

[Luke 36991]

That's correct. We're trying to avoid being known for file sharing.

[tekfranz 6]

That's correct. We're trying to avoid being known for file sharing.

Oh now I understand the discussion here.

 

I wonder if the link could verify the user was already authenticated on the server with an account. That would take the joy out of blasting a link across the internet to have to send a password along. Or perhaps the links could expire in 24 hours. Or the Admin and User have to be paired to each other on the same server to send links between them.

 

Another idea would be an internal messaging system where you could send suggestions and messages to other users.

[lepiaf 0]

Sorry for resurrecting this thread, but had to clear up some things. I suppose some of these were already discussed, but as I relatively recently started using Emby more (than Plex)..

 

If the app stores are the issue - then don't implement sharing from mobile apps as such. However, that doesn't limit you to enable sharing from server itself (web), right?

Synology NAS Video station app does exactly that, with possibility of setting link duration validity and so on. Its reach may be not as big as Kodi, Emby or Plex (or is it?), and I don't see Amazon not selling their products because of that. For what I recall Kodi came under scrutiny when torrent streaming plugins matured, and people started selling boxes with Kodi + plugins preinstalled and market to them larger audience with "watch anything you want for free", not because it has any kind of "share this item" feature (afaik it never had).

 

I'm failing to see how not implementing this kind of sharing actually prevents sharing of copyrighted content, as others posters mentioned, what is stopping to create public library and shared them to some users, etc.

Sharing would also be covered with eula "share only content you own/have right to share", and there can also be server-imposed hard limit on longevity of such shared link, for example it cannot last more than x days, which was already mentioned, avail only to premium users which further reduces public exposure and so on...

I supposed I know how you feel/think, that even mentioning this as feature can make some dumb big fish up in the chain says "a-ha! burn them, they're enabling sharing!", but I'm not sure if this fear is real or you're just overly cautious and exaggerating misuse power of this feature. Or invent some new name for it, so that mentioned fish won't be triggered by common term .

 

Tried to not sound like rant, but I guess it does a bit

 

keep up with good work, even if you still decide not implement this

 

cheers

[ebr 14897]

If the app stores are the issue - then don't implement sharing from mobile apps as such. However, that doesn't limit you to enable sharing from server itself (web), right?

 

ebr, on 17 Feb 2019 - 09:29 AM, said:

 It isn't just the app stores either.  Every single business relationship we have (e.g. payment processors) ask the specific question of "do you allow file sharing" and, in today's security-strict environment, they basically shoot first and ask questions later.

[lepiaf 0]

 

ebr, on 17 Feb 2019 - 09:29 AM, said:

 It isn't just the app stores either.  Every single business relationship we have (e.g. payment processors) ask the specific question of "do you allow file sharing" and, in today's security-strict environment, they basically shoot first and ask questions later.

 

Hi ebr, thanks for pointing that out.

 

Answering yes to that/explaining what kind of content sharing is allowed immediately leads to account suspension? Is discussing/explaining terms with payment processors before implementation viable option? Do all payment providers share stance for such hard action against even whisper of similar feature?

If they're so trigger happy - what arguments stands right now for defending Emby if someone malicious send report to PP (Payment Processor, not that other Pay ) that "this software offers means to share copyrighted content to other parties"? Not en masse, but it certainly does. I could share something from any OS on local network to be available to public that way....

I know that most likely only handful of Emby users will use and benefit from such feature, and time spent investigating legality of this will surpass more interesting actual developer time, but it will certainly be very nice to have something like that.

Somehow I have a feeling (correct me if I'm wrong) that no one really asked/tried implementing this just because of previous kodi situation that gave media players/servers of this kind bad reputation.  

 

cheers

Edited April 29, 2020 by lepiaf

[ebr 14897]

The short answer is yes - it is that draconian.  They shoot first and sometimes don't even ask questions (we have direct experience with this).  We work hard every day to try to make sure our product is not improperly perceived by the stores, our relationships and the market in general and it is a daily battle.

 

The short answer is just that whatever benefit this would provide is not worth the risk to the entire Emby ecosystem's existence.

[tomnjerry74 93]

On 2/17/2019 at 8:29 AM, ebr said:

 

Every single business relationship we have (e.g. payment processors) ask the specific question of "do you allow file sharing" and, in today's security-strict environment, they basically shoot first and ask questions later.

But you do allow file sharing. Am I missing something, or is that not one of the core features of the software? The sole fact that "users" even exist in the first place implies that multiple people will access content. Ignoring that, there are even download buttons for any file hosted on the server. Are you falsely answering the "do you allow file sharing" question to begin with?

Even if you were to argue that having users differs from public sharing because there is a sign-in process (which actually doesn't make a difference in terms of the 'do you allow sharing' question, which is incredibly unspecific), why not just add a simple feature like a four digit pin-code that a user has to enter before being able to access media through the "shared" link?

Regardless - and more importantly - I'm not getting the connection here as to how a feature defines how others are able to interpret the content on users' HDDs. Users' content is independent of the Emby software that it's accessed through. Emby is advertised as being "designed to help you manage your personal media library, such as home videos and photos." You're setting the precedence right there that you've designed the software to be for personal media. You already have no control over what a user hosts. Using your software, I can already (hypothetically) host as much copyrighted content I want, house it behind a user without a password, publicly open it through wan, and blast the info wherever I want.

When you talk about your fear of how other's will interpret the intended use of your product, why is the situation I highlighted above not assumed already, but if you were to add a link-sharing option the ideology would suddenly shift? Shouldn't it be assumed that, under your own claims of being "designed to manage personal media, such as home videos and photos", the content being link-shared is the user's personal content such as home photos and not inherently copyrighted material based on no valid argument? How does a feature define what the content is? They're completely independent. The content will exist regardless of the features available.

Moreover, I don't see how the rebuttal of "well this feature makes it easier to share copyrighted content" is valid. As I've already highlighted above, users are already able to host copyrighted content through Emby and users are already able to share their copyrighted content publicly. Is it "less illegal" because it's slightly more difficult? "Ease" is irrelevant in this case; link-sharing isn't so incredibly different than what is already available. There is no reason for the feature of "link-sharing" to be associated with illegally distributing copyrighted content any more than the entire Emby software itself already is.

Now obviously I'm not an Emby developer, nor lawyer, or anything in between. But, I can't help but question - given all the information accessible to me in this thread - how any of these arguments are valid?

P.S. Emby for life!

[ebr 14897]

19 hours ago, tomnjerry74 said:

But you do allow file sharing. Am I missing something

Not by the definition used by the important parties here.  The distinction is the ability to automatically share content between different users (which, in our case is different servers) of the system.  Allowing to publicly share content on sites such as facebook etc. will meet that definition while our system, out of the box and without you specifically setting someone up as as user on  your server, does not.

[tomnjerry74 93]

57 minutes ago, ebr said:

(which, in our case is different servers) of the system.

I can't figure out what this means.

59 minutes ago, ebr said:

Allowing to publicly share content on sites such as facebook etc. will meet that definition while our system, out of the box and without you specifically setting someone up as as user on  your server, does not.

I see what you mean. (And could argue all day about it, but I know you aren't the one making/enforcing the rules )

Nevertheless, knowing your firm stance on public link-sharing as a feature, is the pin-code option I described earlier not viable? Even ignoring that, what is the reasoning for private link-sharing being given the same treatment? Why can't users go to a specific piece of media, copy the link, and send it to another user who would be forced to log-in to view it?

In regards to the whole sharing/linking-sphere, I'm just noticing too many inconsistencies. For instance, this thread explains that users are able to create public links to photos through the social media share button. I have not tested this myself, but supposedly anyone with the link can view the photo, regardless of a "guest" account status; they don't need to sign in.

There is just simply no way to argue that this isn't "file sharing". How is the Emby team comfortable with this? Why are potentially copyrighted images treated with such a rule-bending feature but other content such as video files have strictly enforced boundaries? Does "file-sharing" only apply to specific file-types?

I can already see the argument of "that feature is only allowed for home photo libraries" incoming. But, under Emby's own marketing and "mission statement", the entire software is designed for home, personal content to begin with. Therefore the type of library should be irrelevant, as all content is expected to meet the "home, personal" criteria.

[ebr 14897]

Yes, there is a huge difference between sharing your photos from your phone and sharing videos on public sites.  There are not agencies like the MPA searching for your photos being copied on public sites.

And the technicalities of one thing vs another are largely irrelevant here because the people making these decisions: 1) don't really understand what we are in the first place but the closest thing they have seen that looks like us are pirate free movie systems so we have to look as different from that as possible and 2) they hold all the cards and don't even need a reason to not allow us to be in their stores.  If they don't like us or feel, even in the slightest, that we might be doing something shady, they can simply kick us out.  They don't have to prove anything.  Their stores are private platforms and they are allowed to decide who is in them and who isn't.

[tomnjerry74 93]

1 hour ago, ebr said:

Yes, there is a huge difference between sharing your photos from your phone and sharing videos on public sites.  There are not agencies like the MPA searching for your photos being copied on public sites.

It's unreasonable that you're allowed to assume "from your phone" in this scenario and not give that same description for the videos. Like I've mentioned before, Emby is advertised as being for personal/home media from the get-go. Wouldn't a more accurate/appropriate comparison be between "photos from your phone" and "videos from your phone"? Then I would think it's easy to see how the differentiation of features doesn't add up.

The images in a user's library could very well be copyright protected and do not have to come from their phone. And there are surefire ways to be targeted by both large organizations and independent photographers for photo DMCAs. Here's an example - that escalated to the Supreme Court - where someone's own photographer filed a law-suit against them for posting a photo of themselves.

Better yet, what if I were to download images from a site like Shutterstock, host them all on my server, and distribute them for free download?

Though I understand what you're saying, I'm trying to highlight how these instances (sharing photo vs. video) aren't automatically as different as you're making them out to be.

1 hour ago, ebr said:

And the technicalities of one thing vs another are largely irrelevant here because the people making these decisions: 1) don't really understand what we are in the first place but the closest thing they have seen that looks like us are pirate free movie systems so we have to look as different from that as possible and 2) they hold all the cards and don't even need a reason to not allow us to be in their stores.  If they don't like us or feel, even in the slightest, that we might be doing something shady, they can simply kick us out.  They don't have to prove anything.  Their stores are private platforms and they are allowed to decide who is in them and who isn't.

I completely understand where you're coming from here. I think it sucks that that's the way it is, and while I know I'm clearly arguing with the wrong people about most of this stuff, I still think it would be nice to have some form of easy-to-use sharing features for Emby. Even if it's literally just the ability for a user to send a link to someone who is then presented with an authentication screen before being able to view the content.

Also, thank you for taking the time to respond to users' concerns, I really appreciate it. The more dialogue that occurs between the developers and the consumers, the more open-ended issues get cleared up for everyone.

[oneduality 8]

14 minutes ago, tomnjerry74 said:

It's unreasonable that you're allowed to assume "from your phone" in this scenario and not give that same description for the videos. Like I've mentioned before, Emby is advertised as being for personal/home media from the get-go. Wouldn't a more accurate/appropriate comparison be between "photos from your phone" and "videos from your phone"? Then I would think it's easy to see how the differentiation of features doesn't add up.

The images in a user's library could very well be copyright protected and do not have to come from their phone. And there are surefire ways to be targeted by both large organizations and independent photographers for photo DMCAs. Here's an example - that escalated to the Supreme Court - where someone's own photographer filed a law-suit against them for posting a photo of themselves.

Better yet, what if I were to download images from a site like Shutterstock, host them all on my server, and distribute them for free download?

Though I understand what you're saying, I'm trying to highlight how these instances (sharing photo vs. video) aren't automatically as different as you're making them out to be.

I completely understand where you're coming from here. I think it sucks that that's the way it is, and while I know I'm clearly arguing with the wrong people about most of this stuff, I still think it would be nice to have some form of easy-to-use sharing features for Emby. Even if it's literally just the ability for a user to send a link to someone who is then presented with an authentication screen before being able to view the content.

Also, thank you for taking the time to respond to users' concerns, I really appreciate it. The more dialogue that occurs between the developers and the consumers, the more open-ended issues get cleared up for everyone.

I believe he eluded to the problem he faces pretty clearly though.. when you're dealing with the MPAA and the RIAA, they are the monsters of the industries and come down on you like a sledgehammer.. they have shutdown projects like this before for facilitating piracy.

Photos can be copywritten but they don't have the brute force power that MPAA/RIAA have..  Emby is simply covering their a$$ here, and I don't blame them one bit in this scenario .. and I'm one of their biggest critics in other areas, but this one I understand because I've seen what can happen when you don't bow to those titans.

[tomnjerry74 93]

9 minutes ago, oneduality said:

I believe he eluded to the problem he faces pretty clearly though.. when you're dealing with the MPAA and the RIAA, they are the monsters of the industries and come down on you like a sledgehammer.. they have shutdown projects like this before for facilitating piracy.

Photos can be copywritten but they don't have the brute force power that MPAA/RIAA have..  Emby is simply covering their a$$ here, and I don't blame them one bit in this scenario .. and I'm one of their biggest critics in other areas, but this one I understand because I've seen what can happen when you don't bow to those titans.

Right... which is why I already stated that I completely understand where he's coming from, recognized that he was the wrong person to argue with, and ultimately requested a solution that shouldn't be problematic based off of these conditions..

[kingy444 108]

@ebr as the original requester I wanted to clarify (and maybe hopefully get this through after all this time) as it is becoming clearer that most of the focus on this is around copyright and the requirement to create a user account to utilise emby

i didn’t want to request the ability to share to Facebook etc, I was hoping to be able to share home video items (library or directly) on occasions such as kids Christmas concerts (recent example)

I don’t want these to be available on Facebook etc and would be happy for them to be locked to say a pin code (this would be good actually as people couldn’t just have the link)

purely because I don’t have an emby account for each family member and they don’t like the complex passwords I enforce when allowing external authentication

could we make special links that require a pin only and were only valid for x amount of time ?

edit: perhaps lock the functionality to library of media type ‘home media’ ?

Edited December 14, 2020 by kingy444

[oneduality 8]

19 hours ago, kingy444 said:

@ebr as the original requester I wanted to clarify (and maybe hopefully get this through after all this time) as it is becoming clearer that most of the focus on this is around copyright and the requirement to create a user account to utilise emby

i didn’t want to request the ability to share to Facebook etc, I was hoping to be able to share home video items (library or directly) on occasions such as kids Christmas concerts (recent example)

I don’t want these to be available on Facebook etc and would be happy for them to be locked to say a pin code (this would be good actually as people couldn’t just have the link)

purely because I don’t have an emby account for each family member and they don’t like the complex passwords I enforce when allowing external authentication

could we make special links that require a pin only and were only valid for x amount of time ?

edit: perhaps lock the functionality to library of media type ‘home media’ ?

The pin code is a good idea though that opens up an issue I have with Emby and that is lack of security features... brute force blocking for example.. Your link leaks out, people WILL be trying to break it, that is almost guaranteed.. and if they have unfettered attempts, they can just let brute force scripts run 24/7 .. I still see it constantly on my server and it's consuming tons of bandwidth even when the server itself is idle.. 

MPAA / RIAA will not be happy with this regardless of what you label the media type as.. nothing will stop me from sharing movies and labeling it home media, sharing a link and the link leaking to a broader audience.

I know it sucks for legitimate law abiding users ..  but these organizations also don't like you sharing their content in any form.. if it's on blue ray it's encrypted, if you bought a stream, they don't expect you to be able to download the stream.. there's no accepted method in their mind that should allow you to have it available and they won't risk something like Emby being a way to facilitate it.. all it would take is an instance or two of someone abusing it and it could endanger this project.

I hate it as well .. I wanted it as a way of sharing MY OWN music that I wrote.. I wanted to share it and videos I made on social media but I couldn't.. but I do get the bigger picture.

[tomnjerry74 93]

58 minutes ago, oneduality said:

The pin code is a good idea though that opens up an issue I have with Emby and that is lack of security features... brute force blocking for example.. Your link leaks out, people WILL be trying to break it, that is almost guaranteed.. and if they have unfettered attempts, they can just let brute force scripts run 24/7 .. I still see it constantly on my server and it's consuming tons of bandwidth even when the server itself is idle.. 

MPAA / RIAA will not be happy with this regardless of what you label the media type as.. nothing will stop me from sharing movies and labeling it home media, sharing a link and the link leaking to a broader audience.

I know it sucks for legitimate law abiding users ..  but these organizations also don't like you sharing their content in any form.. if it's on blue ray it's encrypted, if you bought a stream, they don't expect you to be able to download the stream.. there's no accepted method in their mind that should allow you to have it available and they won't risk something like Emby being a way to facilitate it.. all it would take is an instance or two of someone abusing it and it could endanger this project.

I hate it as well .. I wanted it as a way of sharing MY OWN music that I wrote.. I wanted to share it and videos I made on social media but I couldn't.. but I do get the bigger picture.

I don't want to go too off-topic, but genuine question (I'm not really experienced in cyber security): What is the point of bruteforcing into an emby server? People are really taking the time to run brute force scripts? What's their end goal? That sucks you have to deal with that

And yeah I understand the concerns with these organizations and their seemingly godlike powers. Even if they're (Emby team) still uncomfortable with the pin method. Why not even take baby steps and at least let us share links with other users. Meaning, I can copy a direct link to a specific piece of content and send it to someone. Then, they would be presented with the standard auth screen that already exists. After a successful login, they would be redirected to the content.

At that point, it's the same level of security that Emby already has. And in terms of the link generation, it's not like Emby links currently use a format that exposes the content (e.g. https://myserver.com/movies/boss-baby-1080). Just keep the "item?id=" format.

I realize it may be drifting away from the original feature request, but wouldn't that be a small, easily doable, no-extra-risks step?

[oneduality 8]

5 minutes ago, tomnjerry74 said:

I don't want to go too off-topic, but genuine question (I'm not really experienced in cyber security): What is the point of bruteforcing into an emby server? People are really taking the time to run brute force scripts? What's their end goal? That sucks you have to deal with that

People use botnets to try to brute force in for many reasons.. 

1. They may not realize it's a media server and just want to see what is being protected with a password
2. They realize it's a media server and may have tons of pirated content they can leech
3. They realize it's a media server an may have.... persona... videos .. self explanatory

If they rent a botnet it's cheap to them, not legal but cheap.. if they find a weak password, they can leach all of your content even if Emby doesn't have the download option on ( capturing streams is trivial ) .. it will consume your bandwidth and hammer your server.. 

I mitigated the risk of anyone getting in by randomizing login names and passwords and hiding them from the login page, which oddly Emby does not do by default, or didn't used to .. 

Emby could solve this easily by having a login attempt counter and if too many failed logins happen, the ip is blocked for a specified time.. they could also mitigate this by integrating RBL or some other service like stop forum spam.. all are easy to implement.. 

I don't think you're ever going to get the feature you want as long as links can be shared.. What is the point of sharing it with a pin when you could just create a login for someone and only give them access to items with a specific tag? the feature request makes no sense when you start adding authentication to is since those mechanisms already exist.

1. Tag a media item with something like 'joecanwatch'
2. Create a user/password for 'joe' and select options to hide his login from the main screen.. just for at least a wee bit more security
3. Specify that joe can view items only with a specific tag  ( this is under user settings on the parental control tab )

There you have it.. now they just log in and they can see only what you let them see .. you achieve a very similar goal without angering the gods

[tomnjerry74 93]

11 minutes ago, oneduality said:

People use botnets to try to brute force in for many reasons.. 

1. They may not realize it's a media server and just want to see what is being protected with a password
2. They realize it's a media server and may have tons of pirated content they can leech
3. They realize it's a media server an may have.... persona... videos .. self explanatory

If they rent a botnet it's cheap to them, not legal but cheap.. if they find a weak password, they can leach all of your content even if Emby doesn't have the download option on ( capturing streams is trivial ) .. it will consume your bandwidth and hammer your server.. 

I mitigated the risk of anyone getting in by randomizing login names and passwords and hiding them from the login page, which oddly Emby does not do by default, or didn't used to .. 

Emby could solve this easily by having a login attempt counter and if too many failed logins happen, the ip is blocked for a specified time.. they could also mitigate this by integrating RBL or some other service like stop forum spam.. all are easy to implement.. 

I don't think you're ever going to get the feature you want as long as links can be shared.. What is the point of sharing it with a pin when you could just create a login for someone and only give them access to items with a specific tag? the feature request makes no sense when you start adding authentication to is since those mechanisms already exist.

1. Tag a media item with something like 'joecanwatch'
2. Create a user/password for 'joe' and select options to hide his login from the main screen.. just for at least a wee bit more security
3. Specify that joe can view items only with a specific tag  ( this is under user settings on the parental control tab )

There you have it.. now they just log in and they can see only what you let them see .. you achieve a very similar goal without angering the gods

Ah, that makes sense. Thanks for the info.

And what I mean at this point is just having hard links to content that can be sent. I'm not talking about distributing access of certain content through sending links as opposed to the permissions settings.

Say I have a video I took of a cat. I'm saying it would be nice to be able to just copy and paste the link in my browser to the cat vid and email/text it to another user of the server (e.g. "check this cat vid out: https://link"). If they're already logged in, it brings them right to the video, if not, they have to auth first. I'm already making the assumption it's something they have access to.

As far as I'm aware, Emby doesn't even allow this. I guess it's not an uber-significant feature at that point, but it's a nice touch.

Edited December 15, 2020 by tomnjerry74

[visproduction 122]

1) Create custom media access, completely outside of Emby, is a solution for some developers.  It's easier than you might imagine.  This would bypasses Emby completely and solves all the liabilities.  
   a) Apache server set username / password access to folders / subfolders. Create any download or playback web page you like. Users are prompted to login to access, even if the link goes directly to a subfolder or file.  I have a complete site demo, with a player that works cross browser, if anyone is interested. Send me a message.
   b) Do something similar with Windows server.  It should be possible.  I have not done this or looked into it.

Option 1:  Nothing goes near Emby. There is no plug-in.  You do need to have web-dev experience or get help.  It's not that difficult.  Playback inside the webpage works fine. Downloads are possible.


2) Temp library with limited access:
  a) Create a new library, or libraries.
  b) Copy selected media to the new library.
  c) Create a new temporary user with a secure password.
  d) Limit new user to only access the new library.
  e) Promote this media collection and distribute user name and password safely (perhaps not with email or text).
  f) Delete user and library when media playback time is done.

With option 2, there are steps.  But look closely.  It gets easier the more media you put in the library, compared to making each, individual media available to some person or group, one at a time.  I know people like to have features, similar to Facebook or Youtube, where you click, there is a pop-up screen... share with John, Mary, Tom... Click Go.  Making code that does this is not an option because of the liability.  Even if that was not the issue, the code would have to be tested to work in all cases and bugs would need to be fixed and users will come up with ongoing  new feature requests...  It's a lot of work.  Why not act like an admin and administrate your media? Make a temp library and after the holidays, delete it?

These don't give you the share link solution, but these options can show selected media for a limited time.
 

Edited July 2, 2023 by visproduction