#2084 new enhancement

Commercial grids need an ability to disallow downloads without deleting data

Reported by: esnyder Owned by: daira
Priority: normal Milestone: undecided
Component: unknown Version: 1.10.0
Keywords: accounting revocation Cc:
Launchpad Bug:


If you are buying space on a grid, the grid operator presumably wants some way to suspend your ability to download data in the event that you stop paying your bills.

Definitely don't want to delete all the data though; once you pay your bill you should be able to pick up where you left off.

So, need a separate "download authorization" scheme which can be suspended or revoked by the server.

Change History (4)

comment:1 follow-up: Changed at 2013-09-17T19:08:27Z by zooko

I wish there were a "+1"/"LIKE"/"me too"/"☺"/"❤" button on trac to show that I like a ticket.

comment:2 in reply to: ↑ 1 Changed at 2013-09-18T01:09:06Z by daira

Replying to zooko:

I wish there were a "+1"/"LIKE"/"me too"/"☺"/"❤" button on trac to show that I like a ticket.

Think of it as a feature: doing it manually shows a bit of personality in which of those you choose ;-) Likes are boring.

comment:3 Changed at 2019-05-30T16:30:25Z by exarkun

I had some thoughts related to this but they outgrew this ticket so I posted them to tahoe-dev instead: https://tahoe-lafs.org/pipermail/tahoe-dev/2019-May/009947.html

comment:4 Changed at 2019-07-03T14:47:04Z by exarkun

So, trying to tie some of those thoughts back into this use-case...

_If_ you have an access control system which can prevent arbitrary lease renewal then you can lean on lease expiration to disallow downloads.

You don't even need to turn on the garbage collector in this case. The shares will remain stored but unreadable. You can authorize the renew lease operation based on your payment processing system to restore access to affected shares to users who pay their bill.

If you _also_ want to be able to eventually garbage collect something then you do need some kind of two-tiered share expiration system. You have some period of time when the share is retained and access is allowed. Then you have some period of time when the share is retained and access is denied. Then you have a point in time when the share becomes fair game for garbage collection.

You could define these periods in terms of intervals. If a lease lasts 31 days then perhaps a "storage grace period" extends for another 31 days beyond the end of the lease. Then 62 days after a lease is taken on a share, the garbage collect may delete the data.

Tahoe-LAFS already has a configuration option which can probably be (ab)used to provide part of what's required here:

expire.enabled = true
expire.mode = age
expire.override_lease_duration = 62days

With this configuration, a storage server will not consider garbage collecting shares until the associated lease is at least 62 days old. With an access control system (https://tahoe-lafs.org/trac/tahoe-lafs/milestone/storage%20economics%20plugins) that is separately configurable and enforces denial of operations (except for lease renewal) when the lease is older than some smaller age, the desired behavior is achieved.

This might look like:

plugins = tahoelafs-simplepaymentsauthorizerexample-v1

expire.lease_duration_for_access = 31days


Thus, access is allowed for 31 days after a lease is added or renewed but the share is retained for 62 days after a lease is added or renewed.

Note: See TracTickets for help on using tickets.