snapd currently returns a developer field for snaps. Since the store can contain multiple versions of a snap it is desirable for a user to be able to check they have the official version installed.
This is done in other app stores (Apple, Android etc) by putting an icon beside the developer name for accounts that have done some verificiation.
We could implement this in GNOME Software if we had:
A new boolean field from snapd e.g. developer_validated that we could use to hint to the user that this is an official account.
A means of validating developer accounts, perhaps via a store assertion?
A process for validating major account, perhaps the snap advocacy team?
Verified accounts is something that was baked into the model from the start, but we donât yet have a process around that which verifies and displays that information. We just need to put that in place.
Official versions sounds like something else, though, and we donât have that in place in the model, or even a clear idea of what it would entail. Verified accounts would still be able to publish any snap they want, and that would not mean they are publishing the official version for that particular piece of software. Of course, weâll know what well known brands are supposed to publish, but that doesnât work with software for which most people donât recognize their authors.
I donât think thereâs a technical solution / requirement to actually verify the snaps. I would think that a condition of being a verified developer is you only publish your own software.
The use case is:
User wants to install GIMP
User searches for GIMP and gets multiple results.
User asks âis this the official one?â
User is reassured that it is marked as from âGIMP Project (verified)â so continues with confidence.
Ratings and reviews will also help with confidence here (bad copies / malicious apps will be downvoted).
Agreed, but this is the happy case of the scenario described above. The unhappy case is when you run snap info and find âGustavo (Verified)â as the publisher, and then wonder âWho the heck is Gustavo!?â.
Thereâs also some danger that we need to mitigate about people associating trust with verification. On social media thatâs not an issue because all weâre getting are comments anyway. But verified developers will still be able to publish whatever they want, just like everybody else, and people might end up associating trust with that badge, when in fact it just means that there are good chances of this being a real name behind the account.
maybe rather than, or in addition to, verified developers we set up a designation which is asserted by the store on a single snap that indicates that it is the snap endorsed by upstream whoever they happen to be.
Kind of like the way DV SSL Certificates are validated by proving you control some aspect of the domain in question when you request a cert, there should be a manual process for an individual snap-and-developer combination that certifies that the developer is actually allowed to publish on behalf of the project/product.
The snapcrafters initiative should not be blocked from registering the official names, though, because weâre registering the preferred name on the basis that weâll hand-over control when upstream is ready. At the point we hand-over control in this case the store admins would perform the manual verification step that whoever we handed the snap to is the official place and apply the endorsement bit in the store. So people arenât blocked from registering any name, but the store provides proof of a specific snap AND developer combination.
I understand the complexity of this and itâs mainly a business process issue and it really depends how much the SNAP store wants to take on.
Political Blurb:
I donât want to rehash an old issue, but you really need to figure out what the SNAP store wants to be. For example, SNAP has been very adamant about forcing auto-updates. Which is fine, but understand that from a business perspective, youâre taking on more power and responsibility as the store. If you want that power and responsibility, you canât just wash your hands of the situation and say we canât take responsibility for verifying.
Some Ideas on Verification based on increasing âverificationâ
Just ensuring the publisher is valid
Manual check to ensure the publisher is the one who âownsâ that software. For example, GIMP SNAP should be verified to be built by the âGIMPâ team.
Manual inspection of the build process. For example, if there is some project on GitHub, you should inspect the SNAP build process to make sure that youâre basically getting a build from the sources on GitHub.
Manual rating of Publisher trust Level. Something like Mozilla would get a higher level of trust than myself. You donât want this to get political, like if a product is say ad-supported or has tracking⌠that shouldnât reduce itâs trust. Itâs more a trust of if the SNAP is going to get you what you expect. if you download a Facebook SNAP in the future, itâs basically a are you a getting the Facebook SNAP free from viruses, malware⌠It shouldnât get into Facebookâs tracking of users or business model.
Manual inspection of the app itself. Functionality, security, source codeâŚ
How far up the chain you go is up to you. Obviously itâs going to be more expensive as you go up the chain. But thatâs the cost of doing business if you want to be in the âapp-storeâ game. Maybe even start charging money to evaluate an application; especially for commercial users.
Edit, I think as well, you might want to not just have a boolean here, but some value.
Maybe a trust score of 0-10 (Where 10 is very trustworthy). Or something along those lines. Maybe different numbers of checkmarks if you want it easier. The user can then hover over or click in to see more details to see what was verified for that applications/publisher.
In March 2023, I see more and more verified publishers on Snap Store. They have a checkmark next to the publisher name in the web interface, the CLI, and the GUI. So I guess this feature request has been completed.
