> A recent LinkedIn post that I came across as an example of people trusting (or learning to trust) AI too much while not realizing that it can make up numbers too

Honestly, people make them up just as much or generate equally incorrect graphs.

It's about time our trust into random visualizations is destroyed, without the actual formulas and data behind being exposed.

> Especially in JavaScript where I often share a lot of code between the client and the server and therefore also transfer data between them, I like to strictly separate data from logic

Which makes me wonder how it'll look like when interfacing with WASM. Better than Date?

They also have an overly reactive social media presence, somewhat similar to what ffmpeg has. Could end up being bad PR for Motorola.

Funnily enough that same social media person has some odd ideas about trust and PKIs.

>some odd ideas about trust and PKIs.

Can you explain what you mean?

Our project account posted a thread about our recent migration of our mail server to using our ASN and IP space. They replied to the thread by attacking Postfix, DNSSEC and DANE. They promoted the insecure MTA-STS approach promoted by Google despite them not fully adopting it for Gmail similarly to how they don't even use an enforcing DMARC policy despite punishing others for not doing it. We explained Domain Validation depends on DNS security. We also explained MTS-STS isn't the same as browser WebPKI due to an insecure bootstrapping and refreshing system along with lack of mandatory Certificate Transparency. We talked about Google's anti-competitive practices when it comes to email. Here's the thread, read it for yourself:

https://x.com/Avamander/status/2025719336552284161

The fact is that if you use the org TLD then you trust whoever runs it to issue certificates for your website and the same for your domain registrar. There's no point in pretending otherwise. It's very clearly how the system works. WebPKI does not truly add value over a TLSA record and DNSSEC beyond Certificate Transparency which is reactive and is NOT part of MTA-STS. MTA-STS also doesn't have mandatory encryption but rather opportunistic and can be stopped from using it. Gmail, the service which MTA-STS was created to be used with, has 1 day max-age for it.

Gmail has a lot of quite blatant security weaknesses and phishing weaknesses. People largely repeat the mantra of it being secure because Google account login security is decent including an option to make it harder to hijack accounts via customer support missing elsewhere.

Not really interested in a debate about it where someone repeats talking points often visible here and gets angry with us for not agreeing including getting angry because people like our replies.

https://x.com/Avamander/status/2025719336552284161

You take it too personally and if anyone is angry it's you. Listing shortcomings of a project is not "attacking", it's juvenile to think so. Shortcomings you refused to admit and your "explanations" were fundamentally misguided and incorrect. You eventually just resorted to FUD and blocking instead of actually looking at DNSSEC and DANE and the issues it has.

DNSSEC is a *bad* PKI, with infallible roots of trust, terrible adoption rate and horrible transparency. If someone misbehaves, you will have no idea, there will be no recourse and absolutely nobody is enforcing any standards on how things should be ran.

Bringing DMARC and phishing into this topic is a desperate grasp at straws if I have ever seen one.

DNSSEC defenders should actually know what they're talking about first.

I'm not sure it's even ethics, it might just also be about misaligned LLMs giving worse outputs and they don't want to make their models worse. Plus their models tend to be the least sycophantic and push back on inane stuff, giving in to those instead would also likely make the models worse.

Except anything that requires any non-trivial networking or hermetic building.

At the same time given the already terrible reputation of such vanity TLDs, being this hard on abuse might be the only survivable way.

That's not me saying there shouldn't be a warning and a recourse, but the time-to-profit for domain abuse is really short so anti-abuse actions have to be quick.

This isn't being hard on abuse though, this is being lazy and incompetent.

I'm fairly sure that Safe Browsing's false-positive rate is extremely low otherwise it'd be unusable in Chrome. Which also means that acting on positive results is very likely a correct approach.

Safe browsing is meant for websites, not domain names. You really want your registry acting on it and nuking your email services, intranet services, cert renewal automation, et cetera?

You think no bad actor thinks of that, using subdomains or whatnot?

Nor did I say anything about wanting a registry acting on it, it's just that the motivations and reasons are incredibly clear. At least to me.

And let me also reiterate that I clearly said that it should be a thought-out process and they haven't thought it out.

It's not just about being common, it's also about the share of abuse coming from such domains.

Or just incompetence, I had to lobby to get .org unblocked for mail at some CS faculty of a (not my) university, 20 years ago.

Usually not, just look at for example SpamHaus's top abusive TLDs. New TLDs dominate.

What's the benefit over Trusted Types?

Primarily because OP can't verify that the patch is truly correct. There's also the fact that anything LLM-generated will likely be frowned upon (for the same reason).

With some effort OP could review it manually and then try to submit it though.

But QEMU uses a mailing list for development, it's tedious to set up and then later keep track of. I now fundamentally refuse to contribute to projects that use mailing lists for development, the effort it takes and the experience is just so horrible.

Especially if it's a small patch that doesn't concern anyone (any big sponsors), you'll probably never get a response. Things get lost easily.