4 ms·
For this I created a public Backblaze bucket, created a lifecycle rule that deletes files after 7 days, created an application key with write privileges but not
by renonce 3y ago
For this I created a public Backblaze bucket, created a lifecycle rule that deletes files after 7 days, created an application key with write privileges but not read ones, then wrote a script that uploads an arbitrary file under a random name so only people with the name will be able to download or overwrite it. The best part is that the file is available under an HTTP direct link, not behind an obscure webpage with ads, so it’s easy to deal with with any tool and doesn’t require the other end to install WhatsApp or Telegram etc, and there is no file size limit (you pay $1.5/TB but it’s fairly cheap if you deal mostly with files <1GB). Now I just wish I could write such a script for my mobile phone as easily.
Now this violates rule #1 (you need an account and you need to pay $6/TB/month for files stored, or $1.5/TB if you store files for only 7 days). For rule #4 you can set the lifecycle arbitrarily, like 1 day, such that the cost of storage is less than the cost of traffic.
- coin 3y agoHow can you be sure the underlying storage provider actually deleted the file?
- metadaddy 3y agoNo need to give your file an obscure name, or use a public bucket. You can use a private bucket and create a presigned URL with an expiration of up to one week.
- renonce 3y agoPresigned URLs are long and ugly and b2 requires an extra API call to generate that, so I tend to prefer not to use them. The other reason for obscure names is so that you can't download or update files that you don't know the name even if you have the upload key. I know it goes against common sense security practice but compromising convenience can mean compromising security in many cases. The thing is to make sure your scheme is rigourous.