I simply can’t wrap my head around the thought process behind launching a clusterfuck like this. Y Combinator probably didn’t do their due diligence and simply rode the fading AI Bubble, so I can at least understand how the funding might have been approved.

But actively leaving your $250,000+/year job to team up with some questionable choices to basically fork two OS projects, change the discord links and generate an illegal licence for that shit show, all while proudly stating, publicly, “dawg i chatgpt’d the license, anyone is free to use our app for free for whatever they want. if there’s a problem with the license just lmk i’ll change it. we busy building rn can’t be bothered with legal” when they are made aware of the fact.

This is absolutely insane, sounds like someone was about to get fired and decided to use some personal relations and fresh graduates to somehow successfully cash in one last time with absolutely no regard of even the basics. Pretty wild that those guys even managed to figure out how to found a Startup. Probably asked ChatGPT for instructions there, as well.

Buying a domain. There might be some free services that, similar to DuckDNS in the beginning, work reliably for now. But IMHO they are not worth the potential headaches.

DuckDNS pretty often has problems and fails to propagate properly. It’s not very good, especially with frequent IP changes.

Windows, as any operating system, is best run in a context most useful to the user and appropriate for the user’s technical level.

• Need to run Windows apps/games and aren’t afraid to tinker around if and when something doesn’t work as expected or your software simply isn’t supported? WINE/Proton.
• Need to run mostly light Windows apps and don’t want to tinker around? VM.
• Need to run Windows apps/games that don’t rely on Kernel-Level Anti-Cheat, want direct hardware access and aren’t afraid to tinker around, especially if you only have one GPU, and when something doesn’t work as expected? KVM
• Need to run any Windows app/game without things constantly breaking or the need to tinker around and staying on top of things? Dual-Boot from different disks, utilize LUKS/FDE and be done with it.

Why do you keep stating blatantly false info as facts when it is obvious that you’re knowledge of the topic at hand is superficial at best?

In this comment thread alone you’ve stated that:

• to avoid “Google Android”, one should use Lineage OS (?)
• Apps on Lineage are some kind of separated on Lineage OS and not abandonware (??)
• Lineage OS is not terrible for security, because you haven’t found anything wrong with it besides that small little, insignificant detail of an unlocked bootloader (???)
• DivestOS has “all the same issues” as GrapheneOS(???)

Genuinely not trying to stir up shit, I’m curious. Why?

It’s great that it works for you and that you strive to spread your knowledge. Personally, I’m quite happy with my DNS filtering/uBlock Origin and restrictive browser approach and already employ alternatives where feasible in my custom use case.

Thanks for your offer, though!

15-20 years ago, I’d have agreed with you. But apart from a select few news sites and exceedingly rare static sites, what percentage of websites most users use day to day actually function even minimally without JavaScript?

I’m convinced that in practice, most users would be conditioned to whitelist pretty much every site they visit due to all the breakage. Still a privacy and security improvement, but a massive one? I’m not sure.

Very happy to be convinced otherwise.

if you’ve flown for 12 hours with all that entails to go to the US (for a reason) and are presented with the choice of unlocking your phone or be denied entry, you will cooperate. Especially if you moved all your sensitive info beforehand.

I’d appreciate it very much!

Great suggestion to secure the backups themselfes, but I’m more concerned about the impact an attacker on my network might have on the external network and vice versa.

That’d be the gold standard. Unfortunately, the external network utilizes infrastructure that doesn’t support specifying firewall rules on the existing separate VLAN, so all rules would have to be applied on the Pi itself or on yet another device between, which is something I’d like to avoid. Great general advice, though!

Yikes. Thanks for putting in the works and sharing your findings to you and @[email protected].

Ah. So Lemmy with version 0.19.4+ allows users to set a custom thumbnail URL for a post, which can be set to pretty much anything resembling a valid link, especially a link to another image in the local pictrs db and trigger a deletion of both when a minimum age check is passed.

Also this:

Except that the field allows some funny URLs e.g. https://t.t/;';'%22;...[:%3C%3E?]%27;%20yaba%20daba%20doo, if this is an issue too is not confirmed

While this is a great approach for any business hosting mission critical or user facing ressources, it is WAY overkill for a basic selfhosted setup involving family and friends.

For this to make sense, you need to have access to 3 different physical locations with their own ISPs or rent 3 different VPS.

Assuming one would use only 1 data drive + an equal parity drive, now we’re talking about 6 drives with the total usable capacity of one. If one decides to use fewer drives and link your nodes to one or two data drives (remotely), I/O and latency becomes an issue and you effectively introduced more points of failure than before.

Not even talking about the massive increase in initial and running costs as well as administrive headaches, this isn’t worth it for basically anyone.

Because this repo is going viral from time to time to developers, I’m open for discussion if you want to promote a product/service in this README file. Just mail me at XXXX

Ew.

I’ve been tempted by Tailscale a few times before, but I don’t want to depend on their proprietary clients and control server. The latter could be solved by selfhosting Headscale, but at this point I figure that going for a basic Wireguard setup is probably easier to maintain.

