Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

System Hardening in Android 11

security.googleblog.com

Post reply on HN
Print view View original

101–110 of 211 posts

Re: System Hardening in Android 11

#101

Post by [deleted] »

kelnos wrote: post #76
Noluris wrote: post #25

Earlier quoted context omitted.

Scoped storage is going to kill all the most useful apps that I use that require full access to storage (such as SyncThing). I'm going to keep using Android 10 until I die. Or just switch to Apple, since if they're going to lock everything down, I might as well go with the company that supports their phones longer than two years.

My guess would be that apps that target an earlier Android version will continue to work properly, even on Android 11. Ok, maybe that's more my hope than my guess. We'll see.

[deleted]

Re: System Hardening in Android 11

#102

Post by ocdtrekkie »

viraptor wrote: post #73
ocdtrekkie wrote: post #57

Earlier quoted context omitted.

The issue is too many Android apps won't even run without Google's malware installed. Even Google's direct competitors' apps depend on it. Skype from Microsoft will not run on Android without Google Play last time I tried it. So I needed to move to a platform where the default assumption is not that users have Google's background malware enabled, and that means anything based on Android is off the table.

Microsoft phone is dead. They're not competitors. You can also use https://microg.org/ with lots of apps already as an alternative.

Are you saying you do not believe Google and Microsoft are competitors? From office suites and chat apps to cloud services and gaming platforms, they have a lot of competing offerings.

Re: System Hardening in Android 11

#103

Post by usrusr »

grishka wrote: post #56
vorpalhex wrote: post #21

Earlier quoted context omitted.

This was abused by several apps to allow locating and identifying users illicitly. One app, say, WeChat, would ask for broad permissions for location and unique identifiers and then leave unique tracking identifiers in a shared file location. Than another app, say, a mobile game, could pick up on those shared identifiers and link you back. Why this would be a useful benefit worth setting up in an SDK across multiple…

It's not like the switch to scoped storage would mitigate much of it. You can still do all kinds of nasty things when you, for example, have access to the photo library part of the MediaStore content provider. Like adding your tracking ID to the metadata of a picture that other app would then look for. Or, you could just create a "photo" and write your arbitrary data in place of the file contents. Users won't ever no…

