[security] Collaborating on a tiddlywiki securely

[neumark]

Hi All!

Throughout development of tw5-firebase, the questions of finding the right balance between security and "hackability" keeps resurfacing.

The ability to create custom macros, JS libraries and plugins is what really sets TiddlyWiki apart from other wikis in my opinion. That said, allowing your collaborators to run their JS code in your browser (with access to your authentication tokens in the case of tw5-firebase) could easily lead to a security nightmare.

I'm wondering if there's an existing security model for where to draw the line? tw5-firebase loosely follows the original TiddlyWeb model of bags and roles. Only users with an admin role can write bags which may contain javascript tiddlers. While this may be an acceptable solution, I find it both too restrictive (no one can install a wiki-wide plugin), and too lax (any admin user can add malignant code to the wiki which deletes the tiddlers of any visiting user).

@inmysocks, @Jermolene or anyone else who's given this thought: how could I improve the current model?

Thanks,
Peter

[inmysocks]

For Bob and its server the wikis are separate and there are fine-grained access controls and access tokens have a limited time to live.
It is far from perfect, but it doesn't have many of the problems you mention.

The wikis being separate means that anything you do in one wiki has no effect on other wikis, and while accounts can have permissions to change things on the server and insert plugins into every wiki, the fine grained controls means that ability can be restricted to just one admin account. If you can't trust the person running the server then using it is probably not a good idea anyway.

This doesn't prevent someone from somehow getting malicious code into a wiki that steals the access token and then the attacker has access for the duration of the tokens life. This isn't prefect because someone could have their own wiki on the server that has malicious code then if someone who is logged in visits that wiki they could have their token stolen. The simplest way to avoid that is to encode the IP address of the computer the token was requested from and reject any requests that use the token from another ip. I haven't implemented this in Bob yet, but it is on the list.
I don't know if you have that sort of control with firebase.

The solution that Bob is going to use eventually is federated wikis, where each person runs their wiki locally and selectively syncs with other wikis, the same way that twederation works.
You can review anything that you get from other wikis before it is included in your local wiki.
At that point the risk is going to be social engineering, which is the same as everywhere else on the internet.

I don't really approve of the security model used by firebase and similar services so I haven't given it much thought past that.

[neumark]

Hey @inmysocks!

Thank you for your response! I like the idea of fine-grained access control, and probably thought of something similar to what's in BOB. It's precisely this malicious code in the wiki issue you mention that I'm concerned with.

I guess I'm trying to figure out if there's a way to somehow scope the access a particular plugin is granted to the rest of the wiki (and the javascript execution environment). I know TW5 does something like this under node, and it's possible to achieve something similar using iframes in the browser, but there's no concept of "scope" in tiddlywiki plugins at the moment.

I didn't really understand what you mean by the security model used by firebase. Could you elaborate a bit on what specifically you dislike about it?

Thanks,
Peter