3 ms·
Can't all that be modelled with keys/signing? Can you elaborate more on the risks around automated key management?
by the_other 5y ago
Can't all that be modelled with keys/signing? Can you elaborate more on the risks around automated key management?
- grishka 5y ago> Can't all that be modelled with keys/signing? Probably? I don't know. The problem is that it gets really complicated really fast. When someone adds a friend, how do you grant that new friend access to their older friends-only posts? How do you revoke that access, and access to any future posts, when they unfriend someone? > Can you elaborate more on the risks around automated key management? The biggest problem for my project in particular is that it requires the ability to run arbitrary code and reliably store valuable data on the client side. And client-side rendering. I can't quite do that. I have a requirement that everything must work in a regular web browser and JS is mostly optional. And even ignoring that, question remains: how do you make sure the server doesn't have access to the key while the client does, while keeping the user experience sane?
- neopub 5y agoI've been tinkering around with these ideas at https://github.com/neopub/neopub https://github.com/neopub/neopub (demo at https://neopub.pages.dev https://neopub.pages.dev). It runs entirely in the browser, using the Web Crypto API. For key management, I store the user's private keys in the browser's password manager, and friend keys in IndexedDB, backed up to the user's host in a client-side encrypted blob. > When someone adds a friend, how do you grant that new friend access to their older friends-only posts? How do you revoke that access, and access to any future posts, when they unfriend someone? My project publishes an encrypted post as one file, then 1 keyfile for each of your friends to unlock that post. When you unfriend someone, you can just delete all their keyfiles and cease generating them for future posts.