Salta al contenuto principale


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.

reshared this

in reply to 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".
in reply to 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.
in reply to 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.
in reply to 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.
in reply to 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 grapheneos.org/articles/attest…. If apps insist on checking device integrity, that's the only way they should do it.
in reply to 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.
in reply to GrapheneOS

I wish Canada would regulate... well, any of this stuff.
Questa voce è stata modificata (7 mesi fa)
in reply to GrapheneOS

I think you were in talks with the European Commission about the monopoly tactics of the Play Integrity API. Any piece of news?
in reply to 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.
in reply to 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 ro.build/.user/ro.build.host.
in reply to 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.
in reply to 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.
in reply to GrapheneOS

These are the full set of changes fixing Revolut's ban on GrapheneOS:

github.com/GrapheneOS/platform…

github.com/GrapheneOS/platform…
github.com/GrapheneOS/platform…
github.com/GrapheneOS/platform…
github.com/GrapheneOS/platform…

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

in reply to GrapheneOS

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
in reply to Menhera Lexi

@lexi 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 grapheneos.org/articles/attest….
in reply to GrapheneOS

@lexi 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.
in reply to GrapheneOS

Fair enough, i forget that sometimes. Guess im still used to centralized social media
in reply to Menhera Lexi

@lexi 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.
in reply to 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:

grapheneos.social/@GrapheneOS/…

Should be in the Stable channel within 24 hours.

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


GrapheneOS version 2025012600 released:

grapheneos.org/releases#202501…

See the linked release notes for a summary of the improvements over the previous release.

Forum discussion thread:

discuss.grapheneos.org/d/19436…

#GrapheneOS #privacy #security


in reply to 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.
in reply to GrapheneOS

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.
in reply to GrapheneOS

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.
in reply to GrapheneOS

holy shit, sounds like a good reason to move to anything other than Revolut. I've moved banks for less.
in reply to GrapheneOS

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.
vivaldi.com/blog/user-agent-ch…
Questa voce è stata modificata (7 mesi fa)
in reply to GrapheneOS

using vandium to access your revolut account, should work also ? One way to move around the ban
Questa voce è stata modificata (7 mesi fa)
in reply to GrapheneOS

I have not had issues with Revolut in gOS, gotta thank the team for the hard work.
in reply to Shiro

@nahtosama is it fixed? I was just about to migrate to graphene but have suddenly known this revolut issue. Does it work?
in reply to fri ⓥ 🐘

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.
Questa voce è stata modificata (7 mesi fa)
in reply to nat 🦗

@nat 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.
in reply to GrapheneOS

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.")

in reply to Emelia/Emi

@becomethewaifu 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:

grapheneos.org/articles/attest…

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.

in reply to 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.

in reply to Emelia/Emi

@becomethewaifu 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 grapheneos.org/articles/attest…. We don't currently hide if developer options is enabled. Apps detecting that are very misguided though. You can work around it.
in reply to GrapheneOS

@becomethewaifu 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.
in reply to GrapheneOS

Sensitive content

in reply to Flesh 🐀

@flesh 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.
in reply to GrapheneOS

@flesh 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.

in reply to GrapheneOS

@flesh 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.
in reply to GrapheneOS

@flesh 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.
in reply to GrapheneOS

@flesh grapheneos.org/articles/attest… 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.
in reply to GrapheneOS

@flesh 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.
in reply to GrapheneOS

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???

in reply to hexaheximal

@hexaheximal They're specifically blocking GrapheneOS. They do not appear to have actually deployed Play Integrity API enforcement in their service yet.
in reply to GrapheneOS

if that's true, they're not even pretending to not be giving into google's anti-competitive practices
Questa voce è stata modificata (7 mesi fa)
in reply to hexaheximal

@hexaheximal It is true. github.com/GrapheneOS/platform… 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.

in reply to GrapheneOS

@hexaheximal 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.
in reply to GrapheneOS

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?

in reply to gruff

@4ccb4096d76c3a22767d68bd680ddccfde4943f7c6136f5e8f6deb5f2bb871da @hexaheximal 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.
in reply to GrapheneOS

Bah, you got my hopes up then! No dice. I realise this isn't in you, so no probs.

m.primal.net/NuAR.jpg

in reply to gruff

