Feature request: Encrypted _cononical_uri content

Developers
#1

I had a thought about the use of the SJCL and a different use case.

The setup: Say I have a directory of multi media files and I want to provide a nice index page I might use a TiddlyWiki where each entry was a tiddler with its _cononical_uri set. This way it seems like one wiki but the bulk of the data is still separate files. It means they can be deep linked if I wish and the index wiki loads quickly (less to download up front).

But it would be amazing if I could encrypt these files using SJCL and then also set the same password for the index wiki. When the wiki loads the content it can use the already entered password to decrypt the content in the client on the fly.

Is this even possible? And if so are there any tip on where to start looking for hook points (where the SJCL actually does the decryption/encryption, etc.). And can SJCL be used in Node to encrypt on the command line before uploading to a web server?

Is this even a good idea or not?

1 Like
#2

Hi @sukima wouldn’t we need to fetch the bytes of the remote media file to the browser in order to decrypt it?

#3

Your description reads like, that you want better access control and not encryption. IMO it’s the wrong tool for the task at hand.

If you encrypt the media on the server, for every PW and or user you need a duplicated file. I think that doesn’t make much sense.

TiddlyWeb did have a concept to manage access control on a per user basis. It’s called “bags”. The concept is still part of the syncer, but not used at the moment.

There where “recipes”, which contained the recipe how to build a wiki out of different “bags”.
Bags had the information, which user can access the data.

So reading your post I think that’s the way to go. The info about TWeb is still online http://tiddlyweb.com/ … recipe in tiddlyweb

#4

Yeah, For now _canonical_uri is just plopped into a src= attribute so in order to utilize the SJCL we would have to fetch() each request, decrypt and then src="data:" it. Bleck sounds like more hassle then it would be worth.

#5

I think you might have missed what I was trying to convey. I’m kinda not sure where “every PW” and “every user” came into play.

I was conveying the idea that if instead of a tiddler with a PNG as its text in a password protected wiki (single page HTML file) that the PNG could be stored on the server along side the wiki as a binary blob. Then the stand alone wiki on load would fetch the binary blob and decrypt it with the same (stored) password used to decrypt the original wiki.

But because TW doesn’t fetch _canonical_uri but relies on the browser to do so the only feasible way to accomplish this would be to investigate a Service Worker. Hmmm that sounds like a fun weekend project. Cheers.

1 Like