| 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 left-most <-(right-most? -zancas). |
| | 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. |