I’d like to have a look at your rules setup, I’m especially curious if/how you approached the event of the commercial VPN Wireguard tunnel(s) on your exit node(s) going down, which depending on the setup may send requests meant to go through the commercial VPN through your VPS exit node.

Personally, I ended up with two Wireguard containers in the target LAN, a wireguard-server and a **wireguard-client **container.

They both share a docker network with a specific subnet {DOCKER_SUBNET} and wireguard-client has a static IP {WG_CLIENT_IP} in that subnet.

The wireguard-client has a slightly altered standard config to establish a tunnel to an external endpoint, a commercial VPN in this case:

[Interface]
PrivateKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Address = XXXXXXXXXXXXXXXXXXX

PostUp = iptables -t nat -A POSTROUTING -o wg+ -j MASQUERADE
PreDown = iptables -t nat -D POSTROUTING -o wg+ -j MASQUERADE

PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

[Peer]
PublicKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
AllowedIPs = 0.0.0.0/0,::0/0
Endpoint = XXXXXXXXXXXXXXXXXXXX

where

PostUp = iptables -t nat -A POSTROUTING -o wg+ -j MASQUERADE
PreDown = iptables -t nat -D POSTROUTING -o wg+ -j MASQUERADE

are responsible for properly routing traffic coming in from outside the container and

PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

is your standard kill-switch meant to block traffic going out of any network interface except the tunnel interface in the event of the tunnel going down.

The wireguard-server container has these PostUPs and -Downs:

PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

default rules that come with the template and allow for routing packets through the server tunnel

PostUp = wg set wg0 fwmark 51820

the traffic out of the tunnel interface get marked

PostUp = ip -4 route add 0.0.0.0/0 via {WG_CLIENT_IP} table 51820

add a rule to routing table 51820 for routing all packets through the wireguard-client container

PostUp = ip -4 rule add not fwmark 51820 table 51820

packets not marked should use routing table 51820

PostUp = ip -4 rule add table main suppress_prefixlength 0

respect manual rules added to main routing table

PostUp = ip route add {LAN_SUBNET} via {DOCKER_SUBNET_GATEWAY_IP} dev eth0

route packages with a destination in {LAN_SUBNET} to the actual {LAN_SUBNET} of the host

PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip route del {LAN_SUBNET} via {DOCKER_SUBNET_GATEWAY_IP} dev eth0

delete those rules after the tunnel goes down

PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark 0xca6c -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -I OUTPUT ! -o %i -m mark ! --mark 0xca6c -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark 0xca6c -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -D OUTPUT ! -o %i -m mark ! --mark 0xca6c -m addrtype ! --dst-type LOCAL -j REJECT

Basically the same kill-switch as in wireguard-client, but with the mark manually substituted since the command it relied on didn’t work in my server container for some reason and AFAIK the mark actually doesn’t change.

Now do I actually need the kill-switch in wireguard-server? Is the kill-switch in wireguard-client sufficient? I’m not even sure anymore.

Oh I’m fully aware. I personally don’t care, but one could add a capable VPS and deploy the Wireguard Host Container + two Client Containers, one for the LAN and one for the commercial VPN (like so), if the internet connection of the LAN in question isn’t sufficient.

Oh, neat! Never noticed that option in the Wireguard app before. That’s very helpful already. Regarding your opnsense setup:

I’ve dabbled in some (simple) routing before, but I’m far from anything one could call competent in that regard and even if I’d read up properly before writing my own routes/rules, I’d probably still wouldn’t trust that I hadn’t forgotten something to e.g. prevent IP/DNS leaks.

I’m mainly relying on a Docker and was hoping for pointers on how to configure a Wireguard host container to route only internet traffic through another Wireguard Client container.

I found this example, which is pretty close to my ideal setup. I’ll read up on that.

To add to this:

We have to differentiate between physical and cybersecurity.

Are you more likely to physically lose your smartphone you carry around with you all day than your full ATX desktop standing in your office? Yeah.

But let’s consider the consequences for a moment.

If someone physically stole your desktop, chances are that at least a part of your data isn’t encrypted, the boot sequence probably isn’t (at least completely) verified, and your OS is wide open. There is little to no real isolation in most desktop setups. Once somebody managed to gain access to your system, it is outright trivial to steal your browser sessions, modify commands or run some code, at least in userland.

Physically stealing your smartphone is easy. But a modern smartphone is usually protected by verified boot and a password+fingerprint/Face ID combo. Unless you take active steps to compromise the security of the phone like rooting/jailbreaking it, disabling verified boot or disabling the passcode, it’s pretty hard if not near impossible to gain access to your data or modify it in a harmful way. If you visit an infected site or install an infected app, the damage is usually confined to that app’s data and the data accessible to it by permissions you probably had to allow to be set in the first place.

Now that’s speaking to your usual bad actors and usual setups. Exceptions, as always, make the rule. As soon as a sufficiently motivated and technically able actor with access to 0-day exploits, like a state actor, targets you for some reason, all bets are off. But even in this case, due to the advanced verified boot chain on most modern smartphones, those exploits rarely have the ability to survive beyond a reboot.