@4ccb4096d76c3a22767d68bd680ddccfde4943f7c6136f5e8f6deb5f2bb871da @hexaheximal Our recent changes haven't been shipped yet. The changes we're talking about will be in the next release, not the new one.
in reply to Orca 🌻 | 🎀 | 🪁 | 🏴🏳️‍⚧️

@Orca @hexaheximal 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.

in reply to GrapheneOS

@Orca @hexaheximal

./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

in reply to GrapheneOS

@Orca @hexaheximal

./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

in reply to GrapheneOS

@Orca @hexaheximal

./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.

in reply to GrapheneOS

@Orca @hexaheximal

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.

in reply to GrapheneOS

@Orca @hexaheximal 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.
in reply to GrapheneOS

@Orca @hexaheximal

By any chance, would you know the value to put for a Pixel 3a? (sargo). I would like to try on my phone running /e/ OS.

Thank you!

in reply to Fla

@fla @Orca @hexaheximal It would require more changes than that.

Aside from that, /e/OS is a highly insecure OS without basic privacy and security intact. We strongly recommend avoiding it. Pixel 3a is an end-of-life device which hasn't had firmware and driver patches for years, although it's not as if /e/OS ships them properly for most devices they support anyway. Don't recommend doing financial stuff on an OS and devices unpatched known remote code execution holes regardless of device.

in reply to GrapheneOS

@Orca @hexaheximal

what are the other changes needed?

About security, I know Pixel 3a does not receive firmware updates anymore, but the phone itself works very well, it would be a shame to throw it away.

in reply to Fla

@fla @Orca @hexaheximal It doesn't receive firmware or driver patches, and /e/OS is a highly insecure OS not providing other patches properly either along with not preserving the security model as a whole. It has awful privacy and security regardless of the device.

Considering that /e/OS and the company behind it are spreading misinformation about GrapheneOS and attacking our team, we also aren't really interested in contributing to improving app compatibility on it.

in reply to GrapheneOS

@Orca @hexaheximal

Attacking? I would find this quite surprising.

But anyway, I'm not asking about help for /e/ OS specifically, I just wanted to know what should be done to make Revolut works on a custom ROM, I thought changing those build param was enough so I was kindly asking if you knew the proper values for them.
And obviously if there is something else to be done it would be kind to share it. That's how free software works, collaboration 🙂

in reply to Fla

@fla @Orca @hexaheximal

> Attacking? I would find this quite surprising.

They have heavily engaged in attacks on our team including harassment. They spread harassment material from a Kiwi Farms member.

We aren't on the same side as Murena and /e/OS scamming people with highly insecure, non-private software while also harming multiple real privacy projects with attacks.

GrapheneOS is being blocked because /e/OS, LineageOS, etc. have created a bad reputation for alternate OSes...

in reply to GrapheneOS

Even as an outsider I can see how mentally disturbing that Kiwi Farms thread can be. Much of the thread is either flat out lies or spin.
in reply to Charles

@charles8191 @fla @hexaheximal @Orca The thread targeting us was created shortly after Rossmann targeted one of our team members with harassment based on spin and fabrications about them catering to his friends at Kiwi Farms. They support him and were already in regular contact with him, even out in the open via his verified account repeatedly confirmed to belong to him. It was primarily based on his harassment content and the earlier harassment content he supported.
in reply to GrapheneOS

@charles8191 @fla @hexaheximal @Orca Our contact with Rossmann was due to FUTO and he was acting in an official role of a representative of FUTO. FUTO has subsequently used their project account to directly repeat the harassment and endorse it in direct messages. Look into the organization and you'll find it's very closely tied to reactionaries and that's what they believe in. Rossmann used to have different beliefs but he's shifted towards that since around 2020 and is deep into it now.
in reply to GrapheneOS

@charles8191 @hexaheximal @Orca

I am sorry to learn that the relationship isn't good between the two projects. However I have no idea who Kiwi, Rossmann or FUTO are. I simply want to know what you did to make Revolut to work on a custom ROM. I read the GrapheneOS forum thread and thought that changing the build options was enough. Now you are telling me you did more than that, could you please tell me?

in reply to Fla

@fla @charles8191 @hexaheximal @Orca It is not simply that "the relationship isn't good". If you want help, use something from people not involved in harassment.
in reply to GrapheneOS

@charles8191 @hexaheximal @Orca well, I used GrapheneOS before I used /e/, but Pixel 3a is not supported anymore, and I am not going to throw in the bin a fully working phone. So, I use what is available and is not default Android.
in reply to Fla