Why would you even break the photo? Steganography goes back hundreds of years before computers. The only challenge is too make the user keep some of the watermarked pictures (the OS can keep you from writing to files created by other apps. They are sacrificing far too much for a fight they cannot win.

Re: System Hardening in Android 11

#104

Post by jhamilton »

LeoPanthera wrote: post #34

I suppose this will kill multi-emulators like RetroArch. No-longer will they be able to load arbitrary ROMs from a microSD card or other generic storage.

Maybe they could do as VLC on iPhone does and raise a little web server that you could then "upload" the roms to, which would then save to a location the app has access to.

Alternatively, download from the web or access files in Google Drive?

Re: System Hardening in Android 11

#105

Post by Iolaum »

hddherman wrote: post #14
sitic wrote: post #12

In 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…

I switched recently to an iPhone after 6 years on Android, including messing around with Cyanogenmod/LineageOS. It's not that bad, especially considering that Android is reaching the same level of lockdown that Apple has enforced, so you might as well use something that is reasonably secure and has official software update support for 5+ years.

As long as Google allows installation of apps outside the play store this will not happen.

Moreover Google devices are the most open modern mobile devices out there now (I am intentionally excluding Librem5 and Pinephone). That is because on a Pixel you are allowed to relock the bootloader and load an image that you self signed!! This has spawned a niche ecosystem of android forks on pixel devices (look for RattlesnakeOS, GrapheneOS, CalyxOS).

Re: System Hardening in Android 11

#106

Post by no_wizard »

viraptor wrote: post #75
izacus wrote: post #60

Earlier quoted context omitted.

It provides same services as Apple ships with iOS (iCloud, Push messaging services, Find my Friend, AppStore, Location, etc.), except that in Android that's branded "malware that calls home" and in Apple world it's called "integral part of the OS". The only difference here is that in Android you can actually separate the two.

The second difference is, you can replace it - https://microg.org/

This sounds great, but reading the fine print:

>Although most microG components are far from complete, users are amazed by the results.

What users are amazed by what results? And if you read this carefully, it clearly states its missing swaths of the APIs, so its not 1 to 1 compatible and is very likely out of date in at least one reimplementation, per this [0]:

>This is alpha-grade software and not yet ready for production use. Do not use if you don't know what you're doing.

I don't think this would hold up to being what I'd use as a daily driver. I just want my phone to work not fiddle with troubleshooting weird edge cases for apps I want to use.

I applaud the project, but its hardly a simple as saying 'you can replace it' and that's the last you'll have to think about it.

[0] https://github.com/microg/android_packages_apps_GmsCore/wiki

Re: System Hardening in Android 11

#107

Post by cesarb »

kelnos wrote: post #76
Noluris wrote: post #25

Earlier quoted context omitted.

Scoped storage is going to kill all the most useful apps that I use that require full access to storage (such as SyncThing). I'm going to keep using Android 10 until I die. Or just switch to Apple, since if they're going to lock everything down, I might as well go with the company that supports their phones longer than two years.

My guess would be that apps that target an earlier Android version will continue to work properly, even on Android 11. Ok, maybe that's more my hope than my guess. We'll see.

Yes, but the other half of that is that Google will require that new uploads to the Google Play Store target newer Android versions. That is, older applications will not break, but newer applications (and newer versions of older applications) will not be allowed to use that loophole anymore. (Of course, you can still sideload...)

Re: System Hardening in Android 11

#108

Post by pricechild »

zozbot234 wrote: post #66
dcow wrote: post #51

Earlier quoted context omitted.

Wouldn't the solution be to allow people who have legitimately unlocked their boot loader to also install a custom attestation root so that safety net can still say “the software running on this phone is the software the user intended and not a malicious 3rd party”? Or maybe safety net is not so much about user safety as it is about platform lockdown and vendor safety. The number of times I’ve been laughed out of a p…

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…

I would be more sympathetic to this plan if it were also tied to update status.

Imagine manufacturers having the incentive to issue monthly security updates, else their users get very angry they can't watch Netflix/log into their bank app/use google pay...

Re: System Hardening in Android 11

#109

Post by Cactus2018 »

dstaley wrote: post #97
Cactus2018 wrote: post #42

Dear Android Product Owner, I want to have control over which Android apps 'auto-run' on my device.

This is largely due to a limitation of Android itself. If your app wants to do any sort of background task that's not tied to Google Cloud Messaging, it needs to setup those background tasks. When your phone reboots, those tasks are cleared. Many apps use the "run at startup" permission to receive a notification from the system when startup has completed. It doesn't actually mean the app is running in the background.

Oh, I see. I was under the impression that these "Run at startup" apps were using the opportunity to check-in, report telemetry, and the evil ones to start GPS tracking.

Re: System Hardening in Android 11

#110

Post by g_p »

zozbot234 wrote: post #50
sangfroid_bio wrote: post #40

Earlier quoted context omitted.

Another duopoly that needs more competition is push notification infrastructure. Efficient push notification requires OS vendor server support due to radio usage and agreements with telecommunication companies. Everybody is obsessed with closed app stores and completely missing the net neutrality aspect of the iOS/Android duopoly.

It's not clear that push notifications have to be centralised. The OS could coalesce requests for notifications while still querying multiple sources, thus minimizing the time that radios have to be powered on.

I was involved in designing a POC that proved this many years ago now (but after Doze appeared on Android, causing power saving issues). Note this was all for Android though, and I think Apple's restrictions make it very difficult to do this there.

There is a nice model for federating push services, and it worked. If you give apps a push "token" that takes the form of a URI or email-like address, the token can be namespaced by the push server provider. That can be self-hosted. An application can send push messages via websockets or a similar transport to the user's token-defined push server, and the user's apps can listen to it.

The long and short of it was that an app implementing the "push client library" would be able to do push messaging in a power efficient way, and it meant you could still only query 1 source server, that was configured well for long-lived connections. The trade-off is that you need app developers to really want to use it, and be willing to send the push messages to servers identified by the push token/URI.

Post reply on HN