At the core of #AndroidDeveloperVerification are a couple potentially useful ideas. #Google has entirely wrapped them in a pile of anti-competitive garbage designed to defend their massive #monopoly profit margins, but nonetheless, those specific technical ideas might still be useful. #iOS's "notarization" is basically the same. That leads me to ask the key question:
What would a #FOSS-respecting system of #verification look like? What #identity info is useful for trusting the #developer?
@eighthave I'm guessing there are different levels and maybe conflicting aspects?
Anonymity on the dev side versus a need to trust on the users', and then the need to trust may be more or less strong depending on what the software does?
(not an expert, just not happy about what Google is doing right now, and so musing as a way to not be hopeless)
@jexner Can the human be anonymous while the "dev" is public? Clearly, we want the apps we use to be maintained by entities that we can trust. Are given names required for that? I think clearly not. For example, non-profits. People trust #EFF as an entity, even without knowing who everyone works there is, and whether the staff changes. So the entity can be trusted separately from human participants. I think developers are similar. Many trusted FOSS contributors operate under pseudonyms
@eighthave Fully agree!
I guess it is somewhat difficult for an independent dev to do the scaffolding needed, but as long as you build "small" software, it may not have to be as complex as creating an organisation.
Is the question then simply: how do we know which "entities" are trusted and how do we make sure, a particular piece of code is "from that entity"?
@jexner your formulation seems like its going the right direction. On one hand, in the world of financial accountability, "know your customer" and showing government ID is normal. Borrowing an established practice makes sense when it works, but it doesn't feel right to apply that to developing software. I don't think the requirements are the same between finance and software, although sometimes similar. I haven't found a good breakdown though that maps that out.
Hi @eighthave,
being the same as last time and taking responsibility for the product.
So individual trust can build over time.
Translates to: install is visibly signed by the same dev-generated key.
@mro I agree, highlighting the role of the signing key seems key. An app signing key is in effect a pseudonym. The hard part is that there is that there is no concrete way for users to verify what the key management practices of the developer are. Judging that from the outside means looking for any signs that the signing key was misused. If a dev wants to hide misuse of their signing key, that is pretty easy to do. For example, they could sign malware and only ship that to targeted users
Hi @eighthave
> users to verify what the key management practices of the developer are
why should they?
@eighthave A verified link to their fediverse profile.
What #identity info is useful for trusting the #developer?
Otherwise, just a public GPG key.
(here using "GPG key" as catch-all for whatever cryptographic signature system)
The issue after all was never about the identity verification itself, but Google\Apple using it to limit access for developers.
@eighthave Public key(s) placed in a keys.{app}.{domain} DNS TXT record, private key encrypted app hashes in {version}.{app}.{domain} DNS TXT record, and an OS that knows how to download that hash, decrypt it, and compare it to the app binary it has downloaded.
Maybe @postmarketOS wants to implement this as a trial.
@rene_mobile @marcprux @fdroidorg @GrapheneOS @lehtimaeki @ottok @grote
You are all people who have specifically thought about this kind of stuff in relation to software distribution, what do you think?