Dipole

The article seems to take the stance of "thinking about using a commercial VPN? Just use TOR!". But in my experience, TOR is glacially slow, and it's also not suitable for ordinary browsing because of how widely-blocked the exit nodes are. The article at least acknowledges the blocking problem, but for an article which focuses on tradeoffs, it doesn't acknowledge that there's a valid trade-off between TOR and a commercial VPN. A commercial VPN is faster and less blocked than TOR, but there is still an entity with direct knowledge of your browsing (the VPN company itself), there is more vulnerability to correlation (the VPN doesn't [and probably can't] change your exit node for each website, like the TOR browser would), and a commercial VPN is an expense. You don't have to jump all the way from "no-one can know which website I'm browsing" to "anyone tapping any leg of my connection can know which website I'm browsing" just because the website blocks TOR exit nodes.

For reference: I have a commercial VPN subscription, which I have connected for my daily browsing -- in large part to reduce the cognitive load of "what if X party knew I was visiting Y website" for every website I visit. I also have the TOR browser installed, and use it occasionally -- for when I'm concerned about the outcome of "what if the VPN company is breached/subpoenaed/sells my data/etc.". I don't put any stake in the ubiquitous "no logs" claims of VPN companies, since it's completely unverifiable.

I do at least appreciate the article acknowledging the grossly misleading advertising of nearly every VPN company. They advertise their product as solving problems which are solved by HTTPS and not solved by VPNs

I had the issue reoccur, and I can confirm that the jwt token was missing from the request to /, but present for other resources such as the css stylesheet

I waited for the issue to reoccur so I could test that out. The jwt cookie is missing from the request to / but is present in several of the other resources used for the page. That's consistent with Crashdoom's comment. Sometimes, the issue would only occur in a specific tab (refreshing the tab did nothing, but opening a new tab would have me logged in), which is roughly the opposite of what that user reported, but this time, it was a problem in any tab

I wasn't aware that there were any games that could make meaningful use of 16 cores, let alone games that might want more. Was there a major advancement in game programming when I wasn't looking? Or is the headline as far off base as I think?

"If one root server directs traffic lookups to one intermediate server and another root server sends lookups to a different intermediate server, important parts of the Internet as we know it could collapse"

this doesn't pass the sniff test. Records sometimes being out of date for some users is par for the course for DNS. Domain owners already need to account for that. Also, the "intermediate server"s in question would be things like the .com and .org operators' servers. I would hope the likes of Verisign and the Public Interest Registry can handle a delay in sunsetting a DNS server to accommodate something like this.

Any system where the most severe outcome is "A moderator will look at it" is an easy sell for me, so I wouldn't have any problem with 1 or 2. And an opt-in system of nearly any kind is going to be okay by me so long as it doesn't stand to harm anyone who hasn't given informed consent, so 3 also sounds fine.

With 4, I'd definitely want more details on what is considered "a significant risk or pattern of spammy behavior" and on why the temporary suppression "may break existing conversations or prevent new ones" before being comfortable with such a system.