Gregory's ServerAnd open software, like they are slowely locking down Android now
|
22 comments
@didek @tchambers @ipg Android and iOS are two sides of the same coin now. Both closed source OS's running on an open source base. Just that more of Android used to be open source… Locking down specifically how? There is far more code Google is contributing to AOSP than 5 or 10 years ago. The main thing that is no longer supported in AOSP are the high-level apps (like e-mail and such), which were important early on when not many apps exist, but these days there are numerous better options than in AOSP. And these days most such apps need to have a close server integration to be competitive. Saying iOS and Android are the same here is honestly crazy.  @hackbod So yes, Google might support AOSP. At the same time running the McDonald's app to collect bonus points on a android with a custom rom? Not worth the work. And before you say it's about security. BS. You can run your online banking and your driving license app from our interior ministry on an android that has not been patched for 3 years. On such a phone, Malware can probably get root access via long list of known CVE. But it verifies as "manufacturer-provided-bootloader-locked" so everyone pretends that it's safe. If Google cared about safety, they would check the patch level. @hackbod But that would achieve security which nobody is interested in, right?  @yacc143 @hackbod @Lillian_C14 Google have SafetyNet that is triggered when you uninstall preinstalled Facebook or YouTube from the phone, but not when OS is 5 years old. Not that checking if device is old will be a good idea eather... Actually checking how old the software is, would be probably not such a bad idea. But it would force giggle partners to provide security updates. The EU will do that in the next years (effectively from 2025 for 5 years I seen to remember), but Google could do that too. They don't. Not sure what you mean SafetyNet being triggered when uninstalling apps? Though I don't know what OEMs are doing on their devices, Pixel doesn't come with Facebook pre-installed and YouTube is pre-installed on the system image so you can't really uninstall it. Maybe this is some specific OEM doing something odd on their device? Which device do you see it on? What is the experience caused by SafetyNet being triggered? This wasn't direct or serious. Ah okay! I don't think you will ever get the ability to delete things from the system partition, because (1) that is always read-only (only modified by the boot loader and that is important), (2) it would mean factory reset couldn't return you to the original state, and (3) even if you did, you couldn't use the space because it would only free that space in the system partition, not data partition. OEMs are encouraged to use Play Auto Install instead. Ah so you are not talking about the source code, but the anti-abuse features. It is important to understand that this is not Google pushing stuff, but addressing developer demand. That is, the choice is not "Either Google provides SafetyNet or apps don't do anything," it is "Either SafetyNet or apps instead use other 3p solutions that are more fragile and problematic." In fact growing use of 3p solutions has made Android dev problematic as they break with each new platform version. By and large I don't think Google uses SafetyNet for its own apps, because it isn't seen as so necessary... except for stuff like contactless payments. And there is no way you would have contactless payments without device integrity verification. I also find it frustrating how much app developers feel the need to protect themselves from the platform with this stuff, but I don't see how to generally convince them otherwise. (And Apple's Android security FUD doesn't help.) @hackbod Ah, but the point is: Google requires manufacturers to provide the hardware functionality for a PlayStation level verification. Or they do not get the Google apps. OTOH, Google does not educate developers on correct security practices (as in check how fresh the security patches are, or even use a library that actively checks for exploits, instead of “verifying” that your user is running an unsecure 3 years old Android). Because that would cause havoc for their business. @hackbod Actually, with some tender love and care, my custom rom, with root, does Google Pay. And you won't believe it, nobody was defrauded because, shock, it's me, the owner who rooted the device. Not some malware. If I wanted to defraud anybody, I could read up on all the beautiful design faults in the EMV protocol that the payment industry managed to design into it. Google is not very anal about verification. But by not taking a stand, and not doing the right thing, they are spreading it. @hackbod So what exactly is Google fearing if Google Pay is running on a Custom ROM? The EMV protocol is meant to be cryptographically secure, and I'd hope that you store the card credentials on the secure hardware enclave that all Androids must have due to Google requirements. So what threats exactly is Google protecting against by doing a verification? @hackbod I mean I do online banking all the time on a Fedora Linux laptop, with, *gasp*, Secure Boot disabled. (Btw, SMS is still legal as a 2FA authentication under the current EU payment directive. While banks tend to force (“guide”) users into “smart apps”, the initial handshake still happens via SMS.) @hackbod So tell me because you said, “And there is no way you would have contactless payments without device integrity verification”. Against what threats does that device integrity verification protect the user/system? The secrets are in the secure hardware enclave in mobile. The EMV protocol is designed to be cryptographically secure. You should be able to publish the traffic on the Internet, and nothing bad happens. You should be able to modify the traffic and the payment fails. Okay given the false equivalence between Android and PlayStation; blanket dismissal of modern best practices of hardware security modules for software validation, at rest encryption and authentication and biometrics protection; and ignoring my points about the expectations and requirements of app developers... it seems clear there isn't really much opportunity for a discussion, so I am going to bow out. @hackbod You still have not explained which threat Google Pay protects against by verifying that the mobile is untampered, but not checking that the security patch levels are up to say in the past 12 months. And yes, Googlified Android gives App developers the tools into their hands to validate the whole system chain starting with the boot loader to the app. You call it “best practices in hardware security”. I call it Playstation style lock down. @hackbod You seem to forget that the newer "free software licenses" explicitely deal with the issue of the "freedom" of the user being able to modify the software and apply it to his device. What's the point of that freedom, if you make sure that "best practices" include making sure that the open source Custom ROM cannot run most of the software for the platform? So explain what's the threat for the Google Pay running on a Custom ROM? @didek @Lillian_C14 @ipg @tchambers isnt iOS BSD based? Or at least I know OS X used to be. |
@didek @tchambers @ipg This is what open source is.