Zum Inhalt der Seite gehen
Revolut is specifically banning GrapheneOS by checking for the build machine hostname and username being set to grapheneos. We've changed these to build-host and build-user. Combined with another change, this allow our users to log in to it again until they roll out Play Integrity API enforcement.
GrapheneOS
There's no legitimate excuse for banning using a much more private and secure operating system while permitting devices with no security patches for a decade. Meanwhile, Revolut's shoddily made app tells users they're banning GrapheneOS because they're "serious about keeping your data secure".
GrapheneOS
Revolut's app will stop working against once they start enforcing having a Play Integrity API result showing it's a Google certified device. This is not a security feature but rather anti-competitive behavior from Google deployed by apps like Revolut wanting to pretend they care about security.
GrapheneOS
Revolut uses a bunch of shady closed source third party libraries in their app and it's one of these libraries banning GrapheneOS. These libraries are a major security risk and put user data at risk of being compromised. Revolut is not taking user security seriously at all and is cutting corners.
GrapheneOS
There's no legitimate reason for any app to ban GrapheneOS users. It has the full standard security model and massive security improvements. There's no logic in banning GrapheneOS. It makes no sense for them to ban anything when they permit a device with no patches for 10 years. It's performative.
GrapheneOS
GrapheneOS fully supports standard Android hardware attestation for verifying the hardware, firmware and operating system along with the app that's using it. See https://grapheneos.org/articles/attestation-compatibility-guide. If apps insist on checking device integrity, that's the only way they should do it.

GrapheneOS attestation compatibility guide

Guide on using remote attestation in a way that's compatible with GrapheneOS.
GrapheneOS
GrapheneOS
Play Integrity API checks that Google's monopolies are supported through devices licensing Google Mobile Services and integrating their browser, search engine, advertising, etc. It's anti-competitive and clearly illegal. Multiple governments are taking regulatory action and are in contact with us.
TheZorse
I wish Canada would regulate... well, any of this stuff.
Dieser Beitrag wurde bearbeitet. (1 Monat her)
Kevin Karhan :verified:
do these include @BMWK / @Bundesregierung and/or @EUCommission ?
@Bundesregierung @European Commission @Wirtschaft & Klimaschutz
GrapheneOS
We can't talk much about it.
Quincy
I wish you the utmost success in getting this anti-competitive and customer-harming practice banned.

@kkarhan @BMWK @Bundesregierung @EUCommission
@Bundesregierung @European Commission @Kevin Karhan :verified: @Wirtschaft & Klimaschutz
zako
I think you were in talks with the European Commission about the monopoly tactics of the Play Integrity API. Any piece of news?
Adam Chovanec
good. Fingers crossed!
GrapheneOS
Revolut insecurely checks the ro.boot.verifiedbootstate property and forbids it being yellow, which means a locked device with an aftermarket OS that's being cryptographically verified by the firmware. They permit it being orange, which means an unlocked device with any OS.
GrapheneOS
They're specifically banning having a device that's locked with an aftermarket OS rather than banning having an unlocked device or an aftermarket OS in general. Similarly, they're specifically banning the value `grapheneos` for http://ro.build/.user/ro.build.host.
GrapheneOS
Both of these things and other similar insecure, useless checks are being done by several different SDKs. Revolut's app is full of sketchy, insecure third party libraries. They certainly don't take security seriously as they claim in their message about banning GrapheneOS.
GrapheneOS
We've fixed both of the ways they're banning GrapheneOS for our next release. Since third party SDKs are what's being used to do it, our hope is that this fixes a few other poorly written banking/financial apps doing similar stuff to ban aftermarket operating systems.
GrapheneOS
These are the full set of changes fixing Revolut's ban on GrapheneOS:

https://github.com/GrapheneOS/platform_build/commit/bcd027b1273db32d6361092c635bf52a5d08c0e7

https://github.com/GrapheneOS/platform_build_soong/pull/24/commits/cc62edd5c3af000a6089fe2cceef10b9458f8aae
https://github.com/GrapheneOS/platform_system_core/commit/971110e37d73b5acb6e806b62146dcdcb29277b2
https://github.com/GrapheneOS/platform_frameworks_base/commit/5c85337ba0c4f5e40811a5a753754f7ccc2bc72f
https://github.com/GrapheneOS/platform_frameworks_base/commit/29c31dcdb5f826f1032a1a4da4dc584dbee8f01d

