This is what it looks like when they try to police the software that’s NOT from their store (or their partners).
All the Google-verified malware that infests Google’s marketplace will continue to be a problematic vector after this change. But this change will put obstacles in my attempts to install safe alternatives that are free of malware and not part of Google’s junkyard or spyware full of anti-features.
Yes, sorry I had a busy month :P
Yeah, that was my point… that’s why I was saying that if a kid is smart enough to to set up a VM like that they are smart enough to find alternative/easy out-of-the-box methods… the “using someone else’s login” in particular is one of the points I made earlier.
This is why I think the control should be local, and with the parents being the ones responsible. Relying on third party authentication and expecting the remote services to be able to determine the age is not gonna work.
It’s going to be an arm race and the most dedicated kids, not necessarily the smartest or wisest, will figure it out. Eventually they’ll get the concepts behind the tools they mindlessly use until then, eventually find much better tools allowing them to bypass a lot more restrictions.
Well… it depends on how do you define “smart” …but to me, that kind of dedication and resourcefulness is already showing problem-solving skills, regardless of whether they “get the concepts” (many adults don’t fully understand the tools they use either).
I don’t see how a browser will be able to prevent this kind of usage
In Firefox, you can disable websockets (and most other features or about:config settings, but the website you linked uses websockets) through a policy.json setting writable only by root, so it wouldn’t be possible for a user without root permissions to change it.
only understand the concept and know where to find a VM.
That’s already smarter than most of my relatives.
I’d argue that controlling / monitoring where a kid goes should already be responsibility of the parent.
If it’s all in the browser then the unprivileged user is at the mercy of whatever rules the installed browser establishes for allowing them access to. So it’s a battle between the parent (helped by the OS) being smarter at setting up local restrictions / monitoring history and the kid being smart enough to break them / act undetected.
I think the idea here would be that the OS would be able to tell the browser (or any app) that the user is only allowed content of a particular target age group, and then the browser (or whichever app) would apply any appropriate restrictions (which could include restricting virtualization primitives like WebVM, other js APIs or even network-level filtering if that’s what it takes).
You can also advocate for making use of the “guest wifi AP” many routers already provide to ensure the access to the internet for their kids is done in an allowlist basis. To the point that the kid would have to be “smart enough” to break through the WPA encryption of the main wifi access point (or find out some other social engineering way to get access to that wifi) in order to have fully free access to the internet and visit websites that allow them to circumvent age restrictions.
I mean, ultimately it can always be worked around… even if you were to add stronger forms of identification, a kid can take the parents card / ID / DNA sample / whatever when they are distracted and verify themselves. If a kid is smart enough to set up a VM like that they are smart enough to deceive adults. Teenagers have been finding easy ways to get to forbidden stuff for centuries.
I’d much prefer if the source of trust is in the local device, in the OS, that is responsibility of the family to control, and not on some remote third party service offered by some organization in who knows where with connections with who knows who. If parents don’t properly limit the local user account of their kids, or restrict access to the places they don’t want, it’s their responsibility. Set up proxies, blockers and lock the OS locally, but don’t mess up the internet for the rest of us.
I don’t think we would be throwing USB-C away completelly, because it even became mandated by law in EU with the goal of trying to slow down the rate at which people generate trash by getting new cables and power bricks for every new generation of connectors.
But I agree that at the very least there should be a clear labeling mandated by consumer protection laws as well… it’s a nightmare and a scenario that opens the door for a lot of scams… this is even made worse by the fact that nowadays you can even have malicious software running inside of the connector of a cable plugged into an extremely capable port without realizing it, messing up with your device even though the only thing you wanted was to charge it.
I always saw I2P as a more modern and distributed onion-routing alternative to Tor.
The thing is that people are used to making use of Tor in different ways than the way they use I2P, but you can also have outproxies (ie. exit nodes/relays) in I2P the same way as in Tor… and you can also host a service inside the Tor network without relying on an exit node, like in I2P. It’s just that people only seem to want to host exit nodes for Tor and not so much for I2P, this led to internal communications in I2P being more common (which is a good thing), whereas in Tor it’s common to use it for anonymous access to the clearnet (which strains the network and causes chokepoints, specially with big downloads or torrent sharing). That’s just a matter of usage, not capability.
Note that flatpaks are using systemd’s sd_id128_get_machine_app_specific API, which generates an app-specific id that’s derived from the original machine-id.
The app-specific id will be unique per-app so it won’t be shared between different apps / flatpaks. The apps can’t know the original machine-id, but the id they get would still be the same on every restart of the app and in theory does not prevent different sessions within the same app to be fingerprinted as coming from the same user.