A security feature for app stores

I submitted a feature request for Google app store. I also submitted it to Apple.

Now, please, implement it in F-Droid, too.

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.

You do know that all (F-Droid, Play and AppStore) don’t RE-download anything from the developer, right?

They get it ONCE… and host it.

Or maybe I misunderstood your idea?

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

hey, maybe we are lost in translation?

F-Droid builds the app, right?

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

what does secure even mean?

will you watch the source code changes to see when the “bad code” is introduced?

This is wrong

  1. that isn’t the Android issue tracker, you’ll never see a response there. You want this one: https://issuetracker.google.com/issues/new?component=1065083&template=1592194
  2. 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
  3. blockchain has no use here
  4. apps have more security than a browser since the whole package is signed vs a malicious web server serving up any assest at will
  5. who deems what isn’t and is a secure version???
3 Likes
  1. that isn’t the Android issue tracker, you’ll never see a response there. You want this one: https://issuetracker.google.com/issues/new?component=1065083&template=1592194

I didn’t mean to use this tracker to report an Android issue.

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

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

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

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

who? link to their site please

Look smart contract auditors in Google.

Is this a Google feature?

They need to be “smart”?

By that name they won’t appear to volunteer for this job, since it’s FOSS code, FOSS ecosystem, we need a FOSS mindset.

No. It is not a Google feature.

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.

We need people to verify the code, don’t jump steps to… :tada:blockchain:tada:.

2 Likes

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.

not all, some are built reproducible and F-Droid hosts the upstream verified APK

1 Like