Security: prevent attacker from viewing self-destructing data, then simply recreating it

[elimisteve]

Simplest (and probably best) way would be: record the "recipient" miniLock IDs in the DB, and don't let something new get added for, say, 30 days.

Then, when the attacker tries to recreate the data they've just seen, they should get a 409 Conflict error back. And when the intended recipient clicks on the intercepted link, they should get a 404, at which point they'll know something's up (unless the attacker views it right before it expires... maybe the server should say how long ago a share was viewed? and say whether it was viewed then deleted, or whether it expired?).

(This kind of ruins the idea of someone having a sort of "inbox" that others can add multiple things to, but zero people are using it for this anyway; all current use cases are one-off.)

...or, maybe this just becomes the default use case, and when the first thing (ever?) is added to an "inbox" (by recipient miniLock ID), an optional header could be added that tells the server that this is a persistent/long-term identity/keypair/inbox that it's OK to store multiple files from since in that case, no one is sending links around inviting other people to view their own inboxes? This sounds right.