>The desired end state of the world is one where is a well developed and mass-usable "third option" besides the duopoly. There should be a well identifiable app store where vital apps that one cannot not use (public sector, banking, medical etc) can be available, ideally as open source.
It's much easier to regulate the heavily entrenched duopoly at this point, like how EU is trying to do, than somehow get a third player on the market, and convince people and devs to jump on board off Android and iOS. That's just not gonna happen.
Even Microsoft was forced to throw in the towel and exit the mobile market and Windows Lumia phones were actually great, so there just is no space on the market for a third player that comes in so late in the game, to gain any sizable market share, that would convince users and devs to switch and allow for a sustainable business.
I think an issue is the presumption that it has to "compete"...
It doesn't.
A semi-niche device that is also a reliable "Don't need to upgrade hardware for a decade" option definitely has its place in the market, it just won't ever exceed 5% of the market... which would place it exactly where Linux desktop is.
Why do we keep acting like we need more than that?
A phone that won't be unusable due to vendor refusal to upgrade is a big thing for many users isn't it? Given widespread sentiments snd the fact most don't need to play high spec games, I could actually see it potentially exceeding Linux desktop share... but that presumes we don't see hardware fracture that destroys any market potential, which is what I've seen with the few projects for Linux phones - too many dogs eating each others lunches.
>A semi-niche device that is also a reliable "Don't need to upgrade hardware for a decade" option definitely has its place in the market, it just won't ever exceed 5% of the market... which would place it exactly where Linux desktop is.
It won't even reach 5% of the market, when it will cost more than a mass produced cheapo Android device, be uglier, have less battery life, and take worse photos along with not being mainstream available in shops.
FOSS phones already exist, and nobody is buying them other than Linux youtube reviewers (and they aren't daily driving them either), because they cost as much as half-decent phones, while being a lot worse and not supporting the major apps that people use to communicate with normies (what people mostly use their phones for).
The amount of consumers who value a FOSS phone over everything else is a lot less than 5% of the market. It's an extremely niche market.
Ecosystem fracture and uncertainty of LTS are _The_ reasons I don't have a Foss phone. Full stop.
A coordinated drive behind a few hardware designs and an independent central org (think GNU/FSF) that effectively guarantees at least one OS option exists for the device lifetime are the keys to the goal.
Having that allows others to build thier variants.
We can't have a Foss phone built using phones which are explicitly built for a specific OS (android) and without having the drivers for components open source (to ensure anyone can patch it etc).
And look at the drive to "dumb" phones currently occurring specifically because people are tired of the "this device doesn't support the current version of android" bs... there are far more people in the potential customer pool than ever existed with PCs (where you have historically been able to upgrade for a decade+ before hardware was simply unable to support the software).
> It's much easier to regulate the heavily entrenched duopoly at this point, like how EU is trying to do, than somehow get a third player on the market, and convince people and devs to jump on board off Android and iOS. That's just not gonna happen.
There is a significant possibility to do this with Android because nearly the entire platform actually is open source. What you need is for someone to provide an alternate implementation for the Google-proprietary bits. Which isn't trivial -- it's a lot of work -- but it's at least feasible given some dedication.
What you really need from laws is to get rid of the ones that prevent this from happening, e.g. anti-circumvention laws that prohibit a competitor from achieving compatibility by bypassing remote attestation. Because as long as those laws are still on the books, you can't build a compatible system, which is the first foothold you need in a market with a network effect.
>e.g. anti-circumvention laws that prohibit a competitor from achieving compatibility by bypassing remote attestation
I have a feeling you are misunderstanding remote attestation. Unless you are suggesting an Android competitor should harvest the keys from Play certified android phones and inject them into their own phones. Remote attestation does not affect the compatibility of software running on the system. It affects the ability of a third party server from being able to tell if your phone is running software the server trusts. If an app chooses to support only Play certified devices you will need to convince them that is worth supporting your phones too and you may need to provide your own remote attestation API. Perhaps support can be made easier if there was an intermediate API that wrapped a bunch of other remote attestation APIs and made it easier for apps to decide which they trust as opposed to needing to spend extra engineering time in adding support.
> Remote attestation does not affect the compatibility of software running on the system. It affects the ability of a third party server from being able to tell if your phone is running software the server trusts.
In other words, it affects the compatibility of software running on the system, because you can't get software that runs on their system to run on your system, because the third party server has been deputized as a monopoly enforcement agent.
> If an app chooses to support only Play certified devices you will need to convince them that is worth supporting your phones too and you may need to provide your own remote attestation API.
You can provide the exact same API, but if it doesn't sign the same code it won't be accepted until you have market share, which you can't get when your phone can't run people's apps. You have to be able to make it run the existing apps, as they are, without modification.
> Unless you are suggesting an Android competitor should harvest the keys from Play certified android phones and inject them into their own phones.
That is exactly what I am suggesting. Or find and publish exploits that allow users to extract the keys from their own devices and install alternate systems on them or port them to other systems.
If this anti-competitive edifice is not to be banned outright then at a minimum, maintaining it should have no support from the state.
>In other words, it affects the compatibility of software running on the system
Any app that targets AOSP will be compatible.
>because you can't get software that runs on their system to run on your system
Server side code is completely separate from an Android app. It would never run on your system.
>but if it doesn't sign the same code it won't be accepted until you have market share, which you can't get when your phone can't run people's apps.
Then bootstrap this process with as many apps as you can afford to work with. As you grow your platform you can onboard more apps and you won't have to pay as much money to get them to support your OS.
>That is exactly what I am suggesting.
Promoting breaking device security is a shady business practice and if found out the keys would be blacklisted.
You can only get keys to put in your device to do the attestation from Google, who then imposes restrictions on what your device can do.
> Server side code is completely separate from an Android app. It would never run on your system.
You obviously need the apps that run on your system to be able to access the server for that app.
> Then bootstrap this process with as many apps as you can afford to work with. As you grow your platform you can onboard more apps and you won't have to pay as much money to get them to support your OS.
There are no examples of this working. Microsoft even tried it and it did not work.
It's also clearly unavailable to Mozilla or Debian or anyone else without an existing monopoly to extract rents from in order to operate at a loss for an extended period of time.
> Promoting breaking device security is a shady business practice and if found out the keys would be blacklisted.
You don't tell them which keys they are. And if they blacklist entire device models then they'll hit lots of their own customers and make it hard for apps to rely on the attestation, which is great.
>You can only get keys to put in your device to do the attestation from Google, who then imposes restrictions on what your device can do.
The Play integrity API is not part of AOSP. Remote attestation does restrict your device from doing anything. A new attestation API can be made if you want to offer remote attestation to apps.
>There are no examples of this working.
Amazon successfully did it.
>It's also clearly unavailable to Mozilla or Debian or anyone else without an existing monopoly to extract rents from in order to operate at a loss for an extended period of time.
It just means that it will take longer if a there is trouble in finding investors. The standard 30% cut can be used to make it sustainable to support the operating system and fund getting apps into the store.
>they'll hit lots of their own customers and make it hard for apps to rely on the attestation, which is great.
It isn't great because it sets back the security of the industry back a couple years each time an exploit allowing this is found.
> Remote attestation does restrict your device from doing anything. A new attestation API can be made if you want to offer remote attestation to apps.
I guess you wanted to write "does not" here, but it's the opposite - it obviously restricts the new device from being practically useful, but what's important is that this is done not because the device has no capability to run those apps, but because it was not "whitelisted" by the app vendor, so a technically superior device might fail on the market just because of current players artificially blocking it.
This is an anticompetitive practice, where you need to get "permission" to be able to run the app. And no matter how "fair" that sounds theoretically, practically this should (and hopefully will) be a subject of some antitrust ligitation.
> It isn't great because it sets back the security of the industry
Notice how users aren't defending that "security of the industry". Isn't it strange?
>so a technically superior device might fail on the market just because of current players artificially blocking it.
Technically superior products can fail. A users choice on what to buy isn't just what in the most superior product. Apps not trusting a phone is a major drawback of a phone. It's not anticompetitive that apps don't automatically trust every new phone that comes into existence.
>Notice how users aren't defending that "security of the industry". Isn't it strange?
Because users on average do not care about security until its too late and damage has already happened. They don't care about how to stop spam, they just get angry when they get spammed.
> It's not anticompetitive that apps don't automatically trust every new phone that comes into existence.
Creating a mechanism that enables such things to happen obviously is. Google knows well that:
> Apps not trusting a phone is a major drawback of a phone.
and Google having the dominant position created and now controls that "trust", and actively abuses it to force its unremovable spyware onto users' devices. And when the user dares to remove them, then poof - they're not " trusted" anymore.
> The Play integrity API is not part of AOSP. Remote attestation does restrict your device from doing anything.
It prevents you from using apps that require it.
> A new attestation API can be made if you want to offer remote attestation to apps.
In other words, you can't use the existing apps.
> Amazon successfully did it
The Amazon Fire phone was discontinued after only a year.
> It just means that it will take longer if a there is trouble in finding investors.
What investors? The purpose of Debian is not to make money, it's to make operating system.
And if "take longer" means after we're all dead, that's not sufficient.
> The standard 30% cut can be used to make it sustainable to support the operating system and fund getting apps into the store.
30% of nothing is nothing.
Moreover, the 30% is a monopoly rent -- they only get away with it because they're the only viable store for that platform. Who is going to pay 30% in a competitive market?
> It isn't great because it sets back the security of the industry back a couple years each time an exploit allowing this is found.
Then don't use that app. The app won't work on a different phone Linux distro either.
>The Amazon Fire phone was discontinued after only a year.
The Amazon app store still exists. Windows even partenered with Amazon to bring their app store to Windows.
>What investors? The purpose of Debian is not to make money, it's to make operating system.
Making a successful operating system is much easier if you have funding.
>30% of nothing is nothing.
Even the Ubuntu software store was able to find people willing to buy software off of it.
>Moreover, the 30% is a monopoly rent -- they only get away with it because they're the only viable store for that platform. Who is going to pay 30% in a competitive market?
That is part of the business strategy that will need to be figured out.
>They find new ones every year. :)
Yes, but it is something we can get better at preventing and detecting to the point where it stops happening every year.
We should have laws that ban mandatory (i.e. something gets disabled if not present) remote attestation and secure boot for consumer and most business devices and software, period.
The only place where RA should be allowed is purely business oriented embedded devices like bank ATMs that actually need the security guarantees.
In general it should just be smashed into smithereens by a thousand hammers, because it can't be trusted with anything important anyway. Can you imagine what would happen if a bank actually trusted a client device and then somebody broke the attestation? That's not how ATMs work. You make a deposit and the funds are not available the same day, and it's not because their computers are too slow.
The only thing it's good for is anti-competitive prohibitions on interoperability, which only works if the law makes it illegal for competitors to extract the keys and use them.
> Can you imagine what would happen if a bank actually trusted a client device and then somebody broke the attestation? That's not how ATMs work.
I was more thinking about insider attacks aka maintenance people (or thieves with a good drill) inserting a malware-loaded USB stick that instructs the ATM to dump out money [1]. RA could be used as an additional safeguard here.
So the thieves have physical access to the ATM, and power tools. Why do they need the computer to do anything? Drill into the thing and supply power to the actuators that spit out the money.
Not only that, what is remote attestation supposed to do against a purely local attack like that? The attacker doesn't have to prove anything to the server. The local machine they've compromised is the one that directly controls dispensing the cash.
> So the thieves have physical access to the ATM, and power tools. Why do they need the computer to do anything?
It's easier to hack into the computer using an exposed USB port than to drill up the safe - its control electronics are usually well defended which means you have to spend way more time which may raise suspicion.
> Not only that, what is remote attestation supposed to do against a purely local attack like that? The attacker doesn't have to prove anything to the server.
RA could be used to verify what exactly is running on the computer, if done correctly.
>Can you imagine what would happen if a bank actually trusted a client device and then somebody broke the attestation?
Security isn't binary. Attestation makes the attack more expensive to carry out and less likely to happen. Businesses want to minimize risk. They understand that risk always will exist.
Attestation has a minimal effect on risk because the probability of a device being compromised is high and scales with the value of compromising the device. It isn't necessary when the value is low and it isn't sufficient when the value is high. There is no place for it.
Then you might as well give up on all security then if you are going to assume any security will be bypassed. Breaking attestation is not easy to do and increases the cost of a successful attack.
Remote attestation has a track record of being bypassed, unlike e.g. AES. To the point that Intel abandoned SGX in Core processors because it just kept getting broken.
There are security models that actually work. Alice and Bob want to communicate over a non-private channel, Alice encrypts her data with a key she shares with Bob, Eve has to do an infeasible amount of computation to decipher it because she doesn't have the key. Alice wants to encrypt her hard drive so when she turns off her computer no one who steals it can read it because they don't have the key which exists only in her own head.
Attestation is when Eve has Alice locked in her basement under 24 hour surveillance and can go at her with battery leads and MRI scans forever until she gives up the key. It gets broken again and again, because you're trying to prevent Eve from getting a key out of something she has in her possession, and "Eve" is everyone in the world because phones are commercially available to the public. The chances of that being broken are so high that you can't rely on it not happening for anything important.
The chances of AES being broken in the next couple of years, or at all, aren't nearly as high. Conversely, if you need to trust a remote device, you do it by providing physical security. This is why banks have vaults and guards and ATMs are encased in hardened steel and bolted to the ground and contain surveillance cameras with remote recordings. This is why the bank's servers, which actually are trusted by all the ATMs to identify who should be able to withdraw cash, are kept under 24 hour guard.
The amount remote attestation adds to these things is negligible because of the high probability of it being bypassed. It's snake oil. The only thing it does is trigger bad laws that prohibit honest competitors from bypassing it for benevolent reasons. Because the technology doesn't work, and the law only works against people who aren't willing to break the law.
Which is why such laws are pure negative. In the case were someone is trying to commit fraud or some other crime, there is already a law against that and a redundant law against bypassing attestation adds nothing. So all a law against bypassing attestation can do is prohibit legitimate otherwise-lawful activity.
If something has to be regulated as public utility it might as well be a public utility. That this cornered "market" will never produce competition is clear enough. But there has never been a device so intimately coupled with the lives of so many people. Past approaches dont apply to new challenges.
The question is how can the foss community use its limited resources to facilitate a "third way". There is some precedent in this respect from the fediverse/mastodon experience. The easy availability of a near substitute removes the TINA excuse from various stakeholders and policy makers.
Its neither a concrete path nor a certainty. My comment was simply that people should not create further obstacles by pursuing self-indulgent agendas
>The question is how can the foss community use its limited resources to facilitate a "third way".
It can't, you and I already answered that it's impossible to enter the mobile market withtout any government intervention to break up the existing duopoly.
Even the most hardcore Linux/FOSS fans don't daily drive FOSS Linux phones because they suck big time and have quirks impossible to live with, so mostly use iPhone or degoogled Androids, let alone have mainstream average users use them.
>This is plain false. Sent from my Librem 5, which I daily drive.
But what does this prove? The market share isn't there for these devices. Even the vast majority of hardcore Linux fans daily drive iPhones or Androids and only use those toys for tinkering. You being a Librem 5 user doesn't move the needle on how niche these devices are in the wild.
You shifted goals. The share is low, but FOSS enthusiasts do use those phones as daily drivers and constantly improve them. This is exactly how many innovations start.
>but FOSS enthusiasts do use those phones as daily drivers and constantly improve them
How many users other than you use FOSS phones? Is ist a sizable market or are we talking about a rounding error part of niche hobby?
Just judging by the comments here you seem to be the only user on HN with one, and HN is already a super niche community of FOSS enthusiasts, but even here most use iOS devices because people like using stuff that already works with the mainstream apps.
It's much easier to regulate the heavily entrenched duopoly at this point, like how EU is trying to do, than somehow get a third player on the market, and convince people and devs to jump on board off Android and iOS. That's just not gonna happen.
Even Microsoft was forced to throw in the towel and exit the mobile market and Windows Lumia phones were actually great, so there just is no space on the market for a third player that comes in so late in the game, to gain any sizable market share, that would convince users and devs to switch and allow for a sustainable business.