> When Google's CAs start issuing certs to non-Google parties, we can revisit the 'eggs-in-basket' question.

I'm not really seeing the problem there, either. Unless we trust Google to do this less than we trust every other root CA. All evidence I've seen points to Google caring very much about internet security.

  I don't think this is a bad thing. ... This ought
  not be surprising: presumably, who better to say
  that Google is indeed Google than Google itself?

The problem is that "connecting to a Google property" almost certainly includes their WiFi access points as well as other networking offerings. Which implies the ability to MiTM traffic encrypted from products not controlled by Google (other browsers, VPN clients, etc.).

As stated in this Stackoverflow response[0]:

  Especially #2 is rather nasty, even if you
  pay for a highly trusted certificate, your site
  will not be in any way locked to that
  certificate, you have to trust all CAs in the
  client's browser since any of them can generate
  a fake cert for your site that is just as valid.
  It also does not require access to either the
  server or the client.

I wouldn't be surprised if AMP is also in play for this type of MiTM, but do not know for certain. Android native apps, however, are definitely poised to be compromised.

0 - http://stackoverflow.com/a/14907718

Google engineers have been very heavily involved in the CA/Browser Forum (https://cabforum.org), which sets issuance and trust rules for CAs. One of the things the CAB Forum is currently debating is a set of requirements mandating certificate transparency (CT) and obeying certificate authority authorization (CAA) records in DNS.

If implemented for all of these roots (and I don't see why they wouldn't, given their push on it), CT would create an open, unalterable record of every cert published from all of these roots and their subordinates. CAA, as a complement, would create a method by which you as a domain owner could control which CAs are allowed to issue certs for your domain, removing the ability to man-in-the-middle your domain without your permission.

The first step for both of these is making them mandatory for CAs (which Google is pushing hard on); once they're out there, it's possible to write plugins that will check CAA and CT records and fail closed if something looks wrong. It's a long way from perfect, but it's definitely a step in the right direction. Given Google's strong push for making those mandatory, I'm far more worried about a lot of the CAs already in my trust store than I am about these.

According to here[0], when you say:

  CT would create an open, unalterable record of
  every cert published from all of these roots
  and their subordinates.

That provides no substantiation for Google's push to be a Certificate Authority (CA). It arguably makes a case for Google to be a "Log Server" (which has its own troubling implications as that could then (now?) hook Google into the verification process of every certificate issued[1]). But absolutely nothing about CT needs/implies/warrants Google to become a CA.

  Given Google's strong push for making those
  mandatory, I'm far more worried about a lot
  of the CAs already in my trust store than I
  am about these.

The very authority to which you are appealing is precisely the one which is suspect.

0 - https://www.certificate-transparency.org/how-ct-works

1 - From [0]:

  During the TLS handshake, the TLS client receives
  the SSL certificate and the certificate’s SCT.
  As usual, the TLS client validates the certificate
  and its signature chain. In addition, the TLS
  client validates the log’s signature on the SCT ...

For CAA to work, we need fully deployed DNSSEC. Not just the roots, and some resolver, but all local clients too. Otherwise, there's still weak links in the chain.

But that is just it... "when" is not "if" here. There is a "when" it happens, and then a "when" we find out at some later point. Neither of those are reasonable "ifs".

There will be tremendous pressure on them to do it for certain parties, or have it done on their behalf unwillingly, or possibly unknowingly.

> I don't think this is a bad thing. Instead of a third-party you trust (or rather, your user-agent trusts) vouching that Google's indeed Google, it's now Google vouching for itself, and you trust them by the virtue that they're Google.

I'ts like a self signed certificate.

If you trust Google that is. The independent third party no longer exist.

> fairly easy to verify that they're indeed Google, considering they just published their public keys on their own website

This doesn't prove anything, unless you already trust another CA which can vouch that you're looking at Google's site in the first place. Or by some sort of consensus with other people that you see the same key.