How to prevent text transclusion based on filter value?

[Brock_Dyer]

I would like to prevent the transclusion of tiddler text based on the evaluation of a filter.

Example

Let’s say I have a tiddler called No Transclusion with the field prevent-transclusion. I would like {{No Transclusion}}and equivalent transclusions to produce empty text.

Motivation

I am trying to develop a system where information is available to specific users in the wiki but not to others. I may have a tiddler that I want User A and User B to see the content of, but User C should not be able to. And perhaps a tiddler that only a specific user can see, ex Tiddler A, Tiddler B, and Tiddler C for the respective users.

This would not need to be a super secure system, I would just like it to be fairly difficult (non-obvious) to access the obscured information for anyone proficient with basic editing of tiddlers / tiddlywiki.

Attempts, Problems, and Ideas

I have figured out how to hide the body of and prevent editing these tiddlers based on a filter condition (thank you cascades). The problem I now have is that both can be bypassed easily by transcluding the tiddler into another.

I could (probably) disable editing on the wiki for my users (and make sure that I don’t transclude anything I don’t want shown). This would certainly solve the problem, but I’d like to avoid that so my friends who may work on similar wiki projects can learn from mine.

I am open to alternative approaches if there is a better way to accomplish the functionality that I want. I’d prefer solutions that don’t involve modifying the core/shadow functionality, but I am okay doing so if needed.

System Details

OS: macOS Monterey
Browser: Chrome
Tiddlywiki: v5.2.2
I am running Tiddlywiki using Node.js locally on my machine and hosting a build for my users on GitHub via GitHub pages.

Any tips or suggestions are greatly appreciated!

[Charlie_Veniot]

G’day,

Something like this will do the trick:

Oops, forgot to test that with a transclusion. Just a minute …

Poop. That does not prevent transclusion at all. Apologies !

[Charlie_Veniot]

Hide the TiddlyWiki interface and present your own custom interface that displays/provides only what is allowed for a particular user.

The reason to hide the native TiddlyWiki interface: prevent user access to “blocked” tiddlers via search, “recents”, or any other way of getting to those tiddlers.

Setup all transclusions as {{ some_tiddler || tSecure }}.

The tiddler tSecure has the security-related goodies that decide what to display: full-guacamole, partial-guacamole, no-guacamole-for-you.

By custom interface, something like what I’ve done for BASIC Anywhere Machine, but no button to bring back the TiddlyWiki interface except for certain people.

[TW_Tones]

Welcome Brock;

A solution you want may be influenced by the number of transclusions you want to hide, is it a few?

There are a number of security by obscurity methods, but how do they discover the name of the tiddler to transclude it against your will?

• Have you used a system tiddler to keep them out of the search?
• You could have them in a plugin so it is a shadow tiddler as well.
• Perhaps you could add a cascade to stop editing on these select tiddlers so they cant see the tiddler you want to transclude?
• There is also a alternative character sets, including an invisible one, available in UNICIODE so unless they search using this alternative name they may not see it.
• There are parsing rules, such as transcludeinline transcludeblock poorly documented here
  • I think if you use \rules except transcludeinline transcludeblock, just as you would \define macro() a the top of a tiddler, transcluding can not occur.

The problem with security by obscurity is there are so many different levels of obscurity it is hard to know how deep you want to go.

[Charlie_Veniot]

Hey Brock, have you considered multiple TiddlyWiki instances?

TiddlyWiki instances in a hierarchy.

Any TiddlyWiki instance includes TiddlyWiki instances with lower confidentiality.

So say two TiddlyWiki’s A and B, and two security groups a and b.

TiddlyWiki B includes the tiddlers from TiddlyWiki A. Group a has access to TiddlyWiki A. Group b has access to TiddlyWiki B, which happens to include the tiddlers from TiddlyWiki A.

I’m referring to includeWikis in https://tiddlywiki.com/#tiddlywiki.info%20Files

[clsturgeon]

@Brock_Dyer

I am trying to develop a system where information is available to specific users

I have implemented a few TWs for help files. In one case I wanted one TW to be used for two types of users: standard users and technicians. Standard user sees typical help while technicians see detailed implementation details. If an entire Tiddler is for a technician I tag it as technician—hiding these tiddlers from standard users. Otherwise I simply use standard CSS to hide technician content for standard users.

[Brock_Dyer]

@Charlie_Veniot

@Charlie_Veniot

have you considered multiple TiddlyWiki instances?

I have not, but I don’t think it will be feasible for my use case. There are too many possible groups to maintain multiple wiki instances for each group.

I have 7 or 8 potential users. There is the access group for each user, but then there is an access group for User 1 and User 2 only. An access group for User 2 and 3 only, etc… Then we have groups of 3 users, 4 users, etc…

I may not need all of those groups, but they exist in theory. I appreciate the suggestion though!

@Charlie_Veniot

Hide the TiddlyWiki interface and present your own custom interface that displays/provides only what is allowed for a particular user.

