Just to clear up one point -- Let's Encrypt did not at all force ACME on the industry. We deliberately took it to the IETF so that we could get input from more parts of the industry (including some major refactors!). Instead of pressure from Let's Encrypt, I would attribute its success to the open process of the IETF, the awesome open-source community that made great ACME software (shoutout to Matt and Caddy!), and the resulting pressure on CAs for a better user experience from users and customers.
I didn't express myself well but what I meant by force is that by building a standardized to automate way manage certificate, ACME imposed itself and became mandatory.
Previously, most CA had no programmatic way to order certificate, it was all done manually.
As far as I know, the only providers with that would let you automate certificate provisioning at the time where Comodo, GlobalSign and Digicert.
At first none of them were warm at the idea of providing an ACME endpoint. I'm assuming part of it is the cost of implementing it but they probably liked the stickiness of their custom APIs too tied to million dollars contracts.
Nowadays they all implement ACME. At some point, they where effectively forced to implement it to acquire new customers and keep their existing base around because nobody would accept poorly designed custom made protocol anymore.
Hi there, ISRG co-founder and current board member here. In brief, shorter lifetimes force people to automate (which, e.g., avoids outages from manual processes) and mitigates the broken state of revocation in the Web PKI. That latter point especially is what I understand to be driving the Web PKI toward ever-shorter lifetimes.
I actually remember the discussion we had in ~2014 about what the default certificate lifetime should be. My opening bid was two weeks -- roughly the lifetime of an OCSP response. The choice to issue certificates with 90 day lifetimes was still quite aggressive in 2015, but it was a compromise with an even more aggressive position.
With the move to ever shorter certs the risk to letsencrypt having an outage is higher.
It would be nice to read more about what the organization is doing around resilience engineering so we can continue to be confident in depending on it issuing renewals in time.
Do you publish any of this? DR plans? Etc.
I don't mean for this to be a negative - really impressed by LE - but we've had a lot of Cloudflare outages recently and my mind is on vendor reliability & risk at the moment.
Considering how many ACME clients are available today with all sorts of convenient features, and that many web servers nowadays have ACME support built in (Caddy, Apache mod_md, and recent Nginx), I believe that people who don't automate ACME certificates are the people who get paid hourly and want to keep doing the same boring tasks to get paid.
The idea here is to be lighter-weight than profiles, or the similar feature in Chrome. I've got three different containers going right now, side-by-side in one browser window. In addition to the per-tab basis, providing separation within a profile also means you don't have to set your preferences, addons, etc. independently each time.
For example, one of the major use cases for this sort of separation is being able to use multiple accounts on a site like Twitter or Facebook (which don't support multi-account) or Gmail (which does, but it's a bit rough). There's no reason I should have to have separate windows or separate addons for each of those accounts.
It's a mix. Some patches are just getting rebased and landed. For others, the Firefox and Tor Browser teams are working together to re-implement the feature in a way that makes more sense in the broader Firefox architecture.
For example, for First Party Isolation, we took the "origin attributes" feature that we built to support containers (user-specified tracking limitations) and reused it for isolation. In the containers case, origins get tagged with a user-specified label; with First Party Isolation, they get tagged with the top-level origin.
And to be clear, there's no "neutering" going on here. We're adding the full features that Tor Browser has, since the whole point of this exercise is to let Tor Browser user preference changes instead of patches. That means that the full capability of the Tor Browser features are in Firefox if users want to enable them.
Speaking as someone who is familiar with some parts of the Firefox architecture or concepts thereof, but not the source code itself: If you were to implement per-container pref overrides, theoretically yes. AFAIK, prefs are global right now. I don't know if it's feasible to implement this in Fx or if that will leak through to the chrome (process).
But it's an interesting idea! Would you mind filing a bug at bugzilla.mozilla.org?
When a server uses a Let's Encrypt certificate, a browser will consider it as issued under an IdenTrust root CA, which the browser trusts. So it will consider the Let's Encrypt certificate trusted.
