• 0 Posts
  • 177 Comments
Joined 3 years ago
cake
Cake day: December 14th, 2023

help-circle
  • It sounds like it’s just not worth it for you, and that’s totally fine! Plenty of people get by just fine with using random streaming sites.

    Personally, I want something more reliable, I want to have copies of what I watch in my possession that cannot be taken down, and I want to share this with others so that my friends can benefit from my time investment instead of using a solution that only works for me. So that if my friends ask me “where do you get your stuff” I can offer to share with them at 0 extra effort instead of telling them “go do all these things that I already did”

    As for usage, I only watch a few hours a week myself, but I share with 15-20 friends and family who watch a collective 160 hours a month last year and around 360 hours a month this year (about 15 days of watch time per month).

    I have a fairly comprehensive arrstack, torrents and Usenet, seerr, Plex and jellyfin side by side with identical media mounts for maximum user choice, running on a nuc with quicksync so it handles 8+ simultaneous 1080p live transcodes without using much power or increasing CPU usage much more than 5-10%.


  • I’m not gp but I also prefer the app for several reason, like being able to cast to the smart tube TV app which is also ad free and has sponsorblock, and for small UX things like certain gestures, like I can pull down on a video to go to theater mode whereas in the browser it refreshes the video page, and I like that the transitions between views don’t have a brief white screen but has a seamless transition that expands a videos thumbnail into the video view.

    Otherwise the UI of ReVanced is basically identical, but both are ad free and have sponsorblock / return dislike but ReVanced feels smoother to use and there’s lots of customizable ReVanced settings in the app for tweaking things like haptics, downloads, hiding and showing various components like endcards, info cards, quick actions and related videos, shorts, etc.

    Here’s a sample of all the options it has: https://imgur.com/a/gRdd5K0








  • Yes that’s what I would like to advocate for. I did something similar with LunaSea, but often people suggest doing that with Jellyfin and are not aware that almost no apps support it, and that adding exceptions for the API makes you basically as secure as not having it. But people tend to get very defensive when you try to tell them that something won’t work, so I try to phrase it as a question to see if I can get them to understand what the limitations are in a way that’s less confrontational.


  • Yeah that’s fair and I think that’s a good move, my point is just that people are acting like this is not feasible to exploit. I’m at the point in my exploit testing excursion where I have a script that can generate a stream of potential IDs based on real torrent names being parsed and reformatted using radarr’s default naming pattern as well as the commonly used trash guides ones permuted with some common library paths used in the default docker compose examples, and it’s turning up actual ID matches with my jellyfin instance. All I have left to do is make it create API requests to test the IDs against the unauthenticated API instead of checking an exported list and there’s a proof of concept. 5 years is a long time for someone to figure that out.



  • What do you mean viable? The web UI is just an app that is delivered to your browser, it makes more or less the same API requests as an app would make, so IDK why the risk would be lower with an app?

    If an attacker can access the login endpoint for example to brute force or dictionary attack, it doesn’t matter if the web UI is or isn’t accessible if the login endpoint it uses is exposed for an app. The attacker could serve their own copy of the web UI and proxy requests to the API your app connects to. Blocking the html from being served doesn’t make a difference.


  • Do you not do any renaming? That probably would make it even easier as you can just brute force with a database of filenames scraped from torrents. I already have a proof of concept that generates valid jellyfin IDs from any given file path, it only takes a few more steps before you can plug in a shodan scan of jellyfin instances and just shotgun a bunch of IDs generated from torrents.csv at them and find stuff you can stream without authentication.

    People not bothering to rename, using the default radarr naming scheme, or everyone using the same naming pattern from trash guides just makes it easier.

    Probably the only way to guarantee nobody can probe your media and stream it without authentication is to make sure to rename everything using a format that only you use or mount all your media under a path inside docker that contains a long randomly generated folder prefix.





  • Yeah not only would a lot of people have the same media name, because of docker mounts, probably a lot of people have the same path to the media inside of the docker container even if the external location is different. I bet you could make a rainbow table of sorts of the most popular movie/TV torrents combined with the most common place in the container for media to be mounted, then use shodan to get a list of hundreds of instances that you could scan for the common hashes.

    I’m just seeing the issue for the first time and noticed it was raised 5 years ago - surely that was enough time to at least put forward a changeover date and give clients time to update.




  • For starters, it being brought up wouldn’t be an issue if there was some timeline to fix it and the response wasn’t just “it’s too hard and would break clients”, and secondly, I think it’s not congruent with wanting to improve jellyfin if your reflex is immediately to say that nothing is truly secure. Could you imagine if next cloud had a similar issue and put it off for more than 5(?) years?? Is that really not enough time to get the clients and apps in order? They should just put the issue to rest so we can move on with making jellyfin better. I don’t think anyone wants it to remain an issue for another 5 years, and I think calling that blown out of proportion is kinda ridiculous.

    Like if 5 years ago they said you have 5 years to update your app, we could have had this issue checked off and nobody would be able to complain about it or use it as an excuse not to switch, so the next best time to set a deadline would be now. They should just as soon as possible say you have a couple years to update your apps, at least schedule a date years in the future to rip off the bandaid instead of kicking it further down the road.