Other banking apps banning GrapheneOS will need to be retested after the next release.

use non-GrapheneOS-branded build user/host · GrapheneOS/platform_build@bcd027b

This reuses the format used by the stock Pixel OS. This had to be changed due to apps banning GrapheneOS based on this.
GitHub
Menhera Lexi
I love how that first commit reusing Pixel stuff could in theory force them to ban pixels entirely or ban specific build dates and times
GrapheneOS
We have no issue making further changes if needed. They can successfully ban GrapheneOS if they really want but there's no reason we need to allow them to do it in such a ridiculous way. Our hope is that they aren't competent enough to ban GrapheneOS in the near future and it will take them time to finally move to the Play Integrity API. Ideally they could be convinced to stop, or at least to use hardware attestation with GrapheneOS in the allowlist per https://grapheneos.org/articles/attestation-compatibility-guide.

GrapheneOS attestation compatibility guide

Guide on using remote attestation in a way that's compatible with GrapheneOS.
GrapheneOS
GrapheneOS
We just temporarily deleted our response because we wanted to repost it with more information and several platforms don't see edits we make, that's all.
Menhera Lexi
Fair enough, i forget that sometimes. Guess im still used to centralized social media
GrapheneOS
A lot of people view our account through a Nostr bridge since we don't have a Nostr project account yet, which we need to get around to setting up at some point. Many people don't realize it's not a native Nostr account but rather bridged so we'll need to deal with that when we make an account there and maybe get the person doing the bridge to unbridge it after a final post about the native account.
Ben Feakins :linux: :rstats: 📷
LOL... Will this work?
GrapheneOS
It works fine, we've tested it. We plan to include some additional unrelated changes before our next release, which might be significantly later today in around 16 hours or so.
GrapheneOS
Due to these changes, Revolut works with our latest release that's currently in the Alpha channel and will reach the Beta channel very soon:

https://grapheneos.social/@GrapheneOS/113895124919882463

Should be in the Stable channel within 24 hours.

We also added a Play Integrity API notification + per-app menu.

GrapheneOS (@GrapheneOS@grapheneos.social)

GrapheneOS version 2025012600 released: https://grapheneos.org/releases#2025012600 See the linked release notes for a summary of the improvements over the previous release. Forum discussion thread: https://discuss.grapheneos.
GrapheneOS Mastodon
GrapheneOS
Users are already reporting that other banking apps which were previously detecting and banning GrapheneOS are now working properly. This is what we anticipated since Revolut is using insecure 3rd party SDKs for this which are likely used by other banking apps for the same thing.
hobbsc
thanks for all your hard work!
flashbackdealer
It reminded me of my registration on Zen. Of course, I was refused to create an account, citing "security reasons" after a long correspondence with them. I looked into the file and logs, from what I realised they use the IDRnD library, which also uses the scottyab's rootbeer library, which received its last update 4 years ago and root checks using it are outdated, as there are false positives and magisk bypassing.
flashbackdealer
They do battery probing via modempowerprofile with wrong options and outdated features, attempt to covertly obtain bluetooth adapter information without requesting permission, use drm info and obtaining other properties. They are unhappy with insufficient collection of analytics and advertising data, cause no potential profit from profile sales.
Nate Metzger
holy shit, sounds like a good reason to move to anything other than Revolut. I've moved banks for less.
Lawrence Pritchard Waterhouse
Honestly, I'm not sure applying those "fixes" is a net-win. Short term it'll unblock those apps, and *maybe* the Play Integrity API will be regulated away in a timely manner, but they'll just switch to something else, e.g. like the GameBoy did: Check for the presence of a trademarked logo, string, or proprietary app being present that you are not allowed to distribute... Long term, the only winning move is not to play. Let those apps *not* work, if they so desire.
GrapheneOS
We can document all their actions against us and take legal action against them. The clearer they make it that they're going out of the way to ban GrapheneOS, the easier it is to win a lawsuit. How would they justify the ban? It's a far more secure OS and they permit an OS with no security patches for 10 years. Europe has market competition laws they're violating. Apps doing it for Google with their Play Integrity API instead of Google doing it themselves doesn't make it legal.
Lawrence Pritchard Waterhouse
You have *way* more trust in the legal systems of the world than I do. But it's your nerves and energy; Just make sure to keep in mind that those and future "fixes" MUST not negatively affect security, too many projects make unwelcome trade-offs for nebulous reasons like UX or interoperability with proprietary shit, ok? ;-)
Stephan Paternotte
this brings back memories of when #Vivaldi felt compelled to change their default User agent string because poorly designed websites were putting up barriers for alternative browsers.
https://vivaldi.com/blog/user-agent-changes/

