When the power is required by the motherboard, it can size its on-board power converter to suit its needs, allowing the on-board conversion to operate near the peak efficiency of the selected converter (i.e. high in its power band). Conversely, when done in the power supply, the rails must be over-sized, and so spend most of their time operating in their less-efficient low-power regime.

Entirely reasonable choice, particularly given the topic at hand.

Not sure I follow -- there is a plugin that allows KeePass to be used in e.g. Chrome, and there's no reason it couldn't exhibit similar or other security flaws. And if users choose not to use that or any other browser plugin, then it returns to the security vs convenience matter I brought up.

Right, so, based on my understanding, this flaw had absolutely nothing to do with the password database being stored in the cloud (which, for all providers worth their salt, is encrypted client-side); it had to do with the browser extension that provided access to the password database in order to use the passwords. A home server or offline file store as a password database would not have mitigated this security flaw.

Whether browser extensions for filling passwords is a good idea or not is an entirely different discussion, and comes down to convenience vs security, as well as user psychology (as in people won't use password managers at all if they are too much of a hassle, and as a result fall back on poor password practices so that they can actually remember them).

Because an animal didn't have to suffer to bring it to you, and because the net energy consumption is lower.

In our (small) organization, Slack has completely supplanted internal email. Sure, there are some channels for idle chit-chat that really don't need persistent history, but most private conversations and many technical-oriented channels need their full history.

Your use-case is not the only one.

Now you have: via Electrek.

Reportedly this is true. See here.

Tesla isn't a car company though; it's an energy company that also sells cars.

If they control all packets to and from the domain for all users, then they effectively control the domain. If they only control packets to and from the domain for a small subset of users that does not include LetsEncrypt (an assumption of the security model, and why LE likely uses several distributed servers), then they cannot successfully obtain a certificate.

Also keep in mind what an LE certificate actual says: https://en.wikipedia.org/wiki/...

If the attacker controls the domain, then the certificate is valid.

This is one of the reasons I use a separate DNS provider.

I was referring to MITM attacks on the certification process itself.

For an attacker to initiate the process and successfully complete the validation, they would either need control of the server (or be able to impersonate it), or control of the authoritative DNS records. In either case, the certification is logged publicly by LE. In the former case, you point your DNS somewhere else and generate new certificates. In the latter case, the "attacker" actually does control the hostname*, so the certification is valid.

* The assumption here is that it would be difficult to MITM LE themselves when doing authoritative DNS lookups. Presumably LE uses distributed servers to make this very difficult, but I haven't looked into it.

Not quite -- the client generated a private-public key pair when it first contacted LE, communications between the client and LE are encrypted, and the client answering the challenge is required to sign a nonce provided by LE using their private key. The MITM near the server side of the connection does not have the private key, and so cannot read what the challenge value should be, and cannot sign the nonce.

Trust whom, the site owner? LE? Their CA? If you don't trust root CA, then you are SOL. Better unplug your computer. Otherwise, there's your trust chain: root CA vets LE to a level sufficient to grant them an issuing certificate, LE vets the site owner to a level sufficient to grant them a hostname certificate.

Ownership of what, the hostname? The client requesting the certificate has to satisfy a challenge, for example placing a file with specific contents at a specific location controlled by the hostname, or populating a specific DNS record with a specific value for that hostname's zone. If the client is able to satisfy those challenges, then it already has complete control over the hostname and the content it serves.

If you aren't willing to engage in a discussion about public keys and cryptographic signatures, there's no way to answer this question for you. The cryptography is how the process is secured, and the public key nature (combined with satisfying the challenge above) is how the CA establishes trust.