3 ms·

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 compat

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.

dotancohen 5y ago
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.
- frogger8 5y ago
  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.
  - charcircuit 5y ago
    Is it not possible to just store it encrypted and then have your service give out the decryption key to authorized users?
    - frogger8 5y ago
      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!
    - dotancohen 5y ago
      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.
- poxrud 5y ago
  You can set the bucket as allPrivate, then use the API to generate a presigned url for the file that you need.
  - dotancohen 5y ago
    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.
    - poxrud 5y ago
      How would this be different with S3?
      - sofixa 5y ago
        You can go wild with S3 ACLs, including limiting by IP.
jrochkind1 5y ago
> 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 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.

dotancohen 5y ago

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.

frogger8 5y ago
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.
- charcircuit 5y ago
  Is it not possible to just store it encrypted and then have your service give out the decryption key to authorized users?
  - frogger8 5y ago
    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!
  - dotancohen 5y ago
    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.
poxrud 5y ago
You can set the bucket as allPrivate, then use the API to generate a presigned url for the file that you need.
- dotancohen 5y ago
  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.
  - poxrud 5y ago
    How would this be different with S3?
    - sofixa 5y ago
      You can go wild with S3 ACLs, including limiting by IP.

jrochkind1 5y ago

> 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 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.