#48

@zephraph…Can you explain briefly (if that’s possible) whether or not what you’ve written about plugin ‘security issues’ applies equally to someone only using plugins with the Obsidian iPadOS app with Obsidian Sync and NOT Obsidian on a Mac. By that I mean, it is my limited understanding that the iPad App is Sandboxed within the iPadOS ecosystem so that plugins I use with Obsidian Mobile can NOT gain access to anything outside the app unlike on MacOS where the Obsidian app version uses Electron, etc., etc!

1 Like
#49

I’m not an expert on iOS security, but as I understand it having 3rd party plugin code running within obsidian wouldn’t impact the security of a device any more than installing a random app from the app store. There are technically caveats to that statement. One might suggest that the app store review process is in part designed to catch malicious activity, but given that there are high profile scam apps that are left up I highly doubt the process is thorough enough to vet all that deeply.

It’s certainly different that the app running on a desktop though. iOS has built in security sandboxing on a per app basis. Apps can’t arbitrarily access information on the device without explicit granted permissions. If, however, you grant obsidian access to say… view and edit your photos, then it’s technically possible that a plugin running inside of obsidian could also access your photos. So long as the obsidian app limits its overall permission requests then it should be relatively safe.

The risk is smaller, but it’s not without risk.

#50

Thanks. In this instance IMHO, Smaller IS better!

#51

I’m not an expert, but it seems to me that we could approach this question from a different angle:

What would be some ways to run Obsidian with third-party plugins in a relatively secure manner (when using sensitive data, for example)? The most obvious approach for the desktop, it seems to me, would be to use a firewall to disable Obsidian’s internet access whenever one is using third-party plugins. (For a firewall on Windows, I use Netlimiter.) If one is using Obsidian Sync, one could periodically turn ‘safe mode’ back on and enable Obsidian’s internet access to allow syncing. To install or update plugins, one would need to turn off each third-part plugin and then enable Obsidian’s internet access.

This approach wouldn’t stop malicious code that somehow installs itself outside of Obsidian (if such a thing is possible), but it should prevent third-party plugins from directly accessing the internet.

(On mobile, one could turn off WiFi and Bluetooth, and disable Obsidian’s permission to use cellular data, while one has third-party plugins enabled.)

Does the above make sense? It’s a bit cumbersome, but it seems to me that it could be worthwhile in some cases.

3 Likes
#52

@lucasd : good suggestion. On my Mac laptop I use Lulu (it is free) which alerts me whenever an app tries to go online without my authorization.

1 Like
#53

Basically on desktop you can use per-app or IP tables firewalls, and on mobile you can use mobile firewalls or just switch off Internet access to Obsidian.

Some suggestions:

  • Windows: TinyFirewall
  • Mac: Lulu
  • Linux: OpenSnitch (+ GUI)
  • Android: NetGuard (supports IP tables as well)
  • iOS: [no idea]
Making Obsidian's network & sync components source-available
#54

I’ve been a mac user for 25 years. During this time the OS system grew from a few MB to GB. Meantime having huge problems keeping my system clean. Even as a heavy user, i still have very little to no knowledge of developing and programming. I completely reinstall my system every one to two years. To get rid of all the junk that accumulates in the system, especially in the library folder.

I installed Lulu once. Without even having the faintest idea what most of the processes and internet connections are necessary for that were shown to me in this program - so i uninstalled it.

What I want to say, users and programmers view this subject from two absolutely different worlds. I am absolutely unable to verify the security of Obsidian plugins. If obsidian developers want to make sure users will install plugins, there must be another way (from my point of view).

2 Likes
#55

@PietArt: I doubt the Obsidian devs want people to install plug-ins, why should they? Their focus is purely Obsidian, and in order to stay focused like that they (husband + wife) have stated clearly they do not have the time to check and keep tabs on plug-ins.

If you look at the plug-in list there are huge numbers of downloads so they are already popular with many.

At the end of the day you will have to take a gamble: do I trust this plug-in dev or not.

#56

Maybe, for one, so they don’t have to deal with every feature request that is submitted in this forum. Kind’da allows for a narrowing of focus, so to speak.

