Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You can't guarantee privacy in a federated system and it's important to understand. I'm working on my own ActivityPub project and I don't even support any kind of non-public content for now. I'll be exploring the options for e2e encrypted instant messaging later tho.


One-to-many messages can be encrypted with end-to-end encryption by encrypting a copy for each recipient using their public key.

Apple essentially does this with iMessage, both for sending a message to each of your devices as well as to each recipient in a group chat.


The problem with that is that you now have to have a "client" to decrypt and display those posts. And it has to manage keys. And you have to shift some of that burden onto the user because otherwise the key could be accessible to the server.

People do somewhat expect this stuff for messaging, but it'll get really messy really fast for posts and photos and similar long-lived content. It'll get even messier when you consider that privacy options in this style of social network are the likes of "friends only", so they include dynamic collections of users.


Can't all that be modelled with keys/signing? Can you elaborate more on the risks around automated key management?


> 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?


I've been tinkering around with these ideas at https://github.com/neopub/neopub (demo at 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: