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.
(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.)
Not a troll, I'm really curious.
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
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.
Neither situation is perfect, but the browser's rendering engine is surpassed by other priorities when choosing a phone.
I do look forward to the day I can use something like Pine as a daily phone though
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.
- 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.
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.
You seem to state it as a fact but I believe it is your opinion .
- 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.
Did you leave a word out here?
I assume you were going to write default keyboard?
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.
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.
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.
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 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.
[0] https://github.com/microg/android_packages_apps_GmsCore/wiki
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.
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.
I'm actually fine with that.
I didn't realize it was such an issue. I'll make a note to investigate how difficult it is to migrate away.
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.
Sadly, it's exactly this. It's not for your safety at all. It's for keeping stuff on your phone safe from you.
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".
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
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...
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).
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.
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.
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)
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.
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?
That would be a killer app for IPv6 if mobile networks were up to it...
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.
Then your banking app won't be available at all.
So how will perfectly valid use cases like file manager or backup manager work now?
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).
So much the worse for Android.
> 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.
Ok, maybe that's more my hope than my guess. We'll see.
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.
How so? How does SafetyNet make any end-user even slightly more secure?
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.
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.
I'm all for more security measures, but not at the cost of giving up my freedom entirely.
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.
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.
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...
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.
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.
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.
* 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...