Verified developers

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:

  1. User wants to install GIMP
  2. User searches for GIMP and gets multiple results.
  3. User asks “is this the official one?”
  4. 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.

1 Like

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.

Ended up here due to this post.

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:

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