Call it anec-data but all my banking apps work in GrapheneOS, and I have several installed. There is one that reduces functionality if SafetyNet fails (have to do the 2fa flow every time I restart the app, can't set as a trusted device and notifications don't work) but it still works to access my account.
That said... I haven't tried to use NFC payments and do carry around a secondary iPhone 15 as my "business phone" these days that pretty much just has payment/banking apps on it, just in case one bank or another decides to suddenly nuke their app on my main phone...
I replaced that phone with a new one and didn't bother setting up the fingerprints. It doesn't seem to bother me too much and maybe there's some small security benefit to not having the biometric authentication enabled.
It's crowdsourced and therefore incomplete but https://plexus.techlore.tech/ has reports of compatability with the complete absence of Google Services or a replacement like MicroG.
Here in Switzerland my experience is that the big banks like UBS and the cantonal banks tend to work, while the smaller things like McDonald's and my credit card providers tend to break because they have nonsense Play Integrity requirements.
It requires that the card issuer support Fidesmo though. Many here do but I'm not sure what it's like elsewhere.
To be able to do it, you have to authenticate with your card issuer in a mobile app, similar to how you might when setting up Android Pay or Apple Pay. The mobile app then uses your phone as a bridge between the issuer and the NFC chip in the accessory so the relevant data can be written in a secure way.
But not Google Wallet, and with GrapheneOS as the connected device?
At least one of my cards required Google Play Services to have the location permission when initially adding the card though.
We really need a more foolproof technical solution for this if general purpose computing on the mobile phone is to be preserved. Perhaps some type of a remote control scheme to operate on a "slave" device. Failing that, if I do need one of such apps needing "strong" integrity, I'd probably look into getting an iPhone for those.
The manufacturers will do something about it when their hostile behaviour starts to affect their bottom line. They have been ripping us off for far too long.
Normal people just want to buy a phone and use it and they can do that today. They don't want the added complications. There is a reason Amazon is so popular and massive. The goal should be to add simplicity and not add complexity if want something to be popular.
Narrator: "In fact the market did not fix itself"
Yes, it is more secure against the user. That is not a desirable characteristic for the user, it is a desirable characteristic for the controller of the operating system.
I think the market is working just fine. (To which people usually say "for now". Well yeah, the sun hasn't gone supernova... for now)
The opposite is pretty much true when it comes to security I am generally forced to use an apple device since I can be relatively sure that my keys will be safe (not including state sponsored actors, at that point I would have bigger problems).
Now something for the market to actually solve would be poor hardware security in general making locked bootloaders serve no purpose, having strong built-in security at the SOC would diminish the advantages gained with locked down systems and would allow us to have BYOK without compromising on the general populations security.
It's not inherit to the device. Accepting updates signed by a specific key is inherit to the device.
I'm genuinely curious. What's your motivation in making up such a pointless argument/justification?
I don't understand how this works, why/how are a carrier lock and a device lock related? Shouldn't one be a lock on the baseband chip and the other on the main firmware?
For years, carrier lock on iOS devices was simply a software switch. In a lot of devices, still, if you have an unlocked boot loader you can run patched baseband firmware that doesn't care that it hasn't been told the magic numbers to unlock itself.
Unlocking the bootloader will also of course let you eliminate the carrier’s bloatware that they get paid to install and load onto it, including the things that they shoved all the way into the Android “non-disableable” list.
Tracfone called this “cellphone trafficking” all the way since the 90s when people would buy their loss leaders, flash ‘em, and flip ‘em to third world markets for top dollar.
You have to pass an actual, 'notoriously difficult' test?
What are they testing?
here are some past papers. For example:
https://github.com/MlgmXyysd/Xiaomi-BootLoader-Questionnaire...
Regarding the Service in Android's four major components, please do not select the correct statements from the following [Multiple Choice Question]
1. Service must perform time-consuming operations in the main thread, otherwise it may cause stuttering
2. Among Android's four major components, Service runs in the background and definitely will not block the main thread
3. Service's lifecycle does not depend on the Activity that starts the Service
4. A Service can only be started once; multiple calls to the startService() method have no effect
5. Service can use the stopSelf() method to stop the service
It show not only how hard the problem, but they also play on words. You also need to answer 13 questions in 15 minutes. And scoring more than 85 points to have a chance to unlock it.
https://www.bilibili.com/video/BV1jPbXzaE9d/
Because the exam difficulty is too high, some people even go to official repair centers requesting a downgrade, and snatch the phone when the technicians unlock and reflash the firmware.
UPDATE: fix the score requirement and the correct answer.
>Because the exam difficulty is too high, some people even go to official repair centers requesting a downgrade, and snatch the phone when the technicians unlock and reflash the firmware.
Are people that interested in unlocking despite the high friction? Honestly, I’m impressed.