Earlier quoted context omitted.
The most efficient decentralized way would be direct end-to-end connections. One could assign an IPv6 address to each application and have the notifications just sent there, no middleman necessary. If an application takes up too much battery, just kill it by changing the address. That would be a killer app for IPv6 if mobile networks were up to it...
Many LTE networks are IPv6 first, with IPv4 only services generally performing much worse or being unreachable. All 3 US Cell carriers have made this jump, though you see people complaining about IPv4 only sites and services not loading or working poorly through CGNAT.
System Hardening in Android 11
161–170 of 211 posts
Re: System Hardening in Android 11
#162Earlier quoted context omitted.
> Enforcing SafetyNet is probably also a net positive change How so? How does SafetyNet make any end-user even slightly more secure?
It does not. Enforcing SafetyNet only makes it harder for users to use custom ROMs. It provides no benefit whatsoever to the end user. It does provide major benefits to app makers who hope to control the user's device.
However, most people do not unlock their bootloaders and install custom ROMs.
For them having an unlockeded system is an indication of something "bad" happening (spying, fraud, theft) and given how central smartphones are becoming in users life, I prefer that my mothers banking app refuses to work if her smartphones chain of trust is compromised.
I also happen to believe that it is impossible to "out-tech" OEMs in the long run and that the path to a fair app ecosystem is through legislation, regulation and anti trust measures.
That approach worked in other aspects of the economy and society.
Re: System Hardening in Android 11
#163Earlier quoted context omitted.
The security changes are nice and needed so well done. Enforcing SafetyNet is probably also a net positive change, and you (and I) are a minority among the general user base. Sadly this was always coming, it was nice while it lasted, I guess. I'm not quite sure what I will do once my current phone dies. I don't see myself investing in the Apple ecosphere, so either go with the time (do nothing) or have a second phone…
If you have wireless chargers and don't really want paid apps, you can reasonably avoid "investing" much in the Apple ecosphere these days: I have not once since switching bought something with a Lightning connector on it, and I rarely use the charger that came with it either. And the new iPhone SE is more or less the cheapest way to get a phone that's updated and well-supported.
Re: System Hardening in Android 11
#164In addition on Android 11 API * apps can't simply access the "external" storage (enforces scoped storage) * apps can't get a list of all installed apps (package visibility, they can specify app names and intent signatures in the Manifest they want to query) These are welcome changes in my view, but unfortunately they also seem intend to fix SafetyNet and require hardware attestation that the bootloader is not unlocke…
The problem with unlocked devices is that it's a legitimate security risk.
With a signed OS and hardware attestation, you can verify with 100% certainty that the foundation of the device's security model is there and fully intact. Upon that foundation you can build features that you might not be comfortable with otherwise, like an OTP app, authenticator app or a payment app. You wouldn't build an "OTP" app for Windows for example because Windows doesn't have a solid security model, it's quite easy for one application to access another application's resources.
Once that foundation is broken, all bets are off. If the bootloader is unlocked, you have no way of knowing what's running on a user's device. For all you know, all of the permission checks have been removed and nothing is secure anymore. Even the APIs you'd expect to interact with a secure enclave could be replaced.
Others are suggesting that this is the user's choice and so perhaps developers should just deal with it but I disagree. A device isn't necessarily unlocked by the user. A device can be unlocked by anybody with physical access and the passcode. For example a malicious party could install a malicious version of Android on your device if they have unattended access to your phone for a while. They could also buy phones, flash malicious versions of Android and then sell them at a slight loss, making profit off the money stolen from their victims.
There's also the problem of malware that gains root privileges. With a locked bootloader, there's limited opportunity for such malware to become persistent. It can't modify the system partition at all. With an unlocked bootloader, it can modify the system partition and permanently modify the OS. Basically, locking the bootloader prevents rootkits.
This is why these features are here. They're not here to make enthusiasts' jobs harder, they're here to provide a solid foundation of security upon which an OS that's secure enough to handle high-value information can be built.
> When this is enforced for all devices some apps, like the eBay app, won't run on unlocked devices anymore.
In some cases (e.g. games), I think this is ridiculous. For apps that deal with finance or other sensitive areas, as explained above, I think this is entirely reasonable.
All that said, I can see a world in which we have custom ROMs as well as security:
- We make custom signing keys [0] commonplace, not just a thing for Pixel devices.
- Set up an automated service through which a device can submit CTS [1] results and have its build of Android whitelisted.
[0]: https://android.googlesource.com/platform/external/avb/+/mas...
Re: System Hardening in Android 11
#165Earlier quoted context omitted.
Likewise. Termux is the killer feature for me. This needs to wait a year or two so a FLOSS phone is ready for daily driving D-:
Netflix, Snapchat, Pokemon Go, Super Mario Run, etc. will intentionally never work on a FLOSS phone, so I doubt it'll ever catch on outside the tiny enthusiast community.
Re: System Hardening in Android 11
#166I don’t pretty much like Apple ecosystem but I have to say that the best decision I made technically was to switch to an iPhone 7 Plus 3 years ago after years of Android (since T-Mobile G1, first android phone ever). I said goodbye to a lot of customizations but at the same time regain my sanity from battery life, slowness and absurd support timelines
I was also an early adopter of Android with the HTC Hero (Android 1.5/1.6), then the HTC Desire (Android 2.0) then the Galaxy Nexus (Android 4.2/4.3/4.4), but I got fed up of the support timelines too. I don't think my Galaxy Nexus even got an official update to KitKat (4.4). I got it via custom ROMs which were of questionable quality. Battery life and performance were also among my complaints. I eventually switched to an iPhone 6 in 2014 which lasted me 4 years and even then I only had to replace it because the storage capacity wasn't enough for me (16GB). The fact that apps have to ask for each permission also gave me the impression that iOS was more private/secure by default compared to Android. I know it's a moot point in current versions of Android, but it's still shocking to me that it took them so long to address the issue and that it even existed to begin with.
Re: System Hardening in Android 11
#167Earlier quoted context omitted.
You're upset about them requiring hardware attestation in SafetyNet (I am too) so you move to a platform that is way less flexible and way more closed? Not a troll, I'm really curious.
Play Services infuriate me. I have no idea what app is triggering what kind of actions via Play because all of those actions are done by Play on behalf of the app and Play is not showing it to me in enough details
I didn't realize it was such an issue. I'll make a note to investigate how difficult it is to migrate away.
Re: System Hardening in Android 11
#168Earlier quoted context omitted.
Bootloader unlock is under user control by definition - it won't happen unless you're physically interacting with the device. The legitimate case for safety net is platform lockdown for things like financial apps. Banks and other financial services like to provide some form of insurance to users wrt. losing money in a security breach, and they can't do this unless the app really is being run on a pristine, locked-dow…
> Bootloader unlock is under user control by definition - it won't happen unless you're physically interacting with the device. Root exploits more common, but bootloader exploits aren't unknown. String them both together and you can remotely root a device, unlock the bootloader, install another OS, and relock the bootloader. All of this without removing apps or data; do it properly (custom recovery for flashing the n…
Re: System Hardening in Android 11
#169Earlier quoted context omitted.
Play Services infuriate me. I have no idea what app is triggering what kind of actions via Play because all of those actions are done by Play on behalf of the app and Play is not showing it to me in enough details
As a developer, I apologise for the Play Services requirement. I believe this is a hard dependency for Firebase integration (and at the very least, it's the easiest/fastest way to implement Google Sign-in, though I assume this could be replaced with manual OAuth). I didn't realize it was such an issue. I'll make a note to investigate how difficult it is to migrate away.
Re: System Hardening in Android 11
#170In addition on Android 11 API * apps can't simply access the "external" storage (enforces scoped storage) * apps can't get a list of all installed apps (package visibility, they can specify app names and intent signatures in the Manifest they want to query) These are welcome changes in my view, but unfortunately they also seem intend to fix SafetyNet and require hardware attestation that the bootloader is not unlocke…
> These are welcome changes in my view, but unfortunately they also seem intend to fix SafetyNet and require hardware attestation that the bootloader is not unlocked [1]. The problem with unlocked devices is that it's a legitimate security risk. With a signed OS and hardware attestation, you can verify with 100% certainty that the foundation of the device's security model is there and fully intact. Upon that foundati…