The feature is intended to protect the user against malicious (or other kinds of insecure) updates from the developer. It is particularly important to implement Android-native apps in ICP blockchain.
To implement this, there is no necessity to download from a phone (probably).
It is enough to keep in sync phone and your server under the condition that the phone is not hacked, because it protects users from malicious developers, not from the user tweaking (e.g. rooting) the phone by himself. If the user reprograms his phone, the security invariant is broken, but that’s not our concern, it is the user concern. As long as the phone is not hacked, we can know which apps on it may be installed. (Or I think so, I am not an F-Droid expert.)
If the app is signed by F-Droid then whatever the developer does later does not matter, users will get the same APK that F-Droid built… forever.
If the app is built reproducibly, then F-Droid builds and verifies to match the developer APK, IF IT DOES, then F-Droid serves that APK… forever, no matter what the developer does later.
Knowing that, what exactly are you protecting against?
I protect from a malicious (or uncareful) developer updating an app from a known secure version to a new, insecure version.
Particularly, I protect the user from an insecure app requesting a secret key from backend server and receiving it (and then, for example, doing a fraudulent transaction on behalf of the user).
the developer provides both the app and processes those api responses, there is no need for the developer to have the hash of their own apps when processing it because a mismatched hash could only be published by them or by google and if google published a malicious build they could too just provide malicious responses
blockchain has no use here
apps have more security than a browser since the whole package is signed vs a malicious web server serving up any assest at will
I didn’t mean to use this tracker to report an Android issue.
the developer provides both the app and processes those api responses, there is no need for the developer to have the hash of their own apps when processing it because a mismatched hash could only be published by them or by google and if google published a malicious build they could too just provide malicious responses
No, Google server’s API should return a secure hash (not created by the developer). The hash is checked on the backend server. The backend server may use blockchain to be secured, while the app isn’t. Therefore, there is the need to check the app’s hash in the backend.
blockchain has no use here
The use of ICP blockchain is to verify the backend site. The backend site, in turn, should be able to verify the app.
apps have more security than a browser since the whole package is signed
vs a malicious web server serving up any assest at will
Opening an ICP blockchain page in the browser can ensure that this page wasn’t tampered. Apps currently don’t have such a feature. So claiming that apps have more security than a browser is wrong.
who deems what isn’t and is a secure version???
Code reviewers/auditors can proclaim some versions as secure.
Secure means that the app won’t do bad actions (like transferring all my money in a wallet to the app’s developer). Code reviewers/auditors can mark some software as secure after reading it source.
Code reviewers/auditors will watch and if a new version of an Android app is insecure, not add it to list of secure app hashes.
If a user tries to access the site from a not deemed secure app, the app will (intentionally) stop working. That may happen if a new app has been released but not reviewed and not added to the list of secure hashes.
A smart contract is a script inside a blockchain that accomplishes some operations like money exchange, as a whole (so that it wouldn’t happen for example that I pay and don’t receive back).
Smart is a reference to a script language for a blockchain.
To be usable for their intended usage, smart contracts need to be FOSS, because otherwise they would be hard to verify/audit.
I am trying to persuade Google to add verifiable hash to apps. This way, a smart contract of ICP blockchain would become able to check that the user uses a non-hacked app and that it therefore won’t for example withdraw money from the user’s account and send it to the developer for nothing.
The apps provided by f-droid are signed by f-droid. The developer can’t exchange the APK anyway, and they couldn’t do it with the F-Droid signature.
Also one definitely needs no blockchain to verify a hash. This all seems to be a solution looking for a problem.