Hey Everyone,
It's been a while since the last update, been busy thinking out the foundational application architecture making sure I'm happy with the fundamentals.
I thought now would be a good opportunity to explain the depths of details I've gone to protect as many use cases as possible.
I've gone to the nth degree to think about user privacy.
Considering the full application life cycle and its many use cases, my goal was to protect users' data and personal security by having our application installed.
So, from people who want to watch region-restricted videos to journalists in the field who require extra, well, ass-covering as standard, this is what I have come up with that I can share today.
- Anonymous OpenPGP backed, client-side User accounts
- Application data utilises encrypt/decrypt object serialization.
- Obfuscated data storage
Anonymous User Accounts
Without a central database for user authentication or wallets in plain text, the application has to store user account information. However, this poses a risk because people can view the filesystem files either remotely or while the user is not around.
To cover this, I'm going with armoured OpenPGP keys & Anonymous reproducible ID's, with files like:
b1ff8c846af5cdc8e71e096073591dfc1ea2d786558a3fce18f3c2c24a9692cd.lthn.private.asc
Try to figure out the username from the hash or replicate it; it is a sha256 to give you a head start. Oh, and to be fair, the username is test.
Further application data resides in AES encrypted data files that are unlockable only with the OpenPGP private key.
creating a portable user account system that exposes no user information, allowing our users to utilise hardware encrypted USB sticks to carry their user data across multiple installations of Lethean without ever leaving a trace on any device or just one big folder with many users, the security is near enough the same with or without extra effort.
Data layer Enforced Encryption
Our application is a hybrid PWA/Desktop/CLI app, with so many use cases ensuring all data is secure is, well, risky, when left to the programmer to remember... guess what happens? We forget, so, taking human nature and open-source into consideration.
I'm not creating duplicate routines to handle data, and the new CLI handles the long-term storage.
The GUI/Presentation layer uses a data store intermediary to force encryption on object serialisation/deserilsation, so GUI developers don't have to think about encrypting.
Obfuscated data storage
We now have secure internal data namespaces, cool.
This allows the application and users to store arbitrary data, images, documents, passwords, or wallets, to name some examples.
While nothing is stored in plaintext, this user-centric data storage facility could accommodate private social profiles or a user's online metadata enabling decentralised sharing of encrypted information using OpenPGP and preshared public keys.
*more on distributed keyservers in the coming months
My end goal here is a personal data API that will store application settings or the information important to a user, like their music history; with that, you can sync between music services your playlists for free while not giving access to 3rd parties.
Other use cases could be running data analytics, AI's on your data, for just your benefit, on your hardware, suddenly seems less like "Skynet" is about to deploy and way more approachable.
Well, I got stuff to do, I'm going back to code, cya.
Snider
Congratulations @snider! You have completed the following achievement on the Hive blockchain and have been rewarded with new badge(s) :
Your next target is to reach 100 upvotes.
Your next target is to reach 50 comments.
You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOPTo support your work, I also upvoted your post!
Check out the last post from @hivebuzz:
Support the HiveBuzz project. Vote for our proposal!