Essentially Google know more about the state of a website than a user can learn from the domain alone, and they should display that to the user. Once that's happening the various parts of the domain are less important. The downside of this is that it increases Chrome users reliance on Google.

Paypal has good SEO, but not every shopping cart does, and its not like Google are manually vetting the content like AOL keywords did...

I'm not in a position to actually do it though, and Google are (for themselves, without sharing the API), so for now that's the best we've got. Maybe someone who has the resources to compete with Google will step up.

and how is a user supposed to know who to trust for this information, if there are multiple sources?

At the root, the problem is one of verification - that who you are communicating with is who they claim to be. At some level, there needs to be trust in one entity as a definitive source (that the site you're looking at is indeed created by the business that the site is claiming to be representing). There has to be some level of trust somewhere...

They could choose the provider they trust most. Which, for the majority, would probably be Google.

Certificates weren't expensive before Let's Encrypt, several outfits offered free certificates, especially on a "trial" basis that would be adequate for criminals even if it was largely useless to legitimate users.

But expensive certificate were, and still are, available to those with the Apple mindset. DigiCert will sell you a certificate for $218. Lasts 12 months.

And you're probably thinking: Right, that's a _proper_ certificate, that'll assure me of who bought it, and it comes with true security and all this amazing stuff. Nope, that's the same DV assurance that Let's Encrypt gives away, except DigiCert gets $218 of your money, and why not?

If there's a guy wants to buy one glass of water from me for $100 who am I to insist drinking water is free?

Anyway, no, certificates did not require "proof of identity" prior to Let's Encrypt, in fact back then they only required that the CA use "Any other method" a term of art in the rules that meant the CA could use its own best judgement (perhaps clouded by commercial considerations) to decide what was enough to be sure you controlled example.com before issuing you an example.com certificate.

_After_ Let's Encrypt, and with substantial input _from_ key Let's Encrypt people this was reformed to the Ten Blessed Methods (there are not actually ten of them today, but I like that name and it seems to have stuck) in which there are explicit methods defined for how a CA must check that you control the DNS names you want certificates for.

You are living in an all too common fantasy world. A world where you needlessly spend more money to achieve less security because you don't want to be confronted with facts.

Who's the "they" in that sentence? As it stands, a certificate reseller knows that the Paypal account "[email protected]" paid for a SSL certificate for "www.unrelatedcompany.TLD"

The certificate itself tells you nothing about who paid for it - it doesn't even tell you which email account was used to confirm some level of association with the unrelatedcompany.TLD domain.

Q2: Can't the bad guys just buy a pre-paid debit card with cash if they're that desperate to cover their tracks?

Paypal.com vs random-Name.com: much easier to distinguish.