Klox

Next time please do that research for Dem primaries. We continue needing the best Dems.

The UFOs nobody cares about /s.

We’ve already seen these movies. And they weren’t very good to begin with.

Well that was an impressive speed run to enshitifcation. What kind of sensorship is queued up next?

Get a router/travel router and set it up as a gateway where it provides its own SSID for the Roku to connect to. Basically a bridge to the complex, where you can inject some software. A lot of the travel devices have baked in Wireguard+Tailnet support. iNet are generally good products.

to get something that is idiot proof.

The problem with Jellyfin in particular is that it needs to support binary streaming protocols. You can implement some gateway/firewall-based security in front of Jellyfin, but in the end it is still Jellyfin’s internal mechanisms mostly responsible for its own security. I don’t use Authentik but I have read many good things. The only real “advantage” of it is that it forces your users to somewhat better credential handling. Jellyfin still only supports LDAP, so the users will have to enter their Authentik username and password – very similar to just local accounts managed by Jellyfin. So IMO, not offering you that much extra in terms of security. You will be better served by firewall tools like fail2ban, crowdsec, geo-fencing, etc.

Depending on where/how your users access Jellyfin you could have something a bit tighter. If they never run it on a TV you could do something more advanced like mTLS where you issue them a certificate with a TTL of several years, walk them through installing it on their phones/laptops, and then have that in a reverse proxy. But at that point you might as well walk them through setting up a VPN mesh network.

For Seerr, it’s just a standard web app .You could put a reverse proxy in front that requires OIDC with Authentik. Seerr is also pretty close to having native OIDC integration. Personally I prefer having two rounds of OIDC – reverse proxy really narrows what the public can see as a first layer.

For BookOrbit, I am not familiar enough with the Kobos. My guess is, you could put BookOrbit behind a reverse proxy that enforces OIDC, but you might have to allow a bypass for /api route. Then you’re relying on BookOrbit to authenticate all /api requests through API tokens. This would look like the normal Kobo linking process, so no real difference, but then your BookOrbit web UI is locked behind OIDC authentication.

I’m not one to defend Lemmy’s downvoting behavior, but let’s put ourselves in the shoes of an antifa to understand their mentality. OP didn’t say anything other than “conceive the inconceivable”. They could have suggested anything, like maybe the book had her birthday in it. Or maybe the FBI can’t read and thought it was an ANTIFA strategy book. Anything to help conceive the inconceivable. I also have doubts that the judge approved taking a children’s book, and likely approved retrieving birth certificate documentation. But we know the mind of a fascist, and they will self-justify every action to achieve their goals.

But an old children’s book might conceivably be relevant.

lmfao

Two NIC. I’m usually using the SFF. I went 10G last year and it’s been so great. Single, used, low profile, dual port SFP+ module. One port has SFP+ to RJ45 to my modem. Other port is SFP+ passive DAC to a used Brocade ICX 2750.

I was Unifi gear and then went back to Opnsense :P. That shit is way too expensive to replace.

OPNsense on used dell optiplex. Very easy but it can do whatever you want to grow into as you learn more.

I wanted a city that would be absurd to claim anyone would caravan from.

I’m sure they can invent a caravan from Lima to get bootlickers drooling before the election.

No, I’m just a professional software engineer that has been in security and privacy for the last ~9 years (unrelated to passkeys). But I am also head of security for my company and rolled out updated hardware keys in the last year, so am somewhat more familiar with the topic as of recent.

I also generally enjoy discussing privacy topics. Even more so when I feel the community’s understanding is off /shrug. Was chilling on my phone while the kids were crashed this afternoon.

Apologies if I miss-stated your point and conflated service’s other arbitrary decisions with what you’re suggesting may happen with passkeys.

Maybe I have one follow-up question, there are a number of websites that just don’t use passwords at all. It’s always one-time codes sent to emails. Where does this fall on your freedom spectrum?

Do you have similar arguments about HTTP 3? QUIC? Web RTC? There’s so many protocols that could be used in a way to lock in users. Just because it has some bits in the schema, doesn’t really mean much. Particularly when it’s actually supplying a very real need in other contexts. Nobody wants 30 versions of passkey-alt protocols.

Cheers

IMO you’re reading way too much into the value proposition of passwords. Services can “deny service” for arbitrary reasons already with zero consequences, but your idea is that they will ban based on… passkeys? You’ve got people banned from youtube for arbitrary comments. You’ve got MS locking out non-profits for arbitrary reasons. But in your mind, those all pale in comparison to what will happen if we all start using passkeys? I’m not buying what you’re selling.

You seem to think that’s tangential, but I reject that. It’s kinda the whole point.

I didn’t say it was tangential. Attestation is for very specific purpose. Non-attested credentials are not sufficient for government and corporate security. I cannot allow BYO hardware to authenticate my users on my services. I highly doubt any public service would require attested passkeys. I doubt passwords will stop being allowed, almost ever, so you probably have nothing to fear. Maybe you can throw that comment back in my face in 20+ years, heh.

Here’s another counter-point: Google, Apple, et. al already implement proprietary authentication mechanisms. Sign-in prompts on recent devices, email codes, etc. are all proprietary. None of these companies killed passwords despite having implemented the tools to do exactly that with vendor lock-in. All the evidence is the opposite. This is one of the first times we’re even getting an open standard authentication, the exact opposite of “walled garden”.

Authenticating based on a shared secret is an interface with a special property: there’s no way for a service provider to know how you remember a secret.

The same special property that allows rampant attacks on the public. I deal with so many people with compromised email inboxes, malware installs, stolen credentials, etc. Passwords are not the end solution to end user security, and I welcome improvements that also simplify UX.

I think we’ve probably hashed out enough of the sides of the argument. Good luck to you.

This is the equivalent of Sony arguing that you never owned any games

It’s far from that and bad analogies pollute otherwise very simple conversations. If you want a more apt analogy, this “debate” is shaping up closer to LED vs incandescent bulbs.

It’s easy to say passwords are sufficient when you’re one person practicing good op-sec. It’s not when you’re supporting thousands of people of varying technical proficiency, thousands of machines, thousands of services, and thousands of bad-actors. It was an even simpler time when 4 digit PINs were “sufficient”, but the world you and I live in is more complicated. Certain passkeys are transferable, so you’re not even losing out on that capability. Curmudgeon arguments aren’t convincing. Passkeys aren’t “giving power away”. Using passkeys doesn’t mean your giving up freedom. Passkeys have no bearing on the “economic system” and inflation. As far as the IT ecosystem is concerned, we’ve never lived in a more open and capable time. There are so many alternatives to every service (that isn’t tightly coupled to copyright). Of course companies are trying to offer unique products people can’t get anywhere else. None of this has to do with passkeys.

I’ve personally refused to use Apple for decades because of their walled-garden, and it sounds like I’ll continue to follow that principle, heh. But that also has nothing to do with Passkeys, and everything to do with whatever Apple is doing. So I guess, you got me there, Apple sucks.

I will say, I am able to deploy FIDO2 for SSO on Apple devices just fine with both Microsoft Intune and Jamf. But that’s not really Apple’s Passkey vault.

Cheers

Literally just name a service that forces this. If it’s all of them, it should be pretty easy.

I replied to someone else asking the same thing, but we can avoid this infinite-universe syndrome. Which service is forcing a specific passkey provider, and doesn’t offer alternatives? I just need an example to understand because I don’t know of any and I have been using passkeys for awhile, so I’d appreciate being informed.