I was digging into federation protocol description, as well as diaspora* sources, in attempt to borrow some ideas of implementing decentralized secure timestamping — e.g. the way to prove that particular message said to be written a year ago, had really existed year ago, and hadn’t created later.
I was interested in the way diapora* provides these proofs, but while searching for created_at field handling, I hadn’t met any checks.
Am I right, or maybe had I overlooked something, that malicious pod can publish posts with timestamps being far into the past or into the future? If I’m wrong, what is the way diaspora* protects from such behavior?
Note: This discussion was imported from Loomio. Click here to view the original discussion.
Checked the first of Rich’s links on three pods using its guid (/posts/7dd254454d8cc863) and the time-stamp came out as 6 Jan 2014 09:26:44, so it seems a time-stamp forged on a remote pod doesn’t federate. Whether a time-stamp forged on the originating pod would federate is a different question - care to fiddle with one of your own posts, Rich?
There are a lot of things against which Diaspora doesn’t defend. There’s no way guarantee that any part of your message isn’t molested from the time it’s received by a pod until it’s presented to a user. There’s no guarantee a message from a pod actually came from the user associated with that message (the pod itself can generate bogus messages). If a podmin wanted to be malicious, falsifying timestamps is a relatively benign way to go about it. Aside from having users sign messages themselves in the browser a la S/MIME email signatures, there’s no technical way around these issues.
By and large the way to deal with these issues is by not federating with pods that have demonstrated to be bad actors; taken to the extreme this means running one’s own pod.
It’s possible. The sending pod encrypts the message with the user’s private key (which the pod generates and stores itself); there’s nothing preventing the pod from using something other than the text the user entered on their browser and submitted to the pod. The user must trust the pod they’re using in the current model.
@bradkoehn sure but I thought you meant that someone can send messages as me for example, from another pod Of course the pod that has the key can do whatever it wants.
@jasonrobinson True that. It would be very difficult for a pod to forge a message. I was just saying that there’s not much point putting effort into validating the timestamp of a message if a pod can forge messages from its users.
It’s true, the verification of messages depends on the users signature by their individual key pair. If created_at is a field that is federated as part of an entity, it is also part of the content that will be signed.
So yes, if someone builds a malicious pod, it can forge arbitrary messages by users that are registered there.
This design stems from the initial idea by the founders to let every user (eventually) host their own pod, or maybe host a pod for themselves and a few friends, who sign up there based on personal trust.
But that plan didn’t really play out in the scale it was intended. Instead we have a few very big pods and not as many individual/small community installations as hoped.
With todays security concerns and the real deployment situation in mind, one would probably let the users browser store the keys and sign the messages client-side, to minimize the risk of forged messages.
But there is something about it here: 
Of course the pod that has the key can do whatever it wants.