Did you read the article? The system is designed so that an authentication token is derived from the password, and this token, rather than the password itself, is authenticated against on the server. Since the encryption key can not be derived from the authentication token, this shields the content of the encrypted data the server stores from itself.
GP rightly noted that deriving the authentication token with code served by the server at log-in time renders most of the security architecture of the system rather moot, unless user has the time to verify the JavaScript they are served every time they log in.
There's actually a great difference, because for binary distribution it simply suffices that the user verify the cryptographic hash of the binary they downloaded. Then they can be confident that they were served the correct publicly distributed binary, and not a subverted version.
JavaScript by its very nature can not be easily, if at all, verified. Even if you verify that you are being served the same code as other users and the code is not subverted at one point in time, it's very much expected that the code may change at any time at the web developer's discretion. This is also probably the very reason why Mozilla implemented it like this (so that they can update the Sync experience branding without updating the browser.)
Even if you hard-coded the signature of the JavaScript library file responsible for the cryptographic operations in the binary, browser DOM by itself would require modifications so that any other UI logic script in the page would not be able to sniff your password as you enter it..
> JavaScript by its very nature can not be easily, if at all, verified.
Yes it can, in the same way you mentioned in your previous paragraph. Mozilla post the hash of the JS source file, and any user who wants to can verify the hash of the source file they have can do so in exactly the same way they verify a binary. It's literally calling sha1sum on the js file isntead of the binary.
> This is also probably the very reason why Mozilla implemented it like this (so that they can update the Sync experience branding without updating the browser.)
I'd partially agree here - it's implemented like this so that they can update sync without updating the browser. If there's an issue found, mozilla can fix it, change the JS that is being served, and update the hash of the file. Sync branding (to me) has nothing to do with it.
> Even if you hard-coded the signature of the JavaScript library file responsible for the cryptographic operations in the binary, browser DOM by itself would require modifications so that any other UI logic script in the page would not be able to sniff your password as you enter it..
Yes, but this is moving the goalposts from the user verifying the js. This is true whether the code is in the binary or not. If the code goes in the binary, and is shown as part of the DOM, you need to modify the DOM logic to ensure nothing else can see it.
GP rightly noted that deriving the authentication token with code served by the server at log-in time renders most of the security architecture of the system rather moot, unless user has the time to verify the JavaScript they are served every time they log in.