JRaccoon

Thanks. This is kinda important info so I’ve edited my initial comment.

They are not saying anything on why they are removing it.

Jellyfin is dropping HTTPS support with a future update[…]

What’s the source for this? I wasn’t able to find anything with a quick google search

I see everyone in this thread recommending a VPN or reverse proxy for accessing Jellyfin from outside the LAN. While I generally agree, I don’t see a realistic risk in exposing Jellyfin directly to the internet. It supports HTTPS and certificates nowadays, so there’s no need for outside SSL termination anymore. (See Edit 2)

In my setup, which I’ve been running for some time, I’ve port-forwarded only Jellyfin’s HTTPS port to eliminate the possibility of someone ending up on pure HTTP and sending credentials unencrypted. I’ve also changed the Jellyfin’s default port to a non-standard one to avoid basic port-scanning bots spamming login attempts. I fully understand that this falls into the security through obscurity category, but no harm in it either.

Anyone wanna yell at me for being an idiot and doing everything wrong? I’m genuinely curious, as the sentiment online seems to be that at least a reverse proxy is almost mandatory for this kind of setup, and I’m not entirely sure why.

Edit: Thank you everyone for your responses. While I don’t agree with everything, the new insight is appreciated.

Edit 2: I’ve been informed that infact the support for HTTPS will be removed in a future version. From v10.11 release notes:

Deprecation Notice: Jellyfin’s internal handling of TLS/SSL certificates and configuration in the web server will be removed in a future version. No changes to the current system have been made in 10.11, however future versions will remove the current system and instead will provide advanced instructions to configure the Kestrel webserver directly for this relatively niche usecase. We strongly advise anyone using the current TLS options to use a Reverse Proxy for TLS termination instead if at all possible, as this provides a number of benefits

What if a bad actor acquires one of these once popular tracker domains? Could they somehow take advantage of it? For example, what if they make the tracker advertise a large number of “fake” peers that serve malware instead of the actual files? I only have a crude understanding of how BitTorrent works, so I’m not sure what kinds of protections, if any, it has against this type of attack.

Usually the gear is retracted almost immediately after takeoff, as it creates a huge amount of unnecessary drag if left out when not needed.

They’re also not saying it couldn’t have happened, are they? They’re waiting for investigators to gather all the facts before making any statements, just like they should.

Meanwhile, we here on the internet are just speculating based on the limited information available (basically just the video footage). Based on the current information we have, my opinion is that pilot error is the most likely cause.

You’re free to disagree about the likelihood of different scenarios, but right now we have no evidence that makes the theory of the pilots accidentally retracting the flaps instead of the gear impossible or “absurd.” It’s really counterproductive to start ruling out scenarios without concrete proof.

I don’t get what you mean by “and no one figured that out yet.” As you said yourself, no one knows what happened yet. Pretty much all we have at this point are the videos, and all we can confirm from them is a rough flight path of the plane and that the landing gear remained down after what appeared to be a normal takeoff. I haven’t seen any footage that clearly shows the state of the flaps with any certainty, but please correct me if I’ve missed something.

In my mind, that leaves us with three possible scenarios:

• Pilot error (retracting the flaps instead of the landing gear)
• Dual engine failure at the critical moment (there’s no evidence of this in the videos, but also nothing ruling it out)
• Something else (we don’t know what we don’t know)

From the two scenarios (pilot error, engine failure) that fit the flight path from the videos, the option one seems more plausible to me. But that’s just my armchair opinion, it doesn’t mean anything. All we can really do is wait for the investigation and the preliminary report.

According to type rated pilots the 787 doesn’t allow you to retract flaps immediately in critical flight after takeoff.

That’s interesting. Do you have the source for that? I wasn’t able to find a definitive answer with google

There are minimum airspeeds the aircraft must reach before the flaps can be safely retracted. I don’t know the exact numbers, but assuming a standard flaps 5 takeoff for B787, retraction to flaps 1 would occur around 1000 ft by earliest, that’s typically 20 to 30 seconds after the takeoff.

Are the 787’s controls arranged in such a way that you could accidentally retract the flaps instead of the landing gear?

Not in a sense that someone could just grab the wrong lever in the dark for example. The levers are in different parts of the cockpit and also shaped very differently. But we humans can do all kinds of weird mistakes that are hard to explain. Almost everyone has experienced this sometimes. Think something like searching for you phone while it’s in your hand. Afterwards it’s very hard to explain why would anyone do such a silly mistake but it still happened. This would be similar.

One theory circulating online is that the pilots may have accidentally retracted the flaps instead of the landing gear. Apparently that would result in kind of a flight path seen on the published videos.

While this cannot be confirmed or ruled out with the information we have, in my opinion the available videos seem to kinda support this theory. Initially the aircraft appears to take off and climb normally, but for some reason the gear is not being retracted when usually it would be retracted right after the takeoff.

Naturally the gear could be forgotten or left intentionally down if there were a dual engine failure right after takeoff, for example, but as the videos show no evidence of this, I’m more inclined to believe in simple pilot error.

That’s reassuring to know. What I don’t understand is why you have the /api/v3/post/like/list route. You say you don’t want votes to be snooped on, but then you add an endpoint that makes it very easy for instance admins to do exactly that if they choose to? Also worth pointing out that the tool linked here wouldn’t work in its current form if this route didn’t exist.

Compare your actions to releasing a 0-day exploit for a security vulnerability instead of responsibly disclosing. It doesn’t help, it just causes chaos until the people who do the actual work can figure out a solution.

This comparison is not fair at all. It’s not like the devs are unaware of this. They could start by removing the API endpoint that lists a post’s votes, but they haven’t, which means they seem to think it’s okay for the instance admins to snoop on votes if they so wish.

They can include runnable JavaScript too, which can cause vulnerabilities in certain contexts. One example from work some years back: We had a web app where users could upload files, and certain users could view files uploaded by others. They had the option to download the file or, if it was a file type that the browser could display (like an image or a PDF), the site would display it directly on the page.

To prevent any XSS (scripts from user-provided files), we served all files with the CSP sandbox header, which prevents any scripts from running. However, at the time, that header broke some features of the video player on certain browsers (I think in Safari, at least), so we had to serve some file types without the header. Mistakenly, we also included image files in the exclusion, as everyone through image files couldn’t contain scripts. But the MIME type for SVG files is image/svg+xml… It was very embarrassing to have such a simple XSS vuln flagged in a security audit.

My use case is a bit different than yours but still worth mentioning, I think; I have Sharry running in Docker and it makes sharing and receiving files super easy. All downloads and uploads are resumable so they work well even in unstable networks.

Nope. But as mentioned in the article, some support for display servers might be coming in Android 16.

Networking does work. I was able to install packages using apt and also ping machines on my local network. Could be useful.
I guess in a pinch it could be used to ssh into other machines. However, I’m sure there are plenty of SSH clients available for Android, which are much more lightweight solution than running a whole VM.

It has access to /sdcard as a shared folder.

How does this work? The app doesn’t seem to have any settings related to it yet. Under /mnt in the VM I noticed folder shared that seems to match the downloads folder on my phone, which seems odd

Tested this on my Pixel 8a. Works as you would expect. Personally I have a little hard time coming up with use cases for this but I guess it’s kinda cool.