Historically, all data was encrypted locally before being sent to the other device. Now, by default, some data will be local-only encrypted, and some won't (the motivation being recovery services). There are plans though to have an option to locally encrypt all data.
https://wiki.mozilla.org/Identity/AttachedServices/Architect...
If it's a username/password pair, either the data has to be stored in plaintext, or with a key escrowed using the user password, which are not as secure as a private key only known to the user.
No, you can use a different system: don't send the password to the server, instead create a private/public key pair from the password (deterministically) and send only the public key to the server.
When you want to authenticate, just have the client sign something with the private key. If you want to encrypt on the client, it can just do PGP-like encryption (encrypt data with random AES key, encrypt that key with public key, send all to the server).
Considering the average user's password choice tendencies, that's still weaker than a key from a proper source of entropy, then password reuse on top of that.
That plus IIRC, RSA isn't deterministic even with the same seed. Not sure about generators for elliptic curve though.
Not true, there are plenty of key-derivation schemes. Basic idea for how one may work (not necessarily the one they will use, I'm still reading the wiki pages): data is encrypted locally with a hash of the user's passphrase, then that hash is hashed again and sent to the server as a login credential. The server never sees the original passphrase, nor the encryption key, nor the contents of the material uploaded.