Secure and encrypted note taking - Revision history

Kinscoe: /* My goals */

2020-04-19T18:29:51Z

My goals

← Older revision		Revision as of 18:29, 19 April 2020
Line 21:		Line 21:
	==My goals==		==My goals==

	*Off-line: works completely off-line. No cloud!		*Off-line: works completely off-line. No cloud storage.
	*Self-contained: program and files in a single collection to make secure replication ~~easier~~.		*Self-contained: program and files in a single collection to make secure replication possible.
	*Multimedia: notes and attachments are stored in a single encrypted vault in a single nosql database file and rendered inline.		*Multimedia: notes and attachments are stored in a single encrypted vault in a single nosql database file and rendered inline. Similar to IBM Notes NSF files.
	*Private: intended for a single individual. Non collaborative notes and articles of a personal or private nature. Sharing of notes possible via export. Access and and authenticated is strongly encrypted and secure. 2FA a possible future.		*Private: intended for a single individual. Non collaborative notes and articles of a personal or private nature. Sharing of notes possible via export. Access and and authenticated is strongly encrypted and secure. 2FA a possible future.
	*Encrypted: end to end even while editing.		*Encrypted: end to end even while editing. Note that while editing a text blob the in memory is possible accessible in a shared memory system. This is difficult to get around.
	*Desktop: oriented and not client server. ~~Mobile~~ or cell device is not a design goal.		*Desktop: GUI oriented and not client server. command line editing, mobile app or cell device is not a design goal.
	*Organization: notes organized by drawer/folder with tags or other semantics. Links between documents possible.		*Organization: notes organized by drawer/folder with tags or other semantics. Links between documents possible.
	*Editor: support for any editor. edited files stored in secure blobs.		*Editor: support for any editor. edited files stored in secure blobs.
	*Rendering: TBD but likely RTF, MD or HTML a mode that supports multi-media.		*Rendering: TBD but likely RTF, MD or HTML a mode that supports multi-media.
	*Reliable: journal of revisions to documents and document recovery.		*Reliable: journal of revisions to documents and document recovery.

Kinscoe: /* Security enhancement */

2020-04-19T18:16:52Z

Security enhancement

← Older revision		Revision as of 18:16, 19 April 2020
Line 17:		Line 17:
	==Security enhancement==		==Security enhancement==

	I then started using MediaWiki for all of my notes private and public and began to realize the security implications in doing such. Since all wikis are written with collaboration and sharing of information in mind not much effort has gone into this. I looked into to making MW more secure but found the database seemed to be the weakest link. I thought of encapsulating a VM with an encrypted file system which would seem to solve my worries about losing the files to theft (laptop) but I became more and more concerned about man in the middle attacks on using TLS (https) connections with corporate proxies (most notably Blue Coat). For more on this issue see https://security.stackexchange.com/questions/8145/does-https-prevent-man-in-the-middle-attacks-by-proxy-server. Is was this reason I decided to move away from ~~web~~ based solutions and look at local solutions with a secure way to synchronize between desktops (I use three regularly).		I then started using MediaWiki for all of my notes private and public and began to realize the security implications in doing such. Since all wikis are written with collaboration and sharing of information in mind not much effort has gone into this. I looked into to making MW more secure but found the database seemed to be the weakest link. I thought of encapsulating a VM with an encrypted file system which would seem to solve my worries about losing the files to theft (laptop) but I became more and more concerned about man in the middle attacks on using TLS (https) connections with corporate proxies (most notably Blue Coat). For more on this issue see https://security.stackexchange.com/questions/8145/does-https-prevent-man-in-the-middle-attacks-by-proxy-server and https://blog.cloudflare.com/introducing-strict-ssl-protecting-against-a-man-in-the-middle-attack-on-origin-traffic/. Is was this reason I decided to move away from HTTPS based solutions and look at local solutions with a secure way to synchronize between desktops (I use three regularly).

	==My goals==		==My goals==

Kinscoe: /* My goals */

2020-04-17T20:47:46Z

My goals

@@ Line 21: / Line 21: @@
 ==My goals==
+*Off-line: works completely off-line. No cloud!
 ==Solutions sought==

Kinscoe: /* Solutions sought */

2020-04-17T19:15:34Z

Solutions sought

