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?
@mro if the signing key is the root of trust in the developer, then it is important to know that the developer understands that and takes it seriously, and doesn't just give away the keys to the root of trust.
@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.
@alsutton @postmarketOS This would specifically link the app and the domain name. That would give the app signer's pseudonym a website/email link, building a more complete pseudonym profile. But I can't see how that would change anything for when the user wants some method of verifying the developer. Linking to someone's government identity does make it easier to track down the actual people who are involved.
@eighthave @postmarketOS The owner of the domainwould be considered the developer, and most (if not all) DNS registrars have an identity verification requirement (even if it is checking a card is on file that, at some point, was used for payment)
@alsutton @postmarketOS sounds like you are proposing some kind of government ID check, then, albeit via the domain name registrar. Also, there is no natural link between a domain name and an app, that has to be invented.
@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?