> Historically, they did because everyone's capacity for violence was equal.

This is so wildly ahistorical I'm immediately suspicious of your intentions.

The US alone offers plenty of counterexamples from the last ~50 years.

Try something else until it does.

The only other option is to go on being miserable.

Even fewer people want to wear earmuffs while hiking.

There are so many styles and those people can choose one consistent with their muff preferences.

It's actually 6 and 2/3rds! I'm trying to figure out a rationale for 160 hours and similarly coming up empty, if anyone knows I'd be interested.

200 would be a nice round number that gets you to 8 1/3 days, so it comes with the benefits of weekly rotation.

I chose 160 hours.

The CA/B Forum defines a "short-lived" certificate as 7 days, which has some reduced requirements on revocation that we want. That time, in turn, was chosen based on previous requirements on OCSP responses.

We chose a value that's under the maximum, which we do in general, to make sure we have some wiggle room. https://bugzilla.mozilla.org/show_bug.cgi?id=1715455 is one example of why.

Those are based on a rough idea that responding to any incident (outage, etc) might take a day or two, so (assuming renewal of certificate or OCSP response midway through lifetime) you need at least 2 days for incident response + another day to resign everything, so your lifetime needs to be at least 6 days, and then the requirement is rounded up to another day (to allow the wiggle, as previously mentioned).

Plus, in general, we don't want to align to things like days or weeks or months, or else you can get "resonant frequency" type problems.

We've always struggled with people doing things like renewing on a cronjob at midnight on the 1st monday of the month, which leads to huge traffic surges. I spend more time than I'd like convincing people to update their cronjobs to run at a randomized time.

I have always been a bit puzzled by this. By issuing fixed length certificates you practically guarantee oscillation. If you have a massive traffic spike from, say, a CDN mass reissuing after a data breach - you are guaranteed to have the same spike [160 - $renewal_buffer] hours later.

Fuzzing the lifetime of certificates would smooth out traffic, encourage no hardcoded values, and most importantly statistical analysis from CT logs could add confidence that these validity windows are not carefully selected to further a cryptographic or practical attack.

A https://en.wikipedia.org/wiki/Nothing-up-my-sleeve_number if you will.

There is a solution for smoothing out the traffic: RFC 9733, ACME Renewal Information (ARI) Extension

https://datatracker.ietf.org/doc/rfc9773/

That only addresses half the problem and is just a suggestion vs something clients can't ignore.

It's less than 7 exactly so you cannot set it on a weekly rotation

biweekly rotation?

We say pan-weekly these days

Or is it semi-weekly?

Breaking prod repeatedly probably impacts your stack ranking too.

Depends on how easily the failure is connected back to you personally. If you introduce a flaw this year and it breaks the system in two years, it won't fall back on you but the poor sap that triggered your bug.

So can "heroically" save prod ... anti patterns.

I'm not convinced that's their goal any more. The number of users turning off or ignoring AI features is probably considered a problem, not a signal.

This suggests one article or the other is incomplete.

To have evidence of bias, you would have to show that a paragraph like the one in the English article would be rejected for the German one.

In order to find this useful you would have to believe that Jimmy Wales writes the articles on Wikipedia which is a ridiculous notion.

Rich people don't write articles on Wikipedia. They pay other people to do so. Some of the articles on billionaires read like hagiographies.

"Give up" is not the best option. Certainly not from the EFF's perspective.

I mean, the best option is to fight this legislation, and AIUI they're doing that too. But this article is not about that, it's about how to minimize the harm if you encounter it.

Many open source projects are created by engineers being paid to solve a problem their employer has, and they just happen to release it freely.

I don't think Google needs a dollar every time I write a script in golang or run a container in kubernetes, and I would put a lot less trust in Envoy if I thought Lyft was building it profit and not because they needed to.