← Older revision		Revision as of 19:15, 17 April 2020
Line 18:		Line 18:

	I then started using MediaWiki for all of my notes private and public and began to realize the security implications in doing such. Since all wikis are written with collaboration and sharing of information in mind not much effort has gone into this. I looked into to making MW more secure but found the database seemed to be the weakest link. I thought of encapsulating a VM with an encrypted file system which would seem to solve my worries about losing the files to theft (laptop) but I became more and more concerned about man in the middle attacks on using TLS (https) connections with corporate proxies (most notably Blue Coat). For more on this issue see https://security.stackexchange.com/questions/8145/does-https-prevent-man-in-the-middle-attacks-by-proxy-server. Is was this reason I decided to move away from web based solutions and look at local solutions with a secure way to synchronize between desktops (I use three regularly).		I then started using MediaWiki for all of my notes private and public and began to realize the security implications in doing such. Since all wikis are written with collaboration and sharing of information in mind not much effort has gone into this. I looked into to making MW more secure but found the database seemed to be the weakest link. I thought of encapsulating a VM with an encrypted file system which would seem to solve my worries about losing the files to theft (laptop) but I became more and more concerned about man in the middle attacks on using TLS (https) connections with corporate proxies (most notably Blue Coat). For more on this issue see https://security.stackexchange.com/questions/8145/does-https-prevent-man-in-the-middle-attacks-by-proxy-server. Is was this reason I decided to move away from web based solutions and look at local solutions with a secure way to synchronize between desktops (I use three regularly).

			==My goals==



	==Solutions sought==		==Solutions sought==

	Software and tools I tried bu ultimately they didn't satisfy my desires.		Software and tools I tried but ultimately rejected since they didn't satisfy my desires.

	*https://laverna.cc/		*https://laverna.cc/

Kinscoe: /* Security enhancement */

2020-04-17T19:06:30Z

Security enhancement

← Older revision		Revision as of 19:06, 17 April 2020
Line 17:		Line 17:
	==Security enhancement==		==Security enhancement==

	I then started using MediaWiki for all of my notes private and public and began to realize the security implications in doing such. Since all wikis are written with collaboration and sharing of information in mind not much effort has gone into this. I looked into to making MW more secure but found the database seemed to be the weakest link. I thought of encapsulating a VM with an encrypted file system which would seem to solve my worries about losing the files to theft (laptop) but I became more and more concerned about man in the middle attacks on using TLS (https) connections with corporate proxies (most notably Blue Coat). For more on this issue see https://security.stackexchange.com/questions/8145/does-https-prevent-man-in-the-middle-attacks-by-proxy-server. Is was this reason I decided to move away from web based solutions and look at local solutions with a secure way to synchronize between desktops (I use three regularly)		I then started using MediaWiki for all of my notes private and public and began to realize the security implications in doing such. Since all wikis are written with collaboration and sharing of information in mind not much effort has gone into this. I looked into to making MW more secure but found the database seemed to be the weakest link. I thought of encapsulating a VM with an encrypted file system which would seem to solve my worries about losing the files to theft (laptop) but I became more and more concerned about man in the middle attacks on using TLS (https) connections with corporate proxies (most notably Blue Coat). For more on this issue see https://security.stackexchange.com/questions/8145/does-https-prevent-man-in-the-middle-attacks-by-proxy-server. Is was this reason I decided to move away from web based solutions and look at local solutions with a secure way to synchronize between desktops (I use three regularly).

	==Solutions sought==		==Solutions sought==

Kinscoe: /* Security enhancement */

2020-04-17T19:06:14Z

Security enhancement

← Older revision		Revision as of 19:06, 17 April 2020
Line 17:		Line 17:
	==Security enhancement==		==Security enhancement==

	I then started using MediaWiki for all of my notes private and public and began to realize the security implications in doing such. Since all wikis are written with collaboration and sharing of information in mind not much effort has gone into this. I looked into to making MW more secure but found the database seemed to be the weakest link. I thought of encapsulating a VM with an encrypted file system which would seem to solve my worries about losing the files to theft (laptop) but I became more and more concerned about man in the middle attacks on using TLS (https) connections with corporate proxies (most notably Blue Coat). For more on this issue see https://security.stackexchange.com/questions/8145/does-https-prevent-man-in-the-middle-attacks-by-proxy-server		I then started using MediaWiki for all of my notes private and public and began to realize the security implications in doing such. Since all wikis are written with collaboration and sharing of information in mind not much effort has gone into this. I looked into to making MW more secure but found the database seemed to be the weakest link. I thought of encapsulating a VM with an encrypted file system which would seem to solve my worries about losing the files to theft (laptop) but I became more and more concerned about man in the middle attacks on using TLS (https) connections with corporate proxies (most notably Blue Coat). For more on this issue see https://security.stackexchange.com/questions/8145/does-https-prevent-man-in-the-middle-attacks-by-proxy-server. Is was this reason I decided to move away from web based solutions and look at local solutions with a secure way to synchronize between desktops (I use three regularly)

	==Solutions sought==		==Solutions sought==

