I get the idea, and in general I love it - especially since they eliminate phishing in theory. BUT making my device my “password” now shifts the single point of failure from me forgetting my password to me protecting my devices from any kind of error/damage/data loss/… Collecting all passkeys in your Google Account is probably also not the best idea, considering how little chance you have to get your account back if it ever gets locked by a random event you may or may not have participated in.

Having them device independent (e.g. in a password safe) is nice, though. But then, if I use my password safe right, I should already be somewhat protected from phishing, as my auto fill won’t trigger on a random phishing site.

Mine didn’t want to migrate and I had to build them a new PC with Win11 (their old one was barely able to run win 10 and had already some hardware problems, so a new one was on my bucket list for a while) - but… yeah the most time was spent tracking down all these passwords and accounts they were constantly using without knowing which email address and which password was used for the account…

Русский военный корабль, иди на хуй?

🍆💦 ^✊👁️👄👁️^👌

370 to go

Watch out to not accidentally make a typo and change a vowel. Otherwise pacman will be upset and sabotage your install.

So also cancel ALL cargo flights. Got it.

No, that’s just another hypothetical app that you’re using a reverse proxy for. I just included it to show how you can also set settings for a single subdomain/reverse proxy entry that isn’t used globally on all domains that get served. I used a hypothetical REST API that needs a CORS Header that other apps don’t need (or maybe serve themselves).

admin off disables Caddy’s admin interface (which shouldn’t be public and if you’re using config files this usually isn’t needed. So just a bit of gardening)

servers sets some general server options.

and then I just inserted several blocks that each define a reverse proxy to a different app / backend to show that you can just dump them all in a single Caddyfile. And the last example to show that you can set specific settings only for a specific subdomain instead of globally. As I set headers mostly used by REST APIs, I just called that api.example.com instead of app3.example.com.

If you like, I can send you an example of the Caddyfiles, that I’m using (I used the import directive to split every service into its own Caddyfiles, you could just copy and paste everything in the same file). It will take a few hours until I get home, though.

But basically you can just put every subdomain and it’s target in a separate block and the add some things globally (e.g. passing the original IP, switching off the admin API of Caddy,…)

Something like this should work:

admin off 

servers {
		client_ip_headers X-Forwarded-For X-Real-IP
}

app.example.com {
    reverse_proxy 127.0.0.1:8080
}

app2.example.com {
    reverse_proxy 127.0.0.1:8081
}

api.example.com {
    reverse_proxy 127.0.0.1:8082
    header {
        Access-Control-Allow-Methods "GET, OPTIONS"
        Access-Control-Allow-Origin "*"
    }
}

With some kind of pointy hood?

Go ahead and give them your Social Security number, and see what happens.

“Socially I’m rated 3/10, but for security I’m an 8/10. Now that I’m replying to this, I think my security score just dropped a bit, though.”

I mean… Is it really spying? Your company can detect which AP or Switch you’re connected to (or if you’re using a VPN from home), so they do have that data anyways.

WTF?

I mean, my work PC is managed by the company and thus a Windows device, but why disable that feature? Yes, it somewhat makes sense if you see it like “we don’t want other OS to have all features to make costumers less likely to switch” BUT Teams on Mac has some unique features that haven’t been ported to windows and are still exclusively available on Mac, so…?!

Yeah, that’s exactly why I didn’t use my own CA. There’s a plethora of devices that you now need to import the CA to and then you need to hope, that every application uses the system cert store and doesn’t roll its own (IIRC e.g. Firefox uses its own cert store and doesn’t use the system cert store. Same for every java based application,…)

It’s fiddly with Caddy, as you need a specific plugin to get it to work with anything else than the default challenge. That means using a custom build via caddy - and with docker, you’re SOL. BUT you can just use certbot and point caddy to the cert file in your file system.

I have this setup. I bought a domain (say homeserver.tld) from a registrar that allows zone edits with an API. Then I use certbot with a plugin that supports my registrar to get real Let’s Encrypt certificates. Usually Let’s encrypt connects to your server to ensure that it responds to the domain you’re requesting a certificate for, but this challenge can also be done by editing the DNS record of your domain to prove ownership. That is called DNS-01 challenge and is useful of your domain is not publicly reachable. Google for certbot DNS-01 your registrar to find some documentation.

Some of the VMs/LXC now get certificates for a specific subdomain (“some-app.homeserver.tld”), other just get a wildcard certificate (“*.homeserver.tld”) - e.g. my docker host.

Wouldeth youeth liketh toeth seeth myeth dicketh?

Wasn’t it also some kind of DNS problem on top?

Just use the terms as every layman does:

• Dumb X <- offline/manual/no app (or none that works if you’re not in your home network/no cloud
• Smart X <- requires a increasingöy more costly monthly subscription, spies on you and shits itself on the thought of losing internet access. Usually yields worse results than Dumb X

In this case, she just wanted to make sure that everything is off and without current before the vacation and since I told her to not trip that one breaker, she unplugged some seemingly unrelated cables and just unplugged the wrong one

My wife: accidentially unplugs homeservers (with PiHole running)

Also my wife: the internet is down?!