Obsidian plugin was abused to deploy a remote access trojan

The first trade-off is not precisely stated, you can do "both" with user choice. In this case it would be: no plugin has "all filesystem access" unless user explicitly approves it, and that approval steers the user to a very narrow "plugin folder only" path by the way UI is done. Think this is "secure by default"? You don't undermine any ability here because most plugins don't need any filesystem access, so you get extra security "for free" for most of the users and with only some friction (but still not removing the ability altogether) for the rest.

I have to agree. You can keep pulling that logic back another step (and that seems to have been happening for many steps now) to the point that you no longer have the ability to use the computer.

This can't be dismissed as "slippery slope" logic either. Should elderly people with a bank account be allowed to use a computer? They might read something online and give their savings to a scammer. Frankly, that's a far more convincing argument than the one given here. There's only one solution if your objective function is exclusively to minimize the possibility of a security incident.

Because a box is an intuitive way to limit the blast radius of arbitrary code? But the wasn't a requirement, I'd be fine with sandbox-free secure plugin systems

> multiple safety warnings in Obsidian

Idk, I've always thought it was odd that the "community plugins" settings pane seemed more concerned with assuring the user that community plugins were fine than actually explaining the risk.

There is literally a single sentence about the fact that plugins "may cause data integrity and security issues", and it is hedged with the mealy-mouthed modifier "like any other software you install". The absolute majority of it - maybe 80% of the text by window height - is about the measures Obsidian does to vet and secure plugins. All of it appears to be written with the intent to placate any concerns.

Is this the safety warning? The screen that says that community plugins could cause issues "like any other software", but they're actually super safe and vetted and totally fine? Is it surprising that a person, faced with a screen like this, would be susceptible to a social engineering attack?

There are many essential features missing that should be included in the core app for security, compatibility, longevity and for the benefit of new users who prefer to stay clear of plugins.

1) Basic functional search

Search should handle different order of words, misspellings (fuzziness), offer indexing and searching in a larger scope than just titles and aliases (e.g. headers or content), as well as allowing users to customize search priorities. Basically - just include Omnisearch as a core plugin.

2) Basic image preview

Displaying an image on full screen, with panning and zoom, when clicked upon.

3) Full "folder notes" support

Out-of-the-box support for a vault structure where each note has its own dedicated folder where all its attachments are placed. While the basic functionality is present, an external plugin is required to declutter the vault file hierarchy and actually make this approach feasible. Folder notes approach is in my opinion the only way to keep a large vault organized.

4) Basic formatting.

Text coloring. Text alignment and justification. Basic image positioning. Proper text flow wrapping around images. Table formatting (at least a setting minimum column width).

5) Markdown parsing within HTML tags

Basics Markdown features like [[linking]] don't work within a section of text enclosed by HTML tags. And using HTML/CSS is currently required to achieve basic formatting like centered or colored text.

6) Option to use the first h1 tag as the note title

I'm talking about actual support for this and integration with core functionality like search and linking. Useful (sometimes long) titles are an essential part of note-taking and knowledge databases. Meanwhile, filenames are simply semi-unique file system identifiers. Forcing users to use filenames as titles compromises the usefulness of titles and leads to issues with filename / filepath length. In HTML and Markdown, the h1 tag was always intended for the title.

7) Consistent formatting between reading view and editing view

Rendering of content, especially vertical spacing between elements differs between those views for no credible reason. The code syntax highlighter is also deficient in editing mode, despite it being the mode in which Obsidian users spend 99% of their time while writing, editing and reviewing notes.

It's not an exhaustive list, but these are the biggest pain points right now. And let me repeat - you shouldn't continue to rely on community plugins for these features. Even though community plugins are great, they are a security concern, their development could cease at any point, and new users don't know about them.