I have seen things approved by those sort of organizations that were extremely dangerous, such as a listed fire alarm that when installed has a significant chance of becoming silently deactivated.
With that said, it can be even worse when it isn't listed.
The newer Android version could simply give empty data (for example, location is 0,0 latitude longitude, there are no visible WiFi networks), when the permission is missing and an app on the old SDK version requests it.
Of course, they don't like this because then apps can't easily refuse to work if not allowed to spy.
Phone companies are required to make sure 911 works on their phones. Random people on the internet aren't required to make sure 911 works on random apps, even if they look like phones.
It runs just fine at 165 hz for me. Given that xrandr and CRTs have been around for a while, and both have supported high refresh rates for a long while, something seems fishy here. Something is probably at fault, but it's not X11.
It is able to output the high Hz to the display, but the desktop (like window decorations and window dragging) remains at 60 Hz, it looks like. Individual windows can still successfully render at high Hz. Contrast this with Wayland where I've always seen everything go at the high speed, even if I'm using the same DE in both (like Gnome Wayland and Gnome Xorg on the same hardware).
> Why would a player knowingly choose to play on matchmaking that is advertising no anti-cheat?
My understanding of the proposal is that it advertises no invasive anticheat (meaning mostly rootkit/kernel anticheat). So, the value proposition is anyone who doesn't want a rootkit on their computer. This could be due to anything from security concerns to desiring (more) meaningful ownership of one's devices.
There is a lot of merit to this view, but there is also a major problem: rules like this make it substantially harder to start a new business due to increasing overhead and complexity, which is bad for everyone long term. Such comparatively more complex and burdensome regulation is why so many (but not all) startups go to America or Israel instead of Europe.
To address this I prefer ultra low friction and ultra low cost regulations over complex and performative schemes. For example, GDPR requires the appointment of a "data protection officer" in some cases, which is mostly just an extra fee for small companies. Instead, it should only regulate the rights (such as to be forgotton, etc.). Appointing such an officer is mostly performative.
The most important thing in my view is that both parties are aware of their rights and responsibilities. If the plain text of the warranty agreement specifies replacement, replacement should be required. If the business doesn't want to assume the risk, that's fine, but the warranty should then clearly and explicitly stipulate replacement or refund at the retailer's discretion, in such a way that an average consumer would be expected to see and understand this (i.e., no "replacement" in large, friendly letters and "or refund" buried in fine print or legalese, or leaving out specific details to be filled in by default provisions when such provisions favor the retailer).
I don't think that it's that simple. I'm advocating for regulations to consider the burden on small businesses and aggressively minimize it.
Another example than the GDPR example that I previously gave is beneficial owner registration. The US government tried to pass a law requiring every corporate entity to state who the beneficial owners are, to reduce tax evasion. In principle, this sounds great, but the vast majority of corporate entities are small businesses with natural persons owners, so that beneficial owner is already obvious. So, they should have added such an exception to filing requirements. Even better would be to just work with states to put beneficial owner fields on the existing state incorporation forms, instead of creating a new form, that are optional to fill in when the owner is a natural person. That way, we reduce tax evasion with the better data, but we aren't relying on a random electrician in Ohio or a tech nerd startup founder in California to be aware of these requirements. While one form isn't a big deal on its own, the whole system is like this, and it adds up.
> even a really cool library that makes Rust do this.
The first library that comes to mind when I think of this is `serde` with `#[derive(Serialize, Deserialize)]`, but that gives persistence-format output as you describe is preferable to the former case. I usually use it with JSON.
Maybe a little bit. But serde works with JSON (among other formats), and you can use it to read and write JSON that interoperates with other libraries and languages just fine. Kind of like how SQLAlchemy looks kind of like you’re writing normal Python code, but it interoperates with SQL.
I know "serde" is a take on "codec" but *rewrite* was right there! Also, as long as I'm whinging about naming? 'print' and 'parse' are five letter p words in a bidirectional relationship. Oh! Oh! push, peek, poke, ... pull! It even makes more sense than pop! And it's four letters!
What, exactly, is sandboxed Google play prevented from accessing? Can I feed it a fake location or disable location access? Is it prevented from running in the background 24/7? Can I force it and just it through a VPN? Or is it just blocked from accessing apps and files that aren't in the sandbox? There are many such questions and all could be considered "sandbox".
Sandboxed Google Play receives no special access at all, so you can deny it all permissions if you want, but you should grant network (and maybe notifications) permission for it to actually function.
Well that's a bit misleading answer. Some apps refuse to work if G services are disabled, so they clearly communicate with them. It would be nice to know what exactly G learned about the phone through those "sandboxed" apps.
It's an Android service. But unlike on regular Android where Google play services have hard-coded special permissions, on Graphene it is an ordinary android service with all the same strict rules applying to it, as to any other service you could write.
So an application of course can use other android services if it declared that, that's why it can see whether it's running or not. But you are in full control whether google play services is installed, and what it can use.
Of course this may break certain apps (Google maps location sharing will probably not work with the location permission denied for play services), which may or may not degrade gracefully.
Once this or something like it becomes widespread, won't sophisticated attackers simply test their attacks against this? So, for example, if it checks for `rm` invocations, just implemented the functionally of `rm` in the malware, or if it checks for exfiltration of data, then shell out to curl to do that in a different process.
If you think of making it so robust that this is impossible, you're just describing a container, which we already have.
The container comparison misses where these attacks actually happen. Containers limit what code can do at runtime. We flag what code
intends to do before it ever runs. These are complementary. A container won't stop a postinstall script from reading ~/.ssh/id_rsa and posting it to an
attacker's server if your CI environment has network access and a mounted home directory — which most do.
Yes sophisticated attackers adapt. But the current state of npm supply chain attacks is that most don't even try to evade — because nobody's looking at
the code. Every major attack in 2025 used the same playbook: credential theft + network exfil + install script abuse. Raising the floor from "zero analysis"
to "26 behavioral detectors with cross-signal correlation" eliminates the entire class of low effort attacks and forces the rest into increasingly
constrained patterns.
With that said, it can be even worse when it isn't listed.
reply