Probably folder structure and naming conventions.

If you still have some stubborn pieces of media, [imdbid-tt…] tags and even .nfo files can help.

A bit cumbersome if you are traveling and using a different public wifi every time though

You’re not wrong. But you’re probably also familiar with the “secure vs. convenient” dichotomy: the closer to the “secure” end of the spectrum you get, the more cumbersome things will inevitably get. If you feel like you’re jumping through too many hoops and you don’t know what for, chances are you’re overshooting the target in terms of your threat model and might get away with doing less.

Plex -> Jellyfin (I don’t use it but I’ve heard good things about it);

I do use it heavily and came here to recommend it over Plex.

1. Disable DNS once. Find out URL/IP of captive portal that way.
2. Add to hosts file (Win/Lin/Mac). Maybe even give an alias: “captive-school”, “captive-library”, etc.
3. Turn DNS back on. The hosts file will take prerogative over DNS settings, i.e. it is resolved first.

Thanks for the clarification!

Confusing write-up. Care to clarify

• why exactly your phone fails attestation?
• what exactly it is you did to make it work?

Most lists from https://github.com/blocklistproject/Lists

It does say that, and yet I’ve been doing it for years without issue. You just need to know what you’re doing, i.e. you need to be able to tell apart the connections that are required to make a site work from those that aren’t needed and can be blocked without issue. If you don’t, Tracker Control will break a lot of sites, and they probably don’t want to deal with the resulting support requests.

But if you’ve been using NoScript for a while, you will feel right at home with TC and be able to use it with browsers as well, which is where a lot of tracking happens.

The critical part is: how many supposed “quality” alternatives have been proven not to do any logging? Mullvad has been proven to be solid. They were raided and had jolly little to hand over to authorities on their customers.

How many of the other VPN services can say that about themselves?

It’s a mixed bag really. Disabling JavaScript thwarts a lot of tracking efforts. But at the same time it puts you into a very small niche of users that, combined with other data points (user agent, IP location) makes you pretty fingerprintable.

Coming from a fellow JS Disabler, mind you.

I feel you. Handoff was dodgy af. I’ve switched to BasicSync for this very reason. It’s a minimal Frontend, handling only execution conditions on Android. All config is done through the webUI. It works great and avoids some, if not all of the trust issues.

Immich is dead-easy to set up on its own. I’m a great fan and have been running it for >2 years now.

That said, I don’t think it’ll work for you because:

• I gather you have little experience in self-hosting services. Sure, one can learn all that, but if you’re becoming a parent soon, your priorities will be elsewhere (as they should).
• self-hosting stuff isn’t a one-shot - it does come with maintenance costs. You need to keep your boxes up to date, swap out dead hardware, manage backups… You may not have time for that.
• Running immich itself is relatively easy. But running it securely is a different can of worms. Immich is a young project, written by enthusiasts, but not vetted for security like professionally-deployed software is. Thus, it’s not advisable to expose it to the open internet. Since you want to share access to others, you’d have to setup Wireguard VPN tunnels for your relatives, which complicates matters.

Obviously, I’m making a lot of assumptions about you. Whether these are true is up for you to decide.

Thanks for providing some evidence at last. You’re not wrong on many of those points, but not entirely right either.

Phone numbers are an issue, true, though you can get around that using a burner SIM or even a virtual phone number. Also, contact discovery has been working without exposing your phone number for over a year now.

a phone from Google or Apple

The phone can be made by anyone. The OS needs to be Android or iOS at some point, which is unfortunate; pure (desktop) Linux usage isn’t possible. That said, deGoogled Android has been around for more than a decade, allowing you to use Android in a privacy-friendly way. So if you want, you absolutely can avoid being tied to Google and use Signal.

As you can see, there’s a lot more nuance here than “Signal isn’t private”; privacy, after all, isn’t binary, but rather a gradient. For what it’s worth, Signal is more private than many messengers out there by a long shot, and it allows you to use it in more privacy-friendly ways if you so desire. While there are messengers out there that go even further in terms of security, privacy and decentralisation, a lot of them come with usability and convenience drawbacks. The way I see it, Signal sits in a Goldilocks Zone of “private enough” (for most threat models) and “convenient enough” for mainstream adoption. You can have the most secure and air-tight messenger; if there’s nobody there to talk to, it’s no more than a technically sophisticated brick. For now, Signal may be our best shot for mainstream adoption of reasonably private and secure messaging. If your threat model is higher than that of average Joe, by all means, go for Briar, SimpleX chat or any of the more hardcore options.

1. Blurt out an opinion without the slightest effort to support it with evidence.
2. Whine you’re getting downvotes for ir.
3. Claim your baseless opinion is “just stating the facts”. Again, refuse even the tiniest amount of reasoning.
4. Profit?

Ignore the downvotes. That’s a fair question to ask, but one that does have answers. Signal is FOSS, has E2EE and was audited several times, so we know that

• it did not contain any backdoors at the time of the audit
• it will not for the foreseeable future (they’d be visible in the client code)
• I need not trust the server code since messages are E2EE

Thus, while mistakes do happen and can open up severe vulnerabilities, cf. Heartbleed, there’s reason to assume that Signal is relatively secure. Signal’s centralisation of server infrastructure is a valid concern, but not for security, but rather for

• privacy (they might capture metadata, although it appears they don’t; nation-state actors trying to subpoena user data have so far only gotten “date of registration” and “last online”, which appears to be all they’re storing; that’s as close to “zero knowledge” as you get)
• availability (as the recent AWS outage has shown, which took out Signal as well)

Fair, that’s why I want to avoid it as much as I can.

Follow-up: I added the Guardian project repo to FDroid. Turn out: once FDroid has the repo, it can “take over” and do updates, even if Signal was originally installed from the Play Store / Aurora. That pretty much solved my primary issue here. (I’ll look into Molly at a later point anyway, just for the sake of curiosity.)

Thank you, once again!

Now that’s a smart solution that might just work for me. I completely forgot that they were packaging Signal for their repos too! For anyone interested: Here’s the link to their repo.

I’ll reply to you since you first brought it up, but it’s a question to anyone here recommending Molly: what makes you cofident that Molly is secure (i.e. they’re not fucking up Signal’s cryptography by accident) and maintained by trustworthy people. Signal does get audits from time to time, Molly doesn’t.

Mind you, I’m not trying to shit all over Molly; Unified Push looks great. I’m trying to approach this with due caution though.

Aurora is all I use. We’re still trusting Google not to inject anything malicious into the app, which they’ll do in a heartbeat if the feds come knocking.