[vladikoff]

> I really don't know why Mozilla implemented it this way and login UI is not a part of the browser itself.

How does making the login part of UI help, would you blindly trust part of native UI instead?

the password is secured with JS locally on the client and you can clearly and easily inspect all the requests that firefox makes via dev tools.

[drdaeman]

Why blindly? I can audit the browser's code, lock the updates and know it's reasonably secure against this kind of attack.

With the current implementation, with the page served from the network, there's no reasonable way to check that I'm not suddenly served with something malicious. I mean, I could be served a different page next time.

Well, of course, to be precise, after auditing the in-browser login dialog code I would also have to check the XUL and JS engines that it's using, the compiler that was used to produce Firefox, the system libraries, kernel, firmware and CPU microcode and so on. But that's another story.

[tokenizerrr]

Well, you could run a proxy locally, force all traffic through that and serve your own version of the page.

[drdaeman]

It's using HTTPS - and while I haven't actually tried to MitM it, I suspect that since it's served from Mozilla domain, the certificate must be pinned.

But you're right - it may be not simple to do (or maybe I'm mistaken here) but it's certainly possible (Firefox is FOSS, so as a last resort measure it can be modified to ignore any pins). Thanks for the suggestion.

[tokenizerrr]

Browsers allow you to override pinned certificates with locally installed ones.

[wtbob]

> How does making the login part of UI help, would you blindly trust part of native UI instead?

Because Mozilla can — and can be compelled to — alter the UI they serve at any time, while your browser UI is static and can be verified.

The current design is horribly, horribly untrustworthy. One simply cannot rely on Mozilla to stay honest; any government it is subject to may force it to snoop your password.