id summary reporter owner description type status priority milestone component version resolution keywords cc launchpad_bug 308 add directory traversal / deep-verify capability? warner "We might split our current three-level directory capability structure (write, read, verify) into four levels: write, read, traverse, verify. The 'traverse cap' would be able to access the traverse cap of child directories, and the verify cap of child files. It would not be able to read child names. The issue is that, at present, the verifier manifest (a set of verifier caps for all files and directories reachable from some root) can only be generated by someone who holds a readcap for the root. This manifest generation cannot be safely delegated to some other party (such as a central allmydata server). So we're forced to decide between having customers expose their files to us (by giving us their root readcap) or being required to create their manifest (for file checking/repair) on their own. If we had traversal caps, then customers could give us the traversal cap instead of their read cap. We could still see the shape of their filesystem (and probably the length of their filenames, and the size of their files), but perhaps that would be little enough exposure that customers would be comfortable with revealing it. In exchange, we could provide the service of keeping all their files checked and repaired with less effort on their part, even when they leave their node offline for months at a time. The implementation would require a couple of pieces: * dirnode capabilities would need to have a four-level structure. Writecaps beget readcaps. Readcaps beget traversecaps. Traversecaps beget verifycaps. * I think this means that mutable file caps need an extra intermediate layer as well: this is tricky, and will require some staring at the DSA mutable file diagram to find a place that could accomodate it. * Each edge entry contains five child items: (name, writecap, readcap, traversecap, metadata) * 'name', 'readcap', and 'metadata' are encrypted with a key derived from the dirnode's readcap. * 'writecap' is encrypted with the dirnode's writecap. * 'traversecap' is encrypted with the dirnode's traversecap When we do DSA dirnodes, we should take advantage of the compatibility break to implement something like this. I suspect it will require changes to the DSA scheme as well. (there is probably a better name for this concept.. ""walk cap""? ""manifest cap""? ""deep verify cap""?) " enhancement new major code-dirnodes 0.7.0 vdrive newcaps verify repair privacy anonymity research