4 ms·

I'm not sure that many people would want to share what they put on social networks with their local computer enthusiast. Talk about hobby, neighbourhood questio

by bertil 5y ago

I'm not sure that many people would want to share what they put on social networks with their local computer enthusiast. Talk about hobby, neighbourhood questions, lost child—sure. But a lot of conversation on there are gossiping, private information, the occasional password. A lot has been said here about privacy and how social media company might abuse it; the reality, is that they don’t care much about your private conversation, unless they can target ads based on this, or grab your attention. They don’t have the time or the inclination. Your colleague who can see all private message on Slack without notification and probably does religiously (yeah, that’s a thing) on the other hand…

grishka 5y ago
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.
- eevilspock 5y ago
  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.
  - grishka 5y ago
    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.
    - 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 ago
        I'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.

by bertil 5y ago

grishka 5y ago

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.

eevilspock 5y ago
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.
- grishka 5y ago
  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.
  - 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 ago
        I'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.