If a root/admin user installs a root there is no prompt, if a user does, it is scoped to the individual user profile and a prompt is displayed. No prompt as root would be meaningful because the root/admin user could just update the configuration without using the API. Long story short, don't give root/admin to applications you don't trust.

Right but basically all application installers basically require “root” on windows.

This is an unfortunate side effect of how installation works on Windows I think.

I really think we need to move closer to requesting permissions to specific things rather than a binary “admin or not”.

With the recent GCP Cloud Certificate Manager release the global propagation time is minutes. (I should note I was a PM for this feature)

No, GCP has had arguably a superior TLS story for years.

For example they do managed TLS for their workloads like AWS but they operate their own CA rather than outsourcing to Digicert for certificate issuance which gives them a better SLA.

They have a global load balancer offering that enables TLS to terminate everywhere GCP is without having to manage a bunch of discrete load balancers, this also supports managed TLS.

They now support a very large number of certificates in the global load balancer product which allows SaaS products like hosting services to leverage the global load balancer rather than deploying a load balancer per 25 certificates (the limit per AWS LB).

And now let you enroll for certificates from the same CA they use even if you terminate TLS rather than having them do it for you. They do this via a standard API (ACME) which lets you have uniform and agile device compatibility regardless of how you deploy TLS. AWS doesn't let you do this at all.

(I should note I was the PM for most of these releases and am still the PM for Google Trust Services the CA used for this ACME release)

There is no origin limitation. It works on premise or cross cloud.

We hear you, while I can't speak to future products and features I can say we understand there is room to improve the SSL provisioning and lifecycle management story in our products and we are making investments in that area.

That is effectively how both the Mozilla and Microsoft programs root store programs works.

Some PKI-related services can not, due to user agent behaviors and, do SSL, for example, consider OCSP; if to fetch an OCSP request you need to do an SSL connection and the library doing SSL does an OCSP check to verify the SSL cert you can end up in an infinite loop.

While it would be ideal for that not to be the case, one has to build out infrastructure that supports the way UAs behave today.

Disclosure: I am the author of that post and Product Manager for this project as well as other related work like Certificate Transparency and Key Transparency.

While I can not say what Google will do in the future, I can say we are very supportive of Let's Encrypt. We have provided them funding and I personally act as an advisor to Let's Encrypt.

In short, we love what Let's Encrypt is doing.

I do too, and I also think that if one reasonably well funded, free CA that has full transparency is great, then two would be awesome :D

To clarify, that's a CA, not an ISP

But as Google wants to stop the Fiber project, they will also stop being one. Apparently being an ISP adds no value to the rest.

I wonder, with Alphabet's investment in SpaceX, if they see satilite as the future instead of fiber.

Google has announced an effort to move all CAs to Certificate Transparency, here is a Threatpost piece on the topic - https://threatpost.com/google-to-make-certificate-transparen....

They will already log their public certificates to CT and this will continue given their push for CT.