Rendered at 22:20:47 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
dugite-code 22 hours ago [-]
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.
andrewaylett 10 hours ago [-]
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.
dugite-code 7 hours ago [-]
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.
jordand 1 days ago [-]
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.
Topfi 16 hours ago [-]
> 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...
Kudos 15 hours ago [-]
I don't think we'll see it before CES in January.
kotaKat 9 hours ago [-]
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...
annzabelle 22 hours ago [-]
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.
malmeloo 22 hours ago [-]
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 :-).
annzabelle 22 hours ago [-]
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.
calmingsolitude 15 hours ago [-]
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.
DANmode 22 hours ago [-]
RCS is unstable on iOS, too,
for the same reasons SMS has always been unstable.
It’s the nature of the protocol, unfortunately.
annzabelle 20 hours ago [-]
Maybe I should've specified: I have seen many anecdotes of RCS being substantially more unreliable on GrapheneOS than it is on stock Android.
OneDeuxTriSeiGo 7 hours ago [-]
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.
chaosharmonic 6 hours ago [-]
> 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?
OneDeuxTriSeiGo 5 hours ago [-]
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).
DANmode 16 hours ago [-]
Finish the play: unreliable in what way, on which side (send, receive)?
zackify 22 hours ago [-]
Yeah I use rcs and you can use the pixel camera app if you want??
Rcs had a bug that was fixed recently though
TranquilMarmot 15 hours ago [-]
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...
flexagoon 12 hours ago [-]
> 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.
ThePowerOfFuet 3 hours ago [-]
> 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.
_blk 7 hours ago [-]
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)
realusername 15 hours ago [-]
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
Cider9986 8 hours ago [-]
Google is the only one supporting them currently.
realusername 8 hours ago [-]
Well, also expect the next Pixel bootloader to be locked out if they become too big.
UqWBcuFx6NV4r 23 hours ago [-]
Yep, any day now, it’ll be the year of the GrapheneOS mobile phone. /s
As delusional as ever.
Cider9986 19 hours ago [-]
They've doubled their users in 2 years
copper-float 22 hours ago [-]
Why are you being so aggressive?
el_io 19 hours ago [-]
Pathetic.
ticulatedspline 4 hours ago [-]
"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
jkahrs595 1 days ago [-]
Seems ridiculous, but when their biggest rival can’t be bothered to support Linux… you see why they might announce something like this.
a2128 24 hours ago [-]
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...
nekitamo 16 hours ago [-]
This isn't true. Roblox never had and does not have a kernel anti-cheat.
a2128 11 hours ago [-]
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.
vablings 9 hours ago [-]
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.
not_a9 6 hours ago [-]
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.
vablings 3 hours ago [-]
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.
not_a9 3 hours ago [-]
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.
vablings 1 hours ago [-]
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.
not_a9 7 hours ago [-]
Wine doesn't provide every userspace facility Windows does.
23 hours ago [-]
charcircuit 15 hours ago [-]
The TFA explains that it is up to game to decide if they want to use attestation.
unleaded 1 days ago [-]
Who's their biggest rival? Roblox doesn't support Linux either.
jkahrs595 1 days ago [-]
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.
ChocolateGod 13 hours ago [-]
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.
dannersy 12 hours ago [-]
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.
ChocolateGod 10 hours ago [-]
> 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.
dannersy 2 hours ago [-]
> 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.
not_a9 7 hours ago [-]
EAC is a kernel mode anti-cheat on Windows, though?
And given the whining on UC it seems to be fairly effective.
thenewnewguy 23 hours ago [-]
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.
cyberrock 10 hours ago [-]
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 don't officially support Linux, but they allow the community to continue playing using Sober. Honestly it's probably better that way
x3cca 15 hours ago [-]
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.
haunter 23 hours ago [-]
Fortnite
sinuhe69 15 hours ago [-]
“You have reached your limits on help.roblox.com”
That is the first time I see something like that!
m132 8 hours ago [-]
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.
subscribed 1 days ago [-]
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).
khalic 15 hours ago [-]
Please don’t let your kids on this platform…
15 hours ago [-]
tripleee 3 hours ago [-]
support?
I'm yet to come across an Android app I can't run on GrapheneOS.. what exactly are they doing?
650REDHAIR 20 hours ago [-]
I guess that makes sense given the type of adults that prowl on Roblox.
Cider9986 19 hours ago [-]
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.
spaaaaaaaaaaace 3 hours ago [-]
i don't think kids should be playing roblox to be honest...
AppAttestationz 17 hours ago [-]
Truth be told, GrapheneOS is the only third party ROM that bothers to make app attestation work.
inigyou 10 hours ago [-]
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.
Cider9986 17 hours ago [-]
It's not a ROM it's an OS.
Moomoomoo309 15 hours ago [-]
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.
preisschild 10 hours ago [-]
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?
throawayonthe 10 hours ago [-]
it's a term used for historical reasons, nobody is claiming it's accurately describing some technical property
preisschild 10 hours ago [-]
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.
4gotunameagain 12 hours ago [-]
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.
realusername 15 hours ago [-]
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
matheusmoreira 20 hours ago [-]
That's excellent news!! Hope to see more of this!!
snvzz 16 hours ago [-]
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.
realusername 15 hours ago [-]
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
preisschild 10 hours ago [-]
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 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.
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...
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 :-).
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.
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...
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).
Rcs had a bug that was fixed recently though
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.
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.
As delusional as ever.
> 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 keysThey 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.
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.
That is the first time I see something like that!
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.
Snowball effect (for both sides, software publishers and OS vendors).
I'm yet to come across an Android app I can't run on GrapheneOS.. what exactly are they doing?
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)
https://eylenburg.github.io/android_comparison.htm