search

elk-zone / elk

A nimble Mastodon web client
https://elk.zone
MIT License
5.49k stars 565 forks source link

Plugin System #33

Open sxzz opened 1 year ago

sxzz commented 1 year ago

Support third-party plugins for more features and possibilities.

patak-dev commented 1 year ago

Do you mean that people would publish elk-plugin-xxx to support for example formatting of Latex and then someone could deploy elk themselves using it? Or do you mean something more dynamic that users could select on https://elk.zone itself like a VS Code extension?

sxzz commented 1 year ago

Yeah, it's the latter. We could download the npm package and store it. Deploying is no required.

JonasKruckenberg commented 1 year ago

I just want to throw in a word of caution here after being on a 2yrs long research endeavour into extensible software now: The solution proposed by this (and the one starting to be implemented in #913) is a security nightmare. It's the best we can do within JS at this point-in-time (in lieu of shadow realms) but to me that is not really enough. What this proposed system comes down to is basically XSS-as-a-feature, and while this might work in a developer-tool setting (this is the de-facto standard used by Vite and all other JS tools after all) it's not really something I personally would be comfortable with in a web setting.

We must also keep in mind that the average Mastodon user might be a bit more technical than my grandma, but by no means is guaranteed to be a technical person that understands the consequences and possible ramifications of running basically untrusted code in their social media client. They also might not have the technical know-how to vet code coming from npm for validity.

A good (albeit somewhat outdated) read is this post by the sigma team https://www.figma.com/blog/how-we-built-the-figma-plugin-system/

patak-dev commented 1 year ago

Thanks a lot for this comment @JonasKruckenberg, we aren't going to move forward with this feature until we're sure we got the security story right 👍🏼

JonasKruckenberg commented 1 year ago

Thanks a lot for this comment @JonasKruckenberg, we aren't going to move forward with this feature until we're sure we got the security story right 👍🏼

Great to hear, I'm sorry I don't have a great solution right now either :/ but I could give it some thought!

I'm currently working on secure runtime extensions for Tauri apps using WASM, and while not directly applicable to a web environment (the Tauri host uses the wasmtime runtime instead of the browser) there might be some interesting prior-work there 🤔 Edit: Of course untrusted wasm in the browser has a whole suite of other security implications, so there fundamentally is not really perfect solution here

tom-sherman commented 1 year ago

Figma have published how they built their secure plugin system: https://www.figma.com/blog/how-we-built-the-figma-plugin-system/

IMO this is a nightmare can of worms not only from a security perspective but also from maintenance perspective. After working on many projects with plugin systems, I can say that the plugin system always slowed down development and introduced a ream of bugs that usually took a whole team to monitor.

I wonder if adding a plugin system now is actually doing it too early, there doesn't seem to be a real use case here apart from "plugins would be cool" and it's not clear to me why other options do not meet the requirement. Some solutions that I have seen work much better than plugins are:

boehs commented 1 year ago

913 was closed by it's author, and I'm closing this issue given the above discussion

patak-dev commented 1 year ago

We're still discusing here, lets keep it open

ayoayco commented 1 year ago

Hi all!

Not a security expert and honestly don't understand what are the risks if the plugin only affects elk on the user's browser? As I see the nightmares are because their plugins run for whole teams, whereas Elk will always be an isolated software for the user who will be responsible for vetting existing plugins or creating his own. In this sense they always opt-in to the plugin themselves.

I'm thinking we can offer some level of security by requiring that the plugin is open source and available for security scans?

AlexErrant commented 1 year ago

Twitter XSS attacks have hit the news before:

Just because it's only on the user's browser doesn't mean Bad Things can't happen. Unfortunately being open source isn't enough, see Heartbleed, and scanning isn't 100% (if it was, Chrome extensions wouldn't have the rep they do.)

It is relatively simple to sandbox plugin Javascript to an iframe or webworker and communicate with it via postmessage/Comlink. (Relevant.) (You could also require plugins to be written in Rust/wasm and use that to sandbox, hah.)

The problem is most plugins will want some kind of DOM access, and that's the dangerous bit. Iframes, as suggested by the Figma article, seem like the only way forwards. I'm unaware of any other tech that allows for securely displaying 3rd party content on your page. (That's why advertisements (with multimedia) virtually always use iframes. Some tried to develop a "safe" subset of Javascript, e.g. ADsafe, but it's been dead for a while.)

Modal iframes seem like the best MVP solution. (Inline iframes have a resizing problem. There's https://www.npmjs.com/package/iframe-resizer but you probably don't want it for MVP.)

But really, do ya'll need this feature? :)