pfg

I don't understand your argument. When we're comparing "overall death rate in a world without COVID" to "death rate in a world with COVID", we're looking at the same population. We don't need to adjust for age if we're looking at the same population.

This kind of misconception is so common it even has its own name: Simpson's paradox. It's laughable to think that the vaccinated population, compared to unvaccinated, is dying at the rate suggested by these numbers and no one is ringing the alarm.

There's a reason China hasn't made this their strategy for the rest of the pandemic. It works as a stop-gap, if you accept low quality of care (read: high mortality) and if you're dealing with a regional outbreak where you can ship in resources from surrounding areas.

It's not going to work if the entire country, continent or planet is in the same situation.

There are all kinds of possible explanations for this. If you look at this heatmap of vaccine uptake by age and time (you'll need to select second dose)[1], you'll see that the uptake percentage is fairly uniform across all age groups below 60 e.g. in March, but goes up fast for 55-59 in April, meaning the "10-59 + Second dose" group became older on average during that time. My best guess is that the uniform distribution early on was from healthcare workers; later on, the age-prioritized vaccination rollout changed the distribution.

There's a reverse trend that coincides with an increased uptake in younger groups: The age-specific death rate for "10-59 + Second dose" in June was 2,8 and went down to 2,4 in September.

One thing to keep in mind: When we're talking about the 10-59 age group on their second shot prior to April, that's only a population of 800k with a total of 16 deaths reported between January and April. Confidence intervals for this period are very wide and the upper confidence limit in the ONS data is quite close to what they're reporting e.g. for September.

[1]: https://coronavirus.data.gov.uk/details/vaccinations?areaTyp...

Just to clarify: half-doses are only used for booster shots (following EMA recommendation). First and second shots still use full dosage.

Are you referring to the same ONS data mentioned in [1]? That figure is highly misleading.

[1]: https://news.ycombinator.com/item?id=29323441

That age group is too wide to make a meaningful comparison without standardising for age. Less than 10% of under-18s and less than 60% in the 18-24 age group have been fully vaccinated, whereas it's more than 80% for the 55-59 group.

The unvaccinated population in that age group is significantly younger than the vaccinated population. As you would expect, older people tend to die more often.

This is also mentioned in a footnote in the ONS data (and this is why they tend to focus on age-standardised figures).

I'm assuming this should be https://www.ons.gov.uk/peoplepopulationandcommunity/birthsde....

Can you be more specific with your claim? The age-standardised mortality rate appears to be significantly higher for the unvaccinated population according to your source.

// edit: Sorry, I missed the part where you were talking about a specific age group. This can be explained by [1].

[1]: https://news.ycombinator.com/item?id=29323980

> The risk calculus has changed and so must the response shift from the public to the private: from government to individual.

I don't think it has shifted all that much in many countries. Yes, we have vaccines and better treatment. At the same time, vaccination rates aren't as high as they should be, plus we're dealing with a new variant that's more than twice as contagious and probably causes more severe cases. We're also dealing with waning immunity.

I wouldn't go as far as saying these factors offset each other completely, but last year, we've had all kinds of non-pharmaceutical interventions in place (masks, contact restrictions). Many countries have now abolished these.

I might buy the "individual choice" argument if negative effects were only felt by those choosing to not get vaccinated, not wear masks or similar, but once hospitals/ICUs overflow, other people suffer or die too.

The Wikipedia articles on Virus Latency[1] and Slow Viruses[2] offer some examples. Some widespread examples:

  varicella zoster virus: chickenpox => shingles
  HPV: warts/precancerous lesions => cancer

(Note: also layperson.)

[1]: https://en.wikipedia.org/wiki/Virus_latency

[2]: https://en.wikipedia.org/wiki/Slow_virus

Reduction of infection/transmission is only one endpoint to consider. We also need to consider the overall effect on the quality of healthcare we can expect to receive in a situation where low vaccination rates causes hospitals to be overrun. This is where the line between personal health decisions on whether to get vaccinated or not and what is fair to society as a whole gets blurry.

People tend to argue "but what about $arbitrary_unhealthy_habit, we don't regulate that!" when someone mentions this, but $arbitrary_unhealthy_habit has been accounted for in terms of resources required to treat people (assuming a working healthcare system), whereas a once-in-a-century-level pandemic hasn't, so it's not a valid comparison.

There's no actual written law on this, but the relevant authority (Standesamt) has to take the child's welfare into account when accepting names, and may reject them as a matter of common law.

(I suppose it's possible this would be under the purview of the Verbotsgesetz as well, but it wouldn't get that far due to the name being rejected.)

The article mentions that the influenza B virus has no known animal reservoir.

The verification app needs to maintain a set of trusted certificates. More details on the trust model can be found here: https://github.com/ehn-dcc-development/hcert-trust/blob/main...

Infrastructure for code generation and signing is probably country-specific, though I imagine most countries will establish centralized systems dealing with this and integrate with other systems that track vaccination or test records on various levels (some countries delegate vaccination efforts to their states, others handle it nationally, etc.)

To add a real datapoint: the QR expiry date for the certificate of my second shot is set to 360 days after I received the shot.

A 0.002% risk of experiencing myocarditis due to the vaccine seems a better deal than catching COVID, which brings a ~0.3% risk of experiencing (symptomatic) myocarditis in a (to my non-expert understanding) similar demographic[1]. Many experts assume COVID will become endemic, so this is not a theoretical risk.

[1]: https://jamanetwork.com/journals/jamacardiology/fullarticle/...

The third tweet in the thread you linked[1] demonstrates why it would have been a bad idea to treat those initial findings as a "major red flag".

[1]: https://twitter.com/JamesCTobias/status/1399882478488334337

My understanding is that Serious Adverse Events are not necessarily reactions that can easily be attributed to the vaccine (unlike a headache occurring soon after the vaccination), so we have to check whether these results are statistically significant and/or whether any patterns can be found in terms of what these events actually are.

I don't think 0.4% vs. 0.1% with n=1127 is significant, and the study mentions no patterns were observed.

We still have systems like VAERS to ensure side-effects that are too rare to be caught by a study of this size still get caught.

Both studies[1][2] mention doctor's sex as a factor. "Effect of education and performance feedback on handwashing: the benefit of administrative support in Argentinean hospitals", for example, has these figures (calculated as Number of handwashings/Number of opportunities [to wash their hands?]):

> Male vs female: 46% (1989/4350) vs 53% (5895/11,181)

[1]: https://pdfs.semanticscholar.org/f3c8/bb1914d5226c719df53dd8...

[2]: https://pdfs.semanticscholar.org/8887/835e725b4347a5392e095a...

Supermarkets will be providing surgical masks (not N95) free of charge. In places where none are available, use will not be mandatory at this point (though strongly recommended).

Case fatality rate for swine flu was around 0.02%[1]. There's still a lot of uncertainty around 2019-nCoV, but most estimates appear to be closer to 1-2%.

You're not wrong in that old and sick people are the affected the most, but it's significantly worse compared to e.g. Influenza[2].

[1]: https://www.worldometers.info/coronavirus/coronavirus-death-...

[2]: https://raw.githubusercontent.com/jbloom/CoV_vs_flu_CFR/mast...

To be clear, CAA is relevant even if you're using http-01. CAs need to check whether the CAA records of a given domain allow/forbid issuance in addition to any of the methods used to demonstrate domain ownership to the CA.

> I'm guessing customer IDs are associated with e-mail addresses?

They are (on Let's Encrypt's end), if an email address was provided.

It's a 1:n relation, the same email may be used for any number of ACME accounts. Roughly speaking, for most clients, the ACME account maps to a specific ACME client on a specific host. If you run three servers with separate ACME clients, you're probably using three ACME accounts (even if you're using the same email and issuing certificates for the same domain).

Large or custom implementations may reuse the same ACME account across many servers and domains. (Issuance would typically be centralized and operated as a separate system in these scenarios.)

To my knowledge, there's no such mechanism in any of the relevant protocols (i.e. ACME and OCSP).

Hash algorithms may not have been the best examples as they require client support.

A better example would be something like Certificate Transparency. Currently, browsers may require Certificate Transparency for certificates issued after a certain date. A malicious or compromised CA may work around this by backdating certificates. This would be less of an issue with shorter certificate lifetimes.

Multiple reasons:

1. Firefox remains the only mainstream browser to support OCSP Must Staple.

2. OCSP Must Staple does not cover all threat models: if an attacker gains the ability to temporarily issue certificates for the victim's domain (rather than obtaining the private key of an existing certificate), they can request a certificate without the OCSP Must Staple extension. A more effective method would be something like the Expect-Staple header[1] (in enforce mode).

3. It allows the ecosystem to move significantly faster. In a world where all certificates expire after 3 months, phasing out insecure hash algorithms (in certificates) would no longer take many years.

4. It encourages regular key rotation (even if it's not enforced)

[1]: https://scotthelme.co.uk/designing-a-new-security-header-exp...

The Baseline Requirements for publicly-trusted CAs (section 4.9.1.1) require timely revocation of mis-issued certificates - either 24 hours or 5 days depending on the reason. I'm not entirely certain which is applicable here, but I'd assume Let's Encrypt's hands are tied in this case.

Germany has a section called "Violation of intimate privacy by taking photographs" that seems to apply here[1].

[1]: https://www.gesetze-im-internet.de/englisch_stgb/englisch_st...

Fun fact: You may find signs warning of the oak processionary moth in some of the woods in Vienna, Austria[1].

[1]: https://www.vienna.at/2018/05/eichen-wien-16-9-017650366-650...

Most of these concerns are luckily not a problem in practice, I'll try to go through them one by one.

> In the future I'm imagining my 2FA secrets being stolen from my browser, or being used to track me.

The API does not provide access to secrets. Keys remain on the WebAuthn device, and the device only signs data and sends that back. The key is likely also stored in a way that makes extraction hard - for hardware tokens, past attacks of this nature mostly required physical access, and modern iPhones and some Android devices have high-quality key stores offering similar protection. AFAIK keys used by these devices differ for each origin/domain (IIRC through some crypto magic on hardware devices, as they don't have space for many keys), preventing cross-origin tracking.

> Google "for my convenience" automatically logs me in so it can track me?

Most (all?) implementations I'm aware of require approval on the token (physical tap, approval of a prompt). Browsers also tend to show a prompt/notification when sites use this feature.

> Or perhaps, my bank checking my battery level, WiFi hot spots, and the model of phone when it pulls the 2FA tokens to verify my location.

The API does not allow this level of access.

> Also, I can only log on with their app on my phone, because the tokens are hidden, further making my desktop useless.

There is nothing stopping you from using hardware tokens (which use the same standard) or even soft tokens running on your desktop. IIRC GitHub created a desktop implementation utilizing the Secure Enclave that modern Macs come with for this purpose.

> Maybe a website figures out how to use JavaScript to generate another logins tokens. It takes an hour of tokens, and feeds it into hashcat on AWS to break my key.

This does not make sense with the implementation in mind - the key is stored on a separate device and the browser only ever gets something that was signed using said key.

I can't find a source, but my recollection is that Google developed U2F because autofill didn't work reliably enough, so many users would just paste the password manually anyway.