HerbCaudill
commented
2 months ago This scenario is only a problem if we honestly think it's a good idea for a single ID to simultaneously have the jobs of (1) uniquely identifying a document and (2) acting as a token giving the bearer read/write access to that document until the end of time.
Rumplestiltskin security has served us well while we work on other problems, but I hope we're being honest with ourselves about the fact that it's only really an option for a real-world application with zero security concerns.
pvh
Imagine the following -- I have a document containing secrets. I give you the AutomergeUrl so you can request it from me.
In order to request the document, you broadcast that URL to all your peers asking if they have it. Now any misbehaving peer could record that request and replay it a few minutes later to fetch the document.
Unfortunately, there isn't really a great solution for this right now aside from only connecting directly to peers you trust. This hasn't been a major issue to date in our work because we only use a single trusted sync server -- but in the case of federated sync servers (per @clemens work) or peer-to-peer configurations, we'll need a more robust solution.
Probably the state of the art here is to do something like hypercore's discovery key: a deterministically hashed version of the ID in question which can be trivially calculated if you have the actual document but is unguessable otherwise.
I've filed this as an issue so it doesn't get forgotten as we think about the next version of our sync protocol. cc / @alexjg