Show a badge for certified apps

arslivinski commented 6 years ago

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

jgarciao commented 6 years ago

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 commented 6 years ago

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

SISheogorath commented 4 years ago

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 commented 4 years ago

@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 commented 3 years ago

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:

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.
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.)
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.)
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 commented 3 years ago

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

elsiehupp commented 3 years ago

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

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),
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 commented 3 years ago

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

patrickrst commented 3 years ago

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.

SISheogorath commented 3 years ago

As @TingPing has pointed out, we can not use anything that is maintainer-controlled (on the flatpak side) to validate that the maintainer is the actual maintainer.

So I guess the only way to mark an app published by the developers is either by maintaining a list of these apps somewhere externally and/or by marking only apps that are actually uploaded by maintainers (such as it currently is the case with Firefox) to flathub and have no flatpak repository representation.

However, AFAIK the Firefox app is currently and might be permanently the exception. So I don't see this going anywhere near future unless one wants to do manual verifications.

patrickrst commented 3 years ago

My idea was that if the source in the manifest of the app is set to the developer repository, then the developer controls that repository and could place a piece of information to identify the account used to maintain the app on Flathub.

For example, the manifest for CherryTree includes the following in the modules section:

{
    "name" : "cherrytree",
    "buildsystem": "cmake",
    "sources" : [
        {
            "type" : "archive",
            "url" : "https://github.com/giuspen/cherrytree/releases/download/0.99.42/cherrytree_0.99.42.tar.xz",
            "sha256" : "d490df4c841bf71721bdb1f6b77831dc11bafbaed22fe129f5566e2499a90154"
        }
    ]
}

Someone that wants to upload CherryTree on Flathub would need to use the repository https://github.com/giuspen/cherrytree as the URL of the source since this is where the program is hosted and developed. That repository is owned by the developer, so we know we can trust information from there. If the developer place a piece of information on that git repository to identify the GitHub account used to upload to Flathub, then we can verify that the account matches. This is not possible right now since there is no way in the Flatpak app manifest to identify which source actually represents the application and is not just a dependency.

A user could still fork the repository and upload an app using the forked repository, which would show the "verified" badge. I guess forks are allowed as long as they are not malicious, so what would be important is to clearly show the app ID and the repository or website containing the program source for user to be able to see those are different app. Some semi-automated verification could also be done to verify that an app is not pretending to be another app (for example check if app with similar name already exists).

Again, that would require to modify Flatpak manifest to be able to identify which source in the modules section is the "main" program source and for every maintainer to add it if they want to get the verified badge. This may not work for every app depending on where the source comes from, but should work for git repo and when hosted on website controlled by the developer.

Jehan commented 3 years ago

My idea was that if the source in the manifest of the app is set to the developer repository, then the developer controls that repository and could place a piece of information to identify the account used to maintain the app on Flathub.

The problem is that having control of some website or some repository absolutely doesn't mean you are the actual upstream. For repositories nowadays, with everyone "forking" every repo, it is harder to determine valid upstream, especially for smaller projects. When we add new dependency source, I always spend 10 minutes to make sure we get the right upstream. I'm sure many people who make flatpak manifests here can relate to this.

As for websites, it's the same. Even for bigger projects, there are many cases of impersonation. Here for instance is a recent message by the Inkscape team warning everyone not to trust anything but inkscape.org because there are actual cases of fakes in the wild: https://twitter.com/inkscape/status/1446169748656431134

At GIMP, we also have had various cases of impersonations. I remember one app on some store publishing GIMP and pretending to be a fake "Gimp foundation".

While it might seem obvious for seasoned developers what is the real GIMP or Inkscape website, many users don't even know we have a website (they just download from various third-party sources, like repositories or sometimes more shaddy software-download websites, so they don't need to know!) so even less which URL it is.

So yeah the .well-known/ process is good to tell you "the person using flathub also controls this URL (which can be anything like a fake GIMP or Inkscape website, or a source repository fork)" but it is not telling you that this person is the upstream developer. It looks like manual verification (trusted community of "moderators") is the only way to do it right.