Kinscoe: /* Security enhancement */

2020-04-17T19:04:57Z

Security enhancement

← Older revision		Revision as of 19:04, 17 April 2020
Line 17:		Line 17:
	==Security enhancement==		==Security enhancement==

	I then started using MediaWiki for all of my notes private and public and began to realize the security ~~holes~~ in doing such. Since all wikis are written with collaboration and sharing of information in mind not much effort has gone into this. I looked into to making MW more secure but found the database seemed to be the weakest link. I thought of encapsulating a VM with an encrypted file system which would seem to solve my worries about losing the files to theft (laptop) but I became more and more concerned about man in the middle attacks on using TLS (https) connections with corporate proxies (most notably Blue Coat). For more on this issue see https://security.stackexchange.com/questions/8145/does-https-prevent-man-in-the-middle-attacks-by-proxy-server		I then started using MediaWiki for all of my notes private and public and began to realize the security implications in doing such. Since all wikis are written with collaboration and sharing of information in mind not much effort has gone into this. I looked into to making MW more secure but found the database seemed to be the weakest link. I thought of encapsulating a VM with an encrypted file system which would seem to solve my worries about losing the files to theft (laptop) but I became more and more concerned about man in the middle attacks on using TLS (https) connections with corporate proxies (most notably Blue Coat). For more on this issue see https://security.stackexchange.com/questions/8145/does-https-prevent-man-in-the-middle-attacks-by-proxy-server

	==Solutions sought==		==Solutions sought==

Kinscoe: /* Security enhancement */

2020-04-17T19:03:18Z

Security enhancement

← Older revision		Revision as of 19:03, 17 April 2020
Line 17:		Line 17:
	==Security enhancement==		==Security enhancement==

	I then started using MediaWiki for all of my notes private and public and began to realize the security holes in doing such. I looked into to making MW more secure but found the database seemed to be the weakest link. I thought of encapsulating a VM with an encrypted file system which would seem to solve my worries about losing the files to theft (laptop) but I became more and more concerned about man in the middle attacks on using TLS (https) connections with corporate proxies (most notably Blue Coat). For more on this issue see https://security.stackexchange.com/questions/8145/does-https-prevent-man-in-the-middle-attacks-by-proxy-server		I then started using MediaWiki for all of my notes private and public and began to realize the security holes in doing such. Since all wikis are written with collaboration and sharing of information in mind not much effort has gone into this. I looked into to making MW more secure but found the database seemed to be the weakest link. I thought of encapsulating a VM with an encrypted file system which would seem to solve my worries about losing the files to theft (laptop) but I became more and more concerned about man in the middle attacks on using TLS (https) connections with corporate proxies (most notably Blue Coat). For more on this issue see https://security.stackexchange.com/questions/8145/does-https-prevent-man-in-the-middle-attacks-by-proxy-server

	==Solutions sought==		==Solutions sought==

Kinscoe: /* Security enhancement */

2020-04-17T19:02:08Z

Security enhancement

← Older revision		Revision as of 19:02, 17 April 2020
Line 17:		Line 17:
	==Security enhancement==		==Security enhancement==

	I then started using MediaWiki for all of my notes private and public and began to realize the security holes in doing such. I looked into to making MW more secure but found the database seemed to be the weakest link. I thought of encapsulating a VM with an encrypted file system which would seem to solve my worries about losing the files to theft (laptop) but I became more and more concerned about man in the middle attacks on using TLS (https) connections.		I then started using MediaWiki for all of my notes private and public and began to realize the security holes in doing such. I looked into to making MW more secure but found the database seemed to be the weakest link. I thought of encapsulating a VM with an encrypted file system which would seem to solve my worries about losing the files to theft (laptop) but I became more and more concerned about man in the middle attacks on using TLS (https) connections with corporate proxies (most notably Blue Coat). For more on this issue see https://security.stackexchange.com/questions/8145/does-https-prevent-man-in-the-middle-attacks-by-proxy-server

	==Solutions sought==		==Solutions sought==

Kinscoe: /* Security enhancement */

2020-04-17T18:47:24Z

Security enhancement

← Older revision		Revision as of 18:47, 17 April 2020
Line 17:		Line 17:
	==Security enhancement==		==Security enhancement==

	I then		I then started using MediaWiki for all of my notes private and public and began to realize the security holes in doing such. I looked into to making MW more secure but found the database seemed to be the weakest link. I thought of encapsulating a VM with an encrypted file system which would seem to solve my worries about losing the files to theft (laptop) but I became more and more concerned about man in the middle attacks on using TLS (https) connections.

	==Solutions sought==		==Solutions sought==