Carl

Just remember to put a MOCA filter on the line coming into your house from the street. Or disconnect it entirely, if you’re not using the cable connection. Otherwise you’ll be sending all your Internet traffic straight out the cable line to all of your neighbors.

And this is actually how I’ve said it should be done from the start, though those ages are too granular for my taste. Just allow the user to verify their age once, then it shares a broad (child/teen/adult) age range with whatever asks.

We even have the technology to securely verify a person’s age without sharing any details, the same way we can share a password without actually storing it directly. It would require governments to actually pull their heads out of their asses and be technologically literate, but it could 100% be done:

Step 1, the government sets up a public database query. This simply returns a “true/false” response for if a hash matches their database of people over 18. Have people set up a password or PIN directly with the government (probably when they’re applying for an ID, which they would need to verify their age anyways), to act as a salt for their personal info hash.

Step 2, the user who wants to verify their age enters their data and password on their device. This info never leaves their device. It is hashed, and sent to whatever service their device is trying to verify. Google account, iCloud account, Microsoft account, etc… It can even be a local user account for things like Windows or Linux machines that don’t want to use cloud accounts. The important part is that the info is never directly sent, only the salted hash is. And simply using the info on a stolen ID won’t help, because you don’t have the password so the hash will be wrong.

Step 3, this hash can then be used to query that database, to see if the user is over 18. Again, the government simply returns a basic true/false on whether the info matches something in their database. It doesn’t give any specific info about the person. The service (whatever it may be) never gets your personal info, because they only saw the salted hash. And the government doesn’t need to know what specific device or person is trying to verify, because they only saw Microsoft/Google/Apple/etc asking “hey, does {hash} match your hash database?”

Step 4, once the query returns as true, the account is now flagged as age verified. This flag can be set directly on the account, so any device the user logs into can automatically be verified without needing to repeat the process.

On the user’s end, they get a much smoother experience. They never need to deal with the “are you over 18” pages on porn sites. And they don’t need to verify each individual site. The site simply asks if the user is over 18 as part of the initial https handshake before the webpage even loads. And then it boots the user (or more realistically, redirects them to a SFW “your device isn’t age verified, here is how to do that” page) if the user isn’t verified. And once a user is verified, it can be logged directly on their account so that they don’t need to verify each individual device. Your iCloud/Google/Microsoft/etc accounts could simply have the age flag added to your account, so any device you log into is automatically verified.

And importantly, parents protecting their kids is as simple as refusing to age-verify their kid’s accounts. By default, everything assumes you are a child until proven otherwise. Protect your password (which you should already be doing anyways) and your kid can’t sneak into your purse to use your ID to secretly verify themselves. Hell, you can even allow verified users to create specific child/teen accounts for their kids, which can be trusted without needing to re-verify anything. Because (again) that is simply a tool for parents to use if they feel like they should. By default, everything is assuming you’re a child anyways.

But of course, this is all a pipe dream. It will never actually be implemented in a sane way, because the tech companies are the ones pushing for age verification. They want to be the ones to handle your data, which means they’ll actively rebel against anything that takes that away from them. They’d lobby governments to prevent the hash database system from being implemented, because it would prevent them from being able to collect your data directly.

The em dashes always give it away tbh. Anything “coded” by this user would 100% be slop. If they can’t even be bothered to think of a pitch for it, why would they think of the code?

I used Google Timeline to prove I was at work one time. This was back when I was freelancing. My client tried to say I was stealing time, because I had an off-site meeting that ran long. They were threatening to withhold a few hours of pay, even though I was at the worksite the entire time. I pulled up my timeline and used it to prove that I was, in fact, at the meeting site for an extra few hours. Being able to de-Google that functionality has a lot of value to certain people.

They make sprung flip-top covers specifically for this reason. It’s just a little adhesive square/circle that you stick over the power/reset button, and it has a flip-top that automatically springs closed again.

I mean, would you want it to serve clients outside of your subnet? I guess maybe if you had something like a guest network. But I tend to take the “fuck it, you get basic service and nothing else” approach to things like guest networks.

Isn’t it a potential security issue to have your pihole serve things on any subnet, because it allows an improperly configured firewall to stab at your pihole? I think you can specify any additional subnets it will serve in the settings somewhere. But IIRC, the default behavior is to intentionally drop traffic from unknown subnets. But that’s just off the top of my head.

I’m somewhere in the middle, because comments like yours actually reinforce my concerns. A reverse proxy isn’t really doing anything to make you more secure, unless you’re using it for some sort of access control. It hides which ports you’re using, and allows you to encrypt your traffic with TLS… But it doesn’t add any additional security to the services you are exposing.

Maybe if you use it for access control, to add a secondary username/password to the services. But that breaks most legitimate things (apps, mostly) that try to reach the double-password-protected service. Because a user on a web browser may be able to type in two passwords, (one for the reverse proxy, and then one for the service itself) but an app will try to pass that info automatically using headers.

Any vulnerabilities in the services will still become potential attack vectors. Anyone who remembers the Huntarr debacle will know exactly what I’m talking about, because a single service being vulnerable can do a lot of damage. Yes, containerization does a lot to help mitigate damage by excluding access to everything except what you give it. But it won’t completely stop things from going wrong.

The only accurate answer is basically going to be “it depends, we’ll need to see how they’re doing it.” You’re correct that virtualizing an entire system is inefficient. Outright attempting to emulate the entire Xbox would likely be a struggle, even on good hardware. But a translation layer (like WINE) can be extremely efficient, because it allows you to simply translate things from one system to another.

For example, DirectX is a proprietary Microsoft driver, developed for both Xbox and Windows. It’s what allows for things like native Xbox controller support on a Windows PC. It’s also a large part of why Xbox games were fairly straightforward to port to PC, meaning games could release on both the Xbox and PC to hit both markets.

Linux doesn’t natively run DirectX, because it’s proprietary. So anything relying on DirectX will fail if you try to boot it directly on Linux, the same way a Linux program would fail if its dependencies were missing. But Linux can use a translation layer like WINE to translate a program’s DirectX API calls into something that Linux can use.

So a program boots in WINE, and attempts to call DirectX’s API. WINE simply takes those API calls, and translates them to a Linux-native equivalent for your OS to use. Notably, WINE is not emulating the entire Windows OS. It is simply translating the API calls back and forth so the program and Linux can talk to each other. The program likely doesn’t even know it’s running on Linux. It thinks it’s talking to DirectX’s API, because it is getting successful inputs and outputs.

You don’t need to virtualize the entire OS, when you can simply translate from A to B and back again. This can be extremely efficient, because it allows you to boot only what you need, instead of booting the entire Windows OS. If your Linux install only takes up 60% of the resources that Windows would, and then WINE takes up an additional 30%, that means you’re still running 10% faster than native Windows.

God damn it Donut