Hi JWHoneycutt,

I needed to modify your original text, and added some numbers, so it's 
easier for me to reply.

Sorry for the wall of text, that follows. As I wrote the Conclusion, I 
thought I'd start with it, because it's much shorter than the reply's :)

On Sunday, October 16, 2016 at 7:04:43 AM UTC+2, JWHoneycutt wrote:
>
>     1) I want complete control over my wiki.
>     2) I want to make it accessible on the web, and not with a link to my 
> Dropbox, or in a way that has my name all over it.
>     3) I want it securely encrypted.
>     4) I want to know who is logging in to access it, so that I can verify 
> their identity. (Facebook login confirmation?)
>     5) I want to be able to control what portions of the wiki are 
> available, and individually expand what is available over time.
>     6) I need to restrict/eliminate the viewer's ability to edit a tiddler.
>     7) I need the viewer to be able to provide comments/suggestions for me 
> be able to incorporate into the wiki.
>     8) I need to create a separate wiki for each different viewer, if they 
> chose to enter personal information into it.
>
>     9) This is all about medical records - so the controls have HIPAA and 
> legal requirements.
>

*Conclusion: (also see second post)*

Your sentence from the OP (original post) here: 

>There's a whole bunch of stuff there: Gitignores, Readmes, Dockers, Gems, 
and even "instructions" with racing graphics.

shows me, that you did read and think quite a lot about your problems. The 
solutions should be easy, but they aren't and that may be frustrating. 
(just a guess :)


IMO if you treat your point 9), the HIPAA requiremtns, real, it makes 
everything complicated. So my proposal is: 

 - Use TiddlyWiki and 
 - Use encrypted e-mails.          ... That's not a joke. 
 

The following reasoning will show, you why "the cloud" may be the wrong 
thing here. 

Or jump to the second post, why I'd go with plain old email :)


== reasoning ===========================


You are touching 9 points, which are a valid desire and seem to be simple. 
But they are very very challenging because of (but not only) point 9 
"medical records" aka "sensitive personal data". For me it also seems, that 
you mix up several things. ... I'll try to explain some contexts, that I 
think are important, to understand, what you actually request here. 

add 1) I want complete control over my wiki.

That's exactly, what TiddlyWiki is intended to be used for. TiddlyWiki.html 
is a single file, that lives on your local harddisk and therefore you have 
"complete control". If your haddisk is transparently encrypted by your 
operating system, no extra steps are needed. Not even the built in 
encryption. .. The weak spot here probably is your log in password ;)


add 2) I want to make it accessible on the web, and not with a link to my 
Dropbox, or in a way that has my name all over it.

If you want to keep 1) "complete control" in tact, you need your own server 
in your own location. Because that's the only way to have "complete 
control". period. 

If you don't want to have your own server, you ''have to'' trade "control" 
for "convenience".

IMO because of 9) private data, a free hosting service is ''No'' option 
here, since: 

* There are many "free hosting" companies out there, that let you trade 
"convenience" for "tacking-data" and "control". They are _NOT_ free. You 
pay them with your data and the allowance to spam you with adverts. period.
* So you need a paid service that you can trust. Processional hosting 
services trade money for "convenience". They provide hosting solutions that 
give you "full control". They just run the hardware for you! Important: 
know the "terms of service"!!!

The problem here is, that you still need to deal with "Authentication" 
https://en.wikipedia.org/wiki/Authentication and "Authorisation" 
https://en.wikipedia.org/wiki/Authorization, which isn't simple at all if 
done right. That's why we tend to trade "convenience" with "control" and 
"tracking-data" and let 3rd parties do that for us. eg: log in via: 
twitter, facebook, google, .. (but: there is NO free lunch!)


add 3) I want it securely encrypted.

TiddlyWiki has a built in mechanism, that let's you encrypt the whole 
content. All tiddlers. The encryption process runs locally in your browser. 
The library and the mechanism, that is used to encrypt the stuff is 
considered to be safe at the moment in time. 

see: http://tiddlywiki.com/#Encryption,
and: http://tiddlywiki.com/#Stanford%20JavaScript%20Crypto%20Library

The important point here, is the password that you use. If it's weak and 
guessable, the whole mechanism is also weak. I found a nice article about 
strong passwords: 
http://www.howtogeek.com/195430/how-to-create-a-strong-password-and-remember-it/

I think this topic is important, since not only you have to remember your 
passwords. Your clients will have to remember them too!! Also see your 
point 5) "expand access over time" ... 
So to make your workflow acceptable for your users, you may be forced to 
trade "security" for their "convenience". Which imo is bad thing!


add 4)I want to know who is logging in to access it, so that I can verify 
their identity. (Facebook login confirmation?)

Guess what: (Facebook, Google, Twitter, ...) will track all your users, 
whenever they access your content, if you let them do the authentication 
for you. Do you really want that? Here you trade "your users privacy" for 
"your convenience". For me that's an ethical problem, if you deal with 
"sensitive private data"! ... A little thought experiment: "Which illnes do 
you think I have, when I frequently access a website about flue medicine"?

If you really want to implement a tracking mechanism into your SW, I 
personally wouldn't want to be your client. There needs to be a better way, 
to get the information, that you need. Just ask me, and I'll send you a 
mail!



add 5) I want to be able to control what portions of the wiki are 
available, and individually expand what is available over time.

There is a plugin, that lets you selectively encrypt / decrypt portions of 
your TW. .. The downside here is: password management. ... You know, they 
need to be strong: 12 unguessable characters minimum and your clients have 
to remember them ;)


add 6) I need to restrict/eliminate the viewer's ability to edit a tiddler.

IMO that's just a theme, that somebody has to create. There are several 
hacks posted here in the forum. So that should be straight forward, but 
somebody has to do it. 


add 7) I need the viewer to be able to provide comments/suggestions for me 
be able to incorporate into the wiki.

TiddlyWiki is a wiki and no discussion platform. So imo you need a 
separated "point to point - encrypted" discussion service here. That's a 
whole project for itself. I suppose it needs to be encrypted because of 3) 
and 9). 

If you want to keep the discussions on the web and you want them to be 
secure you'll need something that's called: "perfect forward secrecy" see: 
https://en.wikipedia.org/wiki/Forward_secrecy. Otherwise you content will 
be open in the future. ... There is a saying: "The internet doesn't forget" 
and for most knowledge based info that's correct. see: 
https://archive.org/index.php .. but for my private data, I'd like it, if 
it would fade away :) Especially since encryption, we consider safe now, is 
worthless in the future. 


add 8) I need to create a separate wiki for each different viewer, if they 
chose to enter personal information into it.

That's just a management problem. Especially for passwords used ;)


add 9) This is all about medical records - so the controls have HIPAA and 
legal requirements.

I found this: 
https://www.hhs.gov/hipaa/for-professionals/privacy/laws-regulations/ and 
didn't read it. I just searched for one term: "audit". IMO, due to the 
nature of the whole system you describe auditing always is a "killer 
feature". TiddlyWiki and all the components I'm thinking of are open source 
and therefore audit-able. ... but ... nobody did it, because it's 
expensive. 

And in some cases it's not even possible, due to the nature of browsers. 
... see: https://tonyarcieri.com/whats-wrong-with-webcrypto and 
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/.
 
Those articles are outdated, but I still think we don't have a viable 
browser based solution yet. This is my opinion. Others may differ. 

just some thoughts
have fun!
mario

PS: I barely scratched the surface here. It would be possible to write 
about the same length for every single point here. 

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To post to this group, send email to tiddlywiki@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/7b8763a0-edb2-4d3c-a4f6-35935d0dc640%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to