Hacker News Reader

Comment by dinkleberg | Hacker News Reader

I know every use case is different, so this may not matter for most. But in my experience, the performance of B2 was quite poor in comparison to other S3 compatible options. It seemed like the crux of the issue was slowness in their API. Generating pre-signed URLs for file upload or download was quite a bit slower, resulting in a poor user experience in my application.

If you're just using it to upload public static content for your site, this shouldn't be an issue. But if you're dealing with private content it probably isn't the optimal solution.

View on HN

> Generating pre-signed URLs for file upload or download was quite a bit slower,

I'd be shocked if generating pre-signed URLs required talking to the Backblaze server, that should be something done totally in client code.

However, even with AWS S3, I discovered that the official AWS ruby SDK client was much slower that it could/should be at generating pre-signed URLs (and even just public URLs!), and was able to write my own ruby code to be significantly faster.

https://github.com/jrochkind/faster_s3_url

I'm curious for the specifics on what code you were using to generate pre-signed URLs for file upload or download with backblaze, and what you are comparing it to when you say it's a lot slower. It could be un-optimized code, but whose "fault" it is depends on what code it is, open source etc.

I would love to hear more. I had a gig where we considered S3 and B2 for serving very private files (financial records). With B2 I could not find a good way to ensure that, assuming the URL is known, a file could only be accessed by an authorized party.

I am in the same boat currently in my research. In fact I posted this gist link we are discussing. My use case is confidential data and this solution won’t work if I can’t guarantee access is limited to specific users around the country.

Is free, secure, and fast to much to ask? Joking of course.

Is it not possible to just store it encrypted and then have your service give out the decryption key to authorized users?

Great idea, I just need to move my thought of encryption on the sending client to encryption on the destination server since this is infosec related and sending client could be compromised. Thanks for the help!

This is a terrific idea, thank you.

I would love to hear some of the implications of this approach. I can already think that the attacker would know the size of the file, so that might give him information regarding e.g. the file type. It might be of interest to an attacker to know that most clients get files of a specific size, but a certain client gets a file that is much much larger.

I wonder what other implications might there be.

You can set the bucket as allPrivate, then use the API to generate a presigned url for the file that you need.

That URL is susceptible to being intercepted in transit, though, such as in an email. And validating the request via a redirect on my own server invalidates 2/3 of the reasons for using an external file host.

How would this be different with S3?

You can go wild with S3 ACLs, including limiting by IP.

Reply on news.ycombinator.com