> 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.
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.