FPP 10 - Plugin install warnings: distinguish disclosure from trust judgments

[rdkbob]

Disclosure up front: I'm the author of PulseMesh, a third-party plugin that has been available for about two years and is currently the fourth most-installed plugin according to FPP's own opt-in usage statistics. This issue is obviously prompted by how the new install UX presents PulseMesh, but the problem isn't unique to us, and I've tried to frame it as a general design question.

First: I agree with the motivation behind the FPP 10 changes.

Plugins run as root with essentially unlimited access to the system and network, creating plugins is getting dramatically easier (including with AI-assisted development), and users should understand what they're agreeing to before installing arbitrary third-party code. Clear capability and privacy disclosure is the right direction, and the new author-provided disclosure section is a good idea.

My concern is with the language, not the disclosure. Several of the new strings go beyond stating facts and read as judgments about whether the software should be trusted:

• Every third-party plugin is described as "untrusted third-party code", and installing one is described as "inherently dangerous."
• A plugin that discloses a proprietary component gets the badge "Includes software that can't be checked" and a red install button labeled "Install, black box included."

These are different questions

The current UI collapses several distinct facts into a single trust verdict:

1. Is this plugin maintained by the FPP project?
2. Has the FPP project reviewed or verified it?
3. Can the publisher's identity be established?
4. Is all of its code publicly auditable?
5. What privileges does it have once installed?

All five are worth disclosing to users. None of them is the same as "should you trust this software," and none individually answers it.

"Untrusted" reads as a verdict, not a status

In a narrow security sense, "untrusted" can mean "trust has not been established." Most users won't read it that way — they'll read it as "this software is regarded with suspicion."

Compare:

"This is a third-party plugin that has not been reviewed or verified by the FPP project."

with:

"This plugin is untrusted third-party code."

The first describes FPP's relationship to the plugin. The second reads as a characterization of the plugin itself.

The same applies to:

"This is inherently dangerous."

The surrounding capability statement — runs as root, can read and change any setting, can reach the network — is factual. Appending "this is inherently dangerous" converts disclosure into a verdict, applied identically to every third-party plugin regardless of its history.

Taken together, "untrusted" and "inherently dangerous" communicate something significantly stronger than "this plugin is maintained by a third party and has not been verified by FPP."

"Black box" creates a disincentive for full disclosure

Closed-source software is not inherently suspicious. A plugin may legitimately contain a proprietary component while having an identified publisher, years of usage, and a large install base.

The factual disclosure:

"Contains proprietary software whose source code is not publicly available."

tells users exactly what they need to know.

Changing the install button itself to red and labeling it:

"Install, black box included"

reads less like disclosure and more like a recommendation against installing.

This isn't a corner case. FPPMon — currently the third most-installed plugin — is a third-party plugin in essentially the same position: it also includes proprietary software.

FPP's own opt-in usage statistics currently show FPPMon on 1,522 devices and PulseMesh on 1,325 devices, making them the third and fourth most-installed plugins in that data set. Because those statistics only include devices whose owners have enabled statistics sharing, those numbers necessarily undercount the actual install bases.

Three of the four most-installed plugins in that data set are third-party (Remote Falcon, FPPMon, and PulseMesh), and two of those — FPPMon and PulseMesh — include proprietary components. Under the current wording, all three are presented as "untrusted," while FPPMon and PulseMesh additionally receive the "black box" treatment.

There's also an incentive problem with the disclosure system itself.

The disclosure section is author-provided. PulseMesh hasn't added ours yet, so our listing currently shows "no disclosure" and a red "Install, no disclosure" button. When we add an accurate disclosure, the proprietary component will change that to the red "Install, black box included" button.

In other words, for any plugin that legitimately includes a proprietary component, there is no disclosure an author can write — however complete and honest — that results in a neutral install experience.

A disclosure system works best when accurate disclosure is the author's best strategy. Right now, accurate disclosure of proprietary software guarantees an alarming installation state.

The bigger gap: no way to establish trust

This is my main concern.

On Windows and macOS, software downloaded from the Internet can also generate strong warnings, but publishers have mechanisms for establishing provenance: code signing, notarization, identified-developer programs, and similar systems.

FPP currently has no equivalent path.

A plugin with two years of history and more than 1,300 installations even within FPP's opt-in telemetry is presented with essentially the same maximal trust language as a repository created yesterday by an unknown author.

That isn't just rough on established publishers — it also makes the warning less protective.

If every third-party plugin produces the identical worst-case warning, users learn to click through it, and the warning carries less signal on the day it actually matters. As plugin creation gets easier, the ecosystem increasingly needs the warning to differentiate between different situations, and today it can't.

Importantly, plugin age or install count shouldn't themselves be treated as proof that software is safe. But they are examples of useful context that the current binary "official" versus "untrusted" presentation doesn't communicate at all.

Concrete suggestions

1. Reword the trust statement to describe FPP's relationship to the plugin while keeping the capability facts.

   For example:

   "This is a third-party plugin. It has not been reviewed or verified by the FPP project. It will run as root and can read and change any setting, reach anything on your network, and do things not listed below. Install only if you trust the publisher."

2. Drop "This is inherently dangerous."

   The capability statement makes the point factually and, in my opinion, more credibly.

3. Make the proprietary disclosure neutral.

   For example:

   "Contains proprietary software (source not publicly available)."

   And leave the primary action as a plain "Install." Reserve red styling and alarming button text for situations where FPP has identified a specific security or integrity concern, so that red continues to carry meaningful signal.

4. Add some path for third-party publishers to establish provenance.

   That could eventually be verified publisher identity, plugin signing, or even simply surfacing contextual signals such as plugin age and install count.

   Those signals don't establish that software is safe, but they give users information that the current binary trusted/untrusted presentation does not.

