Abstractions are inherently a tradeoff, and too much abstraction hurts you when the assumptions break.
For a major example, treating a network resource like a file is neat and elegant and simple while the network works well, however, once you have unreliable or slow or intermittent connectivity, the abstraction breaks and you have to handle the fact that it's not really like a local file, and your elegant abstraction has to be mangled with all kinds of things so that your apps are able to do that.
If you discard all major video streaming sites (including adult entertainment) then you probably can get most of the way there; you're probably mostly interested in text communication and actual user data, not the video content which is so much larger than that.
This shouldn't be a major issue because of Forward Secrecy (https://en.wikipedia.org/wiki/Forward_secrecy) principles built into modern TLS protocols, which ensure that even if the public/private key scheme is vulnerable to (for example) quantum attacks, the attacks have to be done now, as a MITM for the handshake, or otherwise the full traffic capture is useless for future decryption without getting some secrets from one of the endpoints.
That being said, it's not 100% used everywhere yet (Wikipedia mentions 92.6% of websites), and various means of tricking devices into downgrading to an older protocol would result in traffic that might be decrypted later.
No, this absolutely is not how forward secrecy works in TLS. Forward secrecy protects against a break in the signature algorithm, but not in the key agreement algorithms.
Both the FFDH and ECDH key agreement algorithms are vulnerable to quantum crypt-analysis; someone capturing traffic today could later break that agreement and then decrypt the data. An attacker would have to capture the entire session up to the "point of interest" though.
This is why FFDH/ECDH are being augmented with Post-Quantum secure KEMs.
It's interesting that I just read an inteview with YouTube CEO (https://stratechery.com/2025/an-interview-with-youtube-ceo-n...) who mentioned that YouTube fully intends to start getting a cut out of that sponsorship money ("to align interests better").
I'd probably be OK if all the content which doesn't get made without sponsorship wouldn't get made at all, and the people who work as content creators stopped doing so. There is an overabundance of new content, having 10x less content would be perfectly fine, and in pretty much every niche there are amateur enthusiasts who clearly (based on their amount of viewers) are giving their time away, and their content is in many ways preferable and "more real" than the professionals - so I'd be OK if all the professionals stop and these awkward amateur enthusiasts are all that remain.
The same applies to web and blogs; the ability to monetize them by ads (and I do remember the "old web" before it was the case) increased the content but drowned out viewership for the true enthusiasts running things in their spare time, which IMHO were more valuable and I think that regime was better; again, losing 90% or 99% of the content wouldn't be bad in my mind, there still would be more than enough for anyone to ever "consume".
Well in your example it didn't write less secure code (wich is the core claim of the article, and something new), it refused to provide an answer about Falun Gong, which the article also claims, but that's not the interesting part of the article as censorship of certain keywords is well known DeepSeek behavior since it was released.
This user said almost the same thing[0], so I'll refer you to that. In short, RTFM. The first paragraph says "refuses to help programmers __OR__ gives them code with major security flaws". I hope we know the difference between && and ||.
Also, I'm requesting people post their replication efforts. What is it that you care about? The facts of the matter or finding some flaw? The claims are testable, so idk, I was hoping a community full of "smart people" would not just fall for knee-jerk reactions and pull shit out of their asses? It doesn't take much effort to verify, so why not? If you get good evidence against the WP you have a strong claim against them and we should all be aware. If you have evidence supporting the claim, then shouldn't we all also be aware? Even if not strong we'd at least be able to distinguish malice from stupidity.
Personally, I don't want to be some pawn in some propaganda campaign. If you're going to conjecture, at least do the bare minimum of providing some evidence. That's my only request here.
It's just that out of these two claims only one is interesting and worth talking about (and that's the one mentioned in the title).
Thank you for your testing! That's a bunch of effort which I didn't do - but checking the other claim is much more difficult; a refusal is clearly visible, but saying whether out of two different codebases one is systematically slightly less secure is quite tricky - so that's why people are complaining about the lack of any description of the methodology of how they measure that, without which the claims actually are not testable.
One is more concerning, yes, but I'm asking for help vetting.
In either case, just blindly accepting or blindly rejecting the claim is unhelpful. Clearly the OP is blindly rejecting, as well as many other comments. These are unhelpful and just perpetuate misinformation campaigns (who's goals are to create chaos, more than they are to create a specific point of view).
So I want to ask, what are your comments contributing to? Why are you passionately attacking my comment? What is your vested interest here? Because I don't see this, or the similar comments, contributing much. Can we try to not be so quick to make conclusions and try to figure out the truth? Why are we arguing instead of trying to verify? I do value your opinions, but let's also make sure we know if they are pure conjecture of there's some evidence (even if minor). We can verify the claims, so let's try.
All the US megacorps tend send me emails saying "We want to change TOS, here's the new TOS that's be valid from date X, and be informed that you have the right to refuse it" (in which case they'll probably terminate the service, but I'm quite sure that if it's a paid service with some subscription, they would have to refund the remaining portion) - so they can change the TOS, but not without at least some form of agreement, even if it's an implicit one 'by continuing to use the service'.
For a major example, treating a network resource like a file is neat and elegant and simple while the network works well, however, once you have unreliable or slow or intermittent connectivity, the abstraction breaks and you have to handle the fact that it's not really like a local file, and your elegant abstraction has to be mangled with all kinds of things so that your apps are able to do that.