search

Upload / Up1

Client-side encrypted image host web server
MIT License
813 stars 97 forks source link

Option to delete file at first view #58

Open ipatjolvur opened 8 years ago

ipatjolvur commented 8 years ago

Enhancement request: Offer a checkbox on the upload page to delete the file when it is first accessed.

For an open source example, see lutim or ZeroBin: https://github.com/ldidry/lutim https://lut.im

https://github.com/sebsauvage/ZeroBin http://sebsauvage.net/paste/ http://sebsauvage.net/wiki/doku.php?id=php:zerobin

BetterToAutomateTheWorld commented 8 years ago

Hi,

I think your proposal is linked with the issue about file expiration https://github.com/Upload/Up1/issues/19

In my point of view Zerobin is a great example of "burn after reading" and "delete after x time" files

k3d3 commented 7 years ago

One potential solution to this problem is to bundle the deletion key with the file metadata. That way, we can change the client to automatically delete images when it sees that key.

The benefit to this solution is that it requires no changes to the server. The drawback is, obviously, it's up to the client to ACTUALLY do the deletion, and therefore with modified code, the client could forego this deletion.

The other solution is to somehow tag the file in a way that the server can see it. This could be something as simple as a JSON file that sits alongside the encrypted data. That metadata could contain a tag stating the file is to be deleted on first access, or that any access after some time should be rejected (and then deleted) in the case of file expiration in #19. (The latter has an even better solution of a file deletion time being specified in a cron or other exact timing system, so it doesn't stay around on the server past the expiration date).

The benefit to this solution is that the one-time view is enforced by the server, so it isn't up to the client to be trusted. The drawback is that we would no longer have the flexibility to host the files on any server (currently they're handled directly through nginx as static files, but they could currently just as easily be hosted through Apache or some other webserver, and even thrown onto things like glusterfs or IPFS). The files would have to be served by the node.js server or through some other custom server.

As a stop-gap method, we could probably implement the first solution relatively quickly and easily, but I'm hesitant on being required to support the second solution because the flexibility of hosting is lost. Perhaps if that option could be put behind a server-side flag or something, that would be a good middle ground. Allow people to still host files in super-replicated or custom ways, with the understanding that some features such as file expiration and one-time views can't be reliably supported. Alternatively, support file expiry and one-time deletion with the understanding that it has to be done through a custom server.