Show a badge for certified apps

[arslivinski]

Just like on Twitter, show a badge for an app being maintained on the store by the official developer.

[jgarciao]

We discussed recently on flatpak irc about adding something like this in the appdata so the webapp will be able to show "Published by the upstream developer" or "Endorsed by the upstream developer" message

I'll ask @alexlarsson about this

[TingPing]

Will need some trust-worthy way to set that information.

[SISheogorath]

I think rel="me" links (similar to mastodon) on webpages should work. When the flatpak page is linked somewhere and this link is stored in the appmeta data would make it easy for app vendors to mark things as official. and allow mutual authentication. Main problem I see is client privacy (as to validate the claim it would be required to reach out to the claim site). Raises the big question: Do we want this to be cryptographicly secure or are we fine with trusting the upstream repository?

As the build-bot could validate the claim and just pass the official badge downwards and clients could re-validate if they want. vs. Clients have to validate it themselves and therefore we pass an cryptographic proof using app metadata to the client.

[TingPing]

@SISheogorath At a glance I don't think that approach is helpful at all, package maintainers can do anything including control the metadata. There has to be something set by the repo admins externally.

[elsiehupp]

Copied over from #214:

One way to differentiate between developer-published packages and “community-published” packages could be to have the storefront check for a specific <meta> tag in the <url type="homepage"/> URL. For comparison, Safari on iOS has long had the ability to check for the following <meta> tag:

<meta name="apple-itunes-app" content="app-id=myAppStoreID, app-argument=myURL">

Flathub could provide a similar template, along the lines of:

<meta name="flathub-flatpak-app" content="app-id=FlathubID">

This <meta> tag would allow several things:

1. If page at the <url type="homepage"/> URL of a Flathub app had a <meta> tag with the corresponding Flathun App ID, the Flathub storefront could feature a “blue checkmark” or something similar in one or more places on the page.
2. Flathub (or, honestly, any third party) could build one or more browser extensions checking for the <meta name="flathub-flatpak-app" content="…"> tag on each page and showing a small banner (as on iOS) telling the user that the page has a corresponding app available on Flathub or suggesting that the user open the app if they already have it installed. (There are a number of further security considerations here that are beyond the scope of this thread.)
3. Eventually, the tag and extension could support an app-argument (as on iOS) for the purpose of allowing websites to deep-link into corresponding apps. (Again, with additional security considerations.)
4. Since one of the concerns on this thread is properly directing bug reports and support requests, the Flathub storefront could set the <url type="bugtracker"/> to github.com/flathub/<app_id>/issues unless the <url type="homepage"/> has been verified.

Obviously, anybody could unilaterally add this <meta> tag to their website; the more important question would be whether Flathub would run a bot making any use of it. Essentially, the <meta> tag could facilitate a “handshake” that would enable a given app page on Flathub to display “flair” emphasizing its verified/official status. App pages without verified <url type="homepage"/> URLs would continue to appear exactly as is aside from the <url type="bugtracker"/> defaulting the corresponding Flathub GitHub Issues page.

Note: there’s an existing npm package specifically for grabbing URL metadata, so the Flathub web storefront wouldn’t have to rebuild the wheel from scratch.

[elsiehupp]

(This is just what I posted on the other issue, so it may not be framed in the most relevant way here.)

[elsiehupp]

I’m not terribly familiar with how Mastodon does things, but it looks like the big difference with my suggestion is that:

1. The attribute name="flathub-flatpak-app" would be specific to the Flathub storefront and need not provide any information other than the fact that the page is claiming that particular App ID (and possibly facilitating deep-linking),
2. The verification would be carried out by flathubbot or something similar, and the boolean “verified” property on each URL would completely static by the time it reached the client, rather than being carried out client-side.

(There would need to be additional safeguards in place to remove verification in the case of suspicious domain transfers, e.g. DNS hacking redirecting a domain to a phishing site, though something like DNSSEC support might be useful to submit to the Freedesktop AppStream specification, as well.)

FWIW the Apple precedent I’m comparing this to does allow for affiliate tracking, but Flathub doesn’t need to implement any similar functionality. That is, if a page were to include tracking data, flathubbot or a browser extension could simply ignore/discard it.

The biggest limitation, of course, is that verifying that the entity publishing the Flatpak on Flathub also controls the page at <url type="homepage"/> doesn’t necessarily imply that the page at <url type="homepage"/> is, in fact, the homepage of the upstream developer. So it would be necessary to temper how the storefront chooses to display the verification accordingly. But even if the checkmark was only shown next to the link at the bottom of the page (and the title of the link, i.e. the developer name, were verified to match the linked page in some way or another), it would still provide useful information that the storefront does not provide now.

This is to say that providing verified links could be in and of itself a useful feature, even if Flathub doesn’t verify applications themselves, per se. This feature would probably work best if it were paired with a clearer contextualization of what each URL means on the Flathub app page template.

[elsiehupp]

Well, I just submitted an issue on the AppStream specification, if you want to weigh in there.

[patrickrst]

Had an idea how this could be done. I'm not familiar with Flatpak/Flathub so much so probably needs some more thoughts.

If the Flatpak app manifest had a way to identify the main application module, then the URL set as the source could be used to verify the publisher of the app. If it's an archive on a website, the developer can place a file under .well-known/. For a git repository, not sure what would make more sense between a commit/tag/branch or something else. But the information needed would be the GitHub username the developer wants to publish with. Flathub can then check that the GitHub user publishing is the same as the one from the information available at the source of the main application module.

Another idea, for public GitHub repository, it could also be done by checking that the user publishing is also the owner of the source repo. But that wouldn't necessarily work for organizations and not at all for archives coming from websites or other git hosting. So not much of a solution.