I might be wrong, but it seems to me that the encryption key for the file is the truncated SHA256 hash of the file itself. This is not how you want to generate an encryption key.

Edit: also, password protection is enforced server side, and has nothing to do with encryption

The key is the truncated hash of the file for the purpose of file deduplication. However, it will not impose any security risks as the person who wishes to decrypt it would have to know the hash of the file which requires them to already know the contents of the file making it useless.

The password encryption is indeed server-side, but it is mainly there to protect the file against anyone who somehow finds/guesses the URL and it's a useful feature if you want to slightly increase the level of security without encrypting the file with AES.

> would have to know the hash of the file which requires them to already know the contents of the file

That is incorrect. Knowing the hash does not mean you know the contents of the file. You should generate encryption keys randomly, preferably using a secure random method such as that shipped with SJCL, rather than JavaScript's random API.

Unfortunately it's required for the file deduplication. Although it slightly degrades the security it's not serious enough to impose any security risks as the attacker would already have to know the hash of the file which almost always requires them to know the contents of the files.

Random strings and numbers are also securely generated through a CSRPNG with window.crypto.getRandomValues().

I have a neat idea: someone should implement a VPN-over-"video", so that all traffic (or at least server to phone) is not counted against data caps.

Doesn't sound too difficult, if you don't mind several second ping times.