I think that that could work. It feels like a large lift for a small feature in my wiki. The biggest issue with this approach that I foresee comes with the {{some_tiddler || tSecure }}. I would have to enforce that that is the only way to transclude something, i.e. that {{Normal Transclusion}} fails or is unavailable. I have the tools to make sure I don’t accidentally transclude the hidden information (my wiki does not rely on much direct transclusion and I can use my filter to handle all programatic transclusion). I would need to prevent a user/viewer from performing the transclusion, and I think that I would need to disable things in the parser to do this (something I am slightly reluctant to do).

@TW_Tones
Thank you for the suggestions!

@TW_Tones

A solution you want may be influenced by the number of transclusions you want to hide, is it a few?

I do not know ahead of time how many transclusions it will be.

@TW_Tones

but how do they discover the name of the tiddler to transclude it against your will?

That is an interesting idea. I could take steps to hide the tiddler title from being found. The tiddlers I want to hide are currently just normal tiddlers as that is what has been easiest for me to create. If I’m unable to stop the actual problem, this may be a good enough solution.

@TW_Tones

I think if you use \rules except transcludeinline transcludeblock, just as you would \define macro() a the top of a tiddler, transcluding can not occur.

I have thought about modifying these to achieve what I want. After giving it some thought, I realize that this would probably do what I want. But there is another problem that arises.

<$set name="noTransclusion" filter="[[Secret Tiddler]get[text]]"> <<noTransclusion>></$set>.

Like you mentioned:

@TW_Tones

The problem with security by obscurity is there are so many different levels of obscurity it is hard to know how deep you want to go.

I am not sure how deep I want to go . I suspect that my users won’t go to such lengths to uncover the hidden information, so I don’t think going down the transclusion prevention path is worth the trouble (especially when I go to update to newer wiki versions and have to handle all the shadows I would have to create).

Long response to say, thank you for helping me think through the problem. I think it is a bigger one than I originally thought (at least to guarantee the information is not seen). So I may be best trying to prevent users from finding the titles of the hidden tiddlers. And I can always ask them not to do such things - it would simply be spoilers for them so it may not be a hard ask.

[Charlie_Veniot]

@Brock_Dyer

I have not, but I don’t think it will be feasible for my use case. There are too many possible groups to maintain multiple wiki instances for each group.

I have 7 or 8 potential users. There is the access group for each user, but then there is an access group for User 1 and User 2 only. An access group for User 2 and 3 only, etc… Then we have groups of 3 users, 4 users, etc…

A-1, but I can’t part on this discussion without a serious recommendation that, since you have a node.js setup already, that you at least look into it.

I’m doing work for a client and getting decently compensated regarding research of a “TiddlyWiki Farm” on a node.js server. And the results so far, and the potential, are really fantastic.

The “farm” is architected such that things are well componentized so that we have true security (not just obfuscation, but people truly can only see what they ought to see) while maintaining control of architecturally important (+ GUI standard, + standard behaviour) tiddlers/etc.

The work/steps involved are in the same ballpark as anything that would be done otherwise for so-so-obfuscation. Except that this approach is the full monty of fine-grained access.

(Better if I had the chops to set everything up under https versus http, but that doesn’t matter much while prototyping. I’m no server-setup/admin guy, so basic nodejs and web server setup.)

Other research, to get around multi-user TiddlyWiki which does not satisfy this kid: sole-authorship tiddlers (i.e. nobody but the creator of a tiddler can edit it; well, admin/system folk can); collaboration is done by somebody authoring a new tiddler that is linked to tiddlers authored by other folk.

Now people with lower credentials adding content to those TiddlyWiki instances, those tiddlers get included in the higher credential TiddlyWiki instances no problem. What we have to resolve is process to deal with Tiddlers created in higher credential TiddlyWiki instances that ought to have been created in the lower credential TiddlyWiki instances. Although this will involve some kind of training and knowledge on users’ parts to know what ought to go in what TiddlyWiki, that can easily be supported (and/or regular curating done) with notifications/reports of tiddlers existing in TiddlyWiki instances that might be better suited in other TiddlyWiki instances.

• The ability to identify content that ought to belong in some other TiddlyWiki can be helped with this other research I’m doing: a forms-based approach to entering content, so getting away from the TiddlyWiki interface and developing a user interface much more similar to what you would find in multi-window software.

Management of these TiddlyWiki instances made easier by this other bit of research I’m doing: setting up TiddlyWiki instances as server-like appliances to other TiddlyWiki instances. Although most of my efforts with server-like appliance has been to make it seamlessly appear like tiddlers from some other TiddlyWiki instance actually exist in the one being looked at.

Anyway, if you or somebody in your team has decent experience in Systems Analysis and Design, good with componentization of things, and good with things like relational algebra, database design and SQL, and have experience designing/maintaining forms-based applications, etc. … all of the stuff I mention above is really woth exploring, even if it just becomes knowledge and practices to apply on whatever else you come up with.

Don’t mind me, I just feel a little overly emotional because I think you’re missing out on something that’s really good.

Best wishes with your efforts.