Note though that it can be coupled with the proposed process, i.e. that we could have .well-known/ file on some website or repository, but then a human being would have to double-check that the URL is actually the upstream dev by crossing sources (so for instance, it's a file in gimp.org/well-known/ not some other official-looking-yet-not-official URL; verifying that gimp.org is indeed the upstream). And of course, there would need to be automatic invalidation if ever the verification URL is changed so that it needs to be manually validated again, from the start.

patrickrst commented 3 years ago

I agree manual verification would be the way to go to have any added security associated with showing a verified badge. Otherwise has you said it is easy to impersonate an app just by forking and using a similar looking name and URL.

Adding the information that the owner of a repo is also the maintainer could be a signal that there is a good probability the app on Flathub will get new releases at the same time as the upstream. But that would need not to give any sense of added security to the user and I don't know if it's worth it as a feature by itself.

Jehan commented 3 years ago

But that would need not to give any sense of added security to the user and I don't know if it's worth it as a feature by itself.

Don't get me wrong, I personally believe having a "Upstream-maintained" notice (or "badge" or whatever you want to call it) is a nice idea. That's why I'm subscribed to this discussion (hence answering).

Just it has to be well done. And I think human-verification (based on trusted community members for instance, not necessary the developers of Flathub or maintainers who may not want to do this day-to-day additional work) is one of the few sane ways to go.

Actually just now I thought about a secondary way, which would be to base ourselves on a trustful database of projects. For instance, we were recently introduced to this Anitya database mostly used to automatically check for new versions of dependencies in flatpak manifests. Well if the info there is well-maintained and is considered trustworthy, then a project could use the well-known file protocol on a URL listed on such database.

For instance, I see GIMP page is properly set so it would work in our case.

patrickrst commented 3 years ago

I'm not sure to follow how the information from Anitya would be used. Would it serve as a source of information for a team of moderators? Right now it seems like anyone with an account can modify the information on https://release-monitoring.org, so that is a problem. But it does make sense to share the workload of verifying app with other distribution projects.

elsiehupp commented 3 years ago

VS Code just implemented a system for publisher URL verification that might be a useful precedent. The linked help section doesn’t go into a lot of detail, but it sounds like they do it using DNS.

jurf commented 3 years ago

They just require adding a TXT DNS entry; it’s a commonly used approach (e.g. Google Search Console uses this to verify you own the domain).

elsiehupp commented 3 years ago

Well, that’s an option here, I guess?

Jehan commented 3 years ago

Well, that’s an option here, I guess?

That's a technical implementation but it doesn't solve the main issue which is: how do you validate that a website is the one from the upstream developers? Let me give you an example:

Say a malevolent third-party uploads GIMP on Flathub and in the manifest I say the website is gimp.scam (instead of gimp.org) which is really a domain controlled by this person.
An automatic system could validate that the person control the domain, it could do it with a DNS entry (which is a common technique), or with a well-known file through https (another common technique proposed earlier). Which method doesn't matter because the third-party really has access to gimp.scam, so they could add the DNS entry without a problem.
As a result: Flathub would now display a "Published by the upstream developer" flag for this package and people would download it completely full of trust (which is very bad as a false sense of security is worse than having a doubt).

So the problem is not how Flathub would validate a domain (there are many good solution for this), but it is how you validate that the said domain is really the upstream one. As far as I can see, the only way to do this with little doubt is through human validation (not perfect, one can still make mistakes, but it more trustworthy than without), which means a community of trusted people who would manually verify a claim of being an upstream domain (the human verification can then be backed by the automatic verifications as secondary step). For instance with any of the proposed techniques above, the only verification to do is whether or not the given domain is the upstream domain. Only then the automatic check has any value.

For the record, the risk stated above is not theoretical. I posted a link above where the Inkscape developer warned people of a fake website (for which a real domain inskcape.<use-whatever-tld> was registered, cf. the screenshot in the link) with people behind who even sent scam messages pretending to be the Inkscape team. This was barely a few weeks ago. In the case of GIMP, we also had similar experiences too. Even just now, it took me less than 2 minutes to find a random (non-upstream) website with GIMP name and logo and proposing downloads (I just tried various TLDs). So yes, a DNS entry or https automatic verifications are not enough. These may be a part of a validation process but are not safe alone by themselves.

Now would this community of reviewers be Flathub-only or use a shared resource (such as the Anitya project I linked previously)? Both are possible. To answer an earlier comment too:

Right now it seems like anyone with an account can modify the information on https://release-monitoring.org, so that is a problem.

I don't know enough this project to give an opinion. It would definitely need to be verified. Nevertheless a process based on community-trust is not so bad, even if it does indeed result in some small risky windows. It all depends on whether there are counter-measures to detect and fix quickly the malevolent edits. Anyway not saying this is necessarily the database to use. I don't know. I simply discovered this project recently and thought it was of interest for this discussion.

elsiehupp commented 3 years ago

One take on this is that as long as gimp.scam isn’t malicious, it would be okay for them to distribute an application with the ID scam.gimp.Gimp. Basically the verification would be that the person submitting the application controls the domain associated with the application ID.

Now, the broader problem this doesn’t solve is when you have multiple versions of the same application with different distributors. In that case, the best practice would probably be to do some degree of investigation to see which version has the best claim to the trademark for the application name.

Obviously some preemptive check would be ideal for trademark purposes, which could potentially allow for someone submitting an application they don’t control but that still uses the official upstream repository. In this case, the application would be “unofficial” but still potentially allowed.

And in general each submission should be manually checked to make sure the repository it points to is indeed the upstream repository, and, if it isn’t, the submitter would be required to use a sufficiently distinguishable name for their fork.

So, yes, there are kind of two separate issues at play, but I don’t think forks should necessarily be rejected outright so long as they don’t use confusingly similar branding to the originating project. What do you think of that?

elsiehupp commented 3 years ago

And in general each submission should be manually checked to make sure the repository it points to is indeed the upstream repository, and, if it isn’t, the submitter would be required to use a sufficiently distinguishable name for their fork.

In this case, scam.gimp.Gimp would not be allowed, but a GIMP fork with the ID scam.gimp.BondageSuit potentially could be.

Jehan commented 3 years ago

One take on this is that as long as gimp.scam isn’t malicious, it would be okay for them to distribute an application with the ID scam.gimp.Gimp.

Of course. But this report is about certifying an application as "being maintained on the store by the official developer." Please check the initial report description. It is not about whether third-party are allowed to publish the software too. We know they are, we know the definition of Free Software too, don't worry. 😛

So the rest of the post is simply off-topic for this report.

but I don’t think forks should necessarily be rejected outright so long as they don’t use confusingly similar branding to the originating project.

I don't think anyone said anything like this. This is not the topic we are discussing here. Nobody has said anything about rejecting apps, or forks, or anything of the sort. 🤷

elsiehupp commented 3 years ago

This is not the topic we are discussing here.

It had been a while since I last interacted with this thread, so maybe https://github.com/flathub/linux-store-frontend/issues/214 would have been a better place for me to comment about the VS Code DNS thing.

1player commented 2 years ago

Verification badges are now tracked in https://github.com/flathub/website/issues/44

flathub-infra / linux-store-frontend

Show a badge for certified apps #48