* 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 unlocked [1]. When this is enforced for all devices some apps, like the eBay app, won't run on unlocked devices anymore. I've always trusted CyanogenMod/LineageOS more then than a device manufacturer, but after >10 years of using Android I think it's finally time for me to switch to an iPhone.
>I've always trusted CyanogenMod/LineageOS more then than a device manufacturer, but after >10 years of using Android I think it's finally time for me to switch to an iPhone.
I'm not trying to go inside Android vs iOS rabbit hole, as it's common knowledge that android's default privacy features pale in comparison to iOS.
But in Android you can leverage the trust of an individual app publisher as well and not forced to 'trust the manufacturer'.
e.g.
Tasker is trusted, it can automate workflows unimaginable in an iOS ecosystem and when Google's API changes broke some of its features; Google listened to the community and whitelisted it.
Don't trust default messaging app? Let Signal handle messages. If there's an SMS based exploit, rest assured Signal update to patch that would arrive faster than android update.
Got 7 year old android device, which hasn't received any system updates in say (cough) 7 years? But you only use it for web browsing, you can still use latest Firefox for android(with its own engine). Which will support latest PWA API.
This can go on and on without rooting android; none of these would be possible in iOS at least not until jailbreak(which compromises security akin to rooting) and probably until Apple steals couple of tricks from the jailbreak community.
Finally, If you are talented but poor developer from a village in India/Nigeria/any other place you can develop a PWA web app on a Raspberry Pi and release it for the world to see without any additional charges and probably profit out of it; It would work fine on Android, KaiOS, perhaps upcoming suite of pure Linux smartphone OS, but if you want it to function on iOS you'll have to invest hundreds if not thousands of dollars in equipment, pay yearly $99 fee, develop new native app with probably a new programming language, Give 30% cut to Apple when you make money out of it.
Tasker looks interesting. Any info on how it compares to iOS Shortcuts?
(also, iOS Safari has limited PWA functionality. It’s by no means as comprehensive as Chrome / Firefox on Android, but it was enough for me to make my latest site installable.)
The last paragraph is a massive exaggeration. iOS doesn't support as many PWA features as some people would like, but it supports plenty. You can't say PWAs simply don't function on iOS.
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?
I love most things about iOS design more than Android, and I've used both, but have stuck with Android over the last 7-8ish years. Mainly because of the amount that I could customize things, freely make little app projects, install custom ROMs, etc. Over the last few years, it's gotten inconvenient to tinker, and I just don't find myself bothering with it anymore. I've run into issues where certain apps stop working because of root.
But also both OS's have gotten much better and need fewer (if any) tweaks anyways to be used effectively. Especially with the upcoming change to allow iOS to use a different default browser (finally).
If the main reason I've been drawn to Android is vanishing more every year, I'd rather use the more elegant OS (Apple), regardless of how closed it is. I have a Pixel 2 that's getting near EOL (only 2 years after buying it), and I'll be getting an iPhone SE as soon as I can justify spending the money.
I guess something that helps too is I've been on a de-googling kick these last few months where I've been switching off all their services because of privacy, another benefit of iOS to me
This is true and regrettable, but that skin is still important.
I get to use Firefox, it comes with nice tracker blocking out of the box, it keeps my history in sync with my other devices and I find the UI to be a little nicer (personal taste).
Of course I'd like the Firefox that's available on Android, with extensions capabilities and web push support. But having the ability to open links from Mail in iOS Firefox would still be nice and I can't wait for it.
As much as you and I may care about that, for many (most?) people the browser chrome is the most important part.
Syncing bookmarks, UI, tab handling etc tend to be bigger pain points for individuals, as opposed to the more dev-focused aspects such as supporting a certain API in Javascript.
If you're technologically illiterate, this might be true. Witness however Firefox for Android (vs iOS), the most important differences for me being:
- Extensions support, so uBlock Origin, Privacy Badger, the best ad-blocking combination that far surpasses Safari's content blockers, which are pretty shitty; and extensions are useful for more than ad-blocking — e.g. I have another one on my tablet that turns all web pages to dark mode, whether they support it or not
- Web push notifications
- (Up until very recently) webp format support
On Android I wouldn't even install many apps, like Facebook, or Twitter, or Fastmail, I'd simply use them as PWAs (web apps), in Firefox with ads blocking on, because I could.
I still use Firefox on iOS for the history / bookmarks syncing, but it's a shadow of actual Firefox.
> As much as you and I may care about that, for many (most?) people the browser chrome is the most important part.
Except that for many/most people it's equally important to have a market choice which drives product improvements by competition. Not being able to choose a fully opensource browser engine (not even Firefox!) on iOS is a severe blow to opensource as a whole and browser engine competition in general. It's way worse than it ever was in times of IE6 - you never needed Microsoft's private signing keys to switch to Firefox or Chrome.
- OS Frameworks are not designed for the next year's IO, rebooting last years best practices, rather have long term roadmaps.
- The build system has stayed mostly the same, instead of having had multiple reboots
- C and C++ are integrated with the rest of tooling instead of feeling like an burden that has to be supported to keep game devs happy
- Everything that matters on iOS development is available in XCode, instead of being a mix of Studio templates, stuff dropped in Github that we are supposed to build ourselves and apparently official APIs (e.g. Oboe, Vulkan)
- Back to frameworks, while iOS offers high level frameworks for common workflows, Android offers Lego blocks that everyone fits in different ways with lengthy discussions on what is good Android code, MVP and whatever is the fad of the month on /r/androiddev
- When Apple does game development sessions, they actually talk about game development tech and do provide related tooling, Google talks about Play Store console and advertising for gamers. Notice that main GDC 2020 theme for the Google talks was to try to show that they are listing and trying to change, pity it came 10 years later.
- Most APIs in iOS seem to have had some though placed into them, in Android you have stuff like Animations that have had multiple instantiations, or others that have deprecated stuff even before reaching a proper release.
- When Google decided to drop Eclipse they had nothing to offer for NDK devs, almost two years later JetBrains decided to create CLion and then they had a solution. Otherwise most likely there still wouldn't exist an alternative to this day.
For me, Play Services is a non-starter: It's malware, plain and simple. For a couple years I tried to use Android without Google services, but I found it too restrictive. Most apps I'd want/need to use wouldn't even run without Google Play, even if you got the APK, since there's not really a good app store that has a lot of Android apps without Google Play. (F-Droid's hard-line open source requirement is too restrictive for my daily driver.)
I went to Windows Mobile for a while, it had more apps than a non-Google Android phone as it was, but obviously that's dead now as Microsoft has left the consumer space and literally told everyone to go buy Android phones.
Until antitrust happens, iPhone is really all that's left. I've got a PinePhone too, and I'm pretty excited about it, but it'll probably be a while until it reaches Windows Mobile-level of app availability. I've been pleasantly surprised by Apple's pro-privacy moves since I bought it, and if they're opening up changing default apps this year too, really the most problematic limitation is going to be gone.
microg is a FOSS implementation of google play services, without the malware part. Apps will still see "google play services" on your phone and mostly will run without problems, but their API calls are actually handled by microg.
You could try one of the Chinese android phones, like Xiaomi. Make sure to get an Asian import, because some models have an US/European export edition with the normal Google ecosystem.
This is an interesting experience in what a fully functional phone not from Google/Apple can be like. It may not be able to run the usual apps though, unless you install the playstore manually.
You should fear your local government most, of course, but it does not follow that given the choice you should pick foreign solutions, quite the contrary.
As a citizen you have rights guaranteed by the law in your own country. That's the very definition of citizenship. As a citizen you have leverage over your government, even if small, because you can organize yourself with others, e.g. in class action lawsuits, you can vote, you can convince others to vote, etc. Foreign governments and companies couldn't give a shit about your rights, the only rights you have are those defined weakly by trade agreements.
Not only that but data can be traded or leaked. A foreign company thousands of miles away, collecting data about you, could always leak that data to your local organized crime organizations.
N.B. I know that big companies like Xiaomi also have a presence in the US. With a big enough presence, the US government could coerce them just as easily, so if you fear the US government, it's a double whammy.
---
So this is a non sequitur. Even if you fear the US government, as a US citizen, you should either pick US solutions, or solutions from countries that have a culture and laws for preserving privacy, such as Switzerland or Germany.
Frankly as a US citizen picking products and services from a country with disregard for basic human rights, because you don't trust the US, is just stupid.
> As a citizen you have rights guaranteed by the law in your own country.
True except for some people like protesters or whistleblowers who do not enjoy "rights guaranteed by the law", or at least not reliably.
> Even if you fear the US government, as a US citizen, you should either pick US solutions, or solutions from countries that have a culture and laws for preserving privacy, such as Switzerland or Germany.
Are you aware of any smartphones from those countries without involvement of Apple or Google?
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.
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.
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.
>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.
MicroG still talks to Google services. It takes their code off your device but doesn't relieve you of the primary issue, that everything is dependent on Google's cloud services to work, and that they can still track everything you sent to them.
If my phone has to be a walled garden, Apple's seems more enticing to me for the moment. I would want to give it a try at least. I might very well regret it and switch back to an Android phone which won't get updates after two years.
I also have to say that to me, even if apps that require SafetyNet don't work anymore after unlocking, it certainly doesn't make the phone certainly useless. But I don't want to live with the inconvenience of not being able to use some random apps.
In my case I am stuck with a spare phone on android 8 since they banned wireless scanning from 9 onwards. it's a matter of functionality over perceived security. fed up with google. will check out the PinePhone
Is it clear exactly what SafetyNet does and reports back to Google?
Is its source code available (including for any TrustZone component), maybe as part of AOSP?
I am OK with the concept and I can value it also as a protection against advanced malware, but only if it is totally transparent (to me!) what data it collects and relies upon.
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.
I do not think there's actually a good way for a developer to avoid Play Services, which in turn leads me to say that you should continue to use it or whatever else lets you get the most functionality out of the Android for the least amount of pain. Objectively, an Android user is not going to disable the Play Services as Google's apps will continue to rely on it so non-Google developers should use it as well.
If you're comfortable disclosing, what is this "bad thing"? From my understanding, Play Services provides roughly the same suite of things that are also supplied on iOS, only on iOS, it's built into the OS (location services, cloud messaging, etc.), while on Android it's a modular component that Google can push updates to without a full OS update. Is that not accurate?
Everything that Google announced in the submitted article requires an OS update. So being able to push just Play Services updates doesn’t help too much....
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 product meeting because I’ve advocated for making decisions that don’t require the apps I’ve worked on to be run on google play services systems... it makes me wonder what is actually important in our industry. It’s certainly not the user privacy, freedom, and advocacy that everyone seems to be milking these days... sad times.
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-down platform. Unfortunately it also impacts sillier things like media streaming and online video games. But the best way to cope with that is simply not to use those.
> 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-down platform.
This seems like a weird policy, though. I can access my bank via a web browser on a desktop computer, which is certainly not even remotely a "pristine, locked-down platform".
That even makes it weirder that a no-name Chinese phone with an unknown ROM is considered more secure than a stock LineageOS just because it's not unlocked...
> 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 new OS) and all the user knows is that the device wasn't working for a while (until they notice the giant new notification Google services puts up now, but some users don't even know what notifications are and either won't notice or will ignore it)
https://github.com/segv11/boot-unlocker
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...
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).
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.
Except that push notifications also require work on telco's side to make sure they don't accidentally cause large battery use.
E.g. there was a long time after Apple introduced push messages where iPhone battery would drain pretty fast because many telcos would have very short connection timeouts on their routing equipment. This forced the phone to wakeup the radio a lot to reestablish connection.
This was "fixed" by whitelisting Apple/Google endpoints, so I wonder how that would work in federated environment.
> This forced the phone to wakeup the radio a lot to reestablish connection.
Perhaps, but if you can tolerate some latency, you might not have to wake the radio all that much. A huge majority of notification use cases can be delivered "late" (at least if the phone is in sleep mode) and still be useful.
Yes, and I believe both GCM and APNS perform cross-app notification coalescing, whereby a low priority notification (e.g. a news article, or some other content update) will picky-back on a high priority notification (incoming call, text message).
This is extremely valuable in reducing power usage.
(Notifications both exhibit radio usage, but also will typically turn on the display, which is a huge battery sink)
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.
That sounds to be exactly what the Push API (https://w3c.github.io/push-api/) is for the web: code can ask the user agent, “please give me a push endpoint”, and the UA gives it a URL, and then the code sends that URL to its backend server, which can then push to that endpoint, and messages will end up back at the user agent and be handed to the relevant code. On desktop platforms, Firefox defaults to using a Mozilla-operated push service, but on Android it could in theory use FCM, or Samsung’s equivalent, &c. if they supported the API.
I really don’t understand why mobile OSes don’t just adopt the Push API wholesale. Android especially. It’s such a mess having each app do its own thing and then have all kinds of problems with power saving measures; why not instead let the OS declare the push service to use (Google phones use FCM, Samsung phones use a Samsung push service, &c.), and apps just use what they’re given?
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.
Yes, but for my approach to work, the device would have to be able to use multiple addresses that are preferrably randomized. Not sure that that will work everywhere.
I am running lineage microg rom and I was literally forced to reverse my banking app (for its usage I am paying to my bank) and remove safetynet and various root checks to be able to use it (luckly they are not updating it very often).
The android ecosystem is toxic to the point where software developers are raging a war against their users.
Luckly there are still projects like lineage and microg where the software is still under control of their users, but google is slowly plugging the holes.
I hope that the true linux on phones (pine?) will emerge and stop this exploitation of user rights.
A File Manager can ask for root folder access permission but Google will closely control which applications in the Play Store can do so (but if you think that sounds good this is also the same policy they have for SMS access, and Google's enforcement of that has been disastrous as review on the Play Store is a dismal mess).
However, this will no longer get you access to Application's own folders, and so backing things up on Android gets even harder and the OS gets more anti-user.
(To be clear, this should absolutely be behind a Permission barrier. But to block off user access entirely is a toxic and unhelpful move that makes the platform less useful).
Media players are also a big deal for this. I put a lot of audio and sometimes video on my sd card and expect to be able to browse and play it. I am actually doing that right now as I type this.
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.
I have a feeling that certain apps will end up forcing their users to accept the popup for this permission in order to continue scanning their storage for "bad" filenames. (A few mobile games rolling their own "protection" by looking for TWRP-related folders, for example)
Unlikely. It's going to be a restricted permission on Google Play, which means the application must have a good reason to use it. Specifics will be provided later, but I'm pretty sure a mobile game won't have a reason to use this permission.
> Note: The MANAGE_EXTERNAL_STORAGE permission allows apps to access potentially sensitive data on shared storage. In an upcoming policy announcement, look for Google Play to provide guidelines for apps that need this permission.
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...)
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 for "secure" apps (Banking, Netflix) etc.
I agree that DRM, and control is probably the main reason why they are doing this.
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.
> 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.
In real life, the main security issue on smartphones right now is dubious quality stock ROMs and checking the bootloader won't help you with that.
The move should be in the opposite direction, it should be impossible for security reasons to query if the bootloader is unlocked or not from the device itself.
It doesn't matter whether your mother's banking app refuses to work. If her phone gets rooted, the attacker will replace it with an app that steals her credentials and then refuses to work. So even in that case, SafetyNet provides exactly zero security to the end user.
Before we enact new regulations in the hope of forcing corporations to build a 'fair' app ecosystem, I would argue step 1 is to repeal section anti-circumvention laws that give big tech one more stick to hit consumers with.
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.
If I understand these SafetyNet changes right, it's now relying on TrustZone, where "trust" frankly means distrusting the end user. This runs on a privilege level above the OS kernel, and it isn't possible to modify that firmware or extract data from it even with the unlocked bootloader, by design. It's currently used for media DRM among other things.
Jeez, WTF. Looks like I have to buy a new tablet (my old one is on its last legs) before this shit hits the markets, no way I'm gonna have a device that is either not rootable at all or keeps me from using mobile banking.
I'm all for more security measures, but not at the cost of giving up my freedom entirely.
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 companies and apps, I'll leave to your own imagination.
This would be solved if they just ported over the revokable permissions that LineageOS implements. You get real security and the app is none the wiser.
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 notice there's a broken image at the end of their camera roll.
Will this change make it look more suspicious when apps request access to photos instead of storage? Yes, sure. Will most users care about it and deny access to apps that aren't supposed to have it? Of course not.
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.
I wonder how this will impact my externally stored music library, which is accessed by two open source apps (Vanilla Music and Alarm Klock) but not managed by those apps or tied to their lifetimes.
> 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 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.
I'd say this is the biggest issue. I own both a rooted, unlocked Android phone and a locked Samsung tablet. I have no way to know how safe any particular custom ROM is, so there's no way I'm willingly going to use any of the banking-/payment-related apps on my phone. I find it baffling that people put their trust in people who are largely anonymous and have no accountability.
Depending on what your goals are, I'd recommend going down the route I chose: run AOSP.
Tagged releases of AOSP are the same base code that all the retail distributions of Android are based on, so should be just as safe.
If you have a Pixel device, the RattlesnakeOS project [0] will allow you to run your own automated AOSP distro, complete with OTAs, on AWS. It also supports adding a few modifications like MicroG.
All but the most recent Pixel devices are also supported by GrapheneOS, which is a security-focused ROM.
Both of these projects support signed builds, so once you flash them to your device, you can lock the bootloader.
That's interesting, thanks. It's going to have to wait until I buy a new phone though, since my phone doesn't have anything like this. Which leads to the next problem. I bought my phone because of its crazy long battery life. Going to a Pixel is a significant sacrifice, which again annoys me about the state of Android.
> 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.
This wipes all existing data and notifies the user that the device is not secure whenever it's booted. There's no way that a user would fail to realize this. I agree that it's unrealistic to expect apps that directly deal with money/finance/etc. to be supported on unlocked devices, but aside from that it should be fair game.
> There's no way that a user would fail to realize this.
I think you place far more trust in an average user than they deserve. If a user saw that their phone was factory reset and had a scary warning, I can easily see many users happily ignoring it and setting up their phone again, assuming it was the result of some bug.
The more tech-savvy HN crowd might be worried and flash it with fastboot to be safe but don't expect that of a random average person.
This dumbing down and locking down on phones and computers, is really worring me. I'm a power user which have been using computers as a tool which I have been in control of (more or less), but now things are really turning. Todays phones are in control of us as we lose more or more power of them. Living in Sweden, I am almost forced to use proprietary phones and software, just to live here. Any idea for what a free software enthusiast should do now that things I've loved to use are slowly being taken away from me, and being replaced by these devices contolled by these monopolies and governments?
Were you worried about dumbing down of phones 15 years ago? In the age of the rotary phones? Are you worried about dumbing down of your washing machine?
Stop looking at phones as computers. Lots of things have CPUs in them, not all are general purpose computers. Your car probably has more CPUs than you imagine.
General computing is waaaay easier today than ever.
> forced to use proprietary phones and software, just to live here
That sounds doubtful. What kind of "phones" and what kind of software does the Swedish government require you to use?
Note that I agree with your general point of locking people and power users out of the hardware they are supposed to be the owners of, it's just that part that kind of detracts from the point (I'm going to go ahead and assume phones and software are not actually required).
They are talking about BankID which is a national identification system that only runs on recent proprietery systems (mostly used on iOS and Android, but IIRC also supported in another version on MacOS and Windows).
There is no linux version available (there used to be a few years ago IIRC), and using U2F or other security devices via open standards is not supported.
It's a pretty OK system (for most people) made much worse (for some people) by not supporting standards they should have years ago. Yubikey is a swedish company, BankID is a swedish company, they both deal with identity online, how they have not actually managed to interoperate is beyond me.
Basically it's a system that caters to the masses and does a pretty good job at that but it's very bad for the non-technical (who don't have a smartphone) and the very technical (who might not use the OS'es that they support). I expect more from a system that most people use to pay their taxes.
There are also any number of security questions from the above, but I'll refrain from those.
> In Android 11, Scudo replaces jemalloc as the default native allocator for Android. Scudo is a hardened memory allocator designed to help detect and mitigate memory corruption bugs in the heap
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.
* random scripts (ex. When I was losing weight, I tracked calories with some shell scripts. I also have one that uses root and /system/bin/input to automate things.)
Half-jokes aside, keep in mind you can use small Bluetooth keyboards and get a micro-laptopish experience, or connect the phone to a monitor or TV and use a large Bluetooth keyboard to get a more desktop-like experience.
I imagine a terminal could work very well in those settings, if you need one.
The option is simple although tiresome, reimplement it in Android Java or Kotlin, instead of trying to pretend Android is Linux, given that POSIX or Linux specific calls aren't even part of NDK Stable APIs documentation.
Any app that access the Linux features directly just works out of luck, given that there are no compatibility guarantees.
I managed to get VS Code (as code-server) running natively and dotnet running on my Android tablet. It makes it a nice little development machine.
Basically anything Android native is horrible for developers; you can't even get a decent IDE or text editor. You still don't have source control, web servers, programming languages, etc. Termux with a few addons gives you all that.
I wish Google would recognize the value of a real Linux/Unix environment the way that both Apple and Microsoft have in recent years.
That's my point. Everything available for Android proper is a toy. I have a Tab S6 with 8GB of RAM and 256GB of storage -- it can do a lot more than play Netflix.
My point is that I am fine with it, I don't want to code on the go on my phone, beyond some toy programming while on the bus, train or waiting for check in.
Coding on Nokia Communicator (even the latest versions) or Nokia's Linux based phones/tablets was also not the best ergonomics.
Also I don't care about having a Linux CLI or something like Termux, any kind of devenv is ok for me, so to extend my list, if you want to develop Android apps on S6, then install AIDE- IDE, it will surely appreciate those 8GB.
No I did not, from my point of view we should embrace new computing models instead of trying to turn everything into a PDP-11, and from that point of view there is AIDE- IDE, and plenty of other developer like experiences.
If none of them are good enough, it is like my business professor used to say, market opportunity.
New computing models are more restrictive and less focused on creation and more on consumption. That's fine for some people but this is hacker news. If there were a new computing model that supported my use case, fine, but there isn't. Playgrounds suck for adults. I've tried every Android editor and IDE and it's like going back 20 years.
Our hardware is now powerful enough to support all computing models in whatever sandbox you want. There's no reason I have to give up my POSIX CLI. Personally I'd prefer Android native GUI software capable of interfacing with a Linux technology stack that can run programming languages, web servers, etc. This should be obvious and yet somehow it's not available.
No market opportunity because the OS is locked down making all this impossible.
Right now on Android I'm using Termux with an proot Ubuntu userland and running code-server which allows me to run VS Code as a PWA on Android. This is, by far, the best configuration I've found. But soon Google will make even this hack on hack impossible.
I think some Linux desktop users might have issue with that statement.
> No it isn't, you just have to free yourself from POSIX chains and embrace Android APIs and architecture models.
Each app in Android runs completely isolated from every other app (and more so every day). You can embrace Android but you have to throw out literally the last 50 years of technology. And plus, Android itself is kind of awful. It's the most hacked together OS that's been created in the last few decades. New does not mean better.
Are you really expecting developers to basically recreate the last 50 years of software development tools? What makes you think that's viable?
It's not surprising that most pure Android tools suck because they can't leverage everything that has been done and is currently being done on the desktop, servers, etc. Everything has to be recreated almost from scratch or shoe-horned in and it's awful.
Android tablets have very few users. And I doubt giving a Linux shell will change that. Chrome OS runs Android apps now. It also has tablets and convertibles.
It's literally a Linux system. I mean, yeah, Android/Linux isn't GNU/Linux, but there's literally a Linux kernel under there and it's certainly usable enough with termux or such providing a saner userland.
My point is that the permission issue is completely unrelated to the unstable API issue. If you don't have permission to do something through raw Linux syscalls, you won't have permission to do it through the official stable API either.
I have done Android coding since version 2.1, never felt the need to do raw Linux syscalls.
This is what many seem to fail to understand, Android is not a Linux distribution as such, trying to pretend otherwise will only lead to disappointment.
Because of this " If you don't have permission to do something through raw Linux syscalls, you won't have permission to do it through the official stable API either."
Just because you aren't supposed to do Linux syscalls directly, doesn't mean there isn't an Android compliant way to achieve the same goal.
For example, you aren't supposed to fumble with Linux networking APIs directly rather use the NDK and Java APIs for the same.
Android 10 poses significant friction with termux. So far I believe the solution has been to target android 9, but google will not allow that indenfitely and updates to play store must likely at some time target android 10.
That is my very informal and perhaps very obsolete view of it. But I could be misremembering details.
"In Android 11, Scudo [1] replaces jemalloc as the default native allocator for Android. Scudo is a hardened memory allocator designed to help detect and mitigate memory corruption bugs in the heap"
I am curious about the performance impact of this change.
I found this [0] 2019 blog post from what looks to be one of the people credited in the blog post (Kostya). It's not directly comparing Android+jemalloc vs Android+Scudo, but it does compare the two allocators and others.
Most Android apps probably allocate more with the JVM than they do malloc, right? My intuitive guess is that they could regress the performance of libc malloc and many people wouldn't notice.
Don't forget restricting the execution environment, breaking things like Termux and partially obviating the advantages of having an Android device in the first place!
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?
This is nice and all, but bigger issue is when will Android phones reach Android 11? Has fragmentation gotten better? Do most phone manufacturers support upgrading to major versions of Android (it does not seem to be in their interest)?
It's really no secret after all these years that you need to buy a Google phone to get best support for their OS, just like you need to buy an Apple hardware to get support for their OS.
I bought a Nokia 6.1 around 2 years ago, which is part of the Android One program and it worked well! Had all security monthly updates, the system is clean and stable, updated to major versions of Android smoothly without any issue.
If I can, I will buy another Android One phone. There is an horror story about an Android One Xiaomi phone, but Nokia delivered the promise with the 6.1, according to my experience
> There is an horror story about an Android One Xiaomi phone
Which one? I had a Xiaomi Mi A1 and nowadays I have a A2, both are fine Android One phones that still receives updates (in the case of A1, only security ones, but the A2 received a Android 10 update).
Yeah, Xiaomi may take a while to update their phones in Android One program, but otherwise it is fine.
Google still has shorter support periods than Lineage manages. The Nexus 6 was dropped by Google at Android 7 but you can install Lineage 17.1 (10.0) on it today. Same with some really old devices like the Galaxy Note 3 or S4. And even older devices got supported up to Android 9 like the S3 or Nexus 5.
The real secret is to buy one of the devices the real core Lineage developers maintain because they will keep those security patches and major release updates coming to you for free that these billion dollar corporations couldn't be bothered to do.
If the entire Android ecosystem wasn't a disgusting exploitation machine meant to produce more rare earth metal waste than naval warfare by forcibly obsoleting devices every 2 years everyone would be better off. Every company could be sponsoring free software devs to support their phones in something like Lineage in perpetuity while paying a fraction what they do for their large internal dev teams to do it. But the perverse incentives mean they don't want to update phones, which also means making it hard to support their device in a real operating system like Lineage is in their interest.
The problem is that Lineage does nothing to update the device driver stack where most security issues are found. Bumping up the Android OS version doesn't make you more secure in that respect.
To be honest I don't understand how this works e.g. even with LineageOS' PrivacyGuard I still see some background processes in cache that had no permission to run on boot.
But it's absolutely necessary. I can't upgrade until I have that. I want full control of what runs on startup and what should be allowed to keep running on background (manually closed by me, I'm not asking for a skynet AI to guess).
Another one is blocking internet access but that will never happen because of their business model and ads. I guess I'll have to risk my personal data by using an open source firewall (not like I'm not going to review all the code) and unlocking bootloader/root.
Android is a disgrace because of these "small" things that they refuse to fix. But I'm glad it's slowly getting better.
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.
At least for the last you can go into Settings->Location and either revoke location permissions entirely or at least make sure they're set to "Allowed only while in use".
I am on Android 9\Pie, and from an app's settings, clicking 'battery', then clicking 'background restriction', I can choose from 'app can use battery in background' or 'restricted'.
But what I originally asking for control over is running at startup.
For example: go to an app like Lyft's settings, Permissions, then "..." in the top-right, and select "All permissions", finally towards the end of the list of all permissions is "run at startup". What I want is to enable\disable "run at startup".
> Prior to the Release of Android 10 we announced a new constrained sandbox for software codecs. We’re really pleased with the results. Thus far, Android 10 is the first Android release since the infamous stagefright vulnerabilities in Android 5.0 with zero critical-severity vulnerabilities in the media frameworks.
It wasn't mediatized, but there must have been like a new stagefright-like media library bug every 2-3 months since stagefright was first publicized. Glad to see this news.
Also, how are they enabling memory tagging if it's an Arm v8.5 feature and new Arm CPUs, except for Apple's own chips, don't seem to support newer than Arm v8.2? Is it just the software version of memory tagging (with some expected performance penalty)?
You've mentioned this before but as far as I am aware there are no chips shipping with MTE, and the links you provided don't support this point either. Even if MTE somehow starts shipping tomorrow I cannot see Google dropping support for every device that is older or cheaper than the one flagship that'll use it.
The official statement, is from Google and ARM, not from me.
From my links above, the TL;DR; snippets are
> Google is committed to supporting MTE throughout the Android software stack. We are working with select Arm System On Chip (SoC) partners to test MTE support and look forward to wider deployment of MTE in the Android software and hardware ecosystem.
> Starting in Android R, for 64-bit processes, all heap allocations have an implementation defined tag set in the top byte of the pointer on devices with kernel support for ARM Top-byte Ignore (TBI). Any application that modifies this tag is terminated when the tag is checked during deallocation. This is necessary for future hardware with ARM Memory Tagging Extension (MTE) support.
> We’re also enabling heap pointer tagging for apps targeting Android 11 or higher, to help apps catch memory issues in production. These hardening improvements may surface more repeatable/reproducible app crashes in your code, so please test your apps.
For the chips without MTE they plan to configure the kernel to randomly target processes for fuzzing.
> GWP-ASan heap analysis - Android 11 uses a variety of tools to harden security-critical components in the platform and apps. In DP3, we’re adding GWP-ASan as another way to help developers find and fix memory safety issues. GWP-ASan is a sampling allocation tool that detects heap memory errors with minimal overhead or impact on performance. We’ve enabled GWP-ASan to run by default in platform binaries and system apps, and now you can now enable it for your apps as well. If your app uses native code or libraries, we recommend enabling GWP-ASan and testing as soon as possible.
> GWP-ASan is enabled on some randomly-selected system applications and platform executables upon process start-up (or when the zygote forks)
> Only recently, Google announced that it is adopting Arm’s MTE in Android. This is exciting news, with Google showing its continued commitment to security in the Android ecosystem. It also shows the strength of our MTE offering, with the article stating that the technology makes “it very hard (if not impossible) to exploit memory bugs.” Alongside the security benefits, the disruption caused by not addressing memory safety bugs reduces user satisfaction and increases the cost of software development. With all these threats to the Android Ecosystem, you can understand why Google has made the commitment to MTE!
So those are the words from Google's Android team and ARM, whatever ARM CPU are being shipped, or alternative CPUs that Android devices might still adopt or be using.
Right, all those seem to point to greater MTE support and hardware tagging when available. But I don’t think any claim that Android 11 requires a new chip to be supported?
Maybe it is my lack of native English understanding, but I read sentences like this one "Only recently, Google announced that it is adopting Arm’s MTE in Android." in another way as you do.
It doesn't make sense adopting support for non-existing hardware.
Ah, I see the confusion. I interpreted https://news.ycombinator.com/item?id=23695227 as “this is a requirement of Android 11 and as such you can’t run the
OS at all if you don’t have the new hardware supporting it”.
That as well, from Android documentation I understand this,
> GWP-ASan is enabled on some randomly-selected system applications and platform executables upon process start-up (or when the zygote forks). Enable GWP-ASan in your own app to help you find memory-related bugs, and to prepare your app for ARM Memory Tagging Extension (MTE) support. The allocation sampling mechanisms also provide reliability against queries of death.
As stop gap solution until MTE is widespread across all Android devices.
> we did all that work on the OS but kept the GoogleService thing that is a sytemapp+kernelmodule+backdoor on top so we can continue to serve our users as they want, with more relevant ads.
I 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
> at the same time regain my sanity from battery life, slowness and absurd support timelines
If the phone had bad battery life or was slow to begin with, don't buy it. If it doesn't and it suddenly appears while you're using it... that's user error.
Support: I'm really not sure what kind of support you're expecting, I assume not "how do I take a screenshot" kind of support. I once returned a phone for warranty but the support delay on that was the time it took me to look up a few website pages if I remember correctly. Is that what you mean? Or maybe it's about how long the warranty process takes: it took almost 2 weeks to repair it for me (from the day of dropping off until the day I could use it again), that is indeed quite long for a fairly essential device, but that seems to be the standard for any laptop or phone (unless you bought a service contract, which I guess one implicitly does with Apple given its pricing).
For the support I meant the security and OS patches X years after the phone released. My wife iPhone 6s is still receiving iOS update at this time. Now try that with most expensive Android flagship. I don’t care if it comes from Samsung LG or Google I could always argue against you!
But you also paid 2x more for it, so it evens out.
For instance Pixel 4 is 74000JPY with 3 years of updates = 24667JPY/year
Galaxy S20 is 78000JPY with 4 years of updates = 19500JPY/year
iPhone 11 Pro is 120000JPY with 5 years of updates = 24000JPY/year
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.
* 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 unlocked [1]. When this is enforced for all devices some apps, like the eBay app, won't run on unlocked devices anymore. I've always trusted CyanogenMod/LineageOS more then than a device manufacturer, but after >10 years of using Android I think it's finally time for me to switch to an iPhone.
[1] https://groups.google.com/forum/#!topic/safetynet-api-client...