4 ms·

Why the hell doesn't Mastadon encrypt data at rest so the admins aren't responsible for user privacy? What the hell? Is this the 1990s?

detaro 4y ago
I don't think "encryption at rest" is what you want, because it doesn't help you against the admin if the app still can/has to be able to decrypt it? Encryption at rest protects against someone walking away with the database, not an admin.
- Xeoncross 4y ago
  Encryption isn't mentioned once in the whole Activity Pub spec. Encryption at rest isn't good enough. E2E should be the default on federated protocols with breakouts for public content only needing to be signed.
  - mariusor 4y ago
    ActivityPub is a transport protocol. The content of an ActivityPub object can be anything, including a stream of bytes coming from an E2E encrypted exchange.
    - Xeoncross 4y ago
      I disagree, ActivityPub is closely intertwined[1] with ActivityStreams[2] and expose all the actions and intents of the sender as part of the protocol. 1: https://www.w3.org/TR/activitypub/#like-activity-outbox https://www.w3.org/TR/activitypub/#like-activity-outbox 2: https://www.w3.org/TR/activitystreams-core/ https://www.w3.org/TR/activitystreams-core/
      - mariusor 4y ago
        First of all, I must clarify that I didn't truly address your initial statement, that "all" ActivityPub elements should be E2E encrypted, which is a notion that I find absurd, because it increases the complexity at least an order of magnitude and except "Create", no other activity in the specification has side effects that pass "content" between servers. In my opinion the only part of an ActivityPub request that can be sensitive and could require encryption are dereferenced objects inlined in a "Create" activity. What I addressed with my (granted too terse answer) was that E2E communication is actually possible, but it would require one of the following options: A "Create" Activity can wrap any type of object that has a JSON-LD document describing it (the ActivityStreams vocabulary is extensible[1]) so adding a new "E2EEncryptedMessage" object that contains all the properties required (and which are not already exposed in the existing vocabulary, eg, public keys which exist for the actors that participate in the exchange) in such a communication is possible. As long as all the information required for E2E can be encoded fully at each communication step (ie, nothing needs to be communicated off-band) everything will behave as expected for the clients that support this protocol extension. Another option would be to piggy back on existing Object types like "Document" and encode a full E2E payload in it's "Content" to obtain a similar effect but with less expressiveness from a ActivityPub point of view. This probably needs a custom "MimeType" to accompany it so other clients can avoid processing these objects. In conclusion, that's what I meant by having ActivityPub behave like "wire protocol", and apologies if I created confusion. [1] https://www.w3.org/TR/activitystreams-vocabulary/#extendedtypes https://www.w3.org/TR/activitystreams-vocabulary/#extendedty...

detaro 4y ago

I don't think "encryption at rest" is what you want, because it doesn't help you against the admin if the app still can/has to be able to decrypt it? Encryption at rest protects against someone walking away with the database, not an admin.

Xeoncross 4y ago
Encryption isn't mentioned once in the whole Activity Pub spec. Encryption at rest isn't good enough. E2E should be the default on federated protocols with breakouts for public content only needing to be signed.
- mariusor 4y ago
  ActivityPub is a transport protocol. The content of an ActivityPub object can be anything, including a stream of bytes coming from an E2E encrypted exchange.
  - Xeoncross 4y ago
    I disagree, ActivityPub is closely intertwined[1] with ActivityStreams[2] and expose all the actions and intents of the sender as part of the protocol. 1: https://www.w3.org/TR/activitypub/#like-activity-outbox https://www.w3.org/TR/activitypub/#like-activity-outbox 2: https://www.w3.org/TR/activitystreams-core/ https://www.w3.org/TR/activitystreams-core/
    - mariusor 4y ago
      First of all, I must clarify that I didn't truly address your initial statement, that "all" ActivityPub elements should be E2E encrypted, which is a notion that I find absurd, because it increases the complexity at least an order of magnitude and except "Create", no other activity in the specification has side effects that pass "content" between servers. In my opinion the only part of an ActivityPub request that can be sensitive and could require encryption are dereferenced objects inlined in a "Create" activity. What I addressed with my (granted too terse answer) was that E2E communication is actually possible, but it would require one of the following options: A "Create" Activity can wrap any type of object that has a JSON-LD document describing it (the ActivityStreams vocabulary is extensible[1]) so adding a new "E2EEncryptedMessage" object that contains all the properties required (and which are not already exposed in the existing vocabulary, eg, public keys which exist for the actors that participate in the exchange) in such a communication is possible. As long as all the information required for E2E can be encoded fully at each communication step (ie, nothing needs to be communicated off-band) everything will behave as expected for the clients that support this protocol extension. Another option would be to piggy back on existing Object types like "Document" and encode a full E2E payload in it's "Content" to obtain a similar effect but with less expressiveness from a ActivityPub point of view. This probably needs a custom "MimeType" to accompany it so other clients can avoid processing these objects. In conclusion, that's what I meant by having ActivityPub behave like "wire protocol", and apologies if I created confusion. [1] https://www.w3.org/TR/activitystreams-vocabulary/#extendedtypes https://www.w3.org/TR/activitystreams-vocabulary/#extendedty...