Content
@
https://warpcast.com/~/channel/walletbeat
0 reply
0 recast
0 reaction
polymutex
@polymutex.eth
Possibly-controversial change: Should servers running in enclaves be treated as privacy-preserving? https://github.com/walletbeat/walletbeat/commit/294dde48a808c93b1c619171a226ffd40ac908f8
3 replies
2 recasts
7 reactions
polymutex
@polymutex.eth
Assuming: - The server-side code is source-available - The server-side code is built reproducibly - The client actually checks that the server is in an enclave - The client actually checks that the server runs the code it claims - The server code doesn't log anything ... Is such a server privacy-preserving?
2 replies
0 recast
4 reactions
xh3b4sd ↑
@xh3b4sd.eth
I guess you can argue that the server is more privacy preserving. What I would be asking though, is whether the connection between client and server is verifiably encrypted. How can we ensure that no middlemen tampered with the data in transit? So verifiable end-to-end encryption might be as important as secure enclaves. And then we should also make sure that encryption happens inside the enclave, so that it doesn't just stop slightly before that interface.
2 replies
0 recast
3 reactions
Sebastian Bürgel
@scbuergel
This ^^ Also: (how) can users/clients validate trust assumptions on a request by request basis if needed? I've looked into the 1RPC docs but didn't find what I'd consider a 101 tutorial on how to verify their claims *for my specific usage session*
1 reply
0 recast
2 reactions
polymutex
@polymutex.eth
True. In practice that means ensuring the TLS layer ends in the enclave. I took this for granted but in retrospect that's not obviously the case, especially given that there's the temptation to terminate the TLS handshake at the load balancer level. I'll need to add this.
0 reply
0 recast
2 reactions