User Agent Changes | Vivaldi Browser

Vivaldi is changing how it presents its User Agent in the upcoming release. Here is an explanation of what a User Agent is and what we are doing.
Ruarí Ødegaard (Vivaldi Technologies)
#vivaldi
Dieser Beitrag wurde bearbeitet. (1 Monat her)
nounoursfaisdeschoses
using vandium to access your revolut account, should work also ? One way to move around the ban
Dieser Beitrag wurde bearbeitet. (1 Monat her)
GrapheneOS
Their site barely has any functionality and requires using the app somewhere.
Shiro
I have not had issues with Revolut in gOS, gotta thank the team for the hard work.
Frida ⓥ 🐘
is it fixed? I was just about to migrate to graphene but have suddenly known this revolut issue. Does it work?
GrapheneOS
It works fine but they blocked logging into the app from GrapheneOS. We've fixed it and it will be included in our next release. It doesn't impact users who were already logged in. Same thing applies if they extend the check again: it probably won't impact people who are already logged in.
Dieser Beitrag wurde bearbeitet. (1 Monat her)
Frida ⓥ 🐘
thank you very much!
nat 🦗
Have you guys tried to contact seon.io about it?
GrapheneOS
We don't know which SDK is doing it. We've looked at the disassembled code and it doesn't appear to check ro.build.user / ro.build.host. It does check for the device running the stock OS and is likely part of what is banning GrapheneOS. There's no point contacting any of these companies aside from serving them with a lawsuit.
Entropy
Out of curiosity, do you know the names of some of those problematic 3rd party libraries?
GrapheneOS
https://docs.seon.io/ is one of them. We don't know all of them or which one is directly responsible for specifically banning GrapheneOS but it's a high chance it's that one.
Entropy
Thank you, other than banning GrapheneOS specifically, are there any specific behaviours these SDKs exhibit that concern you?
GrapheneOS
These anti-tampering SDKs do super shady things and are often full of issues like memory corruption bugs. They're the source of most incompatibilities with our exploit protection features. They've blocked us from shipping important security improvements which cannot be easily turned into toggles.
Cezar Lungu
Ugh, just briefly reading about the Digital Footprint of Seon and it already sounds pretty concerning.
GrapheneOS
It appears to be used to ban using any aftermarket OS in a very poorly done way but we think it's https://www.appsflyer.com/ that's specifically banning GrapheneOS since it's what's getting passed ro.build.user which they seem to check for it being grapheneos. We've worked around all of it for now but Revolut is likely going to adopt more of this nonsense including the Play Integrity API. They've shown no interest in implementing https://grapheneos.org/attestation-compatibility-guide.

AppsFlyer | Make good data-driven choices

Get visibility into performance, scale installs, and maximize LTV with a new standard of measurement and deep linking solutions.
AppsFlyer
Emelia/Emi
Banks really need to get a reckoning with regards to this "checkbox security" bullshit. Unfortunately government regulation is often written as "you must follow every checkbox to the letter on this list written by an uneducated bureaucrat that went to defcon once" so the problem persists...

My bank's app won't run if developer settings are on, much less ADB. There's just 'a few' problems with that with regards to actual security:
  • Aside from mobile deposit of checks, there's nothing in the app worth locking down (it's a browser in a tin)
  • modern Android blocks debugging of release-build apps
  • adb no longer allows backups to access /data/data for non-debuggable apps
  • Apps can check if the debugger is attached
  • And finally, if I was somehow using the debugger to be malicious at it, I could simply jump over the checks
