The common viewpoint is that we are practically in an economic downturn, but the overall stock market is being propped up by circular spending within the AI bubble.
It's not a helpful reply to that particular comment, but I think it's worth recognizing that the US is now in the same camp as HK or mainland China now where there will be some people who just simply cannot enter.
>Btw. The https communication comparison does not hold, there is always a third party that can read what you say. E2E chats are effectively communication where evidence is instantly destroyed.
If I use a third party CA this is correct. But what third party can read communications over HTTPS between a client and a server I control with a self signed SSL cert?
This isn't correct with 3rd party CA's with modern TLS either.
TLSv1.2 has Perfect Forward Secrecy with DHE and ECDHE key exchanges and in TLSv1.3 PFS is mandatory. A compromised root CA or even leaf certificate these days protects you from a man-in-the-middle and not a whole lot else - the certificate private key is never used for session key derivation and the keys themselves are ephemeral and never sent over the wire so even intercepting the key exchange doesn't allow decryption of the stream.
Even if you don't have Forward Secrecy, like you decided to use RSA KEX which is a terrible non-default idea even in 2015 let alone today (this feature isn't even present in TLS 1.3 deliberately, lobbying to keep doing this failed), your private key is still needed so a third party CA can't imitate you.
The CAs have never been supposed to know your private key. For a long time now it's straight up forbidden on pain of removal from trust stores for the CAs to learn somebody else's private keys.
For the example of Let's Encrypt your client probably picks a private key and stores it where your web server can use it, but it never sends this key to anybody else. In fact if you care you can even have the key chosen by the web server and literally never send that key to the Let's Encrypt client at all, the client picks up a "Certificate Signing Request" and it goes OK, I see you want a certificate for some key you know but I don't, that's cool I will go ask Let's Encrypt to issue a certificate for that and let you know.
There's societal memory of monarchies and kings that held a lot of power that still impacts things to this day, sometimes unconsciously and sometimes consciously.
The NSA is an American body, and Trump is the subject of a personality cult far in excess of any European monarch. Authoritarianism is a personality trait independent of political structures.
I think deprecation in intra-company code is a completely different beast. You either have a business case for the code or not. And if something is deprecated and a downstream project needs it, it should probably have the budget to support it (or code around the deprecation).
In many ways, the decision is easier because it should be based on a business use case or budget reason.
The business case is the easy part, the quagmire is in getting the different teams to agree who should support the business case, why it's more important than the business cases they wanted to spend cycles on instead, and how much of the pie supporting it takes on the budget side. Less so when the place is small enough everyone knows everyone's name, more so when it's large enough they really don't care what your business case is much even though it'd be 10x easier to support from their side instead of another.
Oh. But that is a solved problem. The users of the library just copy the code from before the deprecation and then stick it in their codebase not to be maintained anymore. Problem solved. /s
O365 and other Microsoft products are a massive, massive drain on valuable foreign exchange for third world countries like mine. If it were up to me, I would outlaw paying Microsoft for anything in my country.
reply