It requires a positive action from the application developer to include GrapheneOS's keys as well as Google's keys. So this is a deliberate positive step, rather than a default.
Only if they are using hardware key attestation. From what I've read elsewhere it looks like it was never broken so maybe they never went that far before.
Makes sense for them to support this given their scale. I wouldn't be surprised if GrapheneOS secures another big Android OEM vendor (after Motorola Mobility) and the user base of the OS quickly grows from its current 400k+ to millions.
I've been looking into GrapheneOS as a longtime Pixel user who is thinking of becoming a bit more security conscious. But, looking around at its current state RE: RCS and camera apps, I think it makes the most sense to stick with stock Android.
I also have a really niche feature I rely on daily (letting me "wifi call" from one sim over the data line of the other sim), and it's really hard to tell if GrapheneOS supports it.
If I can grab my old pixel that's stored in a box at my parents' house on another continent I might give it a try, but GrapheneOS really doesn't seem ready to be a daily driver.
What's the issue with RCS and camera apps? RCS works (from what i've heard) and you get the same image quality as on stock if you install the pixel camera app.
Not sure about that other feature you mentioned, but you can always revert back to stock if you don't like GOS. Restoring a backup is easier than it's ever been nowadays :-).
My understanding was that you have to install google messages to get RCS to work and on google's end it gets finicky about device ids. I read a couple blogs where people found RCS to be really unstable on GrapheneOS even with a couple workarounds.
If I'm going to have to install a bunch of google products onto my phone anyways, I don't buy the benefits as much.
I also had a recent experience being shaken down by a border guard entering Australia, and if he'd asked to go through my phone, explaining that I'm running a weird privacy focused OS he's never seen before seems like it would be a great way to increase my chances of spending a night in airport jail and being put on the next flight to North America. I don't really have anything to hide and appearing like I have things to hide could seriously inconvenience my life. Barring a tourist from entering a country has a very low bar of evidence.
Edit: Also the backup restoration is a bit more of a mess for me right now for the same reason I need the dual sim feature. I've got an American esim that's difficult to reactivate without being in America.
Yeah, it's not really a global "I have nothing to hide from any government whatsoever" but more of a "I don't have chat logs about overstaying or smuggling," which is what they're likely to implicitly assume if they've hit the point of searching your phone and you've got some special phone they can't search.
In my home country I would take a principled stance and hire a lawyer, but in the particular case of border crossings to a country you're not a citizen of, seeming like you have something to hide can easily lead to them denying you entry.
Basically all of Graphene's RCS issues have been fixed[0]. Additionally, your stance seems somewhat unusual - GrapheneOS isn't only meant to be used by people that have "something to hide". As for explaining it to border guard - it's just Android - if you're unlocking your phone for them anyway, they definitely shouldn't care about what flavor of Android you're running, whether it's LineageOS, ColorOS, GrapheneOS, etc.
Of course, there might be more nuance to your situation than I am privy to, but almost everyone travels, and I'd heavily hope that being stopped at the border isn't the reason keeping them away from Graphene.
There is little difference these days between the government spying on you and your own device spying on you. The difference is one only cares if you do something wrong, the other one will steal pilfer and sell your data despite already purchasing a product.
So the issue with RCS is that google just this last year made the move from their internal implementation of E2EE for RCS to the standard implementation based on MLS (now that the standard impl is actually viable).
They did this quietly in the background and most people didn't notice but in doing so they released new system/OS level services and started relying on those. And notably they did this rollout staggered such that only some people got it and some didn't which made everything way more confusing.
GrapheneOS has a bunch of security hardening to restrict crosstalk between apps and services and the assumptions GOS made and the assumptions Google made about how services and apps should be allowed to interact were disjoint. That mismatch in assumptions broke things for a while. And the lack of clear communication from Google about this change combined with various anti-spam/rate limiting issues (Gmessages kept trying to register not expecting to fail and kept slamming the servers which looked like spam and triggered exponential backoff retries) compounded together to render RCS broken for a few weeks during that migration.
Notably this was also broken for basically every other non-google/non-samsung android provider for a while as well due to how poorly the migration was communicated by google.
Then not long after that was resolved graphene changed how they handled their sandboxing to make it less brittle to google changes and since then there's not been much in the way of issues.
The only issue with RCS since then has been a brief break in RCS (~1-2 days) about a month ago due to what was essentially an update to Google's services putting the graphene sandbox briefly out of sync. This was fixed almost immediately on the alpha release channel and just took ~48 hours to move through the alpha->beta->stable pipeline.
From this point on now that RCS is more or less all "standard" stuff now you shouldn't see any major breakages. The only situation where you might see one would be when android inevitably opens up RCS outside of the google services walled garden but even then you should be able to continue relying on the google services version until the non-google version is stable.
> So the issue with RCS is that google just this last year made the move from their internal implementation of E2EE for RCS to the standard implementation based on MLS (now that the standard impl is actually viable).
> They did this quietly in the background and most people didn't notice but in doing so they released new system/OS level services and started relying on those. And notably they did this rollout staggered such that only some people got it and some didn't which made everything way more confusing.
> From this point on now that RCS is more or less all "standard" stuff now you shouldn't see any major breakages. The only situation where you might see one would be when android inevitably opens up RCS outside of the google services walled garden but even then you should be able to continue relying on the google services version until the non-google version is stable.
Is there anywhere public that there are writeups or roadmaps about this? I'm particularly curious about whether there will ever be an API for third-party clients.
What's left in terms of meaningful technical barriers, that would prevent this all from being baked into Android instead of requiring Play Services?
Tbh I have no idea. I kept up with it on the GrapheneOS discord and I think GOS put out bluesky/mastodon posts about it at one point.
> What's left in terms of meaningful technical barriers, that would prevent this all from being baked into Android instead of requiring Play Services?
Well now I think the last major barrier is cleared (which was E2EE being nonstandard). Currently the on-device infra is very google-oriented but there is support for non-google-jibe RCS but it still requires google, etc to explicitly opt-in apps to get access to the APIs on device.
A big part of this IMHO is google refusing to give up their moat but they may finally get it into AOSP at some point.
If they don't at this point I think the only way it'll happen is if the EU forces their hand (which they hopefully will do).
> GrapheneOS really doesn't seem ready to be a daily driver.
As someone who has used it exclusively as their mobile OS for three years, it is absolutely ready. Does that mean it's perfect or bug-free? No, but nothing is.
Been using GrapheneOS as daily driver for 4 years on three pixels. Problems only start when banking apps start actively sabotaging it by pretending the phone is rooted etc. Normal apps work normally and you get way more control over them. I'll never go back to stock or worse than stock (Samsung) as long as GrapheneOS is around even if they get rid of all security aspects (which of course they won't, I'm just saying security is not the only selling point, de-googling is a big one too.. I didn't de-google but I sure like having the option)
Does anyone know anymore on that front? For months, I've regularly looked up whether there were any news, only to find nothing besides the original announcement. No ETA, no upcoming devices to be supported, heck, on the Graphene side, their own webpages make nary a mention. Would buy a Razr 70 Ultra + Clicks the second that is confirmed, but for something that was so publicly announced months ago, this seems very shaky...
Roblox has a long history of not supporting Linux, and the game was rendered unplayable for many years. In 2022 it became possible following some Wine patches, but then they began to implement a kernel-level anticheat. Roblox initially committed to keeping Wine working but suddenly went back on that and blocked it without notice. Today, the last remaining way is through running the Android version of the game through an Android container or emulator. The TFA is about stopping this exact method of running the game though...
My mistake, I just assumed their Byfron anti-cheat is kernel level because that's the most common reason why anticheats take issue with Wine. If their anti-cheat operates entirely in usermode, then their decision to block Wine is even more baffling to me.
It is not kernel level, they use a number of pretty fancy user mode tricks to prevent people messing with the game.
They encrypt every page and register an exception handler that decrypts the page when a fault is reached to keep memory secure. They do cache timing checks to see if a page was recently in the working set outside of the expected control flow and will flag you if you fail the check too many times because it indicates tampering.
While the page decryption trick should work in Wine just fine (ZeroIT Lab Theia does that too, right?), I don’t remember if Wine provides workingset info like Windows.
Yes, Wine was (EDIT: partially) compatible with the Roblox anti-cheat, and there was a period in time where Roblox with its anti-cheat ran on Wine. Eventually, however, a decision was made to block Wine.
EDIT It looks like the Roblox anti-cheat devs themselves explained why Wine was blocked:
Yes, it does. Wine lets you register a VEH. They do other stuff to prevent Wine and virtual machines in general that I am not fully aware of.
Even then it's just a fancy party trick, you can suspend the process call the decryption function enumerating all the pages and take a full dump to get the binary
FYI; Theia is a very bad product. It absolutely tanks binary performance and does little to prevent a moderately competent engineer from cheating in your game.
Are the other Zero IT Lab products like their code virtualizer of similar quality to Theia? My only exposure has been that one RE//verse presentation and shitposts on UC.
I can't speak for all the products, but from what I have heard it's pretty bad. Pay close attention to the shitposts on UC, they regularly get taken down but have some interesting information in them.
Fortnite doesn't actively oppose Linux, compared to Roblox cheating which keeps a lot of logic on the server, cheating on Fortnite on the client has a more bigger impact.
Unfortunately there's no way to properly ship a kernel level anti-cheat on Linux right now and none of the mainstream distros ship with any kind of attestation or OS verification out the box like Android does.
SteamOS could change it here though, we'll see. I don't have much hope given the thing doesn't even use Secure Boot by default.
Kernel level anti-cheat seems to be ultimately ineffective. I've seen this with my own eyes with backend data when I worked for a company with a moderately successful shooter. Kernel level anti-cheat is serving a similar function to something like EAC these days, which basically just keeps the lazy people out. With any decently sufficient backend data analysis, you catch these folks just as easy.
I am of the belief that if you cannot completely control the environment, like a user's physical hardware, you're fighting a losing battle. Forcing them to install spyware is, in my opinion, just marketing for your competitive shooter and too invasive for the perceived gain.
> With any decently sufficient backend data analysis, you catch these folks just as easy.
No you can't. Using server side analysis of behaviour will always get false positives, especially as ML networks are getting better and better at reproducing normal player behaviour.
Your server side logic can't detect wall hacks, ESPs etc.
> which basically just keeps the lazy people out
That's better than nothing. Cheating will always be possible (see DMA devices), but as long as you make it reasonably hard to put most people off it, that's a success.
> cannot completely control the environment
But applications should be able to attest the environment is not modified, which is what desktop Linux lacks. Windows, macOS and Android do have methods to do this.
> like a user's physical hardware, you're fighting a losing battle
If you think there aren't hackers on console, you're deluded.
> Your server side logic can't detect wall hacks, ESPs etc.
Correct, neither do the invasive tools. You can get these things without modifying memory or the game, which is the majority of what the kernel level stuff keeps on eye on.
> especially as ML networks are getting better and better at reproducing normal player behaviour.
True, there is no answer here. Again, if the provider is this sophisticated, then EAC isn't helping here. Then it is just the usual cat and mouse, and the kernel level is moot.
> But applications should be able to attest the environment is not modified, which is what desktop Linux lacks. Windows, macOS and Android do have methods to do this.
Also true, but they are frequently circumvented anyway, so ultimately you're at the same level of Linux from a functional standpoint.
I know you're probably thinking that we should just hit all vectors, and I agree to an extent. The problem is that those who charge for cheats easily circumvent (yes, easily, they are literally within 24hrs sometimes of adjusting to modifications by anti-cheat software) the methods you're claiming help. While the data you get from users on the server end doesn't paint a whole picture, it is the source of truth of what the game decided happened, so it becomes the only thing you can rely on. I know folks who specialize in this area who basically believe that online competitive shooters are basically lost and it isn't worth the investment to fight it.
I am of the opinion we should just go back to dedicated servers and have self moderation. Sure, you get false positives if the owner or their mods suck at the game, but at least the players can do something about it. CS2 is a fucking nightmare at the moment.
Doesn't roblox use an anticheat that prevents the game client from running on linux? I thought nowadays the way to "run roblox on linux" involved using an android emulator.
Native Roblox has blocked Linux for 3 years, and games on it (especially PvP ones) can and do require Android remote attestation which Sober doesn't implement. It wouldn't surprise me if Graphene can't play those games as well.
Roblox is a platform. Fortnite is still primarily one game.
They're 60% of the North American game's industry revenue growth. Their rival is negative stock market sentiment. They need to pull out all the stops to prove growth.
"Support" seems a bit strong here. the statment has more of a "known to work with" than a whole lot of direct support effort, also you have to have a locked bootloader, here's the relevant statement.
> For power-users: Are all third-party ROMs blocked?
No. We currently support GrapheneOS when the bootloader is locked. We may support other third-party ROMs if:
They do not break the AOSP security model,
They support installation with a locked bootloader,
They properly configure and publish self-signed verified boot keys for their ROM, and
They promptly update to the latest AOSP patch level. We frequently update minimum operating system security requirements.
If ROMs do not consistently adhere to the standards above, we will remove them from the set of supported verified boot keys
It would be accurate to call it official support if it means they have set up their app with the privacy-friendly Android Hardware Attestation API on GrapheneOS.
Unless I'm wrong and they just support Basic Play Integrity or a lower one, I don't know much about that. But those would require play services. I could test to see if it works without play services which would indicate they are using the Hardware Attestation API to check the bootloader lock.
Don't get too excited, this still goes against the basic freedom to own the devices you've paid for.
Remote attestation is still there and only official builds of GrapheneOS are supported. While this is marginally better than being tied to a build from an advertising company, you're still out of luck if you want to build the OS yourself.
It's Roblox's responsibility to police their platform and the vast majority of bad actors use mainstream operating systems and mainstream services like Discord or Telegram. Clearly lack of privacy does not prevent crime as we can see on Telegram and Discord which are both not E2EE and yet have far more crime taking place then on encrypted alternatives.
Good for all of them. Attestation is a terrible infringement of rights, and both Graphene's approach (trying to make it a more open ecosystem) and the other one (refusing to participate/trying to destroy the ecosystem) are viable responses to it.
ROM is to android what distro is to Linux. The term is used correctly here. An android ROM could refer to the stock OS, GrapheneOS, LineageOS, Pixel Experience, etc.
With immutable distros (see bootc or systemd-sysupgrade) the operating system itself is also only just a read only file system. Does that count as ROM too?
Might as well just use the term "Android distr(o|ibution)" whenever talking about it. I think its also more self-explanatory vs "Android ROM" if you never heard of them before.
All the third party roms I know offer sign builds and remote attestation, GrapheneOS isn't special here, it's just that usually app developers just ignore the signatures
The announcement is very funny in that regard, devices with last update in 2023 like the Galaxy S10 are still ok despite having every root exploit under the sun available but god forbid you want to update it to the last version
LineageOS has no AVB support at all unfortunately and most devices don't allow using verified boot with custom keys anyways. With GrapheneOS they can just add GrapheneOS public keys (https://grapheneos.org/attestation.json).
For LOS Roblox would have to disable hardware attestation completely, which means you can easily just add extra modules such as a setuid binary which makes cheating easy (at least on the client side, you'd have to rely completely on server side anti cheating)
While that is true the bigger issue is that LineageOS doesn't qualify for "They do not break the AOSP security model" as it allows users to get root access without modifying the OS. So even if there was verified boot Roblox would still block it.
For me this means that Roblox's requirements are fundamentally incompatible with any device I would want to use as they want to restrict my access and I want full access.
This is a really interesting signal tbh.
While it sounds like it already works on GrapheneOS having a corporation come out and say they won't go out of their way to break it is quite unusual.
It requires a positive action from the application developer to include GrapheneOS's keys as well as Google's keys. So this is a deliberate positive step, rather than a default.
Only if they are using hardware key attestation. From what I've read elsewhere it looks like it was never broken so maybe they never went that far before.
Makes sense for them to support this given their scale. I wouldn't be surprised if GrapheneOS secures another big Android OEM vendor (after Motorola Mobility) and the user base of the OS quickly grows from its current 400k+ to millions.
I've been looking into GrapheneOS as a longtime Pixel user who is thinking of becoming a bit more security conscious. But, looking around at its current state RE: RCS and camera apps, I think it makes the most sense to stick with stock Android.
I also have a really niche feature I rely on daily (letting me "wifi call" from one sim over the data line of the other sim), and it's really hard to tell if GrapheneOS supports it.
If I can grab my old pixel that's stored in a box at my parents' house on another continent I might give it a try, but GrapheneOS really doesn't seem ready to be a daily driver.
What's the issue with RCS and camera apps? RCS works (from what i've heard) and you get the same image quality as on stock if you install the pixel camera app.
Not sure about that other feature you mentioned, but you can always revert back to stock if you don't like GOS. Restoring a backup is easier than it's ever been nowadays :-).
My understanding was that you have to install google messages to get RCS to work and on google's end it gets finicky about device ids. I read a couple blogs where people found RCS to be really unstable on GrapheneOS even with a couple workarounds.
If I'm going to have to install a bunch of google products onto my phone anyways, I don't buy the benefits as much.
I also had a recent experience being shaken down by a border guard entering Australia, and if he'd asked to go through my phone, explaining that I'm running a weird privacy focused OS he's never seen before seems like it would be a great way to increase my chances of spending a night in airport jail and being put on the next flight to North America. I don't really have anything to hide and appearing like I have things to hide could seriously inconvenience my life. Barring a tourist from entering a country has a very low bar of evidence.
Edit: Also the backup restoration is a bit more of a mess for me right now for the same reason I need the dual sim feature. I've got an American esim that's difficult to reactivate without being in America.
> I don't really have anything to hide
While I understand your position, I cannot help myself from posting this response with the hope that more people will consider their own "I have nothing to hide" positions. See https://moxie.org/2013/06/12/we-should-all-have-something-to...
edit: Linking to original HN discussion about this article - https://news.ycombinator.com/item?id=5869394
Great links.
Yeah, it's not really a global "I have nothing to hide from any government whatsoever" but more of a "I don't have chat logs about overstaying or smuggling," which is what they're likely to implicitly assume if they've hit the point of searching your phone and you've got some special phone they can't search.
In my home country I would take a principled stance and hire a lawyer, but in the particular case of border crossings to a country you're not a citizen of, seeming like you have something to hide can easily lead to them denying you entry.
Basically all of Graphene's RCS issues have been fixed[0]. Additionally, your stance seems somewhat unusual - GrapheneOS isn't only meant to be used by people that have "something to hide". As for explaining it to border guard - it's just Android - if you're unlocking your phone for them anyway, they definitely shouldn't care about what flavor of Android you're running, whether it's LineageOS, ColorOS, GrapheneOS, etc.
Of course, there might be more nuance to your situation than I am privy to, but almost everyone travels, and I'd heavily hope that being stopped at the border isn't the reason keeping them away from Graphene.
[0] stickied comment on https://www.reddit.com/r/GrapheneOS/comments/1pceh1t/am_i_th...
There is little difference these days between the government spying on you and your own device spying on you. The difference is one only cares if you do something wrong, the other one will steal pilfer and sell your data despite already purchasing a product.
RCS is unstable on iOS, too,
for the same reasons SMS has always been unstable.
It’s the nature of the protocol, unfortunately.
Maybe I should've specified: I have seen many anecdotes of RCS being substantially more unreliable on GrapheneOS than it is on stock Android.
So the issue with RCS is that google just this last year made the move from their internal implementation of E2EE for RCS to the standard implementation based on MLS (now that the standard impl is actually viable).
They did this quietly in the background and most people didn't notice but in doing so they released new system/OS level services and started relying on those. And notably they did this rollout staggered such that only some people got it and some didn't which made everything way more confusing.
GrapheneOS has a bunch of security hardening to restrict crosstalk between apps and services and the assumptions GOS made and the assumptions Google made about how services and apps should be allowed to interact were disjoint. That mismatch in assumptions broke things for a while. And the lack of clear communication from Google about this change combined with various anti-spam/rate limiting issues (Gmessages kept trying to register not expecting to fail and kept slamming the servers which looked like spam and triggered exponential backoff retries) compounded together to render RCS broken for a few weeks during that migration.
Notably this was also broken for basically every other non-google/non-samsung android provider for a while as well due to how poorly the migration was communicated by google.
Then not long after that was resolved graphene changed how they handled their sandboxing to make it less brittle to google changes and since then there's not been much in the way of issues.
The only issue with RCS since then has been a brief break in RCS (~1-2 days) about a month ago due to what was essentially an update to Google's services putting the graphene sandbox briefly out of sync. This was fixed almost immediately on the alpha release channel and just took ~48 hours to move through the alpha->beta->stable pipeline.
From this point on now that RCS is more or less all "standard" stuff now you shouldn't see any major breakages. The only situation where you might see one would be when android inevitably opens up RCS outside of the google services walled garden but even then you should be able to continue relying on the google services version until the non-google version is stable.
> So the issue with RCS is that google just this last year made the move from their internal implementation of E2EE for RCS to the standard implementation based on MLS (now that the standard impl is actually viable).
> They did this quietly in the background and most people didn't notice but in doing so they released new system/OS level services and started relying on those. And notably they did this rollout staggered such that only some people got it and some didn't which made everything way more confusing.
> From this point on now that RCS is more or less all "standard" stuff now you shouldn't see any major breakages. The only situation where you might see one would be when android inevitably opens up RCS outside of the google services walled garden but even then you should be able to continue relying on the google services version until the non-google version is stable.
Is there anywhere public that there are writeups or roadmaps about this? I'm particularly curious about whether there will ever be an API for third-party clients.
What's left in terms of meaningful technical barriers, that would prevent this all from being baked into Android instead of requiring Play Services?
Tbh I have no idea. I kept up with it on the GrapheneOS discord and I think GOS put out bluesky/mastodon posts about it at one point.
> What's left in terms of meaningful technical barriers, that would prevent this all from being baked into Android instead of requiring Play Services?
Well now I think the last major barrier is cleared (which was E2EE being nonstandard). Currently the on-device infra is very google-oriented but there is support for non-google-jibe RCS but it still requires google, etc to explicitly opt-in apps to get access to the APIs on device.
A big part of this IMHO is google refusing to give up their moat but they may finally get it into AOSP at some point.
If they don't at this point I think the only way it'll happen is if the EU forces their hand (which they hopefully will do).
> What's left in terms of meaningful technical barriers, that would prevent this all from being baked into Android instead of requiring Play Services?
The short version: no open source RCS libraries exist.
The implementation in AOSP is out of date/dead.
Finish the play: unreliable in what way, on which side (send, receive)?
Yeah I use rcs and you can use the pixel camera app if you want??
Rcs had a bug that was fixed recently though
I did have RCS issues with GrapheneOS (on T-Mobile in the US) for a while, but at some point that was fixed and it works flawlessly now.
As for camera apps, the stock GrapheneOS camera app is a bit clunky, I just download the stock Android "Camera" off of the Play Store...
> I just download the stock Android "Camera"
The "stock Android camera" (the one in AOSP) is absolutely horrible. You're probably using Google's Pixel camera app.
> GrapheneOS really doesn't seem ready to be a daily driver.
As someone who has used it exclusively as their mobile OS for three years, it is absolutely ready. Does that mean it's perfect or bug-free? No, but nothing is.
Been using GrapheneOS as daily driver for 4 years on three pixels. Problems only start when banking apps start actively sabotaging it by pretending the phone is rooted etc. Normal apps work normally and you get way more control over them. I'll never go back to stock or worse than stock (Samsung) as long as GrapheneOS is around even if they get rid of all security aspects (which of course they won't, I'm just saying security is not the only selling point, de-googling is a big one too.. I didn't de-google but I sure like having the option)
> after Motorola Mobility
Does anyone know anymore on that front? For months, I've regularly looked up whether there were any news, only to find nothing besides the original announcement. No ETA, no upcoming devices to be supported, heck, on the Graphene side, their own webpages make nary a mention. Would buy a Razr 70 Ultra + Clicks the second that is confirmed, but for something that was so publicly announced months ago, this seems very shaky...
I don't think we'll see it before CES in January.
They're too busy pushing malware on the rest of their lineup in system updates left, right, and center.
silently re-enables com.glance.lockscreenM one more time on you...
If it become to big, it will go the same way as CyanogenMod, Google will send some people to pressure the manufacturers to drop them off
Google is the only one supporting them currently.
Well, also expect the next Pixel bootloader to be locked out if they become too big.
Yep, any day now, it’ll be the year of the GrapheneOS mobile phone. /s
As delusional as ever.
They've doubled their users in 2 years
Why are you being so aggressive?
Pathetic.
Seems ridiculous, but when their biggest rival can’t be bothered to support Linux… you see why they might announce something like this.
Roblox has a long history of not supporting Linux, and the game was rendered unplayable for many years. In 2022 it became possible following some Wine patches, but then they began to implement a kernel-level anticheat. Roblox initially committed to keeping Wine working but suddenly went back on that and blocked it without notice. Today, the last remaining way is through running the Android version of the game through an Android container or emulator. The TFA is about stopping this exact method of running the game though...
This isn't true. Roblox never had and does not have a kernel anti-cheat.
My mistake, I just assumed their Byfron anti-cheat is kernel level because that's the most common reason why anticheats take issue with Wine. If their anti-cheat operates entirely in usermode, then their decision to block Wine is even more baffling to me.
It is not kernel level, they use a number of pretty fancy user mode tricks to prevent people messing with the game.
They encrypt every page and register an exception handler that decrypts the page when a fault is reached to keep memory secure. They do cache timing checks to see if a page was recently in the working set outside of the expected control flow and will flag you if you fail the check too many times because it indicates tampering.
While the page decryption trick should work in Wine just fine (ZeroIT Lab Theia does that too, right?), I don’t remember if Wine provides workingset info like Windows.
Yes, Wine was (EDIT: partially) compatible with the Roblox anti-cheat, and there was a period in time where Roblox with its anti-cheat ran on Wine. Eventually, however, a decision was made to block Wine.
EDIT It looks like the Roblox anti-cheat devs themselves explained why Wine was blocked:
https://devforum.roblox.com/t/roblox-on-linux-everything-sum...
Yes, it does. Wine lets you register a VEH. They do other stuff to prevent Wine and virtual machines in general that I am not fully aware of.
Even then it's just a fancy party trick, you can suspend the process call the decryption function enumerating all the pages and take a full dump to get the binary
FYI; Theia is a very bad product. It absolutely tanks binary performance and does little to prevent a moderately competent engineer from cheating in your game.
Are the other Zero IT Lab products like their code virtualizer of similar quality to Theia? My only exposure has been that one RE//verse presentation and shitposts on UC.
I can't speak for all the products, but from what I have heard it's pretty bad. Pay close attention to the shitposts on UC, they regularly get taken down but have some interesting information in them.
I personally liked their Code virtualizer. And it's under active development. Sorry to hear about Theia, I haven't run into it yet.
Wine doesn't provide every userspace facility Windows does.
The TFA explains that it is up to game to decide if they want to use attestation.
Who's their biggest rival? Roblox doesn't support Linux either.
Let me rephrase, it doesn’t actively oppose Linux like Fortnite does. Roblox absolutely can run on Linux, even though it’s not officially supported.
Fortnite doesn't actively oppose Linux, compared to Roblox cheating which keeps a lot of logic on the server, cheating on Fortnite on the client has a more bigger impact.
Unfortunately there's no way to properly ship a kernel level anti-cheat on Linux right now and none of the mainstream distros ship with any kind of attestation or OS verification out the box like Android does.
SteamOS could change it here though, we'll see. I don't have much hope given the thing doesn't even use Secure Boot by default.
Kernel level anti-cheat seems to be ultimately ineffective. I've seen this with my own eyes with backend data when I worked for a company with a moderately successful shooter. Kernel level anti-cheat is serving a similar function to something like EAC these days, which basically just keeps the lazy people out. With any decently sufficient backend data analysis, you catch these folks just as easy.
I am of the belief that if you cannot completely control the environment, like a user's physical hardware, you're fighting a losing battle. Forcing them to install spyware is, in my opinion, just marketing for your competitive shooter and too invasive for the perceived gain.
> With any decently sufficient backend data analysis, you catch these folks just as easy.
No you can't. Using server side analysis of behaviour will always get false positives, especially as ML networks are getting better and better at reproducing normal player behaviour.
Your server side logic can't detect wall hacks, ESPs etc.
> which basically just keeps the lazy people out
That's better than nothing. Cheating will always be possible (see DMA devices), but as long as you make it reasonably hard to put most people off it, that's a success.
> cannot completely control the environment
But applications should be able to attest the environment is not modified, which is what desktop Linux lacks. Windows, macOS and Android do have methods to do this.
> like a user's physical hardware, you're fighting a losing battle
The alternative is no releases on PC.
> The alternative is no releases on PC.
If you think there aren't hackers on console, you're deluded.
> Your server side logic can't detect wall hacks, ESPs etc.
Correct, neither do the invasive tools. You can get these things without modifying memory or the game, which is the majority of what the kernel level stuff keeps on eye on.
> especially as ML networks are getting better and better at reproducing normal player behaviour.
True, there is no answer here. Again, if the provider is this sophisticated, then EAC isn't helping here. Then it is just the usual cat and mouse, and the kernel level is moot.
> But applications should be able to attest the environment is not modified, which is what desktop Linux lacks. Windows, macOS and Android do have methods to do this.
Also true, but they are frequently circumvented anyway, so ultimately you're at the same level of Linux from a functional standpoint.
I know you're probably thinking that we should just hit all vectors, and I agree to an extent. The problem is that those who charge for cheats easily circumvent (yes, easily, they are literally within 24hrs sometimes of adjusting to modifications by anti-cheat software) the methods you're claiming help. While the data you get from users on the server end doesn't paint a whole picture, it is the source of truth of what the game decided happened, so it becomes the only thing you can rely on. I know folks who specialize in this area who basically believe that online competitive shooters are basically lost and it isn't worth the investment to fight it.
I am of the opinion we should just go back to dedicated servers and have self moderation. Sure, you get false positives if the owner or their mods suck at the game, but at least the players can do something about it. CS2 is a fucking nightmare at the moment.
EAC is a kernel mode anti-cheat on Windows, though?
And given the whining on UC it seems to be fairly effective.
Doesn't roblox use an anticheat that prevents the game client from running on linux? I thought nowadays the way to "run roblox on linux" involved using an android emulator.
Native Roblox has blocked Linux for 3 years, and games on it (especially PvP ones) can and do require Android remote attestation which Sober doesn't implement. It wouldn't surprise me if Graphene can't play those games as well.
Roblox is a platform. Fortnite is still primarily one game.
Use Sober
For anyone curious: https://sober.vinegarhq.org
I'd assume Fortnite Creative
They don't officially support Linux, but they allow the community to continue playing using Sober. Honestly it's probably better that way
They're 60% of the North American game's industry revenue growth. Their rival is negative stock market sentiment. They need to pull out all the stops to prove growth.
Fortnite
“You have reached your limits on help.roblox.com”
That is the first time I see something like that!
"Support" seems a bit strong here. the statment has more of a "known to work with" than a whole lot of direct support effort, also you have to have a locked bootloader, here's the relevant statement.
> For power-users: Are all third-party ROMs blocked?
No. We currently support GrapheneOS when the bootloader is locked. We may support other third-party ROMs if:
If ROMs do not consistently adhere to the standards above, we will remove them from the set of supported verified boot keysIt would be accurate to call it official support if it means they have set up their app with the privacy-friendly Android Hardware Attestation API on GrapheneOS.
Unless I'm wrong and they just support Basic Play Integrity or a lower one, I don't know much about that. But those would require play services. I could test to see if it works without play services which would indicate they are using the Hardware Attestation API to check the bootloader lock.
Great news! I never had problems running Roblox on my GOS, but it's nice to to see the explicit, official support.
Snowball effect (for both sides, software publishers and OS vendors).
Don't get too excited, this still goes against the basic freedom to own the devices you've paid for.
Remote attestation is still there and only official builds of GrapheneOS are supported. While this is marginally better than being tied to a build from an advertising company, you're still out of luck if you want to build the OS yourself.
Please don’t let your kids on this platform…
I guess that makes sense given the type of adults that prowl on Roblox.
It's Roblox's responsibility to police their platform and the vast majority of bad actors use mainstream operating systems and mainstream services like Discord or Telegram. Clearly lack of privacy does not prevent crime as we can see on Telegram and Discord which are both not E2EE and yet have far more crime taking place then on encrypted alternatives.
wow what a nonsensical argument. "not all criminals wear ski masks. so let's let let anyone walk on school premises wearing a sky mask"
Truth be told, GrapheneOS is the only third party ROM that bothers to make app attestation work.
Good for all of them. Attestation is a terrible infringement of rights, and both Graphene's approach (trying to make it a more open ecosystem) and the other one (refusing to participate/trying to destroy the ecosystem) are viable responses to it.
It's not a ROM it's an OS.
ROM is to android what distro is to Linux. The term is used correctly here. An android ROM could refer to the stock OS, GrapheneOS, LineageOS, Pixel Experience, etc.
With immutable distros (see bootc or systemd-sysupgrade) the operating system itself is also only just a read only file system. Does that count as ROM too?
it's a term used for historical reasons, nobody is claiming it's accurately describing some technical property
Might as well just use the term "Android distr(o|ibution)" whenever talking about it. I think its also more self-explanatory vs "Android ROM" if you never heard of them before.
ROM is to android what an image file is to Linux. A distro is a collection of software and tools, more akin to an android OS.
All the third party roms I know offer sign builds and remote attestation, GrapheneOS isn't special here, it's just that usually app developers just ignore the signatures
support?
I'm yet to come across an Android app I can't run on GrapheneOS.. what exactly are they doing?
That's excellent news!! Hope to see more of this!!
i don't think kids should be playing roblox to be honest...
However, if on LineageOS, which mind you is the only way to get updated (and thus safer) android versions in many devices, they simply block you.
Awful.
The announcement is very funny in that regard, devices with last update in 2023 like the Galaxy S10 are still ok despite having every root exploit under the sun available but god forbid you want to update it to the last version
LineageOS has no AVB support at all unfortunately and most devices don't allow using verified boot with custom keys anyways. With GrapheneOS they can just add GrapheneOS public keys (https://grapheneos.org/attestation.json).
For LOS Roblox would have to disable hardware attestation completely, which means you can easily just add extra modules such as a setuid binary which makes cheating easy (at least on the client side, you'd have to rely completely on server side anti cheating)
https://eylenburg.github.io/android_comparison.htm
While that is true the bigger issue is that LineageOS doesn't qualify for "They do not break the AOSP security model" as it allows users to get root access without modifying the OS. So even if there was verified boot Roblox would still block it.
For me this means that Roblox's requirements are fundamentally incompatible with any device I would want to use as they want to restrict my access and I want full access.
[dead]