(In other words, banning developer settings is in the words of raymond chen, a check that's on "the wrong side of the airtight hatch.")
GrapheneOS
There are no regulations requiring banks to do these nonsensical checks and GrapheneOS fully supports hardware-based attestation for verifying the hardware, firmware, operating system and the app running on top of it:

https://grapheneos.org/articles/attestation-compatibility-guide

If they're required to check device, OS and app integrity, that's fine, they can do that while permitting GrapheneOS. We're not aware of any regulation or government which would justify banning GrapheneOS. These apps take lazy shortcuts.

GrapheneOS attestation compatibility guide

Guide on using remote attestation in a way that's compatible with GrapheneOS.
GrapheneOS
Emelia/Emi
As an aside, does GrapheneOS have a way to protect global settings against invasive apps that have zero business reading their state? I rather like having 'show taps' on, and my bank apparently thinks that's a "security risk"...

Honestly given that 99% of modern banking apps are literally a browser in a tin, and browsers don't have that attestation bullshit, I'd argue that they have no right to be attesting against the OS at all for 'basic functionality'. About the only place they have an actual reason to be doing so is operations involving the camera, where there's an actual justified need to ensure it's a real camera.
GrapheneOS
We do have restrictions on which settings can be read which we use for our own settings to avoid introducing new issues. We could expand this to a bunch of standard settings but we have to consider it case by case. We don't want to do anything which would be used as justification for banning GrapheneOS instead of implementing https://grapheneos.org/articles/attestation-compatibility-guide. We don't currently hide if developer options is enabled. Apps detecting that are very misguided though. You can work around it.

GrapheneOS attestation compatibility guide

Guide on using remote attestation in a way that's compatible with GrapheneOS.
GrapheneOS
GrapheneOS
As far as we know, you can use ADB to disable developer options without disabling the settings you want to keep enabled as the UI will do. Just enable the setting you want and then turn off developer options via ADB using the settings put command. We don't know the exact key this, you'd need to look that up in the code or elsewhere.
prom™️
Technically, this seems like slander on their side?
Flesh 🐀
It really confounds me what a reasonable threat model to justify this could be here when installing a whole new OS is generally a decision a user makes deliberately.
Like, granting them the assumption that Graphene is somehow less secure, the only people harmed by that would be people going out of their way to use Graphene in the first place. No threat to their core userbase and not their fault if something goes wrong.
GrapheneOS
GrapheneOS is objectively far more secure than the most secure OS that's certified by Google which would be the stock Pixel OS. It also provides more secure hardware-based attestation for them to verify the software and app if that's what they want to do. We use all the same software-based and hardware-based security features as the most secure stock OS Android device, but we pile on a whole bunch of high impact software-based and hardware-based security with clear real world benefits.
GrapheneOS
Data leaked from companies like Cellebrite shows that GrapheneOS protects users from commercial exploits where iOS and the stock Pixel OS do not. It also shows that the vast majority of Android devices are far easier to exploit, which is already known to security researchers/engineers.

Revolut is permitting Android devices which run OS versions from many years ago. They permit devices without even any partial security backports applied for a decade. They aren't checking for security.
GrapheneOS
To be clear, we're not asking them to lower any of their standards for hardware and software security. They have no standards in the first place when they permit bottom of the barrel, highly insecure Android devices with no patches for the past decade. As you can see later in the thread, they even went out of the way to specifically ban GrapheneOS while permitting an unlocked device running a highly insecure fork of AOSP going without patches for years with no attempt to hide any of it.
GrapheneOS
We don't have a problem with apps having security standards. GrapheneOS exceeds any standards they can implement even if they only permit 1% of the Android userbase to use their app. All we're asking is that they stop banning an objectively far more secure OS running on the most secure Android hardware with full support for securely running an aftermarket OS. There's no downside apps. We don't do anything to enable fraud or cheating. They can also easily verify it's genuine GrapheneOS.
GrapheneOS
https://grapheneos.org/articles/attestation-compatibility-guide is what we're asking these apps to do if they aren't going to stop checking device integrity. This explains how they can use hardware attestation instead of highly insecure, useless software-based checks in their app. It's still not really useful for them to do this but it's certainly far more secure than what they're doing now. With hardware attestation, they can easily permit GrapheneOS by allowlisting our verified boot keys. There's no reason not to do it.

GrapheneOS attestation compatibility guide

Guide on using remote attestation in a way that's compatible with GrapheneOS.
GrapheneOS
GrapheneOS
Devices launching with an earlier version than Android 8 or which weren't compliant with Android certification standards don't support hardware attestation. None of those still receives security patches. If they want to permit devices without working hardware attestation which they almost certainly do since their standards are so low, they can keep doing it. They can permit stock OS or GrapheneOS on modern devices via hardware attestation and permit highly insecure devices via fallback.
hexaheximal
wait WHAT

I thought that they were blocking GrapheneOS coincidentally by blocking *all* non-play-integrity-approved operating systems but they're deliberately targeting GrapheneOS now???
GrapheneOS
They're specifically blocking GrapheneOS. They do not appear to have actually deployed Play Integrity API enforcement in their service yet.
hexaheximal
if that's true, they're not even pretending to not be giving into google's anti-competitive practices
Dieser Beitrag wurde bearbeitet. (1 Monat her)
GrapheneOS
It is true. https://github.com/GrapheneOS/platform_build/commit/8d0fa9f17c7e69ebc62cbdb67a3a4bf1045c16ad is one of the 2 changes which were required to get Revolut working. They are not enforcing a Play Integrity API device or strong integrity level yet but probably will require the device integrity level soon so our workarounds will stop working once that happens. Might as well get Revolut working again until then.

They're probably banning it via a third party SDK and don't know how the code works but they are explicitly asking the SDK to do this.

use non-GrapheneOS-branded build user/host · GrapheneOS/platform_build@8d0fa9f

This matches what AOSP uses for reproducible kernel builds.
GitHub
GrapheneOS
You can see Revolut shows an error about custom firmware not been supported where they claim they are "serious about keeping your data secure". This is them using an SDK to specifically detect GrapheneOS and then banning it. It is not related to the Play Integrity API at the moment. It's a client side check within the app. Play Integrity API is something their service can enforce based on the app triggering it and their service obtaining the result from Google's service.
gruff
This is a pain. Lloyds Bank (UK) app used to work well until a year or so ago when they did similar. :(

Are you aware of any info, anywhere, on which banking apps are happy to run on custom firmware?
GrapheneOS
It may work again after our recent changes to work around Revolut banning GrapheneOS. They may be using the same SDK as Revolut to ban using GrapheneOS. Neither appears to be enforcing a Play Integrity API device or strong integrity level yet, only their own very weak checks which we can easily bypass if we work on it. The issue is that there are a huge number of apps and they're creating work for us doing this.
gruff
Bah, you got my hopes up then! No dice. I realise this isn't in you, so no probs.

https://friendica-leipzig.de/photo/media/474748
GrapheneOS
Our recent changes haven't been shipped yet. The changes we're talking about will be in the next release, not the new one.
Orca 🌻 | 🎀 | 🪁 | 🏴🏳️‍⚧️
Maybe they blocked everything that is not build-user@build-host ? 🤔
GrapheneOS
No, they specifically blocked those properties being set to grapheneos. We settled on build-user and build-host to match the standard values for Android kernel builds. They are not standard values for the OS build username and hostname. Many different values are used elsewhere and the stock OS doesn't use these values. It uses Google buildbot names. Stock Pixel OS uses this:

ro.build.user=android-build
ro.build.host=r-eaf9838018e7e7ac-49w6

Others use different values.
GrapheneOS
No, they specifically blocked those properties being set to grapheneos. We settled on build-user and build-host to match the standard values for Android kernel builds. They are not standard values for the OS build username and hostname. Many different values are used elsewhere and the stock OS doesn't use these values. It uses Google buildbot names. Stock Pixel OS uses this format:

ro.build.user=android-build
ro.build.host=r-eaf9838018e7e7ac-49w6

Others use different values.
GrapheneOS
./oriole-AP4A.250105.002/system/system/build.prop:ro.build.host=r-456ae1c9fa6a8c5c-phhb
./raven-AP4A.250105.002/system/system/build.prop:ro.build.host=r-456ae1c9fa6a8c5c-77gn
./bluejay-AP4A.250105.002/system/system/build.prop:ro.build.host=r-456ae1c9fa6a8c5c-hd78
./lynx-AP4A.250105.002/system/system/build.prop:ro.build.host=r-456ae1c9fa6a8c5c-4m6w
./cheetah-AP4A.250105.002/system/system/build.prop:ro.build.host=r-456ae1c9fa6a8c5c-n2m7
GrapheneOS
./panther-AP4A.250105.002/system/system/build.prop:ro.build.host=r-456ae1c9fa6a8c5c-srpk
./comet-AP4A.250105.002/system/system/build.prop:ro.build.host=r-eaf9838018e7e7ac-zf3t
./komodo-AP4A.250105.002/system/system/build.prop:ro.build.host=r-eaf9838018e7e7ac-49w6
./felix-AP4A.250105.002/system/system/build.prop:ro.build.host=r-456ae1c9fa6a8c5c-sr3g
./husky-AP4A.250105.002/system/system/build.prop:ro.build.host=r-456ae1c9fa6a8c5c-jv20
GrapheneOS
./shiba-AP4A.250105.002/system/system/build.prop:ro.build.host=r-456ae1c9fa6a8c5c-dk5m
./caiman-AP4A.250105.002/system/system/build.prop:ro.build.host=r-eaf9838018e7e7ac-vwb8
./akita-AP4A.250105.002/system/system/build.prop:ro.build.host=r-456ae1c9fa6a8c5c-bc8m
./tokay-AP4A.250105.002/system/system/build.prop:ro.build.host=r-eaf9838018e7e7ac-tpc9
./tangorpro-AP4A.250105.002/system/system/build.prop:ro.build.host=r-456ae1c9fa6a8c5c-qw7f

It is not always the same.
GrapheneOS
Anyway, that's only the current format used by the stock Pixel OS. They have regularly changed the values of both fields over the years. It would be completely incorrect to hard-wire expecting specific values in any of these fields. Google can do that for the Play Integrity API because each build has data uploaded before release. Others are in no position to do anything like that. We know they blocked GrapheneOS specifically, likely through an SDK which did it.
GrapheneOS
They're using an SDK to determine if a non-stock OS is being used. The SDK implemented this by hard-wiring checks for specific properties used by different operating systems including GrapheneOS and LineageOS. Now that we're aware of it we can just keep removing whatever they check for. If we need to, we can modify the code in the app. After all, we have total control over everything it does and any code it runs. Relatively easy for us to deal with such badly written checks.
Woland
They do the same with e/os/

Your post is unclear: can you now for sure bypass Revolut's new policy?
GrapheneOS
/e/OS is a highly insecure OS not keeping the standard security model intact and with years of delays for full privacy/security patches along with months of delays for partial backports. They make many changes rolling back security. It's nearly the complete opposite of what we're doing with GrapheneOS. GrapheneOS is wrongly grouped with those even though it preserves the standard security model, doesn't set a fake security patch level like those do and greatly improves privacy/security.
GrapheneOS
Revolut is working fine on GrapheneOS with our latest changes included for our next release. If Revolut did things properly and used the hardware attestation API, then they could permit either the stock OS or GrapheneOS combined with a patch level check. They could also permit any other aftermarket OS preserving the security model and providing a recent enough patch level. Apps using the Play Integrity API and nonsense checks like this should either remove it or replace it with that.
Woland
That's just shocking disinformation that makes you look highly unreliable and not serious.
You can brag about your OS without inventing bad points to others.That'd bring higher trust in you

E/OS/ is quite excellent with its patches and security checks, and the issue comes from Revolut not making it easy to os relying on MicroG.

#disinformation #grapheneOS #badcommunity

#eos #degooglisation #RevolutCompatibility #banking #murena @e_mydata
#grapheneos #banking #disinformation #EOS #badcommunity #degooglisation #revolutcompatibility #murena @e_mydata
Dieser Beitrag wurde bearbeitet. (1 Monat her)
GrapheneOS
It is you spreading disinformation and misleading people promoting a highly insecure OS without even the most basic privacy/security.

/e/OS sets a fake Android security patch level across devices to mislead users. It massively rolls back the security model and disables standard security features. It is consistently months behind on providing privacy/security backports and years behind on full patches. This information is all easily verifiable.

No excuse for scamming people as they do.
Woland
@AmyIsCoolz a typical answer from GrapheneOS

It would be laughable if not so sad

I report this message GrapheneOS for diffamatory communication

@factchecking @Sourceyourfantasies
@Amy (เอมี่)
GrapheneOS
You have no expertise on the topic and are making things up to justify your highly insecure OS choice and promote it. Suggest you do basic research instead of consuming marketing materials which leave you knowing less. /e/OS marketing claims are widely debunked by many reliable sources. Stop getting info from marketing and non-technical sources.
Woland
Since the beggining of this conversation, you have failed to provide with any source at all.

@AmyIsCoolz is doing a better job
@Amy (เอมี่)
GrapheneOS
Do basic research rather than expecting people to do it for you and stop pretending to be an expert on topics you know nothing about beyond consuming marketing material for products.
Amy (เอมี่)
/e/OS barely even ships security updates in time, often having a 2 months delay. Their MicroG implementation allows for signature spoofing of all packages unlike Calyx or Lineage. It is truly one of the worst from a security POV (aside from literal jokes like Replicant).

Look, I used to use it as well until I switched to Divest (well that one died), but it makes a lot of big claims without much to back it up. You’re much better off using Lineage and Lineage doesn’t even have that good of a security
Dieser Beitrag wurde bearbeitet. (1 Monat her)
Woland
Source it please. It'd make the conversation so more interesting.
I have updates on eos every two weeks or so, and I find no source backing your security issues claims, so please feed me
GrapheneOS
The rate you receive updates has nothing to do with them being months behind on providing Android security backports, setting a fake Android security patch level after providing those without providing all the driver/firmware updates and not providing full privacy/security patches which are only available for the latest Android years without a year or more of delay. All verifiable with basic research. It is you making highly inaccurate claims to promote a highly insecure OS.
Woland
I beg you to source
GrapheneOS
Do basic research from reliable sources instead of consuming marketing material for their products. Murena are a for-profit company and are scammers misleading people with false marketing and selling them highly insecure products. If you're going to come to our threads and promote a scam, what do you expect?
Woland
Again, no source, and Murena and @e_mydata are two separeted things: @murena is a brand and @e_mydata is an opensourceOS

You're diffaming.
@Murena - choose freedom! @e_mydata
GrapheneOS
They're scammers who promote scam products with false marketing. They're the same people. The developers of /e/OS work for Murena. The fact that they have this sketchy setup of a separate non-profit and company doesn't change anything about the fact that it exists for them to turn a profit. They promote it with false marketing.

Not clear what response you expect to promoting it here. It's the direct opposite of what we do with GrapheneOS. It massively reduces security.
GrapheneOS
LineageOS already rolls back security and sets an inaccurate Android security patch level across devices. /e/OS is dramatically worse than LineageOS and lacks the most basic security. It is one of the worst choices you can make if you care at all about security. Their services have similar issues.
Strange Culprits
Revolut, a banking app provider, making dubious claims... go figure.

The Revolut enshittifiers can go fuck themselves

#grapheneos FTW
#grapheneos
Joel Haefeli
Cancelling an existing Revolut account without access to the app is an ordeal, by the way.
Nux
@stefano welcome to techno feudalism!
@Stefano Marinelli
elly
Thanks for heads-up, time to switch to a different bank. Screw them.
GrapheneOS
It will be possible to log in again in our next OS release but they'll probably take further steps to ban GrapheneOS.
elly
Yes, that's why it's pointless to use a service that's forcing you to play cat-mouse game with the vendor :)
GrapheneOS
We don't currently know if they are going to try to ban GrapheneOS again since they may not even understand they're banning it in the first place.
Dimitris Zervas
any idea when will this update roll out to stable?
GrapheneOS
When we make our next release. We don't have a scheduled time for it yet.
Paolo Redaelli
This is a **very** good reason to avoid #Revolut at all since it tells a lot on what they think about their costumers
#revolut
LukefromDC
You will never see me using any corporate app or website that wants to check my OS or hardware for ANYTHING. I don't play monetized games, I don't bank online, I don't use any site's app. Even online shopping is limited to things not found in any store and exiled to a separate quarantine operating system and such use will never touch a phone in my hands.

The really great thing about Graphene is how poorly Cellbrite works with it! From my understanding the only thing Cellbrite can do with Graphene is take a forensic image of an already unlocked phone.

This actually might happen if someone with both their own Cellbrite box and their own graphene phone needs an image to analyze say, an attempted attack without having to keep the phone out of service. It has to be booted, unlocked, USB debugging on, and here's the kicker: Cellbrite can't even bypass the requirement to authorize the particular computer connected to the phone to use the adb bridge!

I think given the events since November Graphene is going to be getting a lot of new users.
GrapheneOS
We have access to the latest Cellebrite Premium January 2025 documentation and they still can't exploit GrapheneOS in After First Unlock state to get all the data. Our defenses against the attack vector it uses have become increasingly strong with hardware + software disabling of USB-C by default, expanding use of hardware memory tagging and much more. We also have the 18 hour default locked device auto-reboot which can be lowered further. They'd likely need a new attack vector.
GrapheneOS
Bluetooth, Wi-Fi and cellular are still major attack vectors for exploiting a locked device. We're continuing to add more defenses and we could add ways of limiting the attack surface from those further. We already have Wi-Fi and Bluetooth auto-turn-off features but not enabled by default yet and auto-reboot set to the same or lower value would make them unnecessary for this attack vector. We don't have access to their code so it's our systemic security features working as intended.
GrapheneOS
If we did have access to their code we could also fix all the bugs they currently exploit in Android but we don't have that. Would be nice to get it and fix those despite our defenses working. They appear to have some Linux kernel USB exploits which we were preventing them exploiting with general exploit protections and last year the addition of our lower-level disabling of USB-C followed by enhanced software layer protection really walled off that attack vector quite well.
GrapheneOS
USB attack vector is still somehow relevant via physical tampering but it should be pretty much impossible to exploit by simply plugging something into it while locked with the default setting. If they physically tampered with the device, i.e. not simply plugging in a tool, then that opens up more attack surface since they could potentially coerce the USB controller into getting enabled and then target the firmware or low-level OS code. We can improve it further and other things.
GrapheneOS
Physical tampering with the device is the biggest thing it's vulnerable to since a general purpose SoC is not really hardened against tampering and neither is the memory. Fully encrypted RAM would be a nice upgrade in that area. Auto-reboot is the main defense against very advanced physical tampering since it's almost always going to reboot before they can get it to a special lab able to tamper with it, and it may take them months or years to even be able to do that from there.
Support GrapheneOS 667
https://reports.exodus-privacy.eu.org/en/reports/com.revolut.revolut/latest/

Report for com.revolut.revolut 10.62.1

Known trackers, permissions and informations about this specific version of this application
εxodus
GrapheneOS
Exodus has inaccurate information on what they call trackers and also especially for permissions. It's not a good source of info. It's not aware of most of the shady third party code and fundamentally can't detect privacy invasive code in general. The way they detect and list permissions is completely wrong and heavily contributes to users misunderstanding the permission model.
Ondřej Kozák
this is crazy, I am currently still apple sheep, but I plan to switch to GrapheneOS with my next phone device update (within next 2 years). Maybe off topic, but is there any revolut EU alternative with respect to GrapheneOS, if I take the barebone, what they offer = good exchange rates, different currencies accounts and debit cards? Nothing more.
GrapheneOS
We're not on an expert on that topic. Revolut will be working again after today's GrapheneOS release unless they implement more changes to ban it.
Iznogoud
that is pretty stupid
Dieser Beitrag wurde bearbeitet. (1 Monat her)
⇧