Roblox Officially Supports GrapheneOS
en.help.roblox.com
en.help.roblox.com
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.
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.
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 :-).
Rcs had a bug that was fixed recently though
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.
for the same reasons SMS has always been unstable.
It’s the nature of the protocol, unfortunately.
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.
> 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?
> 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).
The short version: no open source RCS libraries exist.
The implementation in AOSP is out of date/dead.
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
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.
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...
> 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
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.
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...
The "stock Android camera" (the one in AOSP) is absolutely horrible. You're probably using Google's Pixel camera app.
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.
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.
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.
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...
silently re-enables com.glance.lockscreenM one more time on you...
Motorola is currently porting GrapheneOS to their devices.
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.
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.
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.
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.
And given the whining on UC it seems to be fairly effective.
Roblox is a platform. Fortnite is still primarily one 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.
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.
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...
That is the first time I see something like that!
Snowball effect (for both sides, software publishers and OS vendors).
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.
Most criminals are not smart which is why they commit crimes.
The idea that GrapheneOS is for criminals is as absurd as saying iPhones are. They are just tools trying to be the best they can be.
Awful.
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)
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.
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.
I'm yet to come across an Android app I can't run on GrapheneOS.. what exactly are they doing?