yasaheblasa

Secure shell had to wait quite a while for gradual adoption by anyone new and caskets of the older to pile up. SSL wasn't exactly shiny new in 2014 when LetsEncrypt was brought in to make it prevalent together with Google pressure. Similar pressure has the same groups picking DNSSEC experience up just in the last year.

If we put aside the advertising for a moment, the US had the same problems with every technology that is newer than landlines. Big investments in companies that will be prevented from failing will try to keep the US behind the trend but a few US companies will see that they better get ahead of where the rest of the world is going with or without US tech.

Sure, biggest Brand/Monopoly (and largely US) Tech is of course an interesting situation with a few different directions for interpretation. Yet, I think that many of them simply have to add DNSSEC, IPv6, etc as soon as the numbers finally look too much like 50%+, I.e. MS is about half the sites and already has selectively added it, usually where the consumer brand consequence is theirs via a SaaS product.

1&2 sound worse after this update as described.. I'm not really sure why we are still bothering with this when DNSSEC progress means DANE like setups could solve the original E2E S/MIME issues of payment and domain indicating expectation of what its email senders are required to have for S/MIME.

There are some aspects of (possibly positive) deniability by an individual that probably still remain with DKIM but they kind of remain anyway with domain anchored S/MIME.

You are simplifying ad absurdum. The NSA is as likely to compromise hash and signing algorithms as the police are likely to recommend pissing in petri dishes to cast doubt on that troublesome forensic science. The NSA likely has orders more experience with the area of cryptography Kyber comes from than everyone who worked on Kyber. Estimates at one point were that they had more than half of appropriate PhD level Mathematicians in the US, that may have gone down with more cryptocurrency firms, etc, but those firms are not researching algorithm families that may or may not replace the standards with all that much interest.

I was under the impression that breathing in burnt particulate of any sort was associated with serious cardiovascular risk? I would think a significant portion of cannabis users ingest smoke very frequently or at least second hand smoke more frequently than people who do not engage at all with a subculture that is largely smoke oriented.

I'll certainly mull this over. I think the point of including the creation time in the primary key was to eliminate lookups in old partitions, I.e. if an active order can only be 90 days old it can only span 2 year based partitions. A cache of what id is 91 days old would seem similar but is even more partition details affecting app queries than saying 90 days directly. Similarly, I don't cache ids in any sort of session, an API call reusing cache is another kind of layer violation I don't want to get into.

This is a topic that interests me a lot but there's a lot I find surprising since I finally started working with postgres dependent apps. Why for example is the id a good primary key? Joins are not uncommon, but I don't have anyone searching on id in my application and it is not even supposed to be user visible. I would think every possible user search would look at all partitions indexes if I did this instead of creation date.