@fla @charles8191 @hexaheximal @Orca You can use a highly insecure OS on an insecure end-of-life device if you want, but it doesn't only impact you. Highly insecure devices without current security patches like yours are compromised and used in attacks on servers including ours. It contributes to the centralization of the internet behind services like Cloudflare. It isn't only your own privacy and security at risk. Devices not receiving proper patches are a problem for the internet as a whole.
in reply to GrapheneOS

@fla @Orca @hexaheximal Hello friends, I'm just an end user trying to avoid the tyranny that is Google/Apple, and I'm just trying to use Revolut on an OS which is at least better than stock Android.

I would gladly use GrapheneOS but I have a non-Pixel handset, so I am trying LineageOS and /e/OS. Neither has allowed Revolut to work.

@GrapheneOS I understand your displeasure with /e/OS but for the good of the overall cause and users like me, can you please help get Revolut working?

in reply to GrapheneOS

Can you also please elaborate on your concerns with /e/OS? Maybe it's something the developer community can improve?

As I said I'm just an end user but in my opinion we all need to work together against the giants like Google, and we can only do that by helping each other.

The drama with /e/OS sounds regrettable and unnecessary, but please don't forget it's end users like me who are held back by the lack of progress in open source OSs because of issues like this (Revolut).

in reply to GrapheneOS

They do the same with e/os/

Your post is unclear: can you now for sure bypass Revolut's new policy?

in reply to Woland

@Woland /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.
in reply to GrapheneOS

@Woland 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.
in reply to GrapheneOS

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

in reply to Woland

@Woland 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.

in reply to GrapheneOS

@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
in reply to Woland

@Woland @AmyIsCoolz 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.
in reply to GrapheneOS

@AmyIsCoolz

Since the beggining of this conversation, you have failed to provide with any source at all.

@AmyIsCoolz is doing a better job

@Amy
in reply to Woland

@Woland @AmyIsCoolz 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.
in reply to Woland

/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

Questa voce è stata modificata (7 mesi fa)
in reply to Amy

@AmyIsCoolz
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
@Amy
in reply to Woland

@Woland @AmyIsCoolz 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.
in reply to Woland

@Woland @AmyIsCoolz 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?
in reply to GrapheneOS

@AmyIsCoolz

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.

in reply to Woland

@Woland @AmyIsCoolz 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.

in reply to GrapheneOS

@Woland @AmyIsCoolz 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.
Unknown parent

mastodon - Collegamento all'originale
GrapheneOS
@ententropy 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.
Unknown parent

mastodon - Collegamento all'originale
GrapheneOS
@ententropy 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.
in reply to GrapheneOS

Thanks for heads-up, time to switch to a different bank. Screw them.
in reply to elly

@elly It will be possible to log in again in our next OS release but they'll probably take further steps to ban GrapheneOS.
@elly
in reply to GrapheneOS

Yes, that's why it's pointless to use a service that's forcing you to play cat-mouse game with the vendor 😀
in reply to elly

@elly 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.
@elly
in reply to GrapheneOS

@ententropy
Ugh, just briefly reading about the Digital Footprint of Seon and it already sounds pretty concerning.
in reply to Cezar Lungu

@randshell @ententropy It appears to be used to ban using any aftermarket OS in a very poorly done way but we think it's 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 grapheneos.org/attestation-com….
in reply to GrapheneOS

This is a **very** good reason to avoid #Revolut at all since it tells a lot on what they think about their costumers
in reply to GrapheneOS

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.

in reply to LukefromDC

@LukefromDC 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.
in reply to GrapheneOS

@LukefromDC 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.
in reply to GrapheneOS

@LukefromDC 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.
in reply to GrapheneOS

@LukefromDC 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.
in reply to GrapheneOS

@LukefromDC 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.
Unknown parent

mastodon - Collegamento all'originale
GrapheneOS
@lpwaterhouse 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.
Unknown parent

mastodon - Collegamento all'originale
GrapheneOS
@Feakster 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.
Unknown parent

mastodon - Collegamento all'originale
GrapheneOS
@SupportGrapheneOS_667 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.
in reply to GrapheneOS

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.
in reply to Alvyn

@alvyntc 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.
Unknown parent

mastodon - Collegamento all'originale
syd 💕
it works again, not sure what has changed. have a good weekend