Yeah I doubt this. I don't know what exactly Google's PKI will be for but to me this seems like a close relative of Google Cloud (esp. DNS) and Google Domains. Also, similar infrastructure services from Google, like Google's public DNS resolver, show no signs of being turned down.
(Disclaimer: I am a Google employee, but I don't work on any of this.)
7.2 Deprecation Policy. Google will announce if it intends to
discontinue or make backwards incompatible changes to the
Services specified at the URL in the next sentence. Google
will use commercially reasonable efforts to continue to
operate those Services versions and features identified at
https://cloud.google.com/terms/deprecation without these
changes for at least one year after that announcement, unless
(as Google determines in its reasonable good faith judgment):
(i) required by law or third party relationship (including if there is a change in applicable law or relationship), or
(ii) doing so could create a security risk or substantial economic or material technical burden.
The above policy is the "Deprecation Policy."
If you click through to https://cloud.google.com/terms/deprecation you will see the covered services.
(Reasonable good faith is a legal term of art, so no, Google would not get away with whatever silly edge case people come up with)
This is the best guarantee any company ever gives.
For smaller companies if something becomes too expensive or hard, they just go out of business. For larger companies, they have to draw the line somewhere. You won't get stronger guarantees from anyone, that would be insane.
Google definitely has a history of turning down free services when they're proving unprofitable, but that's only free services. There's no history of Google turning down paid services without good notice that I know of.
Many of the products Google has already shut down would easily have passed a reasonable good faith judgement that they were too expensive to keep running. I don't see how this would be any different. I know that "reasonable good faith" is a legal term of art, and I'm saying that I don't think Google would struggle to meet that standard if they needed to shut one of these services down.
"Many of the products Google has already shut down would easily have passed a reasonable good faith judgement that they were too expensive to keep running."
That isn't the standard listed.
It's "substantial economic burden".
None of those services were a substantial economic burden for a many-billion dollar company, so sorry, but i completely disagree.
What does "protection" and "guarantee" really mean? If a dozen meteors simultaneously strike every Google datacenter and office location, would the products continue to live on, even in the face of every conceivable guarantee their leadership makes before the event?
Point being; the only guarantees that any consumers should hold companies accountable to is: Does the product make money, and is it parallel to their conceivable long-term vision? That's literally all that matters. That's the only data consumers can use to decide whether a product will still exist in 10 years.
Google Cloud is this. Its absolutely profitable. And cloud tech is so deep in their DNA, they're literally decades ahead of anyone else. They were running containers and clusterized homogeneous server resource pools 8 years before anyone else knew to call them that, its just taking them time to productize everything they use internally.
Trust money. Trust vision. Don't trust words. G-Suite, Cloud, and Domains are very safe products.
No, it wouldn't require them to keep it operating if all of Google was simultaneously destroyed by meteors. But it would probably allow lawsuits against Google if they didn't give the required advance notice merely due to a change in business strategy, without a sufficient reason.
Interestingly, AWS doesn't have that kind of guarantee, though they do have a long public cloud track record of not turning stuff down.
You make a lot of additional good points about why these Google products are safe.
I'm not convinced I'd put Domains in that list, and for G Suite and GCP I'd only put the core services (G Suite jargon) and GA offerings (GCP jargon). Plus some other services under those umbrellas if Google has told you something about their plans under NDA, which they do for many customers.
But Google reliably provides transition plans and data exports if they do turn anything down, and I expect that will continue.
(Disclosure: I formerly worked for Google and GCP in particular, but no more recently than early 2015 and I have no current insider info.)
AWS likely doesn't have because they don't have the same trust problem Google does. Google likely were loosing from GCP deals because of this, so they put it in there to appease customers.
One year is way too short as well. Enterprise application development does not happen at that speed . Teams and budgets are not readily available to start migration to something equivalent just coz Google felt like it.
Even if that's not a problem migration may not even possible with proprietary APIs. You may have to deprecate entire fearures. If your SLA is longer and reasonable time to your customers, you are screwed.
Hell, I bet there are insiders who were surprised about the decision to close up shop on Google Inbox. There's no guarantee that Cloud and Domains will never be closed, but that's on the level of RIM no longer making Blackberries. Google's a modern Internet company and has bet, and bet big, on being a leading cloud services provider, and Domains are a key component to having a vertically integrated offering.
Google is a public company and as such they are required to release certain information in annual report, so their investment in the cloud is verifiable.
> Hell, I bet there are insiders who were surprised about the decision to close up shop on Google Inbox.
Not an insider, but TBH, I was always pretty much sure that one of Gmail or Inbox will go away soon. With Gmail having more user base, it was natural for Inbox to be subsumed by gmail.
Inbox was not really fundamentally different from Gmail. It offered some new features, but I can't imagine that it would be too hard to implement them in Gmail too (e.g., snooze feature).
I suspect Inbox was never meant to survive. It had small details that prevented mass adoption. For instance, it took them months after launch to implement an automatic signature, and then they added the artificial restriction to only allow them in your gmail.com account, not other accounts like in gmail. This prevented a lot of people whose workplace policy requires a specific signature, me included, from completely ditching gmail.
That article mentions that bundles are supposed to arrive in Gmail soon. My point still stands that Inbox features would be not-so-difficult to add to Gmail.
It's much easier than developing and maintaining 2 apps, and testing them on variety of platforms (Web, ios, android etc.) and device/browser combinations.
Wouldn't be surprised if it was related to their new Titan Security Keys. They are advertised as 2-factor authentication devices but they almost certainly have the ability to act as a certificate store. If you have a CA you can start issuing certs to people and drop the password / user name login altogether.
Google has been behind the effort to kill client certificates on the web, though, and as as someone who has run a web host for a large client-cert-using population I think this is a reasonable move: in particular, the protocol doesn't provide confidentiality for client cert data any more than it provides for server cert data, so if your name is in the subject it is sent in the clear which is a huge privacy violation, and there's no obvious way to implement a "logout" button, because auth is tied to SSL. You can work around these things, but at that point it's not obviously better than just doing some auth with WebCrypto (or your own WASM) and localStorage, and the tradeoff of using SSL client certs is that the complexity is inside your SSL layer and not sandboxed to the individual websites.
I happen to like, and have used, mutual authentication (and thus client certs) for B2B HTTPS APIs where the systems at both ends are servers not people or user agents. I agree it's not so great for people.
FWIW TLS 1.3 encryption kicks in before the certificates get sent, in either direction, so if you like/ need client certs but worry about confidentiality you should go to 1.3
Oh TLS 1.3 also has nicer filters so you can tell a client "Hi, please send me a client cert, but, I want one that has the following properties based on ASN.1 OIDs" whereas with earlier TLS versions you could only say "Here is the list of Certificate Authorities which I trust to issue client certs, give me any cert you have from one of those CAs".
A logout button could work the same way as with usernames and passwords. Sure you could use the cert to reauth the user with every page load but you could also use a traditional login page you just replace the user / password entry with the certificates and then operate as usual from there. Same with privacy it is all in the implementation details.
A logout button doesn't give extra security if anyone with access to the PC can hit the 'login' button. So unless access to the cert is behind a password there is no useful way to logout using client certs.
The user usually has the option to require a pin be supplied to unlock the hardware token. The advantage to certificates on a hardware token is that they can't be stolen remotely unlike a user name and password which can be compromised on either the user end or service provider end.
i.e., put a cookie on the site, and trust the cookie instead of the cert for all pages except the login one? That leaves you with all the usual problems of cookie-based logins that certs are supposed to solve (revocation, risk of being stolen, etc.), and also if you want to do that you can just put a private key in localStorage and use WebCrypto on the login page. Or with username + no password + FIDO security key as your only factor, if you want a hardware token, or whatever. There's no advantage in using SSL for this.
The point of the hardware token is that the credential never touches the PC. Putting a private key in local storage is no better than a user name and password because it leaves it open to theft. The most common problem that an everyday user faces is either a data breach on the service provider end or a virus / keylogger on their PC. Hardware tokens with certs solve both those problems in terms of account access.
(Disclaimer: I am a Google employee, but I don't work on any of this.)