Right, but that doesn't compromise the security of the service necessarily.
Users can catch a malicious server injecting incorrect keys by looking at security notifications and comparing security codes. This is part of the Signal protocol.
This may be tedious but only needs to be done in the event of phone keys getting reset (a once in a year event?), as all companion device keys are automatically verified with signatures provided from an account owner's primary (phone) device
For me their actions speak volumes. But if you want sources, here's Craig Federighi, Senior VP of software, literally yesterday:
"It [privacy] is a value that is so deep in us. Personal information can be used and abused and even weaponized in ways that can be really, really destructive. Often in a way that's not at all apparent to the person who might be giving up that information." and "These devices are so intimately a part of our lives and contain so much of what we're thinking and where we've been and who we've been with that users deserve and need control of that information. Abuse ranges from creepy to dangerous".
He says more about privacy in that same interview, recommended listen.
Reminds me of the "We value your privacy" pop-ups Google keeps popping up. A for-profit company will say anything that it believes is profitable. PR statements like the one you quoted convey no information.
Would e2ee really be guaranteed if a user sets an 8 char password? Because if so an attacker with control of the server could brute forcedly decrypt the encryption key, and in turn all DB contents for a user, no?
Apologies if this is covered somewhere in the docs, but I couldn’t find it.
We use scrypt for password hashing. From the scrypt paper (which keep in mind is assuming hardware from 2002, and isn't assuming an attacker is using ASICs which have been developed since then), the estimated cost of hardware to brute force guess an 8 char password in 1 year is $4.8 million with our chosen parameters. [1]
Ultimately we strongly recommend that developers using the end-to-end encryption mode of Userbase recommend their users use a password manager, since losing their password means losing their data (and we try to make this extremely clear to any developers using Userbase via the admin panel and docs). A password manager randomly generating passwords makes this a non-issue.
But alas, we do recognize not everyone will, which is where scrypt comes in to play.
From the scrypt paper (which keep in mind is assuming hardware from 2002, and isn't assuming an attacker is using ASICs which have been developed since then)
Just to be clear, the scrypt paper assumes attackers use ASICs fabricated with 2002-era technology. Obviously there weren't any scrypt ASICs in 2002; but I was able to estimate what their performance and cost would have been.
> Discord is a close second. But the quality and polish of telegram blows me away to this day.
User experience is, well, subjective to the user. For tech savvy, primarily desktop users, Telegram and Discord can be great choices.
This is however probably not true for the majority of the population.