Besides, in an earlier post in this thread @Licat said-
“ Sandboxing code is certainly doable technically, but it would either cripple the entire plugin API, or it would be trivial to bypass the sandbox. Proper sandboxing basically means removing almost everything from the API (access to the DOM elements, most node.js and electron APIs), which means pretty much 90%+ of current plugins would just plain be impossible.”

#57

They don’t have to deal with every FR, the mods do that.

#58

So…….the Mods determine what’s ‘worthy’?

#59

No, I’m not sure what Klaas is referring to. You are certainly right that the plugin API has allowed the community to build out tons of features that would have been impossible for the developers to handle by themselves.

#60

@Daveb08: if I am not mistaken the FRs go through an initial filtering by the mods, notably WhiteNoise. FRs maybe unachievable/unrealistic, or perhaps have already been submitted, or being worked on, ……

That in and of itself relieves the devs of a lot of work, although they ultimately decide what is “worthy”, as you call it.

#61

What I’m suggesting is that the Devs DO want to encourage the creation of Plugins precisely because the Plugin creator scratches an itch that the Devs don’t have to ‘worry’ about. And other folks may have the same ‘itch’, so they’re happy too. This leaves the Devs to Focus on new goodies, e.g., WYSIWYG. All of this I have no issue with except the concern that I have (including the OP?) regarding the Security of the Plugins. Maybe it would be helpful if someone (Mods?) could point us to the specific process in place (maybe outlined in the Help Vault) for reviewing Plugins before they are allowed into the Community Plugins.

2 Likes
#62

@Daveb08 OK, I agree with what you are saying.

#63

The process, as I understand it, is that Licat checks through the code of each plugin before approving it as a Community plugin. Updates are not specifically checked.

#64

First, feature requests are prioritized in a very very fuzzy process. Popularity is important (as shown by demonstrated interest by users here on the forum). So is ease of implementation. So are a dozen or so other factors. The devs look at the forum, and so do us mods, in order to find interesting and valuable FRs. It is not a methodological process. Now, please keep on topic.

In terms of security reviewing: if you handle sensitive data in Obsidian and you do not have the skillset to review what a plugin is doing, consider either hiring someone to audit the code for you or not using the plugin.

As has already been discussed, it is impossible to offer a security guarantee on just one plugin, let alone at scale. More than a plugin a day has been published since Obsidian’s API was launched. Many of those plugins have been updated dozens of times. Reviewing each of those plugins and updates takes hours. The initial review is a quality review. It does not mean the plugin has been guaranteed to be safe and secure. It’s a cursory analysis to check for anything obvious, and to provide feedback to the plugin developers about how they might improve the plugin design/engineering.

Let me restate: it is impossible to offer a security guarantee on plugins. Please please stop beating this poor horse. What we have instead is a social system in which other users and developers are highly likely to notice and report nefarious behavior. But, if you are dealing with sensitive data, it is best to audit the code of plugins you’re using yourself, hire someone to audit for you, or not to use third-party plugins.

I encourage future contributions to this thread to advance the conversation beyond this focus. E.g., by…

  • suggesting ways of checking plugin security on the user side; or
  • suggesting and discussing models of resourcing so that a more robust reviewing mechanism could be offered.
4 Likes
#65

(1) (I added the numeral to the Quote) That gives me comfort.
(2) THAT, brings back to square one. Concern for ‘Security’.

#66

Thank you for your expansive explanation of the plugin ‘review’ process. It is most helpful. On the other hand, your statement……”please stop beating a dead horse”…is troublesome to me. I love the app, I appreciate ALL that the Devs do to provide me with a game changing app/workflow. Likewise, my hats off to the Mods for all they do. I personally don’t know of any other site/forum/app with this kind of participation or value. My purpose in posting is simply to gain whatever insight I can from people who certainly know more than I do. It is not my intention to be negative!

3 Likes
#67

Oh….and one more thing :wink:……is there some way to post your reply in a section of the Help Vault designed to explain Security. Hope this is not another example of me beating a dead horse.

1 Like