When a plugin is removed from the community repo, the user isn’t notified. Instead they’re allowed to continue unknowingly using an unmaintained plugin.
For example, I only found out that Customizable Sidebar had been merged into Commander when I opened its description page to get the link for someone and the page was missing with no explanation. I had to search the web to figure out what had happened, and it was an annoying hassle.
More recently, someone in Discord mentioned that a plugin I have installed (but turned off a while back because of bugs) had been deprecated.
These aren’t how I should find out — Obsidian should tell me.
Proposed solution
Minimally: when checking for updates, also check for installed plugins that have been removed from the community repository. Notify if any are found.
Ideally: Provide a way for developers who remove their plugins to leave a message, and for Obsidian’s devs to do the same if they remove a plugin.
I just find out by happenstance, but I suppose you could manually check the description page of every installed plugin every so often to see if it still exists.
Related feature requests
Related discussion
Changes
(Examples of users encountering the problem are added in comments as I find them.)
2024-06-24: Added mention of plugins that haven’t been removed but which have the dev has indicated aren’t maintained.
2023-03-02: Added “and for Obsidian’s devs to do the same if they remove a plugin.”
Nearly a year later, still seeing users with Advanced Mobile Toolbar installed who don’t know it became part of Commander and isn’t maintained: Discord
What about using the plugin’s manifest.json to help this usecase ?
It could be a simple flag similar to isDesktopOnly or a more structured object.
For reference: Manifest - Developer Documentation
Moreover, the manifest.json can have an associated official JSON schema to provide better context to developers.
For reference on this topic: JSON Schema - Creating your first schema
Advanced Mobile Toolbar has apparently finally broken and left a user wondering about replacements because they weren’t notified of its removal and incorporation into Commander.
Dataloom is still in the plugin store, but its last update 2 months ago added a message to the description saying it is no longer maintained and that users should migrate to something else. This user only found out today:
Hey folks, just wanted to mention how outdated I’ve been in the plugins thingie cause I found out I’ve been using a deprecated plugin 2 months after it was killed (Discord)
This is a different case from that described in the feature request, but related, and for the end user very similar. A standard way to notify the user of this would be good.
A user tried to install a plugin they use in one vault in a new vault but wasn’t able to find it in the community store because it’s not there anymore.
I just realized that the plugin I am using for “Calendar View” is 3 years old and is no longer in the community store. searching for another Calendar View plugin dont’ bring me what I want . It is very bizzare. (Discord)
I wanted to install it on one of my new vaults and I was forced to copy paste the folder manually. … I was wondering I am searching for a wrong keyword or something. (Discord)
This is a critical missing feature. Users who unwittingly continue to use removed plugins could potentially incur data loss/corruption. Immediate In-app notification is particularly important when plugins have been removed because of security issues.
If we are aware of data loss or security issues we disable plugins, but most of the time a plugin is just outdated, and does not work, without data loss, that’s what this FR is about.
Currently when you turn on community plugins you get a warning about the risks and the mitigations that come with the plugin directory. However, there’s no distinction between risks for official plugins and risks for unofficial plugins.
This therefore has the effect of implying that any plugin installed after that point has the same level of risk. But this isn’t true. Installing a plugin through BRAT or by manually unzipping a download holds far greater risk because policy and review only applies to those officially submitted to the directory.
Proposed solution
I think this can be fairly easily improved.
On launch (or periodically), Obsidian could check if there are new plugins installed that are not in the list of those installed through the directory, and it could then give a big extra modal warning that plugins not installed through the directory, even if installed through another plugin, come with even more risks — Such as stealing your data, monitoring your actions, etc.
This delineation (Between managed installs and unmanaged installs) is the security vulnerability the review process is trying to mitigate. But the current messaging doesn’t highlight this, it instead lumps them all together and implies they’re all as de-risked as the official directory.
I believe this kind of improvement will bring a greater awareness to users when they’re installing things that might be a risk to them.
Related
This came from a discussion on Discord regarding telemetry restrictions. Not super relevant but here’s the link if curious.
I think there’s some argument to be made about whether the levels of risk are actually very different between the two. But I would point out that the current warning talks a lot about mitigations that the plugin directory provides — None of which apply to non-directory installed plugins.
So it’s also about making it clear that when installing a plugin manually those aforementioned mitigations no longer apply.
I don’t agree with this logical deduction. I don’t think it’s logical expect that a manually installed plugin has been reviewed. The BRAT plugin itself has its own disclaimers in the readme.
This FR is about making clear to the user (via icon, or notification) whether an installed plugin is NOT part of the official plugin directory. Either because it was manually installed by the user or because it was at some point removed from the official directory due to inactivity.
As explained by Joethei, a mechanism for deactivating a plugin that is causing data-loss is already implemented and is not related to this feature request.
I don’t think it’s logical expect that a manually installed plugin has been reviewed.
I think we agree. That’s what I’m saying.
A manually installed plugin may not have ever been reviewed - or may have even been reviewed and rejected.
Therefore, I believe there should be a reminder on abnormal install of a plugin that plugins not installed through the official directory carry further risk.
A disclaimer in the BRAT readme isn’t enough as that’s likely never read, and BRAT isn’t the only way to manually install.
No, I don’t think we agree at all.
I think a user that manually installs a plugin understands that said plugin has NOT gone through the review process.
The user is taking intentional actions that go beyond what the official directory offers, so they should understand that whatever they install has not gone through the review process.
I think a user that manually installs a plugin understands that said plugin has NOT gone through the review process.
I don’t think that’s a very reliable assumption. Certainly many people understand that, but that doesn’t mean all do. Especially new users.
The user is taking intentional actions that go beyond what the official directory offers.
But how do they know that’s what they’re doing?
Being in the Zeitgeist, watching YouTube videos, reading forums, these all create awareness for non-tech-savvy individuals but not for those that don’t research these things.
If you look at the community plugins notice. It doesn’t say that “only things directly accessible from this search box” are community plugins. And in the user flow of installing either type of plugin for the first time (community or URL), you’re still required to turn off restricted mode and read about community plugin safeguards.
To give a slightly related example… I regularly tell friends about the plugins I make and the next thing I usually have to explain is “What is a plugin”…
So when someone in the “community” says to get this functionality you install this URL using the BRAT community plugin". How does a layman know what’s risky and what’s riskier?
(Deleted my previous post cause I felt I could describe it more succinctly)