Quick note: Google's Advanced Protection program disallows sideloading apps, so you can't install F-droid.
Edit: Note that the Advanced Protection program is opt-in for users that require the highest degree of security Google can offer. Regular users won't be impacted by this.
I wonder what the actual numbers are on malware installed via side-loading and malware installed from the play store.
There is no shortage of sketchy apps on the play store.
Through my personal bias I would imagine that most people side-loading apps tend to be people using F-Droid who know more or less what they're doing. Although I'm sure there are some people who blindly follow sketch website telling them to install sketchy APK directly. But do these people really outnumber people installing flashlight app from play store that steals your data?
All this locking down your device "for your own protection" assumes that the play store software is actually vetted and secure, but that second piece never seems to fall in to place.
This random article [1] suggests that 67% of malicious app installs comes from the play store itself. So this whole "Advanced Protection" scheme only protects against 23% of threats. Pretty weak IMO.
The problem is, it's much easier to be socially engineered into installing something from the Play Store, or far worse, the Chrome Web Store, and both have extremely unchecked amounts of malware.
The real difference is between "apps that have to give Google 30%, and apps that don't".
Likely but not because no filtering at is is better than mediocre filtering rather precisely because it's not easy for a user to "accidentally" side load.
Tons of apps are referencing 100% turing complete web content and not taking flak.
NORPS don't "accidentally" side load by means of typing stuff in a terminal that makes them both feel hackerman and scared shitless at the same time.
Only boomers and ties believe it's not about anti competitive behavior.
> There is no shortage of sketchy apps on the play store.
Certainly the Play store being a walled garden which appears to be full of weeds, nightshade, and hemlock is one of the key factors in pushing me over to iOS.
If side-loading is generally discouraged to the point where it's a hassle, then it's a less attractive entry point for malware authors... so I'd expect the result is that there are ultimately fewer malware instances installed.
If side-loading becomes easy and normalized though...
Sure but does a 23% malware rate justify further restricting side loading? Seems like snake oil security, rather than addressing the bigger problem of malware through the official channels.
Wow! That is a very big deal!!! Almost all of the Apps I have on my Android phone are installed from F-Droid, and I try to avoid installing any Apps from other sources, exceptions force upon me by my social circle, like WhatsApp.
I have a PinePhone but it is not yet ready as a daily driver, and also the difference in hardware performance between my Android phone (which I bought this year) and PinePhone (or even Librem) is abismal. I wish there was at least one (or many) linux phone ready to be a daily driver and with hardware comparable to modern Android phones (or iPhones), but unfortunately that is not yet the case, although the community has made a massive effort this year to advance the state of linux on phones, at least for PinePhone...
I use a MacBook for work and same thing, almost all the apps I have I installed using homebrew (and the UI apps, with brew cask)
EDIT: I see that, at least for now, it's optional and you can un-enroll, which is good.
> EDIT: I see that, at least for now, it's optional and you can un-enroll, which is good.
It's always going to be optional. It's their solution for high-risk users (think: journalists, whistleblowers, and similar), it's not meant to be for everyone.
Disclaimer: No Google affiliation, but I've tested the program a long time ago before it was available to everyone.
The problem will start with such offerings only if third parties (like employers or banks) demand turning this on. The patronizing of users that started with saftynet is horrifying. I think it will become crucial that some commercialy relevant group uses non play store content. Otherwise the affordance to use non main stream stuff will become higher and higher.
I have a strict "if you want me to use a phone for work, then issue me a work phone" policy. No, I will not install your MDM app on my personal phone, because that is tantamount to surrendering my phone to the company.
I mean it makes sense. The employer requires you to only trust Google-approved apps since something like an evil maid (or mugging, or blackmail, etc) attack on an unlocked phone is part of their threat model.
And it seems reasonable for an employer. What about banks? The argument I'm coming up with just isn't as compelling for no other reason than I'm 'only' risking my money, not corporate access.
> I have a PinePhone but it is not yet ready as a daily driver, and also the difference in hardware performance between my Android phone (which I bought this year) and PinePhone (or even Librem) is abismal.
I don't know about it being so much a hardware performance issue, rather than a software optimization issue. Personally, I don't think I need much performance, but I have had issues unlocking my Pinephone because the lockscreen seems to have a hard time keeping track of my finger as I slide it or press the keypad buttons. I've also had a number of kernel panics in the few times that I've used it (I got it just recently).
For the Pinephone to be my daily driver I just need to be able to run Whatsapp on it (so run an Android emulator with access to the SIM card, I imagine; haven't tried) and take real 5MP images. That's all I really need to switch the SIM card and leave my Android phone at home. It can even drop calls and I won't really care (not that it does; I haven't tried).
EDIT: I see I misread a bit and thought you meant its low performance prevented its use as a daily driver. I don't think it makes sense for linux phones to be offered with more expensive hardware until the software catches up to enable their use as daily drivers for more people. I think we're at a stage where the buyers are primarily people that are looking to possibly contribute to the software to get it to that point. Being a cheap phone is important for that.
Your Whatsapp running on an Android emulator doesn't need to have any access to the SIM card. You only need to have the SIM card on some phone so you can enter the code you're receiving by textwhen signing in for the first time.
You can then use a bridge to connect it to Matrix and chat using Whatsapp from any Matrix client.
Oh wow! Thank you so much for the tip! I've never used Matrix, but I'll look into that! Not having to depend on the Whatsapp client sounds like a dream.
> Almost all of the Apps I have on my Android phone are installed from F-Droid ... I see that, at least for now, it's optional and you can un-enroll, which is good.
I can't see it going away. Google uses it to fend off monopoly accusations, viz you aren't locked in, you can always use another app store. Apple doesn't, and they are in a much more threatening territory when it comes to anti-trust law suites against their app store because of it. https://www.cnbc.com/2020/10/06/house-antitrust-subcommittee...
Google has far worse anti-trust problems than Apple in general because they own 80% of some markets, and is being reminded of it repeatedly by ongoing law suites being brought in various countries. https://www.vox.com/recode/2020/12/16/22179085/google-antitr... But for Google Play they have a free pass, and I don't think they aren't likely to give it up any time soon.
I learned recently that having Advanced Protection enabled also rewrites all URLs in your email messages to use the Google URL redirector, even when accessed via IMAP.
It breaks PGP signatures, among other things.
No way to turn it off without disabling all of Advanced Protection. Sweet, huh?
Office 365 does that too - and Twitter by the way... Copying & pasting URL is becoming mostly a tedious rigmarole of opening the link, seeing what it finally resolves to - and only then copying & pasting...
Which advantages does Advanced Protection give you in particular so that you have enabled it? It seems that things like hardware 2fA should work without it as well? Genuinely curious.
It forbids 2FA with anything other than U2F hardware, which is practically unphishable. I don't really trust the Google auth system without the hard "disallow all non-hardware-based auth" restriction, due to the innumerable stories about sim swapping, et c.
I am on it and like it. It seems to explicitly forbid a bunch of edge cases in the login auth that would otherwise be tricky to configure properly and keep up to date. Yes, you can set up and use hardware key auth without it, but it's nice to guarantee that you can never login without a hardware key no matter what. IIRC it closes off a few other types of misconfiguration or over-authorization that might allow someone to exfiltrate data from your account.
I use f-droid, and I'm lucky enough to be one Android version behind. Can someone who's upgraded let me know what to expect when I upgrade? The blog post mentions that adb still works. Does this mean I'll have to use adb once to install f-droid and have it work normally after that, or will _every_ app need to be installed using adb?
Advanced Protection is an opt-in for people at risk of targeted attacks. Unless you have a company phone, it's unlikely to be enabled without your knowledge.
And even if you disable it, it can still block you.
I didn't try to reset my phone completely, but I have to Force Stop the Google Play Store and empty cache/user's data to install any apk
You can sideload apps via ADB. And once an app is installed that way you can then update it normally with an APK going forward. (I have Advanced Protection and I do this.)
Thanks for the clarification. I was going to say I might as well just switch to Apple if I can't sideload and enjoy some freedom with my phone even if it's not as free as I would like.
> Quick note: Google's Advanced Protection program disallows sideloading apps...
According this rule, all web browsers should be removed from Google Play too, as JavaScript apps (embedded in webpages) are "sideloading apps" by design.
Ok thanks. Somehow must have missed that one - I guess it's voluntary unless you install some work related app where company security policies pretty much default to switching off any possible loophole. I don't like where this path is going to lead :(
> Note that the Advanced Protection program is opt-in for users that require the highest degree of security Google can offer. Regular users won't be impacted by this.
Yet. Google seems to be restricting Android more and more with each release.
I fully switched to the PinePhone last year because of this.
The AP program is optional and only for people with high security needs. The restrictions make it utterly inappropriate for unskilled users, so it will never be expanded to the general population.
Note that there are 297 hidden items in that issue so you have to click "Load more..." ceil(297/60) times to read all of the comments about how APK packaging is soon necessary for latest Android devices so the termux package manager can't just dump executable binaries wherever.
FWIU:
- Android Q+ disallows exec() on anything in $HOME, which is where termux installed binaries that may have been writeable by the executing user.
- Binaries installed from APKs can be exec()'d, so termux must keep APK repacks rebuilt and uploaded to a play store.
- Termux shouldn't be installed from Google Play anymore: you should install termux from the F-Droid APK package repos, and it will install APKs instead of what it was doing.
- It seems C compiled with clang on the device wouldn't be executable? (If it was, that would be a way around the restriction: distribute packages as source, like the good old days)
This seems a promising solution: compile from source, create an apk, install - your custom distribution! For popular collections of packages, a pre-built apk.
- Java might be explicitly blocked, being a system language for android, even though its byecode is interpeted and not exec()ed.
- Other interpreted languages should be OK e.g. python
DEX bytecode is compiled to native code since Android 5, Android 7 introduced a multi-layer where it is intepreted only to get the first execution profile for the JIT, then the JIT gathers PGO data while executing, which will be used by AOT compiler when the device is idle, afterwards only the pure machine code binary executes until the next update, or loading code that wasn't touched by the JIT.
As of Android 10, PGO data files are uploaded into the store and shared across similar devices so that the AOT compilation with PGO can be done right away on installation.
Unfortunately not. The underlying mechanism they're using to enforce this is essentially: if your app can write to a directory, it can't execute from that directory.
Apparently this is plugs a vulnerability known as W^X. See their explanation in the issue here[0]. Personally I would love to know how many real-world exploits they can blame on this specific vulnerability, stacked up against the number of truly useful apps like Termux that have now been hamstrung.
Also, this leaves the state of running native executables on Android as something of a joke. Any executable you want to run has to be named `lib<exe_name>.so`, and included in your jniLib directory at build time.
It's clear what side GOOG has picked in the war on general-purpose computing[1].
> > offer users the option of generating an apk wrapping their native code in a usable way.
> This seems a promising solution: compile from source, create an apk, install - your custom distribution! For popular collections of packages, a pre-built apk.
FPM could probably generate APKs in addition to the source archive and package types that it already supports.
The conda-forge package CI flow is excellent. There's a bot that sends a Pull Request to update the version number in the conda package feedstock meta.yml when it detects that e.g. there's a new version of the source package on e.g. PyPI. When a PR is merged, conda-forge builds on Win/Mac/Lin and publishes the package to the conda-forge package channel (`conda install -y -c conda-forge jupyterlab pandas`)
The Fedora GitOps package workflow is great too, but bugzilla isn't Markdown by default.
Yeah, I think you're right: you could download instead of compile, it's just the assembling into an apk on the device that has the advantage of customizing exactly what you want.
Are there any SELinux + Android experts there? Do you know if there is a way to alter the policy to undo this change with root privileges without disabling SELinux enforcement entirely? It fundamentally seems like it should be possible; I just don't know how. It would get around the issue very nicely if someone can figure out how, since I imagine many people with Termux also have root.
Sadly, since January 1st, 2020 Termux team dropped[0] support for Android 5.x/6.x, so actually in F-Droidrepo it now requires minimum Android 7.x:
> Support for Android 5.x.x - 6.x.x is dropped forever. Time to upgrade your devices or learn how to backport git changes.[1]
And this part from Termux devs reply is especially cynical:
> ... Time to upgrade your devices...[1]
It looks like they has a contract with devices manufacturers...
... No, I no need such type of "app improvements in new version" which require me to buy a new device.
FTR, In F-Droid Archive[2] repo there is still Termux v0.75 for Android 5.x/6.x (which I'm using on Ido device), but it is horrible because Termux packages repo for Android 5.x/6.x are now disabled[3] too.
I think this was a very logical thing for them to do.
Supporting platforms that old comes with a massive amount of headaches. It is hard enough for big teams of applications with high MRR to do, and is near impossible for a FOSS application to do in perpetuity.
Because 5 year old isn't really that old. My Android 5 powered phone (which is my only phone) works perfectly fine, the only annoyance i have with it is that it has become sluggish - but that is the fault of software developers bloating their code (the software pretty much does the same stuff as it did when i got the phone years ago), not of the phone itself.
Note that i do not expect someone to do free work for me, i just do not consider a 5 year old device "old" enough to be weird for it to be supported - especially when it works just fine.
Apple devs has a smart trick how to declare you to buy new iPhone {n+1} just next day after it out: Apple devs just may decrease performance of your previous iPhone {n} fully remotely without any prompts to you and without your permission.[0]
And such remoted control over users costs only $500M single pay - not too much as for Apple at all.[1]
P.S. My 10+ year-old laptop perfectly works with latest MX Linux distribution (based on Debian 10 buster) and all modern FLOSS desktop apps (GIMP, FreeCAD, Inkscape, etc.) works like a charm on it.
So, software devs should NOT declare users to buy/upgrade hardware.
Phone manufacturers certainly ought to offer 5+ years of OS updates. Apple does, after all. So I agree with you to that extent.
But if users want third parties volunteers to support devices whose vendors have already dropped support? If there are no volunteers wanting to do the work, the work doesn't get done.
The bad guys here are the phone vendors, not the Termux developers IMHO.
I mean, I'll admit its tone is quite direct - I guess they could have copy-pasted some corporate-speak about what a difficult decision it was and how very sorry they were about having to make it, instead of being so direct and unambiguous. But that's pretty trivial IMHO.
Now that just comes off as being written by someone who feels very entitled to the hard work of others.
If you feel so strongly about it, why don't you fork the project and continue integrating upstream features and fixes for those on pre 7.x devices? Or would that take too much of your own time to do?
If you're committed to sticking with a really old phone and want to use Termux, you should switch to a custom ROM based on more modern Android. Android 5 and 6 are ancient at this point.
While i do not agree with the expectation that others should do work for free, 5 year support is really short when the devices work perfectly fine. Why contribute to e-waste and force people spend money they may not have when that isn't necessary?
5 years is okay for a phone, but once you subtract the time it takes for Android releases to get into new phones it can be a problem. Hopefully the manufacturer releases OS updates! Hopefully.
For an open source project, yes. There aren't enough people to really work and maintain this thing.
But in general, hell fucking no. 5 years is terribly short sighted. Look at how much e-waste is piling up. We can't really recycle phones. They get shipped to Asian and African countries where people melt down the plastic without adequate ventilation and extract out all the metals they can in OSHA free environments.
We should be designing things to be as useful as possible for as long as possible.
TL;DR: Android is trying to enforce all data being either writable, or executable, never both. iOS already does this. There are big security benefits (it becomes much harder to exploit an app).
A disadvantage is it becomes much harder to make things like terminal emulators and things that want to download random code and run it.
But those are by far the minority of apps, and it seems crazy to make a pretty massive security tradeoff for something that 99% of apps don't need to do.
One solution might be a special permission to be allowed to do that, but it seems unlikely a user could really make an informed decision.
Another solution could be to interpret rather than execute the code - you lose a lot of performance, but for people running bash scripts, that might not matter. Using WebAssembly might be a good middle ground.
>But those are by far the minority of apps, and it seems crazy to make a pretty massive security tradeoff for something that 99% of apps don't need to do.
It also completely eliminates general purpose computing.
>One solution might be a special permission to be allowed to do that, but it seems unlikely a user could really make an informed decision.
I think the way "Developer Mode" on Android is implemented is pretty good.
> It also completely eliminates general purpose computing.
The number of people who want general purpose computing on phones is vanishingly small. And since malware is often indistinguishable from general purpose computing, it can be a reasonable product choice.
"The number of people who want free speech is vanishingly small. And since criticism of government is indistinguishable from hate speech, it can be reasonable to forbid everything potentially dangerous."
This feels like a ridiculous comparison. Free speech protects people from going to prison. Flexible OS options enable some personal choices with a product. Even if we take a much wider view of free speech (protection from corporate interference), this is still a massive stretch.
Free speech is enshrined in the constitution because, although dangerous, lawmakers generally believe that protecting it is critical to the long term success of the nation (and not every nation even agrees with this). I see no world where exec permissions on arbitrary directories on my phone is critical to the long term success of the nation.
General-purpose computing protects people from being trapped in a walled garden, from dealing with the monopoly. You bought a phone and you can only ask the vendor to fix and update it, not anyone else. Replace "a phone" with "a car" or "a tractor" [0] and see how ridiculous and anti-consumer it is. The current state results in a huge amount of e-waste instead of encouraging reuse of the smartphones.
General-purpose computing is not being attacked or eliminated. Hobbyists and specialists can buy products for them if they like. The monopoly discussion is a red herring because monopolies are bad regardless of whether those business offer fully customizable software.
> Hobbyists and specialists can buy products for them if they like.
Which phones can I buy to enjoy the freedom of general-purpose computing (and not suffer from non-mature ecosystem)? Which vendors manufacture hardware compatible with FLOSS?
> The monopoly discussion is a red herring because monopolies are bad regardless of whether those business offer fully customizable software.
If the phone runs free software, it makes it not a monopoly, because I can ask another company to write software for me.
> Which phones can I buy to enjoy the freedom of general-purpose computing (and not suffer from non-mature ecosystem)?
Does Libram not count? Why do you get to also demand a mature ecosystem? This feels like demanding that corporations build a product specifically because you want it. There are precious few markets where we demand that businesses provide a product that the market wouldn't naturally demand, and I personally don't think that a general purpose computing phone should be one of those.
This whole discussion also feels a bit disingenuous now that you've brought up FLOSS, since Android has never really satisfied FLOSS-advocate goals. So why would it matter to you if exec privileges are changed?
Librem 5 counts [0], but it just started shipping. You can only get one in several months if you buy it now. Even for Librem 5, there is a problem of proprietary software in WiFi, Bluetooth and modem. It was a great struggle of Purism to find reasonable hardware, all vendors refuse to support FLOSS [1].
> since Android has never really satisfied FLOSS-advocate goals
Android was never FLOSS and it's getting even worse. AOSP is FLOSS, but you cannot use it without proprietary drivers. The latter force you to replace your phone every 2-3 years resulting in huge e-waste. It should definitely be "a market where we demand that businesses provide a product", at least for the nature.
> Why do you get to also demand a mature ecosystem?
Because many businesses and even governments force you to use either iPhone or Android. If I choose a GNU/Linux phone, I cannot use their services at all.
don't you think this security first approach is bad for our society?
If walled golden cages like iOS become the only available option,
average users will have an even harder time to get into general purpose computing and programming.
Generation iPad doesn't even know what a file system is anymore.
And updating an existing product i own to kill its main function i use for work is outright evil.
It's like your car pushing an update restricting it to only drive on vendor approved roads,
because there are some people getting in accidents on poorly maintained dirt roads.
Letting people eliminate general purpose computing is the point.
That program permits you to say "as of this moment, all the apps that comprise this device's purpose have been installed, and computing should cease being general, and should instead be limited to only those apps (including upgrades)". This isn't something I'd do for my development device, but I can see how it's a desirable policy for some people.
1. Most people can't write even Fizzbuzz. How could they possibly realise what they're missing?
2. That feature isn't targeted at most people either, it's for "users with high visibility and sensitive information, who are at risk of targeted online attacks".
AFAICT, turning the feature off is simpler than writing Fizzbuzz.
While I agree the current situation does hinder some general purpose computing use cases on Android, it is still possible to run any code you want. If they can develop easier methods for developers to design around the restrictions then that might be a fine solution.
> I think the way "Developer Mode" on Android is implemented is pretty good.
Assuming you meant Chrome OS here, I disagree. Developer mode sucks because it forces you to forego almost all system security and it makes it trivial to compromise your data. There needs to be a middle ground, not just dev mode.
In my opinion there's a similar situation happening with SIP on Mac OS -- it's too drastic to disable, but there's in many cases not enough control to leave it enabled.
Nobody should need to enable dev mode or disable SIP just to run their favorite apps.
And I was talking about the obscurity level of accessing the developer mode, because you said was hard to achieve a good balance between "too difficult" and "too easy to be tricked into".
Like seriously, what are people even arguing here? General purpose computing was a mistake? Is that seriously an argument that anyone is making in good faith as they type into their web browser on an Internet forum?
Just wait until you find out that app stores are always going to have fundamentally imperfect moderation. Forget running unsigned/unapproved code, we should get rid of 3rd-party code entirely.
General purpose everything is insecure. Self-published books spread lies, open markets have bad products, computers get infected, and people burn and poison themselves cooking their own food in stoves. If your goal is 100% security, then you will very likely never build any platform or product that's worth using.
We have other ways to improve security beyond turning smartphones back into flip phones.
so much this. I don't want to be forced into sacrificing what's possible to keep myself safe, thank you very much. I'm more than capable of performing my own risk assessments, and the further we go down the "secure the hell out of everything" road the closer we get to industrial capture of essential tech.
I think it was a piece by stallman I read recently, about the concept of hardware signature-key application whitelisting. kept me up for a week.
The argument is not that general purpose computing was a mistake, but that general purpose computing is not necessary and is to some extent counterproductive for the majority of consumers. Consumers moved away from flip phones because they wanted more capable phones, that doesn't mean they largely want capability to the extent of general purpose computing.
Consumers will be the judge of whether a platform or product is worth using. Given the unparalleled success of iOS and Apple's locked down ecosystem, it's pretty clear that many find this level of security is very much worth using regardless of imperfect moderation.
From a market perspective, the problem is that in the short term it might be feasible to build a closed, tightly controlled market that rivals open alternatives, but in the long term general purpose computing acts as a safeguard against market capture and anti-consumer behavior -- and to a certain extent, consumers and markets in general are very bad at optimizing for long-term consequences.
The movement of both iOS and Android in this direction would not be as concerning if they didn't hold a duopoly over the entire smartphone market. Apple in particular has faced significant antitrust criticism in this area.
Open markets that empower consumers (and I mean that generally -- not just general computing but also home cooking, self-publishing, self-repair and hardware DIY) are the reason why closed-down markets don't degrade and become awful over time. Almost every capability on the modern locked-down iPhone started out as a 3rd-party proof of concept that Apple was later forced to offer in-house alternatives to in order to remain competitive.
It benefits even normal users who don't care about general-purpose computing that there be at least one mainstream option on the market where users can fix their own problems without asking a company for permission. And I don't think it's an accident that as Android and iOS have both moved away from that role, that we are now seeing increased calls for antitrust, increased criticisms from developers, and general outright rejection from these companies of new innovations like game streaming.
> Given the unparalleled success of iOS and Apple's locked down ecosystem, it's pretty clear that many find this level of security is very much worth using regardless of imperfect moderation
I do think it's slightly problematic to assume that users are conscious enough of security to make an educated decision to opt into a locked-down platform, but are not educated enough to avoid flipping a switch in the settings that turns that environment off and on. I don't think that users temporarily become security conscious only when they're in the act of purchasing a phone.
The more likely reality is that most users don't think about security or 'openness' at all beyond reputation/advertising, and the vast majority of iPhone users have probably never thought about the tradeoff between open access and security at any point during any of their purchase decisions for any computing device.
General purpose computing is one possible safeguard, it also has pretty big and clear downsides for many consumers and isn't obviously the right choice for most.
And again, the proof is in the pudding. If closed-down markets degrade and become awful over time, the market will eventually reflect and account for that in the future. Long-term consequences eventually materialize into immediate consequences after all. In fact, the market exists to validate lofty claims like yours because history is filled with failed attempts to dictate what people should produce, by minorities like you who believe they know better than the people who buy them.
> I do think it's slightly problematic to assume that users are conscious enough of security to make an educated decision to opt into a locked-down platform, but are not educated enough to avoid flipping a switch in the settings that turns that environment off and on.
This seems pretty obviously true to me. It's quite easy to realize you suck at security, all you need to do is suffer a security breach or know of one. For example, the Windows era taught many users just how insecure they could be, the lessons were pretty simple. Knowing when to disable security guardrails, however, requires actual security knowledge that most users don't have. We know users usually don't have them because Windows tested this with UAC, which users happily and quickly disabled to allow malicious programs that they didn't really evaluate at all; A long and painful case study in "how to let your users choose to fuck themselves".
Of course users don't think about a tradeoff between open access and security, the choice is obvious to them. Security matters and open access doesn't. On the one hand you have the tangible risk of getting your stuff or info stolen, and on the other you have danShumway's nebulous & unproven prophecies of a day that will soon(tm) come where the lack of open access causes stuff to degrade and become awful.
I don't personally make the same tradeoff because open access matters more to me personally, but I think the majority of consumers have made legitimate choices for themselves. They know what they want and have made choices to support their desires, same as you or I, and frankly no one should be able to violate their choices.
> General purpose computing is one possible safeguard, it also has pretty big and clear downsides for many consumers and isn't obviously the right choice for most.
Yes, but isn't it sad if (say) mom and dad have better hardware at their disposal than people who need general purpose computing for their jobs (e.g. scientists, hackers, ...).
Optimizing for the majority is not always a good thing as it can result in bad outcomes for minorities.
I think it would be sadder if mom and dad had terrible security and lost their savings or treasured memories as a result. Optimizing for one group is always going to cause some problems for a different group, and if I had to choose I'd optimize for the majority every time.
I'll just have to disagree that it's a false dichotomy. System openness is diametrically opposed to security; the more open a system is, the more insecure it becomes. This is especially true for mainstream consumers who have little knowledge or skill to administrate open systems securely. It's one of the classic engineering trade-offs, thinking you can have your cake and eat it to seems pretty ignorant to me.
> the market will eventually reflect and account for that in the future.
Which won't help unless we're willing to break apart duopolies and enforce government antitrust. The point I'm making is that when you get rid of consumers' ability to solve their own problems, they lose the ability to solve their own problems.
They don't magically get that ability back when the market starts being terrible. Take a look at Amazon's DRM -- it doesn't matter if you as a consumer wake up one day and realize that there are negative consequences to being unable to port your library to any other devices. You still can't do it.
Market capture is not a problem that can be solved by the market on its own, which we've seen repeatedly throughout the history of US markets, including in the computing market.
This is why we have regulations around some of the most egregious anti-free-market activities companies can take. For example, it's illegal to use warranties to block unrelated consumer repairs. Car makers are legally required to use some universal interfaces that allow non-manufacturers to repair and alter the vehicle. And we're currently campaigning to get rid of DMCA restrictions on breaking DRM for legal purposes like porting Kindle books to other platforms. None of that is stuff that consumers on their own would prioritize, but they're market conditions that benefit everyone tremendously. These are instances where the free market can't solve the problem on its own, there have to be legislative changes that allow the market to compete.
And unless you're currently buying stock in Purism or Windows Phone, I think we both know that the current smartphone market is not set up to allow competition.
> which users happily and quickly disabled to allow malicious programs that they didn't really evaluate at all
So what makes you think they didn't? You're assuming that consumers are making a rational choice when they purchase a phone, but not when they use the phone. I don't think people's brains stop working when they turn their devices on, I think that we should apply a consistent framework to understand both people's computing usage and their purchasing decisions.
> Knowing when to disable security guardrails, however, requires actual security knowledge
No, it really doesn't. You can have a big warning that says "this makes your phone insecure" and people don't need to know the details to trust you.
Of course, in practice, people ignore those warnings. But there's two ways to interpret that -- either people don't understand security/access at all and we shouldn't treat any of their purchasing decisions on this with reverence, or people are making a security decision not to trust phone manufactures when they uncheck that box, and we shouldn't shame them for having a different risk model than us.
I object to any attempt to try and characterize them as somehow being both conscious/unconscious of the risks at the same time, there has to be some consistency in how we talk about those people. How do you know that normal users don't just have a separate threat model than you and that they're willing to uncheck that box because they're consciously deciding to tolerate a greater rate of infection/malware than you find acceptable?
> And unless you're currently buying stock in Purism or Windows Phone
OT but if Microsoft released a reasonably-open Linux phone, all would be forgiven as far as I'm concerned. They've always made fantastic hardware, and they're one of the few companies who could potentially break into the market in a real way.
> Take a look at Amazon's DRM -- it doesn't matter if you as a consumer wake up one day and realize that there are negative consequences to being unable to port your library to any other devices. You still can't do it.
Because almost no one actually cares that you can't port your library to any other devices, Amazon's DRM is well known by now and they certainly don't mislead customers into thinking their books are DRM-free nor do they advertise library portability as a feature. The mechanism by which consumers "get that ability back" is by buying DRM free books if they're sick of DRM, but that hasn't and doesn't happen for most consumers even though they're completely free to do so.
Most people are content with Amazon DRM, and when they aren't, any company that sells DRM-free books will make a killing. But no one makes a lot of money from DRM-free books because there is no widespread demand for it. It's ridiculous to suggest that consumers have been robbed of their ability to influence the market, they have always held all the cards. Companies only make money if consumers want what they make, and boy do they want it.
If you have reason to believe Amazon is somehow preventing consumers from buying DRM-free books, I'd be happy to hear it. The kind of failures that markets can't solve themselves are typically ones of deception and coercion, show me that.
> None of that is stuff that consumers on their own would prioritize, but they're market conditions that benefit everyone tremendously.
Says you. I'll let consumers decide what's important and what market conditions are beneficial to them, thank you.
> either people don't understand security/access at all and we shouldn't treat any of their purchasing decisions on this with reverence, or people are making a security decision not to trust phone manufactures when they uncheck that box, and we shouldn't shame them for having a different risk model than us.
People don't need to understand security/access at all for their purchasing decisions to be legitimate. Do you need to be an expert in plumbing to know that you need a plumber? Do you need plumber skills to figure out that the wet & broken mess you've made by yourself suggests you need expert help? You can't conflate a consumer's knowledge of security risk with a consumer's knowledge of security itself. Security risks & benefits are really obvious: consumers notice when they or people they know get hacked & phished. They notice when their computer slows down to a crawl and starts injecting garbage into their screen. They especially notice when iPhones & Chromebooks have none of these problems.
Knowing if a non-vetted program is safe to bypass regular security checkpoints? Consumers consistently and repeatedly fail that test almost every time they're given the opportunity.
> How do you know that normal users don't just have a separate threat model than you and that they're willing to uncheck that box because they're consciously deciding to tolerate a greater rate of infection/malware than you find acceptable?
I know because they switch to a more secure & locked down platform wherever they can. I know because they loudly complain that Android is full of malware and unvetted trash and then proceed to buy an iPhone. I know because the anger& confusion they lash out with when they fuck up their own security clearly indicate that they'd rather never deal with that ever again. The idea that most consumers were happy with the previously awful state of security is totally absurd when they fled those platforms en masse the first chance they could get.
> Most people are content with Amazon DRM, and when they aren't, any company that sells DRM-free books will make a killing.
> If you have reason to believe Amazon is somehow preventing consumers from buying DRM-free books, I'd be happy to hear it.
Look, we can get into the nitty gritty details, but if we're going to have this debate, you have to do some basic research online to see how Amazon is currently hurting the Ebook market, or how DRM is actually affecting markets and consumer choice at this moment. I will still assume you're coming into this from an honest perspective of inquiry, but you have to put in a little bit of work here, I'm not going to summarize the entire history of US antitrust for you.
It's going to be very difficult to have a productive conversation if you don't understand how device/vendor lock-in works. Do you really not understand how holding people's purchased libraries captive prevents those people from moving to new devices or ecosystems? Do you really, honestly believe that a superior book ecosystem of any kind could spring up and Kindle owners would just say, "well fine, I'll throw away $200 of purchased Ebooks! It's no big deal." You don't think it affects consumer's book purchasing decisions at all that it's impossible to put Kobo books onto a Kindle or Amazon books onto a Kobo device without breaking a federal law?
Please do some basic research about how DRM and platform lock-in works on Apple/Amazon devices. I heavily recommend reading some of Cory Doctorow's work, or looking at the history of how the DMCA/CFAA has been used to shut down market competitors via legal means instead of via competition, or into how Apple increases lock-in with their current product direction on things like SSO/subscriptions, credit card offerings, and proprietary device standards that competing companies are not able to interop with.
Apple's current product strategy is to increasingly make it so that anyone who wants to buy a different phone must also throw away a substantial amount of sunk cost into app purchases, hardware that isn't allowed to work as well on other devices, social status (incoming Android messages are literally labeled differently in iOS), they may even be forced to cancel their current credit card. This is a really textbook example of how vendor lock-in works, you can find more detailed information online if it's something that you're actually curious about.
----
The way I see it, there are two fundamental problems I have with your point of view.
A) I don't believe that customers magically become stupid or smart based on whether they're holding a smartphone or a credit card. I believe that people's decision making processes when using devices and purchasing devices are the same.
B) I believe that if people actually want to do something, you (usually) shouldn't have to force them to do it. If people genuinely wanted to be in Apple's walled garden, Apple wouldn't need to lock the garden from the inside. It's one thing to argue that people are too stupid to make their own security decisions. It's one thing to argue that people are too stupid to prioritize long-term market effects. But it's ridiculous to argue that people want to be in a walled garden when literally every single opportunity you give them to turn it off or install apps from outside of it, they immediately do so.
That is not the behavior of people who are happy with where they are. I don't know how to do my own plumbing. The reason you can tell that I'm happy to let other people make my plumbing decisions is because I haven't yet taken a hacksaw to my pipes.
If every single opportunity to take apart my toilet I did so, you might reasonably conclude that I did want to do my own plumbing, however misguided my beliefs about my own abilities were. And if having a checkbox in settings labeled, "warning, you are definitely going to be infected by malware" doesn't prevent people from turning off security safeguards, you might reasonably conclude that they do want to manage their own security, however misguided their beliefs about their own abilities are.
----
> I know because they switch to a more secure & locked down platform wherever they can.
This is a wildly simplistic model of how customer behavior actually works. There is a nontrivial percentage of Apple customers who switch to iOS because they're worried about their SMS message bubbles getting colored green. You can't seriously argue that those people are making a security decision.
And in any case, this is all kind of moot because if you want to pretend the market perfectly reflects majority preferences, then people didn't flee Android en-mass. Apple holds a market majority on paid app downloads, but they don't hold a majority of market share on actual devices. The majority of users switched to Android.
Of course, they probably switched to Android in no small part because of large price differences, not because of "openness", but if I'm correctly understanding your worldview it seems like we're not allowed to acknowledge things like that, we have to assume it was an ideological decision because the majority of the world wanted sideloading.
There's no misunderstanding that DRM prevents ecosystem portability, but consumers know about this and consistently buy into them. Just like how they know that Apple iMessage only works with other iPhone users to the chagrin of their Android friends, and still buy into it, sometimes because of the exclusivity. No one registers for an Apple Card thinking it's compatible with Android. "Superior" DRM-free book ecosystems already exist and you've probably seen people promoting these ecosystems to regular consumers with clear explanations of how DRM-free helps ecosystem portability; If you've ever tried to promote this kind of thing you know the kind of blank stare or apathetic silence this is met with.
DRM is an old technique that's been a staple of digital markets almost as long as digital markets have existed. Switching costs and proprietary lock-in are even older concepts. Every market participant knows about them and invests accordingly. You think when the iPhone came out, people didn't leave anything behind? How did RIM's BBM lock-in work out for them? How did iOS ever thrive without Office & Windows integration, lock-ins that Microsoft tried to exploit? Or what about Internet Explorer, which despite huge antitrust action, Microsoft was allowed to continue bundling and defaulting? How did Microsoft's thought-to-be unassailable lock-in work out for them in the server market? Did Linus go to Congress complaining "how can you expect Windows users to say: well fine, I'll just throw away my Windows software, It's no big deal."? This is what happens when consumers in the server market actually give a shit about openness: a completely open ecosystem actually wins.
There's no lack of understanding, consumers see these walled gardens and say "I want in". They know the switching costs and go in anyway. If low-cost switching was actually important to them they would invest accordingly as consumers do in markets where interoperability and openness is actually important. If their locked-in product is actually serving them poorly, they will actually switch.
---
A) I also don't believe that customers magically become stupid or smart based on whether they're holding a smartphone or a credit card. Here's what I also believe: You can be smart yet still be terrible and unskilled at device security. Conflating the intelligence of a consumer with their security skill doesn't make sense at all. Security is a complex and technical field.
B) So who forced or deceived consumers into buying an iPhone? Who forced or deceived them into buy DRM'd books from Amazon? If people genuinely didn't want to be in Apple's walled garden, they wouldn't have gone in to begin with. If they actually cared about openness, they certainly wouldn't repeatedly buy an iPhone.
No, people don't take every opportunity to install apps from outside or disable restrictions. Jailbreaking was well-known and remarkably easy at one point (I think it's harder now?), and it was popular within certain circles but it was never even close to a majority of iOS users. The number of people who install stuff like F-Droid and sideload apps is a tiny fraction of Android users. I doubt the majority of Android users have ever sideloaded anything. Desktop platforms like Windows/macOS/Linux are much more sideload-happy, but desktop marketshare is losing ground to more locked down platforms like Android & iOS. That's the behavior of consumers who are happy with locked down platforms and don't care for general purpose computing.
> There is a nontrivial percentage of Apple customers who switch to iOS because they're worried about their SMS message bubbles getting colored green. You can't seriously argue that those people are making a security decision.
Yes I can, their decision is "SMS message bubbles are the most important difference to me". For them, other factors like security or lock-in are less/not important. If I willingly choose to buy a product that lacks something compared to competitors, it's a pretty clear indication that is something I prioritize less. That's going to be the case for many consumers, security is not their top concern, but it is usually a factor, especially if there are serious discrepancies between competitors. For example, app selection is usually not a factor because both platforms broadly share major apps and there is little noticeable difference between them. With Android taking steps to move closer to iOS' security model like mentioned in the article, Google is reducing the noticeable difference in security between both platforms so it becomes less of an important factor. Security was far more of a factor in Android's early days when it wasn't rare to hear people note Android's terrible security before buying an iPhone.
In the US, Apple doesn't necessarily hold a large majority but they are something like half the market all by themselves. They are also more profitable, which means consumers value and want them more. It's true that price is one of the largest factors between Android & Apple, but at the high-end range of phones where price is less of a confounding variable, Apple is still the brand of choice. Android has recently moved closer to iOS in security model as mentioned in the article, and I think that helps Android stand stronger against the iPhone at the high-end.
> which despite huge antitrust action, Microsoft was allowed to continue bundling and defaulting?
> how did iOS ever thrive without Office & Windows integration, lock-ins that Microsoft tried to exploit?
You need to go back and reread the history here.
I think you have a fundamentally flawed view of how the market works. I'm not sure what else I can say except that markets don't work the way you think they do.
That's not a Libertarian or Socialist or Ancap thing, you can belong to any political spectrum while still understanding that profit is not a perfect representation of value, and that the market is a system that reflects the education of its participants, and that markets can have unoptimal outcomes sometimes.
In a weird way, what you are saying would be correct if the market worked the way you think it did. Except it doesn't, and you're misunderstanding the history of all of the cases you site (and conveniently leaving out really important stories like Bell Labs and the history of the Internet), and you're creating an alternative history where lock-in just kind of doesn't have any effect on anything, and where the market just kind of magically solves all of the problems it creates, and where we haven't had significant legislation to fix these problems.
At some point you have to go back and critically examine those assumptions, they're just not true. Even Conservative circles are going to laugh you out of conversations if you come in with an economic model that isn't sophisticated enough to explain phenomenons like forced arbitration or externalities like pollution. Perfectly efficient markets do not exist, every market has some inefficiency and some instances of consumers exercising their purchasing power against their own interest.
> They are also more profitable, which means consumers value and want them more.
Again, this is just not how markets work or what profit represents. There isn't a perfect one-to-one link between profit margins and consumer value.
> It's true that price is one of the largest factors between Android & Apple, but at the high-end range of phones where price is less of a confounding variable, Apple is still the brand of choice.
And again, this is not really a valid way to think about market data. Anyway, it doesn't matter because according to your worldview the only thing that matters is what consumers choose, and consumers have clearly overwhelmingly chosen that they want the cheaper phones instead of the flagships.
> For them, other factors like security or lock-in are less/not important.
Right, they're not thinking about security and they don't care about it, they care about the green bubble. The security of the phone is irrelevant, and it doesn't make sense to look at their purchasing decisions as some kind of validation of Apple's security model because they don't care, it is not a factor in their purchasing decisions.
If Apple allowed sideloading tomorrow, their purchasing decisions would not change. So why on earth would we use them as examples to say that sideloading is a problem?
> Conflating the intelligence of a consumer with their security skill doesn't make sense at all.
I don't need to be a plumbing expert to know not to take apart my toilet. Nobody needs to be a security expert to know not to flip a switch or mess with default security settings. It's not a complicated system, when I don't know how something works, I just don't mess with it.
I'm not going to let you walk away from the fact that you're saying customers are perfectly informed about the tradeoffs of buying into an ecosystem, but too stupid to be taught not to press a single, clearly market button buried in a phone's settings. That is a contradiction.
> I doubt the majority of Android users have ever sideloaded anything.
Then why is it a security risk to give them the option? You're arguing that iOS is more secure because it doesn't offer people the option to do something that you don't think they would do.
I don't believe perfectly efficient markets exist either and I'm aware of phenomenons like forced arbitration, negative externalities, and consumers voting against their own interests. But you can't start from "the market is imperfect" and then jump to the conclusion that the smartphone market is broken to the point that it requires government intervention. Honestly, it's a little difficult to discuss this when you just vaguely dismiss everything as "you're misunderstanding the history of all the cases you cite". Elaborating on even one example keeps this grounded, although I understand if you don't think it's worth the effort.
I'll take a crack though: the inefficiency/externalities currently present in the smartphone market are well within the capabilities of the market to correct itself. When I say that consumers are getting what they want, I don't mean "the market is literally perfect and there's absolutely nothing wrong with it". Antitrust & government intervention isn't warranted on every market imperfection and risks distorting the efficiency of the market even further because government action is rarely restrained or nuanced. The tech industry traditionally has relatively little intervention and it is littered with similar examples where market obstructions like lock-in or DRM are eventually accounted & corrected for. Yes, there was that big breakup of Ma Bell which held a unique 100-year monopoly, but I don't think any Big Tech is quite comparable to Ma Bell.
And frankly, consumers voting against their interests is a slippery accusation that should require a high burden of proof. Corporate deception can cause this, but beyond that it's your word against the consumer's. I'm not inclined to believe suggestions that consumers would care about X if only they were better informed. Prove it in the market, one could pass a small law that improves labelling or something and see if consumer behavior changes.
> And again, this is not really a valid way to think about market data. Anyway, it doesn't matter because according to your worldview the only thing that matters is what consumers choose, and consumers have clearly overwhelmingly chosen that they want the cheaper phones instead of the flagships.
A little more detail than "you're wrong" would be appreciated. Yes, consumers have overwhelmingly chosen cheaper phones over flagships, but there are multiple groups of consumers with different choices, not all of them are price sensitive. One thing most groups of consumers have in common though is that they don't care much for openness. This is reflected in low legitimate usage of Android's open features, steady bleed from open desktop platforms, and negligible interest in open mobile platforms (including Android-compatible forks).
> The security of the phone is irrelevant, and it doesn't make sense to look at their purchasing decisions as some kind of validation of Apple's security model because they don't care, it is not a factor in their purchasing decisions.
The security of the phone is not irrelevant, I don't know why you think that. There does probably exist a group of consumers for whom the green bubble is the only thing that matters, but that's not everyone or likely even a majority.
If Apple allowed sideloading tomorrow, their purchasing decisions wouldn't change because there is no non-sideloading alternative. Apple is basically the only brand that has such a tightly controlled walled garden. That doesn't mean they don't want it, and forcing Apple to support sideloading takes away a consumer's right to choose to enter a walled garden like that.
> I don't need to be a plumbing expert to know not to take apart my toilet. Nobody needs to be a security expert to know not to flip a switch or mess with default security settings. It's not a complicated system, when I don't know how something works, I just don't mess with it. I'm not going to let you walk away from the fact that you're saying customers are perfectly informed about the tradeoffs of buying into an ecosystem, but too stupid to be taught not to press a single, clearly market button buried in a phone's settings. That is a contradiction.
It's simply wrong to imply that you have to be stupid in order to ignorantly flip off a security switch. The implications of flipping off a security setting is not obvious to laymen and malicious sites will attempt to provide a plausible explanation for why the switch is okay to turn off, an explanation that you need some technical knowledge to debunk. Fortunately, there aren't many motivated liars that are trying to convince you to take plumbing into your own unskilled hands.
Some platforms end up hiding these options deeper & deeper but it's a Sisyphean strategy. Apple has simply taken the option away entirely it which is the least open but most reliable solution.
Teaching them security is also not only incredibly expensive & difficult but also something most normal people don't really want to learn. Shoving elaborate dialogs and explanations in front of them is an effective way to annoy your users (assuming users don't just skip straight past them), or even worse: a skim read that gives your users a false sense of mastery.
> Then why is it a security risk to give them the option? You're arguing that iOS is more secure because it doesn't offer people the option to do something that you don't think they would do.
The majority of Android users not sideloading doesn't mean that it's not a significant security risk, I don't follow this line of reasoning. A majority of users never get seriously breached, even on insecure platforms like Windows, the remaining group of people that did is still quite significant, certainly enough for it to be a serious problem. It would be an unmitigated disaster if a majority of users were at high risk of breaches. An example I remember: it didn't take that many Fortnite players to sideload & spread malware for people to take notice.
"General purpose computing" is not something most users need or want. Whitelisting is an easy, effective way to improve your security posture w.r.t. a given device. Therefore, expect whitelisting platforms to dominate in thr coming decades.
> But those are by far the minority of apps, and it seems crazy to make a pretty massive security tradeoff for something that 99% of apps don't need to do.
Yet oddly, I as the user who paid $550 for my device would like to do that. I understand wanting to put a warning on it, but otherwise my device can kindly screw off and do what I've told it to do, or it will be taking a one way ride out the nearest window.
My personal security metric is "how many bitcoins would I leave in a wallet app on this phone".
Currently that number is about 1 ($30k) on an up to date android. I believe that if I had more bitcoins on a phone, and told people about it, there's a good chance a targeted exploit would steal those keys. Even if I had them encrypted, at some point I have to type a password in to decrypt, and that would be the point they'd be stolen.
However, on an iOS device (which is more robustly locked down), I'd probably happily store 10 bitcoins. (if I had them, hah!)
On dedicated hardware (like a trezor wallet), i'd also be confident up to about 10 bitcoins (far less attack surface, but also a less competent security team than Apple can afford).
On an outdated android, it would be more like 0.1 bitcoins - there are trivial ways to root them from the web browser and any old website can do it!
Considering that for many people, access to all the private data on their phone could ruin their job, relationships, and even put them in prison, I'm sure a lot of people value the security of their phone at multiple years salary. If I have to choose between that and the ability to run an emulated game slightly faster, I'm totally choosing security!
What is so wrong with Android that you trust it 10x less than iOS? What attacks are possible on Android that aren't possible on iOS?
There are also trivial ways to root ancient iOS versions with a web browser, too. In fact, I think that technique was more common among iOS devices than it ever was among Android...
* Lack of things like w^x enforced across the OS. (the root of this post).
* The quality of SoC and OEM provided drivers being very very poor - there are lots of kernel exploits to be found.
* Very slow/no updates. Time from an exploit being reported to Google to it being patched by a typical user is usually 6 months or more. That means for any random device you find on the street, there is probably a viable exploit buyable on the black market.
* Less strict review process on apps - means there is more dodgy code with access to /dev/exploitabledevice...
> Lack of things like w^x enforced across the OS. (the root of this post).
Are you sure iOS does this for the filesystem at all? I can't find any documentation besides some comments that they don't allow apps which exec other binaries in the app store.
> The quality of SoC and OEM provided drivers being very very poor - there are lots of kernel exploits to be found.
And how do we know about the quality of the proprietary code in iOS? There have been plenty of exploits found there too.
> Very slow/no updates. Time from an exploit being reported to Google to it being patched by a typical user is usually 6 months or more.
Where did you get this 6 month figure? Was that before or after the introduction of Project Treble, Project Mainline, the new security update system, etc?
> Less strict review process on apps - means there is more dodgy code with access to /dev/exploitabledevice...
Can't argue with you there. However I will say that even the weak points here aren't any worse than the state of the art for desktop PCs
Sure, but the other poster seemed to be talking about software policy-based security measures with that point (like what Android is adding) and not just app store review restrictions.
> Where did you get this 6 month figure? Was that before or after the introduction of Project Treble, Project Mainline, the new security update system, etc?
Note: definitely not about Pixel outside of US (or even in the US if the phone was direct from Google).
You underestimate the time that it takes to approve updates, even taking into account what Google have done to speed up the update process.
The SoC and the Kernel
From the start, you need to have good driver/HAL for the specific SoC of the device. Qualcomm is very spotty on these: historically, the 8-series revives updates for up to two years (which is an improvement already considering that some older chipsets only has around 1.5 years of updates). This would be a minimal problem if it is Windows-style (where drivers are separate to the system) but Android is currently based on Linux, which integrates the drivers to the build. This means that major kernel upgrades are PITA or even impossible. Worse, Mediatek and other SoCs (aside Samsung, but they control it anyway) tends to only have a binary build of the kernel and as a device manufacturer you have to deal with it (that's why HMD cannot disable the DuraSpeed optimisation that Mediatek has put on it because Mediatek controls to a degree the whole device).
OEM-specific Customisations
It is no secret that OEMs modify Android hard, to the point that the modifications they have done is beyond the UI of the device. This means that patching of the devices takes time even when the OEM and the SoC manufacturer are responsive (as alluded to earlier, not already good). Worse of all, some fixes are in the mercy of SoC manufacturers as they affect the kernel.
OEM Priorities
If you have a flagship phone, congratulations! You receive patches monthly. However what if you are using a regular device (or even a budget device) from an OEM? Unless it is a device from an Android One OEM or a Pixel, you usually only receive updates quarterly, if at all (see SoC and the Kernel above). Plus, good luck contacting your manufacturer about this problem. This rather obviously slows down patching.
Carrier's Shenanigans
If you are not using a carrier-specific device, congratulations! The update should come to you as smoothly as the OEM wants to. But wheat if you bought your device under a carrier? Depending on your country, no significant difference to the non-carrier version or your devices' updates is being hold to by your carrier because they wnat to check it (apparently). Sometimes, your carrier is benevolent and really has a team that checks if the update will break something and authorise the OEM to release the update within a day or two. However, it is more likely that the carrier will slow down the process to the point that the non-carrier version is three versions ahead.
User Efforts
Well, that's the users' fault then. Not really relevant considering that Windows users tends to turn off updates.
What Google has done to mitigate this
Project Treble and Play Services Updates (aka Mainline) have reduced the time of patching of devices significantly and prevent a whole class of attacks (including the Stagefright component, which decodes media files and often has bugs in it due to it being mainly a third-party component). However, you have noticed that the SoC, and hence the kernel, still has teetering problems when it comes to updating. The good news is that Google has requested SoC manufacturers to "mainline" their drivers (aka including the SoC driver source code in the kernel, not to be confused with Project Mainline). However, that is just last month and it is still somewhat rejected by SoC manufacturers. Qualcomm have even promised to improve the updates, but we haven't heard anything from Mediatek et al. And that even excludes the pesky carriers who holds updates for no apparent reason at all.
Recent pixels probably earn near (but not quite) what an iOS device gets... There's still quite a lot of Qualcomm (and Broadcom) written code on the security-front-line, and I'll be honest I don't really trust it much seeing the massive oversights that previous exploits have discovered...
I suspect the focus of their engineering team is more "hardware guys kludge together driver"... And they probably have to do that because it's only the hardware guys that fully understand all the caveats and workarounds required to not trigger hardware shortcomings...
Yup this. I bought my device to do useful things on and store a bunch of personal private information. I'm a lot more concerned about keeping it working at 100% reliability and keeping all of that data as secure as I can than whether I can run some weird random hack on it for kicks.
Well yes, I would consider any Android device family other than the Pixel / Nokia line a security hazard, with or without any bitcoins on it.
Comparing a rushed Q4 market Samsung phone to an iPhone is simply comparing a brick and an orange.
There are many problems with Android, but that the price for a zero day exploit on Android has become more valuable than one for iOS as far as 2019 [0] should tell you something about how a proper Android phone would fare in the comparison. Please leave the brick where it belongs.
> Android device family other than the Pixel / Nokia line a security hazard
As someone who uses a HMD (Nokia) phone, please do not buy the models with Mediatek SoC in it when you are absolutely concerned with security. Apparently Mediatek is the one building the kernel of the device and not even HMD has knowledge on what modifications have been made (for example is DuraSpeed, which was an aggressive battery saver that ruined some apps, was enabled without permission and even HMD cannot disable it permanently). Qualcomm SoC devices are okay, but expect a slight delay (around a week or two especially if it was a device from a carrier) for updates.
You're entirely able to purchase a different phone that doesn't enforce this.
Or not install the OS update that will enforce this.
Or install an old version of the app, e.g. from fdroid.
---
I think it's safe to say Android is more "the device serves me" than iOS, but even now it's pretty far from actually achieving that. Maybe install a different OS that actually has that goal?
If Bob paid $COST for a phone and it got exploited because of this, Bob may throw his phone out of the nearest window.
Do you think there are more Bobs than you in the world?
Personally, I find this reliance on the GOOG OS awful, but most of it was overcome with Xposed last time I ran LineageOS. I tried Cydia last time I ran IOS and that was worse.
I've thrown several phones out of the window (metaphorically) and am waiting on my PinePhone being delivered because I believe in their goals.
It sucks that everything in life seems to come down to Coke or Pepsi choices, or Vi/Emacs.
Big corps aren't the answer.
They monopolise and stifle, giving twoshit sandwiches for consumers to take a bite of.
> If Bob paid $COST for a phone and it got exploited because of this, Bob may throw his phone out of the nearest window.
You and I both know, despite many attempts, there is no hardware or software out there that is unexploitable. From the most locked down chromebook to Apple's walled garden, these devices can and are exploited.
The idea that if somehow we take away enough of your freedom we'll make the device safe is basically a bald faced lie. Not once in the history of computing has it worked out. Even my internet connected lightbulbs which literally have only an on and an off exposed are exploitable.
No amount of removing user freedom will make users safer. This isn't a rocket surgery level conclusion, which means companies that continue pressing down this road probably have some other reason for doing so.
The question is the cost of making things "secure as possible".
Should you harden memory? Setup SELinux? Yeah, do those things, those are good meaningful things to do.
Should you prevent users from running apps? Prevent downloads? Restrict third party apps? What about tracking everything the user types in? Tracking every app the user opens and when they open it (eg, Apple)?
What about bypassing user firewalls (Apple again)? That's for "security", right? Forcing your own DNS resolver (Google)?
User hostility is never an acceptable tradeoff for security.
W^X is not a security protection on iOS, it serves to enforce the integrity of App Review. Apple claiming that it is the only entity that can write a JIT securely both provably incorrect and belies a lack of confidence in the platform sandbox.
It's exactly Harvard. Instructions can only be loaded from the I cache, and data operands from the D cache. If you JIT something you have to flush the relevant D cache entries and invalidate the relevant I cache and then it will get reloaded.
Yes. Linear address spaces are an abstraction to hide this, because everything is in pages (minimum 4k on most machines, up to huge page sizes), and it is the pages that are controlled in terms of W^X.
In the era of ROP and gadgets (control flow being determined by data, to implement strange virtual machine and interpreters) it seems somewhat quaint, but it has made exploits a lot more complicated. The mixing of JMP/RET addresses and stack data is why stack overflow and ROP is so easy; CFG, CET and shadow stacks are all trying to achieve separate I and D stacks.
Arduinos and the like can jump to ram and execute code from it. They simply also have a read-only portion of memory where the code is stored. You can also treat the ROM as memory and use it to store tables, saving you from having to use RAM for them.
Funny, all the binaries in my UserLAnd are aarch64, not x86.
I'm not sure how they do it -- faking syscalls? -- but recently, changes in Android filesystem access policies made it impossible to move files between UserLAnd and the outside Android environment.
Sorry, my comment was a bit misleading – it doesn't seem to use emulation, only syscall translation of some kind. iSH does both.
For that matter, I'm actually not aware why UserLAnd's approach is compliant with the minimum API level required for the Play store but Termux isn't. I always thought the point of contention was exec()'ing executables not delivered through the store, which both of them can clearly do.
Update: It seems like UserLAnd just hasn't been updated in a while, and the API level requirement is apparently not enforced for existing apps in the store.
While I really, really want a GNU/Linux Android-alternative to succeed, at the moment a good solution for those of us who can't go without Termux is LineageOS [1], an Android fork, comes with a terminal emulator WITH root access (of course you can install Termux if you prefer how it handles packages.) You can also install Play Store apps on it, should you feel so inclined.
For the record Sailfish OS[1] (and it's predecessors MeeGo and Maemo) had this from day one. You enable developer mode, set root password and it even installs a terminal emulator automatically for you! :)
The biggest difference is that /e/ is one of the few OSes that has MicroG pre-installed, which allows apps to make use of some features of Google Play Services (e.g. push notifications, map widgets, and COVID-19 exposure notifications) through a FOSS client. MicroG lets users turn on/off some of these features, and does not support Google's APIs for ads or analytics.
LineageOS does not support the mechanism (signature spoofing) that enables MicroG to replace Google Play Services. The developers of LineageOS consider signature spoofing to be a security risk:
As of now, I've only used two Android forks, Cyanogenmod and LineageOS, primarily because they work on so many devices. LineageOS has a whole list of cool custom APIs that I've considered taking advantage of in some future project, but other than that I'm not sure.
FWIW, nowadays, thanks to Project Treble, most ROMs have GSI (Generic System Image) that will work on any device released with Android 8 or more recent, assuming OEM allows bootloader unlock.
/e/ is a fork of LineageOS with the goal to be usable by non-geeks. So it pre-includes a selection of FLOSS apps to make the device usable, like a Map app, cloud backups (well LineageOS now have it), calendar sync, etc.
We have to replicate somehow the PC ecosystem into mobile phones. I'd like PostmarketOS / Manjaro to take off, hope it becomes ready as everyday driver one day.
The list contains many existing Linux desktop distros. The PostmarketOS edition of PinePhone even shipped with a USB-C docking station that you can use to easily connect a monitor, keyboard, mouse and even ethernet.
> At least we can hope terminal + tools as separate app bundles approach takes off.
But think of all the wasted engineering hours that could have been spent doing something useful, but will instead be spent conforming to Android's draconian security policies. This would all be solved if there was a switch that allowed users to disable W^X protections for specific apps.
Even if it required you to pass a Google interview (exaggerating), malicious actors will find a way to mislead 13yo kids through some youtube video or something.
It is increasingly impossible to live in my country without a number of apps that require an iOS device or an Android device with all the Google services enabled. There's one de facto monopoly payment app[0], a lot of places where you can't park without an app etc., but the big thing is we have a government mandated single sign-on solution. You can still get one-time-pads in the mail, but there's also an app, and some features of the service are now app only.
The web allowed us to avoid a world where everyone had to own a Windows machine, but mobile phones are now making that a reality.
[0] A privately owned replacement for cash, doesn't that just sound great...
Thank you for sharing your experience. My country is doing a soft migration, with some places now refusing cash, but I don't care about them or can use help, and larger places like supermarkets having "no cash" and "cash only" checkout lanes, the latter being faster.
Have you experimented with not using your phone for a day or a week and seeing how far you get looking for alternatives? They're usually around, just not immediately apparent, like the "x" button on ads.
My (Android) phone is de-Googled, so no apps except from F-Droid, and I only use the one-time pad for the national SSO solution. Following a recent change, not having the SSO apps means I have to have use an extra password + SMS 2FA on many sites when I want to pay by credit card (the alternative being the SSO app).
I don't drive, so I don't know for a fact about the parking situation, but people tell me some places are app-only.
On a few occasions I've had to get my wife to pay for something using the app I mentioned, but it is becoming increasingly "weird" not to have it, and I see many classifieds specify that they only accept payment that way. I was almost cash-only for day-to-day stuff until Covid, but that's been the nail in the coffin. Technically businesses can't refuse cash, but many places will have signs asking you to pay by card, and I'm not going to be an arse about it to some 17-year-old behind the counter like an anti-masker. Thankfully almost everyone accepts credit/debit cards, but the alternatives are cheaper for businesses so maybe in a few years that will also become problematic, and the app-based solutions will have fully overtaken government cash.
I feel like there should be an addition to basic human rights: Participation in the economy. It should not be a requirement for day-to-day life that one carries some tracking device and accepts thousands of pages of ToS from a private company. I can accept giving up many conveniences, but I feel like I should be able to have a place to live and buy food without a Google account.
I bet it all boils down to what you're familiar with; but on PC if you have a linux distro you can essentially customize your computer exactly the way you want maybe minus some firmware stuff on your hw. I have an android phone and I'm almost always clueless as to how to operate it, sometimes even finding files is hard. It remind me of using Windows, except in my phone.
Nope. To be precise, it will be only a issue if Android compatibility was dropped from applications compiled targeting Pie. Even Gingerbread apps can still run on Q so unless 12 has drastically changed things, it wouldn't be a problem.
termux is not perfect because it is already a compromise!
When google scammed us and sold android devices to all the hackers here and then surreptitiously removed our access to the terminal, we said "that's fine, we can still package this as an app like so and so" and termux was born.
now they are removing access from running any code not signed by their store, even if you install termux from the appstore and compile some code yourself, you can't run it. where are we drawing the line?
99% of people cannot use postmarketOS, either because their market do not have access to devices with unlocked bootloader or because their live depend on some bank/school/work app that checks the OS.
Ironically, the software we create, Android in this case, isn't oriented at us. Castration in Android is considered a feature, because it makes the average user's phone more reliable.
> it makes the average user's phone more reliable.
I would believe that if it was a prime (well described, not difficult to understand, easy to find) option where the user had control.
As it is, it is the same as blocking the second level of a house because 'not allowing the residents to climb a stair makes the house safer for them'.
At some point, we have to see that feature prioritization on android serves only advertising revenue increase, and reduced support costs for google.
This one is for the later. With this feature they can remove tons of cost form app review teams they have. They can just allow every app that downloads crap to the data location and call it a day. It doesn't help the user in any way, only google profits.
I mean, you can block the kernel level execve, but perhaps user space can be hacked to do a user-level execve. Just unmap and re-map the right pieces of memory, close the right file descriptors, do the right stuff with signal handlers and whatever not. No?
Look, Cygwin is able to simulate fork and exec on Windows, both of which are completely missing.
One thing that would put a damper on things would be disallowing executable mapping at all. But you can't just do that since it breaks shared libs. A mechanism that allows shared libs to be mapped executable and then drops the map-execute privilege wouldn't be secure. It would be annoying, but possible to bypass.
The only way it would work is if the entire process setup logic shared libs were moved into the kernel, so that the very first instruction that runs in a process is in a context that can no longer map any pages executable. Or else, it's still in user space, but the dynamic loader is specially privileged, and before dispatching the very first instruction in the loaded executable, it drops that privilege. Either way, so much for trampolines, JIT and other techniques). dlopen could not work either, unless it's moved into the kernel, and allows only "blessed" plugins.
Are there actually any phones for "normal" Linux users?
I've used GNU/Linux as my desktop OS for nearly a decade: Fedora for years, then openSUSE, then Pop!_OS for the past couple of years. These distros seem to have provided a good, current, stable out-of-the box experience (Out-of-the-Box + RPM Fusion and Packman for the former two.)
I just don't enjoy constantly fixing issues on my personal systems, in fact, after work I just want my computer to work. I get some people enjoy tinkering, I simply want my device to work AND provide me the freedom to do what I want if I feel adventurous. I don't distro-hop, and I don't like rebuilding my OS if I can help it. I'll spend a week getting everything the way I like it and expect it to last me at least a couple of years. I use Linux for everything: gaming, writing software, web browsing, you name it.
For as long as I have looked into it, GNU/Linux phones are an absolute nightmare for someone like me. I remember reading an article full of workarounds to get a dialer app to work on some project phone. I just want a phone that works, and could allow me to access root, setup my dot files, and tinker to the degree I'd like. As of now, my only solution has been LineageOS (Android fork) which has a proper terminal emulator with root access by default. As nice as this is, I'd love to support a GNU/Linux Android-alternative, as it's anyone's guess how long LineageOS or other forks will be compatible to the degree they have been in the past.
If you prefer stability over feature set on desktop, choose
Debian stable. It's rock-solid.
> I remember reading an article full of workarounds to get a dialer app to work on some project phone.
Currently, phone calls and sms work fine on both Librem 5 and Pinephone. The development rate is amazing. Only the good battery life is lacking yet, but it's improving every month.
I do prioritize currency over stability in many instances, but I do want a reasonable level of stability which is admittedly quite subjective. Pop!_OS or other Ubuntu-based distros seem to strike the right balance for me (Pop won me over with it's built in, togglable tiling manager, a feature I'd have to spend a week's worth of free time researching and trying to get working properly in, say Arch.) I just don't have much free time and motivation to spend getting some tiny quality of life improvement to work.
Your experience is basically the exact opposite of what's described here[0]. I bring this up as an optimistic PinePhone owner. I just don't think it's there yet.
This thread is quite long and started many months ago. It got much better since then. See later replies. Also, I agree that some OS may not be very stable, but Mobian works pretty much flawless for me for typical tasks.
My feel is that it's not ready for you yet, but Pine64 at least seems to have a sustainable thing going, with thousands of real units shipped. I've started dipping my toes in app development. Main problem for me so far is performance. Firefox crawls.
The chip that Pine64 is expected to move to in the next generation of the Pinephone, will cost the same low price as the current chip but be considerably more powerful. So, indeed, members of the Linux phone community can expect a more performant niche phone for a low price.
I wrote that text, hehe. I'm not aware of any effort to fix that. It's already reasonably non-flickery thanks to other fixes, since that paragraph was written.
I think you mean back to ssh (telnet) to a cloud (mainframe/UNIX) server, or using a browser (X Windows) for a no-exec home folder using IT sanctioned software.
Also worth to take a look at is Fairphone, which is a little more finished product than most. It has an active community around it with many ports ongoing.
GNU Phones suck. You have to drastically lower your expectations and pay more for the experience. For instance, Librem 5 USA costs a cool $2,000. That's $2,000 for a phone with specs comparable to phones in the mid 2010s. To make it worse, you would have to expect near-zero support, and healthy dose of RTFM and DIY mindset along with it.
Thus, for the vast (and I mean VAST) majority of consumers, Librem and the rest of the open source phones were dead on the spot even if it cost 1/3 of their current price.
It's a pipe dream up there with the "year of the Linux desktop".
This is an extremely misleading example. You pay $2k if you want your phone to be produced in the USA. How much do alternative phones produced in the USA cost?
Standard Librem 5 model costs $800, Pinephone costs $150 or $200.
Indeed, the $2k example was misleading, but the fact it's still $800 for a phone with 2014 specs alone would have been more than enough to get his point across. You do have to pay 3-4x the price you would otherwise to get the privilege of running another OS on older hardware with arguably less functionality (OOTB, at least).
Again, those "selling points" are extremely fringe. Let's not pretend like grandma (and the average phone user) cares about hardware killswitches, DP over USB-C, etc...
Like they say themselves in that very article you posted :
> For people who want these specialized features that no other phone offers, the Librem 5's price is not unreasonable.
Also, specs are obviously not the only thing that matters, but having seen Librem 5 phones run, it's pretty damn obvious they do kind of matter - the thing seems to run quite choppy.
That is why I asked why grandma would need a performance of iPhone 12. Native apps work quite smoothly on Librem 5 (and many of them even on Pinephone).
I mean, just take a look at their own damn videos. [1] The thing runs choppy and had horrible input lag just typing the lockscreen passcode or opening the dialer.
I don't expect my mom to need iPhone 12 performance, but even my mom told me her older LG G-something was slow getting slow, and having played with it before her switching phones, it wasn't nearly as choppy looking as this video.
You and I obviously have very different definitions of "quite smoothly". And specs related or not, UI is a major part of the experience. The initial point still stands: Linux phones are pretty damn far from being anywhere viable for anyone but the most hardcore enthusiasts.
It does look quite a bit snappier indeed, but as I said in my previous comment as well:
> specs related or not, UI is a major part of the experience
When someone buys a phone (or hell, a computer), they're buying a package of hardware, which dictates available software. Hell, you could make some hypothetical $200 phone with the best hardware on the market, if it doesn't have what some people consider "basic" functionality software side, they won't buy... coming back to the initial point that Linux phones are not ready for prime time.
Fair enough. Some people prefer to buy early and get all software updates on the way though (with lifetime updates btw). It's also FLOSS, so everyone can contribute.
Is that unreasonable? Running another OS on a device with physical hardware switches is a privilege right now, so it costs more. There are essentially two companies doing this, and neither of them are even at the point where they can completely honestly say their products are out of beta. The Librem is expensive in no small part because its feature list is fringe, and even ignoring the inherent hardware challenges that's just how the law of supply and demand works.
What other market have you seen that acts differently? Look at how much other niche devices like Braille screens cost, or even more "mainstream" specialized hardware like the Remarkable Tablet -- arguably a much less capable E-Reader than a Kindle/Kobo device by almost all consumer-relevant metrics. But you'll pay more for stylus support on an E-ink screen if you need that, and you'll tolerate a suboptimal reading experience as well.
It's also important not to ignore the fact that the Librem is a flagship device. It is currently the most powerful Linux phone hardware on the market. So you can buy a cheap, low-powered Pinephone (the far better choice for most tinkerers), or you can shell out for something with more raw power -- which is also pretty consistent with how most markets work.
If you want to buy the single top-of-the-line Wacom tablet, you'll shell out at least $4,000, probably more when you factor in accessories. You want rotational support in the pen? That's another $100. Is the fractional improvement in a Cintiq Pro 'worth' the frankly massive price increase over consumer tablets? Probably not, you can buy an entire Surface Studio for the same price, and that comes with a "free" computer. But you'll pay the Cintiq price if you belong to a niche that needs the best the market currently has to offer for your particular use-case. And you'll pay the Librem price if you belong to a niche that needs the (currently) most powerful phone hardware that's realistically usable with a Linux OS.
These days, a braille display can be had for around $400-$600. We also have multiple manufacturers, with multiple models and prices you can choose from. I don’t see that happening with open source hardware.
Genuine question, I was interested in trying to play around with one a while ago, and I spent a fair amount of time searching and could not find a single monitor for under $1000, and most of them were in the $3000 to even $7000(!!!) range for a device that can literally only display a single line of text at a time.
If there are manufacturers making cheaper devices, or even just doing anything interesting with the hardware like building multiple-row 2D displays instead of 1D single-line outputs, I would love to know about them. It's a market I'm somewhat interested in.
Ooh! Disappointing to see that it's only 20 characters, but that is way cheaper than what I was finding online. And they're actually experimenting with 2D displays (https://www.orbitresearch.com/product/graphiti/)! Thanks a ton, I need to keep an eye on this.
Don't forget that Purism also pays for the software development, while Pine64 uses that software for free (10 euro donations per sold Pinephone do not cut it).
> Is that unreasonable? Running another OS on a device with physical hardware switches is a privilege right now, so it costs more. There are essentially two companies doing this, and neither of them are even at the point where they can completely honestly say their products are out of beta. The Librem is expensive in no small part because its feature list is fringe, and even ignoring the inherent hardware challenges that's just how the law of supply and demand works.
Sure. 800$ is still quite steep and, exactly as you said, relegates the device to a fringe market.
> What other market have you seen that acts differently? Look at how much other niche devices like Braille screens cost, or even more "mainstream" specialized hardware like the Remarkable Tablet -- arguably a much less capable E-Reader than a Kindle/Kobo device by almost all consumer-relevant metrics. But you'll pay more for stylus support on an E-ink screen if you need that, and you'll tolerate a suboptimal reading experience as well.
> It's also important not to ignore the fact that the Librem is a flagship device. It is currently the most powerful Linux phone hardware on the market. So you can buy a cheap, low-powered Pinephone (the far better choice for most tinkerers), or you can shell out for something with more raw power -- which is also pretty consistent with how most markets work.
"Flagship" doesn't mean much other than "best X company has to offer". Indeed, it's the best you can buy for now, doesn't mean it's particularly great. The experience seems quite hit-or-miss, I've seen both horribly sluggish and quite usable footage just recently.
> If you want to buy the single top-of-the-line Wacom tablet, you'll shell out at least $4,000, probably more when you factor in accessories. You want rotational support in the pen? That's another $100. Is the fractional improvement in a Cintiq Pro 'worth' the frankly massive price increase over consumer tablets? Probably not, you can buy an entire Surface Studio for the same price, and that comes with a "free" computer. But you'll pay the Cintiq price if you belong to a niche that needs the best the market currently has to offer for your particular use-case. And you'll pay the Librem price if you belong to a niche that needs the (currently) most powerful phone hardware that's realistically usable with a Linux OS.
Fair point. Am I misunderstanding the goal of Purism, and merely existing enough for these projects, or are they aiming to grab some market share? I'm just utterly unconvinced that this is anything other than a fun curiosity.
The ultimate goal of Purism is to expand the market, but (opinion me) when I look at Purism's products in general I don't see them ever themselves moving out of niche categories.
If you buy a Purism laptop today, you'll already pay a premium over companies like Dell. I suspect that Purism is happy to see companies like Pine existing, and I know that they want Linux smartphones in general to be a broader market, I don't know that they're seriously thinking about trying to launch $100-200 competitors. To me, it just doesn't match their other products, I don't see anything else they're offering that would fall into that same category.
And while people would like to see Linux completely take over the desktop/mobile space, I think there's a much broader category of people who just want the market to be big enough for us and to be big enough that it is able to meet our needs. Past that it's not the end of the world if it doesn't get larger.
This is also part of what's frustrating about stuff like the "year of the Linux desktop" joke -- in many ways, the year of the Linux desktop already happened a while ago. Linux got good enough that you can pretty easily mainline it instead of Windows without serious issues or downsides. I have not booted into a Windows computer in multiple years, I don't even have a backup install anywhere. It just doesn't come up anymore. In terms of software, Linux support is something that a sizable portion of the indie games market now talks about, and between Steam/Proton and the recent architectural/policy changes happening on Mac you're now about as likely to be able to run a game on Linux (if not more likely) than you are to be able to run it on a modern Mac device. Meanwhile, 'mainstream' Linux OSes finally got polished enough that it's completely reasonable to put a tech-unfriendly kid or parent on a Linux machine without worrying that you'll get tech support requests every week. There's still a little ways to go with some legacy/holdout software in more niche professional fields like graphic design, but if you're a relatively normal user, then at some point Linux stopped being a struggle to run.
So in the same way, when I talk about the success of the Linux phone market in general, I'm not necessarily aiming for "we monopolize the entire space and nothing else exists." I think it's completely plausible that the Linux phone market might grow, not put Apple out of business, but still grow enough that there is a reasonably priced, usable alternative for people who value privacy and freedom.
In them meantime, it's niche. As far as I know, the front camera on the recent Pinephones still doesn't have software support. So yeah, it's currently a niche market for people who have very specific wants and needs. It seems kind of premature to me for people to be complaining about price and hardware when we're still celebrating things like camera support; commoditization is something that happens to mature markets, not new ones -- and that all takes time.
Regardless, the point still stands that if we've had camera support for ~3 months, we're probably not at the point where we need to seriously worry about whether we're currently offering the highest value-to-money hardware choices to consumer demographics that have never opened up a command line before.
Asus 1215B released in 2011 with AMD Radeon HD 6250.
Windows and original proprietary AMD drivers, OpenGL 4.1 and DirectX 11
Open source AMD driver replacement, OpenGL 3.3
So in 9 years no one bothered to match the previous proprietary AMD drivers capabilities, while Asus keeps the Windows ones available in the latest Windows versions.
Sure, Linux phones are probably never going to be mainstream, but there are worse things to waste money on. Being an early adopter is always hard, and in this case you are literally putting your money where your mouth is.
I wish Google took the high road when it comes to Android and let users create legit root accounts on their phones. Instead they seem to be emulating the worst parts of Iphone OS.
And no, root account does not violate any security principles. If your app is leaking secrets due to root accounts, your app is broken.
> If your app is leaking secrets due to root accounts, your app is broken.
Yes it amuses me how banking apps refuse to run on a rooted phone, but the same bank's website works on the same phone. Suggests that they've placed a little too much trust in the app. Never trust the client...
HN has this fetish for root access. But it's more important to protect dumb users, and script kiddos watching youtube videos for everything, than letting someone do some text operation his smug greybeard (tm) 1970s way.
And Google technically allows it, buy a phone with unlockable bootloader.
BTW: I just now have read an announcement that Retroarch is affected by the same policy, and they solve that by offering a limited number of Libretro ‘cores’ that are downloaded from Google's servers on request from the app: https://www.libretro.com/index.php/retroarch-android-new-ver...
I now invoked the ‘convert cores to the Play Store versions’ functionality, and not seeing any new separate apps installed, nor was I asked to install anything (and Retroarch doesn't have permissions for that). It seems like Termux could use the same approach.
The Google play version was crippled beyond being practical anyway. Can't SMS, can't GPS, no access to address book.
The usable version is from F-Droid. And I had to install that one just to install Termux. No need to root your phone. Simply install F-Droid app store, and install from there.
I'm very new to Termux and recently installed the Google Play version. If I install the F-Droid version will it have access to all storage, such that I could edit Dropbox files in emacs and have them automatically sync?
This is annoying, but I am not quite convinced that this requires pulling Termux from the Play Store. I mean, to be honest, Android is literally "easy mode" compared to iOS even after this change, and just having access to execmem would be enough for any iOS app to write a very capable Termux–and that's even without proot involved. I'm seeing claims of execmem possibly going away as a reason to not write their own loader (which is basically the only component they need) but that would require banning all alternative web browser engines from the store, which would be a much larger change in policy than banning exec from certain directories.
I'm vaguely titillated by the prospect of Google Play receiving hundreds or thousands of separate apps with Termux packages. Alas this feeling is chilled by the knowledge that publishing them is not in Google's priorities.
slightly offtopic: I am surprised by how much patience thestinger has on the thread replying to people who clearly have no context about the issue - enough to repeatedly explain the tradeoffs and reasons behind the decisions taken.
The upcoming SELinux restrictions mentioned in TFA would seem to obstruct any app that has the capability to execute any arbitrary binary. I would be highly surprised if any other similar app would continue to work without problems.
Check out Termius. I've never used Termux so I'm not sure if Termius has the same feature set but it was enough to occasionally ssh in to my machine to attach/detach a gnu screen session to do what i needed.
From Termius description, it's a completely different app than Termux. Termius is a ssh client, it's purpose is to allow you to connect to a remote computer, whereas Termux is the computer. You can program, compile, run programs, etc... from Termux.
My use case is emacs, git and ssh so that I can have my org files on my phone and synchronize them with my other computers. And no, the org apps aren't good enough, plus there are other features of emacs that are nice to have at all times.
You can certainly do a lot more with a rooted device. I think it's a reasonable tradeoff to limit uncommon use cases for devices which haven't been rooted. I think the majority of users would prefer the additional security restrictions in place on non-rooted devices. For those who want more control, you can root at your own risk.
Google's safety net API is used to check if the device is rooted/unlocked/tampered. Many apps are using that now and will in future. There's no way around it.
You can either have a phone for tinkering or general usage. There is no in-between now.
That personally doesn't bother me. I think it's reasonable for developers to want to safeguard the integrity of their apps. I can choose to use an alternative app without this check on my rooted phone. If there's no alternative, then of course you're left deciding which is more important. I am a developer (but not for Android) and I've never really felt the need to root my phone for many years. I think if you're a professional Android developer, it's reasonable to have a second rooted device for development if you really feel you need root.
Yeah I don't think the API is unreasonable but many will use this without a purpose other than for compliance or something they saw somewhere that said it makes their apps more secure.
> I think if you're a professional Android developer, it's reasonable to have a second rooted device for development if you really feel you need root.
Safety net API will also fire on unblocked bootloaders, not just root. Android smartphone market is filled with crappy skin from chinese manufacturers and others. I don't want to be spied on by them so I use a custom rom on my phone. That wouldn't work in future.
For those not following. the TL;DR; is basically termux doesn't want to accept that Linux on Android is only an implementation detail and re-implement the necessary shell like functionality using the Java Frameworks.
The actual issue is that Android does not allow executing any code that wasn't downloaded through the play store. And even then only if they're signed by the same user.
1. You can only execute binaries together if they're signed by the same key.
2. Each person has to have a unique signing key.
3. If a user wants to execute a pre-existing software, and something compiled by themselves, both need to be signed by the same key.
4. This means you need to re-package and sign every single program you'd ever want to use together with your own code again, in new packages, and submit it all to Google Play.
This means every Termux user that would want to ever run gcc would have to
(a) submit every single hello world they write to the play store to try it. And every single run requires a full app update, and
(b) additionally repackage and submit all linux packages, signed with their own key, to the Play Store.
This means to even compile and run Hello World, you need to submit several hundredthousand packages to the Play Store, wait for approval, and download them all.
Yet at the same time, Google Chrome can use WebAPK and auto-generate APKs on the fly with custom code and install them on the device without going through the Play Store.
The alternative of course is not being able to use a phone as general purpose computing device, but considering Google advertised Android as exactly that, that's getting close to fraud on Google's part, removing functionality after a sale.
That's also not possible anymore. The new rules explicitly forbid loading any Java code that wasn't previously verified, signed, and published through the Play Store.
Those apps are affected by the same rules as Termux.
> And yes you need to install application extensions via the store, so what?
Writing your own code and executing that is explicitly forbidden. Be it REPLs or compiler suites. That too would have to go through the store. Only interpreters are allowed.
The other issue is obviously that you can’t have an extension developed by person A for an app developed by person B. It’s very common to see mods, plugins, addons whatever you may call them on many other platforms, but Android explicitly forbids this.
No, I've done real work on the go. The manufacturer of my tablet sells it as a productivity device. My tablet is more powerful than my laptop and I have a portable keyboard and mouse for it.
Why have all this power if all I can do is play Candy Crush?
As a programmer, literally no work can be done using it as a "Java based platform". We're effectively unsupported. Why do you continue to argue this over and over when there's no way Android is productive for programmers as-is?
Yes, plenty of musicians, painters, designers, can do real on Android. We cannot. The unix nonoculture, as you call it, is effectively programmer culture -- even Microsoft has included Linux with Windows now. Supporting a Linux user land on Android would be easy (given it's Linux kernel roots) and instantly give developers a massive library of software to work with.
In 12 years, not a single decent useful developer tool has ever been built natively for Android. With a few small moves, Google could give developers 50 years worth of software to be productive with. Instead they continue to make it more difficult.
Apparently the 10 years I spent programming across 8 bit and 16 bit platforms, while UNIX was closed at university campus and deep pocket companies, didn't had any programmer culture.
Adroid is productive enough for me to have some coding session while having a coffee or a short train trip.
As of the existing solutions being lacking, don't wait for Google, produce it, and sell it on the store.
Business opportunity, as one of my beloved teachers used to say.
Honestly, Apple should have gone with BeOS and I look forward to Fuchsia.
> Apparently the 10 years I spent programming across 8 bit and 16 bit platforms
At the time you never touched a command line or a compiler? You keep replying to but you haven't gotten anywhere near a point.
> As of the existing solutions being lacking, don't wait for Google, produce it, and sell it on the store.
You can't even build it -- the store is now restrictive enough that an honest to goodness compiler that produces runnable executables is impossible. That's the whole point.
We can't even make Turbo Pascal for Android.
The funny thing there are plenty of existing solutions that work just fine right now but Google keeps tightening the screws.
Apples huge success with developers on Mac OS definitely resulted from it's Unix abilities. WSL on Windows is Microsoft's direct response to that. You might hate Unix but denying its utility is futile.
Naturally I touched a compiler, IDEs were already a thing, just like AIDE is an option on Android.
And command lines that were 100% unrelated to UNIX, just like some that exist today on Android, written in Java/Kotlin.
A command line doesn't need to be yet another bash clone.
WSL on Windows is Microsoft's marketing to FOSS developers that rather give money to Apple to build their beautiful GNU/Linux apps instead of supporting Linux OEMs, and required to have Docker, the 2020 NoSQL.
It's an option but it's pretty terrible. It's basically the state of the art on Android and it gets worse from there.
> A command line doesn't need to be yet another bash clone.
No, but if your platform already runs Linux then it's a pretty good choice. Plus, at this point, it has the largest body of code/scripting available. I don't want a command line that doesn't run anything just like I don't want an OS that doesn't run anything.
Android doesn't run Linux, it is an implementation detail, Google could replace it by BSD on Android 12 and no well behaved application would notice, given that syscalls aren't part of the public APIs.
Kotlin is the main official language since 2 years now, it shows how much you know Android.
It literally does. It doesn't run GNU/Linux. And the native non-Java API is usable by Android applications so it's not just an implementation detail. In fact, I suspect most games are developed this way. This shows how much you know about Android. Google even calls this the Native Development Kit.
> Kotlin is the main official language since 2 years now
Kotlin doesn't run on Android. You need a "real" computer to run Kotlin. It's not an Android native development tool. Why you bothered to bring it up when it's outside the scope of this conversation, I don't know.
Correct me, but pydroid looks like it is a native python interpreter very much like what termux has to offer.
They write in the description:
- Full-featured Terminal Emulator, with a readline support (available in pip).
- Built-in C, C++ and even Fortran compiler designed specially for Pydroid 3. It lets Pydroid 3 build any library from pip, even if it is using native code. You can also build & install dependencies from a command line.
So when SElinux comes to Android this app will be broken, too.
Not exactly, it doesn't use "java frameworks". I don't exactly remember Implementation details (has been few years since I fiddled with it). It executes binaries same way as any app can do, there may be some JNI involved in the way you get to shell, but that's it.
And what's wrong with it? It may be implementation detail but termux increases utility of the phone. It seems you always have an axe against UNIX / FOSS ecosystem to grind. But every system has its strengths and weaknesses, Unix is just too ubiquitous for what it is worth. Look at fuchsia, while having laudable goals, has already become quite complicated (in typical Google project manner).
Currently my most commonly used tool in Termux is youtube-dl from pip. Please point to how you can install it via these other Java based shells or language REPLs. Termux provides a lot more functionality than an interpreter.
This is far from true. Unless Google removed the possibility of installing packages from third party sources, the situation in Android for *nix username is still far better than iOS.
Edit: Note that the Advanced Protection program is opt-in for users that require the highest degree of security Google can offer. Regular users won't be impacted by this.
Edit: proof https://imgur.com/a/yktPNIc
Edit 2: see @haunter's comment for a link to the change announcement