Private Service Proxying

[DavidBuchanan314]

Requests proxied via a PDS, using the Service Proxying mechanism, may contain sensitive information (e.g. detailed moderation reports).

While the user nominally trusts their PDS, it would be better if the PDS never got to see request bodies, even if just from a data minimization perspective. (e.g., as a PDS operator, I would rather not have the ability to see the service requests of my users).

Since the target service already has a DID, an asymmetric key could be attached to that DID, and used by the client to encrypt the request body such that only the target service (and not the PDS) can decrypt it. The PDS would forward the encrypted body as-is.

I think this would be the first time an atproto client is "required" to do cryptography (it could be optional, though).

By the way, the web crypto APIs support p256 keys https://developer.mozilla.org/en-US/docs/Web/API/EcKeyGenParams

This is something that could be implemented at the application layer (in the sense that "bluesky" is an application), but pushing it further down the stack (as part of the protocol) means it can be more integrated and transparent to application developers (it would be nice if application developers didn't have to care about cryptography)

[DavidBuchanan314]

As for how this might look over the wire, perhaps something like this

{
    "$type": "com.atproto.encrypted",
    "recipient": "did:web:example.com",
    "method": "com.atproto.encrypted.method.ECDH_xchacha20poly1305",
    "key_derivation": {"$bytes": "b64..."},
    "payload": {"$bytes": "b64..."}
}

Where payload is AEAD-encrypted bytes, and key_derivation is whatever information the recipient needs to derive the symmetric key used to encrypt the payload (e.g. the shared data for ECDH).

(just a mockup, I haven't put much thought into this from a cryptography/security PoV)

And just to be explicit, this is for encrypting data in flight, not at rest. Once the recipient (e.g. a moderation service) receives and decrypts the request, it processes it just as it would any other request.

[DavidBuchanan314]

I suppose an alternative to encryption is just to have the client make the request to the service directly (which also saves on network overheads!). To do this, the client needs an auth token - the PDS could have an API for "give me an auth token scoped for service xyz".

[bnewbold]

This makes a lot more sense to me! Or some kind of tunneled HTTPS proxying.

An endpoint does exist for clients to get service auth tokens: com.atproto.server.getServiceAuth

[DavidBuchanan314]

Ah, TIL - so in theory a client could use getServiceAuth, and avoid the use of service proxying entirely, already?

[bnewbold]

I believe so (but haven't actually tried it)

[devinivy]

That's true, should work! Though it's not as practical for certain use cases, as the tokens are short-lived and intended to be single-use.

[bnewbold]

To date we have taken the stance that the PDS is pretty trusted and acts on behalf of the user. An analogy we make is to web browsers: you really need to trust your web browser! It can inspect all your data in clear text. Your PDS hosts your repo signing key, and usually identity rotation keys. In some situations you might trust your PDS even more than your client app: distributing apps via an app store has different friction than deploying a small server, the app (or mobile OS) could be doing tracking tied to your carrier/hardware, can be hard to verify from source (eg, using reproducible builds), etc. (of course there are also professional security teams, regulation, and a bunch of eyes on app stores). In the long run a PDS could be a place for software to act on behalf of users, like removing ads, trackers, and other bogus content (a la browser extensions).

That is all kind of hypothetical though, and we aren't totally beholden to this world view. The reality today is that most folks are the Bluesky PDS, or the reference implementation, and folks might not trust it.