Changes between Version 30 and Version 31 of NewCapDesign


Ignore:
Timestamp:
2013-09-11T06:33:51Z (11 years ago)
Author:
zooko
Comment:

"lafs" is more the protocol, "tahoe" is more the Python implementation, second edit

Legend:

Unmodified
Added
Removed
Modified
  • NewCapDesign

    v30 v31  
    152152   non-word-breaking string. The next best will be to have a large
    153153   non-word-breaking string at the start and end, with smaller segments (if
    154    necessary) in the middle. Note that {{{tahoe:}}} is an easy target, but
    155    {{{x-tahoe:}}} is not (you'd have to double-click on the "x").
     154   necessary) in the middle. Note that {{{lafs:}}} is an easy target, but
     155   {{{x-lafs:}}} is not (you'd have to double-click on the "x").
    156156 * Usable in a browser. Specifically, it should be easy to actually use a
    157157   filecap that you get in email or IM, and many email/IM clients will look
    158158   for http URLs and make them clickable. If tahoe filecaps start with
    159159   {{{http:}}}, then they'll be made clickable. This is at odds with the
    160    IANA-friendly {{{tahoe:}}} prefix. Clients may make {{{tahoe:}}} URIs
     160   IANA-friendly {{{lafs:}}} prefix. Clients may make {{{lafs:}}} URIs
    161161   clickable too (I've seen them make other letters-then-colon strings
    162162   clickable, even when the letters are not "http"), so perhaps a reasonable
    163    solution is to provide an OS-level URI handler for the {{{tahoe:}}}
     163   solution is to provide an OS-level URI handler for the {{{lafs:}}}
    164164   scheme, which could embed the filecap in an http URL and submit it to a
    165    webbrowser (i.e. when you click on {{{tahoe:foo}}}, a helper program is
    166    launched with {{{tahoe:foo}}}, and that in turn launches your web browser
     165   webbrowser (i.e. when you click on {{{lafs:foo}}}, a helper program is
     166   launched with {{{lafs:foo}}}, and that in turn launches your web browser
    167167   with {{{http://localhost:8123/foo}}}). (#52)
    168168
     
    217217  * in addition, tahoe URIs should be distinguishable from local filenames by
    218218    a CLI tool, so that {{{tahoe cp $CAP local/foo.txt}}} is unambiguous.
    219     (unfortunately, the current practice of using "tahoe:" as a default alias
     219    (unfortunately, the current practice of using "lafs:" as a default alias
    220220    name collides with this badly, but perhaps if the new URIs include the
    221221    double-slash, this won't be a problem:
    222     {{{tahoe cp tahoe://CAP local/foo.txt}}} copies from a specific URI,
    223     while {{{tahoe cp tahoe:blah local/foo.txt}}} copies from a child of
    224     the "tahoe:" alias).
     222    {{{tahoe cp lafs://CAP local/foo.txt}}} copies from a specific URI,
     223    while {{{tahoe cp lafs:blah local/foo.txt}}} copies from a child of
     224    the "lafs:" alias).
    225225'''Note that double-slash means "there is a naming authority" (see RFC 3986). I think most people's understanding of caps is that there is no naming authority (i.e. a remote server which you completely rely on to decide what value a name within its domain should denote). I suppose we might fit the semantics of RFC 3986 if we claim that the thing we have there (which will probably be a crypto value derived in complex ways from the plaintext of the file and/or a public key) *is* a naming authority.'''
    226226  * I'd like to make it easy to layer uses on top of one another: since
     
    228228    (mutable) file, let's make the directory cap be closely related to the
    229229    underlying filecap. For example, if we end up using
    230     {{{tahoe://MR/cryptobits}}} to describe a read-only mutable file
     230    {{{lafs://MR/cryptobits}}} to describe a read-only mutable file
    231231    referenced by "cryptobits", then we could use
    232     {{{tahoe://D/MR/cryptobits}}} for the directory that uses it as a backing
    233     store. The rule would be that {{{tahoe://D/$A}}} would be handled by
    234     fetching {{{tahoe://$A}}} and then interpreting its contents as a
     232    {{{lafs://D/MR/cryptobits}}} for the directory that uses it as a backing
     233    store. The rule would be that {{{lafs://D/$A}}} would be handled by
     234    fetching {{{lafs://$A}}} and then interpreting its contents as a
    235235    directory structure. Then reading immutable-dirnodes (#607) would be
    236236    trivial. Another way to think about this is that if our filecaps were
    237237    verbose s-expressions, these caps could be expressed as "(readonly
    238238    (mutable cryptobits))" and "(directory (readonly (mutable cryptobits)))".
    239   * Don't provide an affordance for diminishing caps by editing them, or else make sure that the actual effect of doing so is the same as the intended effect. This actually happened to an LAE customer: they sent us a transcript of their shell session which had their write cap init, and they truncated off the right-hand side of the cap, intending to thus preserve confidentiality of their data. Unfortunately for them, the right-hand side of the (current) write cap format is the integrity-checking bits, not the write-authority bits! The remaining left-hand-side of the cap that they sent was enough to let us (or anyone else who saw their mail) read and overwrite all of their files. This wouldn't have happened if the cap had been a compact thing with no visible separations, like "tahoe:WD1WDDy975ZJkrU7XZTxAB39kmnfxYk3zDb", or if it had been ordered so that the most powerful bits were right-most.
     239  * Don't provide an affordance for diminishing caps by editing them, or else make sure that the actual effect of doing so is the same as the intended effect. This actually happened to an LAE customer: they sent us a transcript of their shell session which had their write cap init, and they truncated off the right-hand side of the cap, intending to thus preserve confidentiality of their data. Unfortunately for them, the right-hand side of the (current) write cap format is the integrity-checking bits, not the write-authority bits! The remaining left-hand-side of the cap that they sent was enough to let us (or anyone else who saw their mail) read and overwrite all of their files. This wouldn't have happened if the cap had been a compact thing with no visible separations, like "lafs:WD1WDDy975ZJkrU7XZTxAB39kmnfxYk3zDb", or if it had been ordered so that the most powerful bits were right-most.
    240240 * provide for verifycaps, repaircaps, and traversalcaps (#308, #217).
    241241   Repaircaps in particular may require a grant of storage authority, which
     
    251251   ciphertext. It should be possible to upload ciphertext directly.
    252252 * provide for a grid-identifier, possibly on the MSB end, e.g.
    253    {{{tahoe://grid1234/IR/cryptobits}}}. Perhaps let some contexts define a
    254    "default grid id", such that {{{tahoe://IR/cryptobits}}} is expanded to
    255    mean {{{tahoe://grid1234/IR/cryptobits}}}. Something like
    256    {{{tahoe://grid1234/D/MR/cryptobits}}} should reference
    257    {{{tahoe://grid1234/MR/cryptobits}}}. (#403)
     253   {{{lafs://grid1234/IR/cryptobits}}}. Perhaps let some contexts define a
     254   "default grid id", such that {{{lafs://IR/cryptobits}}} is expanded to
     255   mean {{{lafs://grid1234/IR/cryptobits}}}. Something like
     256   {{{lafs://grid1234/D/MR/cryptobits}}} should reference
     257   {{{lafs://grid1234/MR/cryptobits}}}. (#403)
    258258 * permit multiple encodings of the same file (same k, different N) to use
    259259   each other's shares (#678, #711)