<div dir="ltr"><div>I was cruising the issue tracker for related ideas and I found <a href="https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2084">https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2084</a>.  At first I thought to leave some comments there tying that issue into this bigger picture but the bigger picture somewhat overwhelms the specific use-case described in that ticket.  So I'm going to put the comment here, instead.</div><div><br></div>I think there is a lot hiding behind this seemingly simple feature.<br><br>Perhaps foremost, currently, a commercial grid operator effectively has no way to refuse service to any user under any circumstances.  A user who has learned a storage server fURL can use that storage server in any way the storage server supports: create new immutable shares and mutable slots, read existing immutable shares and mutable slots, and add or renew leases on existing immutable shares and mutable slots.  A commercial grid operator may want to deny more of these than just reading existing shares and slots.<br><br>The only technical measure currently available is for server operators to rotate their introducer and/or storage server fURLs and distribute the new capabilities to all *other* users.  For any non-trivial grid I suspect this is not feasible, even if we were to build automation supporting it into Tahoe-LAFS itself (introducer fURLs are currently distributed to users "out of band").<br><br>To overcome this, there must be some way of denying some access to some users when some condition arises.<br><br>One solution is "accounting" along the lines of the traditional (at least in computing) definition of that word: every user has credentials by which they identify themselves to the grid and then an authorization decision can be made.  For example, the identity may be checked against a payments database to determine if it is associated with a paid-up account.  There are many tickets (<a href="https://tahoe-lafs.org/trac/tahoe-lafs/query?status=!closed&keywords=~accounting&order=priority">https://tahoe-lafs.org/trac/tahoe-lafs/query?status=!closed&keywords=~accounting&order=priority</a>) in this issue tracker that discuss the nuances of this approach.  In this system, read (and all other operations) are denied on the basis of the identity not being associated with a paid-up account and the use-case is achieved.<br><br>This has the downside of requiring an identity system and reduces some of the current privacy properties of Tahoe-LAFS (every share can now be associated with an identity, shares can be linked to each other, connections can be made between identities based on common shares interacted with).<div><br></div><div>It has upsides, too.  They mostly follow directly from the downsides.  For example, linking shares to an identity enables you to measure per-user usage, impose quotas, and to immediately wipe all data belonging to a particular user.</div><div><div><br></div><div>A different solution is "micropayments" where operations are authorized by the presentation of a value-carrying token.  An operation is allowed if a valid token (of sufficient value) is presented and denied otherwise.  For example, a Zatoshi might be sent along with each operation (technical details of how you send a Zatoshi are deliberately ignored here).  Read (and all other operations) are denied if insufficient value is sent in the request and the use-case is achieved.<br><br>This *potentially* has the upside of preserving the privacy properties that "accounting" removes (if you have a privacy-preserving cryptocurrency).  It has the downside that Blockchain-based cryptocurrencies have a transaction settlement period that is much longer than the desired execution time of most Tahoe-LAFS operations (reads and writes want to complete on the order of milliseconds if not better; Bitcoin settlement period averages 10 - 60 minutes, perhaps a million times longer; Zcash is faster but not *that* much faster) and transaction fees are also much higher than the likely value of these transactions.  Lightning / Bolt might help eventually but these are still fairly young systems and come with an additional layer of complexity on top of merely using a Blockchain-based cryptocurrency.<br><br>One step <i>towards</i> Blockchain-based cryptocurrencies for micropayments is to use an earlier, simpler form of cryptocurrency - eg, something derived from Chaum's DigiCash.  It turns out that PrivacyPass (<a href="https://privacypass.github.io/">https://privacypass.github.io/</a>) has much in common with DigiCash while updating a number of the cryptographic primitives to more recent constructions with nicer properties than the original.  With such a system, clients would send along one or more tokens with each request and the request would be satisfied if the value of the tokens covered the cost of the operation.</div><div><br>The upside of such a DigiCash/PrivacyPass-based system is that the settlement period is basically as fast as you can make it (verify a signature) while all of the current privacy properties of Tahoe-LAFS are kept intact.  The downside is that such systems rely on a "central bank" to issue tokens (and consequently the tokens are only of value to parties with a relationship to that central bank; the tokens are a kind of "company scrip").  This may not prove to be much of a downside for a Tahoe-LAFS commercial grid operator - who can act as that central bank for a token that carries value on their own grid (with which they have an obvious relationship).  And much of the groundwork to support this system would also be necessary to support Blockchain-based cryptocurrency micropayments systems or other cryptocurrency systems (perhaps a friendnet cryptocurrency where every storage server operator mints and distributes their own coins; meejah pointed out this was discussed as "storage clubs" at the 2016 summit, see <a href="https://tahoe-lafs.org/pipermail/tahoe-dev/2016-October/009805.html">https://tahoe-lafs.org/pipermail/tahoe-dev/2016-October/009805.html</a>).</div><div><br>In any micropayments system, the grid operator can make policy choices that fit their particular business.  They can charge for any or all of read, write, and lease extension operations.  For example, they may choose to make reads and writes free but lease extensions cost tokens.  This provides a rough approximation of a traditional subscription model - a user can purchase enough tokens to extend the lease on all their files one month and then enjoy a month of usage.  If they wish to continue the subscription, they just repeat this process.<br><br>Or to more directly achieve the particular use-case in the ticket description, they may choose to make reads and writes cost tokens.  In this case, once a user uses all of their existing tokens and chooses not to buy more, they are unable to read their data (but, perhaps usefully or interestingly, any users they have shared those shares with who continues to buy tokens can continue to use them).  This is precisely the described use-case.  Along with the right lease policy (perhaps leases are checked once a year for garbage collection) this can give some balance between data retention for returning customers and the need to clean up unused/unwanted/unpaid-for shares.<br></div></div><div><br></div><div>Jean-Paul</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 28, 2019 at 8:36 AM Jean-Paul Calderone <<a href="mailto:jean-paul%2Btahoe-dev@leastauthority.com">jean-paul+tahoe-dev@leastauthority.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><p>Dear Tahoe-LAFS community,</p><p>Over the years, we’ve discussed various approaches to accounting and grid access control. Our team is now interested in extending the Tahoe-LAFS protocol so as to provide more granular access-control to storage server resources. There are situations in which it might be desirable to limit access to particular users -- for example, to deny access to abusive users, or to require compensation to storage server operators before access is granted -- without inconveniencing (e.g., by requiring migration to a new set of storage fURLs) other users.</p><p>In our particular case -- supporting the PrivateStorage.io Tahoe-LAFS deployment -- we are interested in providing paid access to Tahoe-LAFS storage servers.  This implies the ability to revoke access to those servers when a user chooses to end their relationship with the service. We are interested in doing this in a way that improves Tahoe-LAFS for everyone and generally fits with the project's overall goals. We would like to work with you to be able to contribute this code back to the master Tahoe-LAFS branch.</p><p>We are operating with these requirements in mind:</p><ul><li><p>Preserve Tahoe's existing privacy properties: Unlinkability a) between individual shares, and b) between shares and the users that can read/write them -- in other words, minimize server-side tracking and metadata trails</p></li><li><p>Preserve Tahoe's existing use-cases (friendnets, etc.)</p></li><li><p>Create the ability to deny share read and write access per-storage server based to certain users.</p></li></ul><p>The approach we are most actively exploring now is to expand most of the storage server APIs that involve shares, perhaps starting with the lease management APIs add_lease and renew_lease, but not necessarily being limited to these. These would change to have one or more new optional parameters giving some value that proves a right to access. </p><p>The storage server would also be extended to support pluggable interpretation of these values, allowing policy to be set by the server operator. One such policy, likely the policy we will pursue, is to have a PrivacyPass-like token (<a href="https://privacypass.github.io/protocol/" target="_blank">https://privacypass.github.io/protocol/</a>) which can be issued upon receipt of payment (rather than completion of a CAPTCHA as is PrivacyPass' original intended use). (Credit to Str4d for suggesting this approach to Liz.) Other policies could include signed access tokens, shared secrets, cryptocurrency systems, and other sophisticated cryptographic protocols.</p><p>This approach is inspired and informed by many past discussions within the community about economic models for Tahoe-LAFS usage, too many to link to.</p><p>The questions we have for the Tahoe-LAFS community are:</p><ul><li><p>Would you be interested in having these changes roll into Tahoe-LAFS</p></li><li><p>Are there other approaches we should discuss in the community? </p></li><li><p>If you are a storage grid operator, would you use this? If so, how would you like to bill/charge users of grids (bandwidth? bytes-stored over time? access over time? etc.)? -- in other words, how could our implementation better-support your desired use-case?</p></li></ul>Thanks!<br>Jean-Paul</div>
</blockquote></div>