A: Hi, Thanks for the question.

>>>> - When will Drive go live? I understand it will be available for tiers 3,4, and 5 according to your answer below.

Yes, 3,4,5 will have Blaze drive, same amount as the LTS.

>>>> - Will the APIs be available for all tiers?

Blaze API will not be available for general purpose use. We will add cusotm Form feature, that can be embedded in user’s website. Form submit and get AP endpoints will be made available.

>>>>>- You previously said you'd post a blog post explaining Blaze security, but I just checked and can't find what I'm looking for. I assume you're busy with all the upcoming updates, so I'll just ask here.

When a file is uploaded I see the link contains the secret key. However, the file and the link are stored on the platform and are always accessible whenever I need them. Since you have access to the link, which contains the secret key, does this mean you have access to our files? I also tried sending a file to Google Drive, the file was sent without asking me the secret key to decrypt the file before sending it, which also implies you have access to keys. I figured one way to keep the keys secure was to encrypt them with my public key, then use my private key to decrypt the keys when needed. However, I'm not providing my private key at any point, which made me think it might be a function of my password. I then changed my password, and the files were still accessible. Am I missing something?

When you upload a file as a link, it;’s meant for users who do not have Blaze accounts (free or paid). For then to be able to read the file, the sender needs to share the link which includes a secret, that will be used to derive key, which is used to decrypt the file. That’s why we ask the sender to use his/her own tools to share the link with the recipients. This feature is for better user experience. When you share files with a Blaze user, no secrets are exposed to any parties, all handled by Blaze infrastructure.

When A Blaze account is created, a set of private and public keys are created, and the private keys are encrypted on the client side using the key generated from the password of the user. This password is never saved in the database, only a digested version is saved. After login, We Blaze decrypts prepare all necessary params, secret keys, private keys etc, that needs to be decrypted using the keys that requires the password for decryption. It’s like a Russian doll, I guess. A bit complex to explain in short text. We will detail in a blog, hopefully soon.

The data you send/store is encrypted using AES265 key, and these keys are shared between sender and receiver through public key encryption. The sender encrypts the AES keys using the public key of the receiver and the receiver decrypts the key using his/her private key. Once both parties have the unencrypted AES key on the client side, the shared data can be encrypted and decrypted on their client sides. It’s a bit simplified explanation.

When you copy a file from Blaze to Google drive/One drive, the encrypted data is loaded in the Blaze app, decrypted using the AES key (that are stored in the database as well), and the decrypted data is streamed to google drive/onedrive.

When a user changes his/her password, Blaze client decrypts existing data using keys derived from the password, and re-encrypt the keys with the keys derived from the new password. When password is lost/forgotten, user need to have the QRCode that's downloaded during signup. Otherwise, all data to that point cannot decrypted.

In short, Blaze database does not have visibility on the user secrets and data, all information (including keys) are encrypted/decrypted on the client side.