Well, it’s a clever idea. Discord seems to have intentionally softened its age-verification steps so it can tell regulators, “we’re doing something to protect children,” while still leaving enough wiggle room that technically savvy users can work around it.
But in practice, this only holds if regulators are either inattentive or satisfied with checkbox compliance. If a government is competent and motivated, this approach won’t hold up—and it may even antagonize regulators by looking like bad-faith compliance.
I’ve also heard that some governments are already pushing for much stricter age-verification protocols, precisely because people can bypass weaker checks—for example, by using a webcam with partial face covering to confuse ID/face matching. I can’t name specific vendors, but some providers are responding by deploying stronger liveness checks that are significantly harder to game. And many services are moving age verification into mobile apps, where simple JavaScript-based tricks are less likely to work.
> Discord seems to have intentionally softened its age-verification steps so it can tell regulators, “we’re doing something to protect children,” while still leaving enough wiggle room that technically savvy users can work around it.
...source?
I sincerely doubt that Discord's lawyers advocated for age verification that was hackable by tech savvy users.
It seems more likely that they are trying to balance two things:
1. Age verification requirements
2. Not storing or sending photos of people's (children's) faces
Both of these are very important, legally, to protect the company. It is highly unlikely that anyone in Discord's leadership, let alone compliance, is advocating for backdoors (at least for us.)
Usually in cases like this, there is no source, there can’t be. Long long ago, long enough to be past the statute of limitations, I was involved in a similar regulatory compliance situation. We specifically communicated in such a way that “actual effectiveness” wasn’t talked about, and we set that up with a single, verbal only and without recording, meeting between the team and one of the lawyers.
Point is, these kinds of schemes where internal communication is deliberately hobbled to comply maliciously with requirements while still being completely in the clear as far as any actual recorded evidence goes. And there’s always at least one person piping in with a naïve “source?” as if people would keep recorded evidence of their criminal conspiracies.
Unless the governments come out with a first party national digital ID that can convey age of majority, they had better make themselves happy with a checkbox because nothing else is realistically possible.
A few days ago, Notepad++ got compromised—apparently by a state actor (or a proxy). And now, today, Windows’ built-in Notepad has a fresh CVE. What a life.
At this point, what am I supposed to do other than uninstall Windows completely? No real sandboxing, a mountain of legacy…
telnetd CVE-2026-24061. It's embarrassingly simple exploit but took years to be discovered.
> When telnetd invokes /usr/bin/login, it passes the USER value directly. If an attacker sets USER=-f root and connects using telnet -a or --login, the login process interprets -f root as a flag to bypass authentication, granting immediate root shell access.
Why does every Linux distro under the sun try so hard to protect the garbage under /usr/bin/ and /etc/ when literally the only files that matter to me are in /home, which is a free-for-all?
Because Linux (and other nixes) have their root in multiuser/time-share systems/servers. Protecting the system* from the users was important, and protecting users from other users equally as important. Protecting the user's $HOME from themselves/user-level programs wasn't as much of a concern, the user was assumed to be responsible enough to manage it themselves.
>Why does every Linux distro under the sun try so hard to protect the garbage under /usr/bin/ and /etc
Because a compromised user could infect shared executables and spread the infection. A bit harder to do with etc but for sure possible. The main target would be infecting bash and you are done from the get go.
>when literally the only files that matter to me are in /home, which is a free-for-all?
The home folder's read write is usually restricted to the user. The only scenario where this isn't the case to my knowledge is Ubuntu where others can read it, but this is just a huge flaw in Ubuntu that almost no other distro has.
> when literally the only files that matter to me are in /home, which is a free-for-all?
> The home folder's read write is usually restricted to the user.
Yeah, and that is the point. All user's programs including curl, wget, the web browser, anything else that connects to the network run as the user, and all the user's programs, by default, have access to everything inside ${HOME}.
Most people don't really care if /bin gets obliterated, but they do care dearly when /home/joe/photos/annies-2nd-birthday gets wiped.
Protecting a user from himself is hard. Protecting user from others is easy. Linux is influenced by unix and a lot of installations are servers. Where most programs run under their own accounts.
You can always have two user accounts: oblio and unsafe-oblio anf have a shared folder between the two for transferring files. Or invest into some backup software.
Just make another user bro. If you can't even create a user to run a program you distrust, the issue is not that windows doesn't provide sandboxes, it's that you don't use them
And no, it's not "a lot of work" it's the bare minimum
Yet 99% of the planet doesn't do "the bare minimum", bro.
We have supposedly all the smartest minds in the world working in tech and they haven't been able to create a simple, cheap, reliable cross platform solution for user data protection, backup and restore.
Yes, because the users are in fact the problem. The options are either to trust the user to make decisions (and technically illiterate users will screw things up for themselves), or lock down the system so that the user isn't allowed to do anything the corporate overlord doesn't let them. There is no middle ground.
There is one where desktops are slowly being remade, which Windows and MacOS are failing at. Have application repositories, but open ones like Debian or Linux in general, so that application developers can publish and don't ask for a cut of every sale. Sandbox all new desktop applications over the years and publish long roadmaps until everything is sandboxed, say, in 2035.
Provide more education and guidance for users and more corporate controls.
If they would have really started to do this in 2005, we would have been there by now. Instead we get more UI toolkits and more UI refreshes and AI everywhere.
I rolled out a home-made backup script in Powershell - just a wrapper around wbadmin that backs up an entire system image and the a standard "Backup and Restore" backup on an external disk once I plugged it in.
Yeah, yeah. It's not purely about installing apps. It's primarily about sandboxing them.
I always thought Americans were "nanny state this, nanny state that". Doesn't this also apply to huge state sized corporations mandating a cut of every app sold and forcing everyone to only install apps from them?
Linux /home is far from a free for all. flatpak, landlock, selinux, podman, firejail, apparmor, and systemd sandboxing all exist and can and do apply additional restrictions under /home
> At this point, what am I supposed to do other than uninstall Windows completely?
Uninstall Windows completely 4 years ago when Windows 11 was released heralding in a new era of absolutely insane, self-destructive, unnecessary and unwanted shit?
There is no valid excuse for this vulnerability. It's existence is a category error that's only possible because Microsoft has completely jumped the shark. Continuing to use /any/ of their products is a choice to accept pure insanity as a default.
That was a CCP group compromising the Notepad++'s underlying hosting provider; not really much to be done there aside from switching hosting providers. The update validation was also improved, and there's also scoop if you don't trust the built-in updater. Fortunately the attack was narrowly targeted and the IOCs are known.
It was not compromised a few days ago, that's just when the attack was disclosed. The actual compromise and exploitation happened months ago for several weeks.
- Windows Sandbox (consumer-level sandbox)
- Creating a separate User (User folders are permission locked to their user by default, system binaries cannot be modified without admin access)
- HyperV (VM hypervisor)
- Edge Browsers
Don't get me wrong MSFT quality is dropping steeply, but this is still a strong point. For comparision, on Ubuntu, user folder by default can be read by all users.
>Creating a separate User (User folders are permission locked to their user by default, system binaries cannot be modified without admin access)
Common practice, and even encouraged by Windows itself, is having the administrator account be the only account. This misuse is a very common thread in Windows systems, and security breaches alike.
Windows has garbage defaults, but if you read through their documentation on enterprise architecture they definitely do not recommend having admin be the only account. They do in fact encourage separate accounts, multiple level of privileges with login restrictions across different types of machines, etc.
Many Linux distros are also guilty of this, disabling the root account by default and having the only user have sudo privileges, just like Windows.
Yes, however much more can be done in the user's own directory on Unix systems. Needing sudo raises some eyebrows, whereas most Windows users don't necessarily understand UAC, and almost never think twice about pressing "Yes" on the popups, which are seen more as an annoyance than something critical for safety. Some even completely disable UAC.
> Common practice, and even encouraged by Windows itself, is having the administrator account be the only account.
This hasn't been true since Vista. Kind of even before that with XP, it really showcased using multiple accounts to home users with a much more stylized user selection screen.
Sorry, the era of free communication is fading. Across middle powers, developed countries, and increasingly North America, governments are tightening the rules around online speech—and often jawboning platforms into going further than the law strictly requires. The list of examples is so long I can’t even begin to type them all.
Instead of "free communication" I would say "free large public social media", because without going all DPRK, there's no stopping people from using the internet, a means of free communication.
I tested it a bit yesterday, and it looks good—at least from a structural perspective. Separating the LLM invocation from the apply step is a great idea. This isn’t meant to replace our previous deterministic GitHub Actions workflow; rather, it enables automation with broader possibilities while keeping LLM usage safer.
Also, a reminder: if you run Codex/Claude Code/whatever directly inside a GitHub Action without strong guardrails , you risk leaking credentials or performing unsafe write actions.
From my years of iOS development—and based on https://xcodereleases.com typically ships two major Xcode updates each year:
- X.0 (September): bumps Swift, SDK versions, etc. It also tends to have a noticeably longer beta cycle than other releases.
- X.3 or X.4 (around March): bumps Swift again and raises the minimum required macOS version.
Other releases in between are usually smaller updates that add features or fix bugs, but they don’t involve major toolchain-level or fundamental changes.
Today’s release doesn’t bump the Swift version, which suggests the core toolchain is essentially the same as Xcode 26.2—so it makes sense that the minimum macOS version wasn’t raised either.
https://xcodereleases.com hasn’t shown anything since last December, so I assumed Apple had taken a breather from Xcode development, but they released an RC build today?
Anyway, the Swift version seems unchanged (6.2.3), so is this update mainly for the so-called “Coding Intelligence” features?
In any case, Xcode isn’t my favorite IDE—it’s too slow and feels quite different from other major IDEs—so I probably won’t use it for day-to-day coding (though it’s fine for building and debugging).
I think a large part of this comes from the fact that the expressiveness of LLVM’s C++ APIs does not translate well into a “plain old C” style interface. Many of the abstractions and extension points are simply awkward or impractical to expose in C.
On top of that, there is little incentive for contributors to invest in the C API: most LLVM users and developers interact with the C++ API directly, so new features and options tend to be added there first, and often exclusively. As a result, the C API inevitably lags behind and remains a second-class citizen.
Why not take the best of both worlds?
Use pre-commit hooks for client-side validation, and run the same checks in CI as well.
I’ve been using this setup for years without any issues.
One key requirement in my setup is that every hook is hermetic and idempotent. I don’t use Rust in production, so I can’t comment on it in depth, but for most other languages—from clang-format to swift-format—I always download precompiled binaries from trusted sources (for example, the team’s S3 storage). This ensures that the tools run in a controlled environment and consistently produce the same results.
Suppressing car usage isn’t about punishing individuals; it’s about correcting urban systems that made car dependency the default in the first place. The Lewis–Mogridge position is well established, and making driving less convenient while improving proximity and alternatives is a core principle of sustainable urban planning.
A lifestyle that requires burning large amounts of fuel just to buy groceries, or maintaining water-intensive lawns at scale, only works under very specific economic and environmental conditions. As those conditions disappear, cities have to adapt—even if the cultural shift feels uncomfortable at first.
I'll take my sprawling suburb with a big yard to grow ample food any day over a densely populated and carefully planned cityscape. With the advent of cheaper solar panels and electric vehicles, it's not a big issue.
While reading the README and related documentation, I noticed that Samsung Exynos NPU acceleration was listed, which immediately caught my attention. According to
https://docs.pytorch.org/executorch/main/backends/samsung/sa..., Samsung has finally built and released an NPU SDK—so I followed the link to check it out.
Unfortunately, the experience was disappointing.
The so-called “version 1.0” SDK is available only for Ubuntu 22.04 / 20.04. There is no release date information per version, nor any visible roadmap. Even worse, downloading the SDK requires logging in. The product description page itself https://soc-developer.semiconductor.samsung.com/global/devel... does contain explanations, but they are provided almost entirely as images rather than text—presented in a style more reminiscent of corporate PR material than developer-facing technical documentation.
This is, regrettably, very typical of Samsung’s software support: opaque documentation, gated access, and little consideration for external developers. At this point, it is hard not to conclude that Exynos remains a poor choice, regardless of its theoretical hardware capabilities.
For comparison, Qualcomm and MediaTek actively collaborate with existing ecosystems, and their SDKs are generally available without artificial barriers. As a concrete example, see how LiteRT distributes its artifacts and references in this commit:
https://github.com/google-ai-edge/LiteRT/commit/eaf7d635e1bc...
But in practice, this only holds if regulators are either inattentive or satisfied with checkbox compliance. If a government is competent and motivated, this approach won’t hold up—and it may even antagonize regulators by looking like bad-faith compliance.
I’ve also heard that some governments are already pushing for much stricter age-verification protocols, precisely because people can bypass weaker checks—for example, by using a webcam with partial face covering to confuse ID/face matching. I can’t name specific vendors, but some providers are responding by deploying stronger liveness checks that are significantly harder to game. And many services are moving age verification into mobile apps, where simple JavaScript-based tricks are less likely to work.
reply