I'd be glad to help with number 4 in whatever form is useful — design discussion, acting as a pilot/test case for a publisher-verification flow, or contributing implementation time.

[jessica12ryan]

If I may add to this, the privacy/security implementations are good, but they are not perfect and could still use some additional work.

I also don’t agree with the statement that “FPP has not verified this plugin.” Plugins are now reviewed and required to meet certain standards with each new major FPP release. Plugin developers are expected to make the required changes or provide reasoning where a change cannot reasonably be made. New plugins also go through a submission, review, and approval process.

The plugin submission and update process has become quite strict. Developers are expected to make changes, meet the guidelines, submit the plugin for review, and then wait for approval. Despite going through that process, the plugin can still end up being denied, and if approved, it is still presented to users as “not official,” “not verified,” or “dangerous.”

That’s the part I have an issue with.

If a plugin is reviewed and approved through the FPP plugin submission process, and then reviewed again when changes are required for a new major FPP release, it has in fact been verified by FPP at that point. The verification may not mean that FPP guarantees the plugin is completely secure or error-free, but saying that it has not been verified is misleading.

If FPP is going to require plugin developers to maintain their plugins, meet strict guidelines, and go through a review/approval process, then the wording in the plugin manager should reflect that.

Something along the lines of “This plugin has been reviewed and approved by FPP, but is not maintained by the FPP development team” would be much more accurate and would still make it clear that users should exercise appropriate caution.

Otherwise, if the intention is that FPP does not verify plugins at all, then the submission, review, and verification process should not exist in the first place. We can't tell people that something hasn't been verified when it has.

A thought to help with this process, if we could somehow check plugins weekly/monthly, to see if >40% of the plugin code has changed since the last major FPP version release, then we flag it as unverified, or perhaps trigger a plugin review on the fpp-data repo.

[darylc]

@rdkbob The FPP developers are discussing the issues you have raised. Hopefully we will have a further information in the next week.

[dkulp]

Thanks for writing this up so carefully, @rdkbob, and @jessica12ryan for the note on the review process. You were both right on the wording, and we've reworked the install flow on master (d02ffc8 and the commits before it). Here's where each point stands.

"Untrusted" / "inherently dangerous"
The per-dialog red callout is gone. Instead, the first time a player installs a plugin, it shows a short neutral note once (and again after each major FPP upgrade):

Plugins add features that are not part of FPP itself. Plugins in the list are checked against FPP's plugin guidelines when they are listed and before each major FPP release, but they are written and maintained by their own authors: the FPP project does not audit their code and cannot vouch for it.

A plugin runs with full access to this player: it can read and change any setting and reach anything on the network this player is connected to. Install plugins from authors you trust. Plugins marked Official are maintained by the FPP team.

"Untrusted" and "inherently dangerous" no longer appear on any install dialog. The only place "inherently dangerous" remains is the warning for installing from a pasted pluginInfo.json URL, which is a developer-only path.

"Not verified by FPP"
@jessica12ryan's point was fair: listed plugins go through the automated listing check, which compares the privacy disclosure with the code, and are re-checked before major releases. The disclosure label now reads "Disclosed by the author · checked automatically against its code for the plugin list". It stays clear that this is an automated check, not an audit. A plugin loaded from a URL says it had no such check.

Black box / the red Install button

• The Install button no longer changes with the privacy disclosure. It's always a plain "Install". It only becomes "Install anyway" for FPP's own checks: a version not updated for the running FPP, not enough RAM/CPU for the plugin's declared minimums, a pasted URL, or no disclosure at all.
• The closed-code light and its headline now read "Includes closed-source software", and the detail line is "Includes software whose source code is not public." The "black box" and "can't be checked" wording is gone.
• The privacy lights are neutral pills with a coloured dot rather than red-tinted badges. The detail for each one is in its tooltip and in a collapsed "Full disclosure" section, not in a block of red text under them.

The incentive problem
This is now the other way around. An accurate disclosure, closed-source component included, gets a plain "Install". What gets a red warning (and "Install anyway") is a plugin with no disclosure at all, since then nothing is known about it. So, @rdkbob, adding PulseMesh's disclosure moves it from the red state to the neutral one. The Privacy disclosure builder will write the block for you, and the Plugin preview shows exactly what FPP will render. Both use FPP's own renderer from master. The published rules in fpp-plugin-Template's PLUGIN_GUIDELINES.md §14.15 are updated to match.

Provenance (suggestion 4)
This one isn't settled. Install counts are already shown on each plugin card and in the detail view, but there's nothing yet for plugin age, publisher verification, or signing. That's a bigger design question the developers are still discussing, so I'll leave this issue open for it. Your offer to pilot a publisher-verification flow is appreciated, and we'll keep it in mind.

All of this is on master; the 10.1.x releases still show the old dialog. If you try master and anything still reads as a verdict rather than a fact, please point it out here. Also, all of the above is still subject to more changes as we continue to discuss.

[rdkbob]

Thanks @dkulp, and thanks to everyone who worked on this. This addresses what I raised. The neutral one-time notice, the "checked automatically against its code" wording (thanks @jessica12ryan), and a plain Install button for plugins with a complete disclosure all read as disclosure now rather than a verdict. Fixing the incentive so that an accurate disclosure gets a plain Install is exactly what I was hoping for.

I've drafted the PulseMesh disclosure with the Privacy disclosure builder and will commit it shortly.

On provenance: thanks for keeping the issue open for it. My offer stands to help with design, act as a pilot for a publisher-verification or signing flow, or contribute implementation time whenever it makes sense to pick that work up.