The Future of Obsidian Plugins
Obsidian has launched a new community site and automated review system for its thousands of third‑party plugins, using linting, dependency checks and scorecards to scale beyond manual review by a seven‑person team. Users and developers welcome better visibility into network access, disclosures and security health, but many argue that without true sandboxing and enforceable permissions, plugins still effectively have full system access and remain a major attack surface. The thread also surfaces broader concerns about proprietary lock‑in, collaboration features, and how far automated scanning—without AI in the loop—can realistically go in preventing supply‑chain style malware.
Plugin security model & risks
- Many are uneasy that Obsidian plugins currently run with full filesystem and network access, with no sandboxing; this is confirmed in the docs.
- Even without network access, full file access allows destructive or indirect attacks (e.g., modifying crontab or shell rc files).
- Some worry the new system doesn’t change this core “click here for RCE” model yet, so structural risk remains.
Automated scanning, AI, and review
- New community site and automated review are widely seen as a major scaling improvement; manual review had become a bottleneck.
- Automated checks use a custom eslint plugin plus dependency/malware scanning; every release is scanned, and rescans are planned as rules improve.
- Some see AI as a promising additional layer for catching malicious or user-hostile behavior; others argue AI is too fuzzy and non-reproducible for a security boundary.
- There is concern that a public linter/ruleset can be used by attackers to iteratively bypass checks, so hidden/extra checks are suggested.
Permissions, sandboxing, and desired controls
- Strong sentiment that a proper sandbox and explicit permissions (filesystem scope, network, external binaries) are the “real” fix.
- Obsidian’s new “disclosures” are described as a first step toward permissions, but currently rely partly on self-report and do not yet enforce sandboxing.
- Several note that permissions alone can’t prevent abuse of allowed capabilities (e.g., generic “network” permission used for exfiltration).
Ecosystem, developer experience, and plugin availability
- Developers welcome an easier submission pipeline and tooling (eslint rules, scorecards); some quickly improved their scores.
- Concerns exist about false positives/negatives, CVE noise, and user confusion over scorecards; filters by “strictness” are requested and apparently planned.
- Some fear good plugins could be delisted too aggressively (e.g., on a bad update) instead of defaulting back to the last safe version.
Trust, openness, and lock‑in
- A sizable group wants Obsidian itself to be open source for long-term trust, workflow stability, and verifiability.
- Others argue that plain Markdown storage and a stable, offline-capable client keep lock‑in relatively low, though plugin-specific formats remain sticky.
- Debate continues over whether a “trusted vendor” proprietary model is acceptable versus insisting on FOSS.
Collaboration, UX, and misc
- Several users struggle to replace Notion for team use; Obsidian is seen as strong for personal/agent workflows but weaker on permissions and onboarding for non-technical teammates.
- Some recommend real-time collaboration plugins (e.g., Relay, Peerdraft) and self-hosted sync tools.
- Dark-mode-only web content is criticized for accessibility (astigmatism, halation); light mode for the site is said to be planned.
- Multiple users list favorite plugins and advise adding them slowly, one by one, to keep complexity and risk manageable.