Hacker News Reader

Comment by rogerbraun | Hacker News Reader

In AP, messages are signed with http signatures (https://tools.ietf.org/html/draft-cavage-http-signatures-09). OStatus has a similar mechanism called salmons, which are signed XML payloads.

View on HN

server-to-server signatures are a good start, but what about encrypting messages end-to-end? I assume the servers already talk over HTTPS.

Hello! Co-editor of ActivityPub here. I wrote a paper for Rebooting Web of Trust on how this could be done: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust...

Thank you! Important part starts half-way down: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust...

The ideas about using DID's (https://w3c-ccg.github.io/did-spec/) and moving off a common transport like HTTP was also interesting.

it's really not worth it. If people want to exchange encrypted messages, they should use a proper tool for that.

Please don't say that. We already had such pain from HTTP, FTP, and SMTP not starting with it.

If building the next version of internet discussion and sharing, we really need first-class support for encryption.

What about gnunet?

no, we really don't. Not every tool needs to be equipped for private discussions. ActivityPub and OStatus are used for Twitter-style communication. Those aren't high security communication services.

They turn into security problems in aggregate. For example, the threat to me from actors slurping up social media data to nudge/manipulate people at a large scale is much larger than the threat to me than someone reading my group chats to my friends or a lot of other personal info that is generally considered more private and more in need of high security.

If my personal twitter-style communication got out it would be worse to me than my more private messages, but it is worse to me personally if all the twitter style communication gets out than only my more private messages.

You have to account for manipulative big data risks in your analysis, thinking only about your personal data is an outdated approach.

Start with the safe and secure option, figure out how to dial it down and open it up.

Doing it the other way around? We literally have 50 years of experience of that being a terrible, terrible idea.

I might be wrong, but I would think that end-to-end public crypto can be used for more than just ensuring privacy.

HTTPS ensures more than just privacy. For instance, authenticity.

i would consider a privacy-first approach a best-practice :)

Reply on news.ycombinator.com