End-to-end using server provided javascript code means that the code can be changed on the fly per user to enable lawful intercept. Plausible deniability only works if the client is encrypting the payload entirely independent of the provider. That would require the end user to be compelled directly and javascript would not be required.
So you're running a local encryption library or app (not relying on server side JS code).
Do you disable auto-update, and risk running a broken version of the encryption library or software, or do you enable auto-update and risk a remote backdoor injection via the auto update?
I disable auto-update and get my software from a computer not associated with me. I compare checksums to copies that friends have and checksums on virustotal.
For linux software, I validate GPG checks of individual packages and of the rpm repo. Both packages and metadata are signed. I get the public key from a non mirror site and compare to keys listed by others.
This does not preclude back-doors, but it means that everyone has the same backdoor as me. I then mitigate dial-home of said programs with firewall rules and selinux. If there is a hard-coded key, it will also affect all the companies and governments using the same software.
