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.
Apps rarely use hardware key attestation directly but rather use it via the Play Integrity API. Play Integrity device and strong integrity levels ban using a non-Google-certified OS. Play Integrity uses hardware key attestation for both integrity levels and it's a hard requirement for strong integrity. Developers enforcing one of those integrity levels to use their service need to either stop doing it or add explicit support for non-Google-certified operating systems via key attestation. Roblox's documentation shows they're taking the latter approach.
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.
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...
At the time of writing, within ~12 months, in 2027, the 2027 Signature, Razr fold, and Razr flip will meet the hardware security requirements and should have official GrapheneOS support.
Motorola is currently porting GrapheneOS to their devices.
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.
GrapheneOS is one of the most widely used alternatives to Google Mobile Services Android along with LineageOS. It already has nearly as many users as the official LineageOS releases do and will have more soon. It's not a niche OS only used by people targeted by governments as is often claimed and it's also not at all only for technical people. It's more aimed at people who aren't technical power users than those who are.
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 fully functional on GrapheneOS. Google Messages is the only implementation of RCS available for Android in practice. RCS is a proprietary Google messaging system in practice. Google hosts a huge portion of the infrastructure and gatekeeps access to it. It would be possible to make an alternative RCS client for Android but it would still using Google infrastructure since carriers are using it.
> 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.
GrapheneOS is not about specifically avoiding Google apps and services. You've said you want to use Google's RCS messaging system, which would not take away from the benefits of using GrapheneOS.
> a weird privacy focused OS
GrapheneOS is a widely used open source project. It's well known and there's nothing unusual about using it. The hypothetical situation you're describing is not something which has ever been known to happen.
> Also the backup restoration is a bit more of a mess for me right now
GrapheneOS has better backup/restore support than the stock OS. It doesn't have privileged Google Play integration for using Google's very limited app backup/restore or their more capable device transfer feature. GrapheneOS has an equivalent to the device transfer feature which can be used for both encrypted local and cloud backups.
> dual sim feature
GrapheneOS fully supports cross-SIM calling and it's one of the features it adds the option to force enable for carriers not otherwise supporting it alongside 5G, VoLTE, Vo5G and VoWiFi
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).
AOSP fully supports everything needed for RCS. AOSP doesn't provide any actively developed messaging app so an app with RCS support needs to come from elsewhere. AOSP never provided an RCS messaging app. AOSP only provides a sample SMS/MMS app for testing purposes which is intended to be replaced. GrapheneOS is well into the process of replacing it including replacing nearly the whole user interface in our development branch followed by improving the under the hood code. It's not an RCS app and never was but we plan to eventually make our own RCS implementation instead of only providing fully functional compatibility with Google Messages.
oh nice is there a tracking issue for this somewhere? I've taken a peek at the issues in the org on github but i didn't see one off the bat (mainly because there's a ton of other SMS related issues that pop up from history)
RCS is fully functional on GrapheneOS. Google Messages is the only RCS available for Android in practice and is fully supported by the sandboxed Google Play compatibility layer. It provides a special for granting ICC authentication access to Play services for it.
Camera features and quality are the same as the stock OS within the same app. Pixel Camera works fine on GrapheneOS.
Cross-SIM calling is better supported on GrapheneOS than the stock OS due to our carrier overrides features for force enabling features which aren't otherwise available.
RCS is fully functional on GrapheneOS with an app supporting it. Google Messages is the only RCS app for Android available in practice. It fully works on GrapheneOS via the official sandboxed Google Play compatibility layer support for it.
Camera features and quality on GrapheneOS are the same as the stock Pixel OS within the same app. Pixel Camera fully works on GrapheneOS even without sandboxed Google Play in the same profile.
GrapheneOS fully supports dual SIM and cross-SIM calling. It has much better support for it than the stock Pixel OS because cross-SIM calling is one of the features which can be force enabled for carriers not usually supporting it with the GrapheneOS carrier overrides. That also applies to 5G, VoLTE, Vo5G and VoWiFi where those can be used on carriers where those aren't available with the stock Pixel OS.
> but GrapheneOS really doesn't seem ready to be a daily driver
GrapheneOS is a daily driver for many people. The 3 things you've listed as concerns work at least as well in GrapheneOS as the stock OS. You're assuming functionality that's available is missing.
> GrapheneOS includes our own modern camera app focused on privacy and security. It includes modes for capturing images, videos and QR and barcode scanning along with additional modes based on CameraX vendor extensions (Portrait, HDR, Night, Face Retouch and Auto) on devices where they're available (Pixels currently only have support for Night mode).
I am indeed using the "Pixel Camera" app, which I would consider the "stock camera" for Pixel devices. It is just labelled as "Camera" in the app drawer.
GrapheneOS doesn't use AOSP Camera and there isn't any official way to install it. Stock means the stock OS on the device which is the Pixel OS with Pixel Camera for Pixels.
> 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)
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.
Roblox supports using hardware-based attestation to verify GrapheneOS. We publish our verified boot keys in a signed JSON file and they use those to verify it as an alternative to the Play Integrity API. That's what's described at https://en.help.roblox.com/hc/en-us/articles/49648939984916-....
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.
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.
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.
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.
GrapheneOS and other operating systems based on the Android Open Source Project (AOSP) are Linux distributions. None of those is a ROM. They're AOSP-based OSes. They're not read-only memory firmware or stored in read-only memory. Using the term ROM that way is very confusing to people who aren't part of communities historically using it that way. It's very misleading and propagates misconceptions. It's not simply about it not being technically accurate.
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?
In the context of GrapheneOS, ROM means read-only memory. GrapheneOS does security research on hardware and firmware where the term ROM is useful and very relevant to security. There are multiple ROMs used on devices including the boot ROM loading, verifying and running the SoC boot firmware from the SSD.
Most people aren't exposed to the Android modding communities where the term ROM is used to mean Android-based OS. It's confusing to the general public including technical people. It misleads people about what it is and directly leads to misconceptions which we keep needing to address. It's best to avoid using inaccurate terminology which creates unnecessary misconceptions. There isn't a good reason to insist on using it. We would appreciate if Roblox fixed their documentation to avoid using it.
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.
GrapheneOS and other operating systems based on the Android Open Source Project (AOSP) are Linux distributions. None of those is a ROM. They're AOSP-based OSes. They're not read-only memory firmware or stored in read-only memory. Using the term ROM that way is very confusing to people who aren't part of communities historically using it that way. It's very misleading and propagates misconceptions. It's not simply about it not being technically accurate.
LineageOS disables major parts of verified boot, doesn't preserve the security model it depends on and sets an inaccurate security patch level solely based on the AOSP security backports. Most alternative Android-based operating systems are based on LineageOS and inherit these properties from it.
GrapheneOS didn't create any attestation system and has been a very strong advocate against apps disallowing people from using an arbitrary device or OS. For developers insisting on doing it, we explain how to permit other operating systems beyond Google certified ones using the standard Android hardware attestation system. We provide a signed JSON file with our verified boot key fingerprints for use with it. Other operating systems can do the same as long as they preserve the security model including verified boot. It isn't anything added or created by GrapheneOS but rather is fully functional in a properly done release build of the Android Open Source Project signed with release keys.
They're doing attestation checks to enforce having a Google certified device and OS. They followed our attestation compatibility guide to support GrapheneOS by permitting the verified boot keys for it and have said they're open to permitting other operating systems in the same way. It would be better if apps didn't do this but if they're going to do it then this is much better than only permitting a Google certified OS.
Roblox goes out of the way to explicitly support GrapheneOS. They permit GrapheneOS users to join servers enforcing remote attestation to verify the OS and app as a form of anti-cheat. They need to explicitly add the verified boot keys for each non-Google-certified OS. GrapheneOS is currently the only one they're supporting but they're making it clear that it's not at all exclusively available to it.
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.
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.
Apps rarely use hardware key attestation directly but rather use it via the Play Integrity API. Play Integrity device and strong integrity levels ban using a non-Google-certified OS. Play Integrity uses hardware key attestation for both integrity levels and it's a hard requirement for strong integrity. Developers enforcing one of those integrity levels to use their service need to either stop doing it or add explicit support for non-Google-certified operating systems via key attestation. Roblox's documentation shows they're taking the latter approach.
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.
> 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...
At the time of writing, within ~12 months, in 2027, the 2027 Signature, Razr fold, and Razr flip will meet the hardware security requirements and should have official GrapheneOS support.
Motorola is currently porting GrapheneOS to their devices.
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...
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...
GrapheneOS is one of the most widely used alternatives to Google Mobile Services Android along with LineageOS. It already has nearly as many users as the official LineageOS releases do and will have more soon. It's not a niche OS only used by people targeted by governments as is often claimed and it's also not at all only for technical people. It's more aimed at people who aren't technical power users than those who are.
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 fully functional on GrapheneOS. Google Messages is the only implementation of RCS available for Android in practice. RCS is a proprietary Google messaging system in practice. Google hosts a huge portion of the infrastructure and gatekeeps access to it. It would be possible to make an alternative RCS client for Android but it would still using Google infrastructure since carriers are using it.
> 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.
GrapheneOS is not about specifically avoiding Google apps and services. You've said you want to use Google's RCS messaging system, which would not take away from the benefits of using GrapheneOS.
> a weird privacy focused OS
GrapheneOS is a widely used open source project. It's well known and there's nothing unusual about using it. The hypothetical situation you're describing is not something which has ever been known to happen.
> Also the backup restoration is a bit more of a mess for me right now
GrapheneOS has better backup/restore support than the stock OS. It doesn't have privileged Google Play integration for using Google's very limited app backup/restore or their more capable device transfer feature. GrapheneOS has an equivalent to the device transfer feature which can be used for both encrypted local and cloud backups.
> dual sim feature
GrapheneOS fully supports cross-SIM calling and it's one of the features it adds the option to force enable for carriers not otherwise supporting it alongside 5G, VoLTE, Vo5G and VoWiFi
RCS is unstable on iOS, too,
for the same reasons SMS has always been unstable.
It’s the nature of the protocol, unfortunately.
RCS is fully functional on GrapheneOS. It works as well as it does on the stock Pixel OS.
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.
AOSP fully supports everything needed for RCS. AOSP doesn't provide any actively developed messaging app so an app with RCS support needs to come from elsewhere. AOSP never provided an RCS messaging app. AOSP only provides a sample SMS/MMS app for testing purposes which is intended to be replaced. GrapheneOS is well into the process of replacing it including replacing nearly the whole user interface in our development branch followed by improving the under the hood code. It's not an RCS app and never was but we plan to eventually make our own RCS implementation instead of only providing fully functional compatibility with Google Messages.
oh nice is there a tracking issue for this somewhere? I've taken a peek at the issues in the org on github but i didn't see one off the bat (mainly because there's a ton of other SMS related issues that pop up from history)
RCS is fully functional on GrapheneOS. It works as well as it does on the stock Pixel OS.
Finish the play: unreliable in what way, on which side (send, receive)?
RCS is fully functional on GrapheneOS. It works as well as it does on the stock Pixel OS.
RCS is fully functional on GrapheneOS. Google Messages is the only RCS available for Android in practice and is fully supported by the sandboxed Google Play compatibility layer. It provides a special for granting ICC authentication access to Play services for it.
Camera features and quality are the same as the stock OS within the same app. Pixel Camera works fine on GrapheneOS.
Cross-SIM calling is better supported on GrapheneOS than the stock OS due to our carrier overrides features for force enabling features which aren't otherwise available.
Yeah I use rcs and you can use the pixel camera app if you want??
Rcs had a bug that was fixed recently though
RCS is fully functional on GrapheneOS with an app supporting it. Google Messages is the only RCS app for Android available in practice. It fully works on GrapheneOS via the official sandboxed Google Play compatibility layer support for it.
Camera features and quality on GrapheneOS are the same as the stock Pixel OS within the same app. Pixel Camera fully works on GrapheneOS even without sandboxed Google Play in the same profile.
GrapheneOS fully supports dual SIM and cross-SIM calling. It has much better support for it than the stock Pixel OS because cross-SIM calling is one of the features which can be force enabled for carriers not usually supporting it with the GrapheneOS carrier overrides. That also applies to 5G, VoLTE, Vo5G and VoWiFi where those can be used on carriers where those aren't available with the stock Pixel OS.
> but GrapheneOS really doesn't seem ready to be a daily driver
GrapheneOS is a daily driver for many people. The 3 things you've listed as concerns work at least as well in GrapheneOS as the stock OS. You're assuming functionality that's available is missing.
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.
Um, ackshually
https://grapheneos.org/usage#grapheneos-camera-app
> GrapheneOS includes our own modern camera app focused on privacy and security. It includes modes for capturing images, videos and QR and barcode scanning along with additional modes based on CameraX vendor extensions (Portrait, HDR, Night, Face Retouch and Auto) on devices where they're available (Pixels currently only have support for Night mode).
I am indeed using the "Pixel Camera" app, which I would consider the "stock camera" for Pixel devices. It is just labelled as "Camera" in the app drawer.
GrapheneOS doesn't use AOSP Camera and there isn't any official way to install it. Stock means the stock OS on the device which is the Pixel OS with Pixel Camera for Pixels.
> 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)
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.
[flagged]
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.
Roblox supports using hardware-based attestation to verify GrapheneOS. We publish our verified boot keys in a signed JSON file and they use those to verify it as an alternative to the Play Integrity API. That's what's described at https://en.help.roblox.com/hc/en-us/articles/49648939984916-....
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!
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"
That's excellent news!! Hope to see more of this!!
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.
Truth be told, GrapheneOS is the only third party ROM that bothers to make app attestation work.
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.
GrapheneOS and other operating systems based on the Android Open Source Project (AOSP) are Linux distributions. None of those is a ROM. They're AOSP-based OSes. They're not read-only memory firmware or stored in read-only memory. Using the term ROM that way is very confusing to people who aren't part of communities historically using it that way. It's very misleading and propagates misconceptions. It's not simply about it not being technically accurate.
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
In the context of GrapheneOS, ROM means read-only memory. GrapheneOS does security research on hardware and firmware where the term ROM is useful and very relevant to security. There are multiple ROMs used on devices including the boot ROM loading, verifying and running the SoC boot firmware from the SSD.
Most people aren't exposed to the Android modding communities where the term ROM is used to mean Android-based OS. It's confusing to the general public including technical people. It misleads people about what it is and directly leads to misconceptions which we keep needing to address. It's best to avoid using inaccurate terminology which creates unnecessary misconceptions. There isn't a good reason to insist on using it. We would appreciate if Roblox fixed their documentation to avoid using it.
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.
GrapheneOS and other operating systems based on the Android Open Source Project (AOSP) are Linux distributions. None of those is a ROM. They're AOSP-based OSes. They're not read-only memory firmware or stored in read-only memory. Using the term ROM that way is very confusing to people who aren't part of communities historically using it that way. It's very misleading and propagates misconceptions. It's not simply about it not being technically accurate.
[flagged]
LineageOS disables major parts of verified boot, doesn't preserve the security model it depends on and sets an inaccurate security patch level solely based on the AOSP security backports. Most alternative Android-based operating systems are based on LineageOS and inherit these properties from it.
[flagged]
GrapheneOS didn't create any attestation system and has been a very strong advocate against apps disallowing people from using an arbitrary device or OS. For developers insisting on doing it, we explain how to permit other operating systems beyond Google certified ones using the standard Android hardware attestation system. We provide a signed JSON file with our verified boot key fingerprints for use with it. Other operating systems can do the same as long as they preserve the security model including verified boot. It isn't anything added or created by GrapheneOS but rather is fully functional in a properly done release build of the Android Open Source Project signed with release keys.
support?
I'm yet to come across an Android app I can't run on GrapheneOS.. what exactly are they doing?
They're doing attestation checks to enforce having a Google certified device and OS. They followed our attestation compatibility guide to support GrapheneOS by permitting the verified boot keys for it and have said they're open to permitting other operating systems in the same way. It would be better if apps didn't do this but if they're going to do it then this is much better than only permitting a Google certified OS.
[flagged]
[dead]
[flagged]
Roblox goes out of the way to explicitly support GrapheneOS. They permit GrapheneOS users to join servers enforcing remote attestation to verify the OS and app as a form of anti-cheat. They need to explicitly add the verified boot keys for each non-Google-certified OS. GrapheneOS is currently the only one they're supporting but they're making it clear that it's not at all exclusively available to it.
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.