Interestingly, I was in a lab yesterday and met a PhD student whose thesis was largely about using LLMs to fake fingerprints and retinal scans.

Tesla's own stats, which I don't believe for a second.

And those stats are for managed "Full Self Driving", where a human has to monitor it all the time. Competitors have had actual self driving cars where there is no full time human monitoring, for years.

This is one AC that deserves to be modded up. I already commented, so I can't.

You are aware of what happened Oct 7, 2023, right?

Actually, islamic fundamentalists qualify for that statement in absolutely every way. So at the absolute minimum you'll have to concede that there are two fascist sides.

For sufficiently gracious definitions of "working". Iran was quite busy building up conventional weapons including delivery systems that could be re-purposed for nukes as well as moving towards nuclear weapons. There is no civilian use for 60% enriched uranium. Moreover, the number "60%" is misleading. The work to enrich isn't linear. When you have 60%, you're not 60% of the way from raw to weapons-grade, you're 95% of the way.

To put into context just how insane any claim that they had 60% for any peaceful purposes is: Most nuclear reactors use uranium enriched to 3% to 5%. 60% isn't "a bit more than usual". It's a fuckton more than any non-weapons use can reasonably explain.

Iran didn't need a reason. We all know the reason they already had: Wiping out Israel.

And no strike or other interruption has ever made them learn that JIT isn't all flowers and happiness and moving your warehouse to the road has more consequences than cost savings.

Wasn't this very article on SD a few weeks ago? * using a Mint computer right now and it works as well as ever.

Have you considered hiring someone on a contract basis to maintain ufraw? If you depend on it, surely it's worth investing in.

My experience with Debian is similar. Much less broken stuff than Ubuntu or Mint. But also the usual problems with things changing in breaking ways between versions, which makes instructions on how to do things outdated within a year or two, 3rd party software stops building and so on... Like you, I have VMs with obsolete versions of Debian and Ubuntu, just to keep certain bits of software working. Meanwhile on Windows I can still install a version of MPLAB from the 90s to build some old firmware.

Out of interest, how do you discover the IPv6 addresses of your IoT devices, so you can connect to them?

I looked into IPv6 for home use a while back, and basic stuff like adding new devices to the network and finding them is a bit of a nightmare.

On IPv4 with DHCP it's easy enough to just scan the entire subnet looking for the new device, if you don't know its IP address. With IPv6... There are three of four different ways devices can make themselves discoverable, and Windows support for them is a bit limited.

IPv4 works, it's familiar, it's easy. That's why there hasn't been a big migration. There just aren't big benefits for most people, and there are considerable downsides.

The spec contradicts itself in various places, with sections saying that the app interacts with the attestation provider only once and that the attestation cannot be reissued, and other sections implying that the attestation gets reissued every three months and that the tokens are single-use.

It also isn't clear about whether they are actually using 18013-5 or are just requiring companies to implement a few tiny fragments of the spec.

I was left more confused after reading the spec than I was before.

Looks like I spoke too soon. The specification massively contradicts itself. 3.4.2 requires reissuance every three months, and requires that it issue 30 attestations at a time, and that they be single-use.

That part is architecturally correct, though allowing access to only 30 adult sites per three months is dubious. And if getting a new proof requires a new request at some point, then it becomes possible for the trusted list provider, conspiring with the proof of attestation provider, to cross-correlate the timing of requests and unmask a user with high probability.

And then, there's this:

So you still have a value that is potentially usable for tracking across multiple websites. It's just a timestamp. I'm not sure if I'm reading what they're saying correctly. If they mean all 30 in a batch have the same value, this is a disaster. If they mean always set the value to 00:00:00 so you get only one day of precision, that's better than nothing, but when the request comes from an area with low population density, it is still potentially inadequate for anonymization.

I can't make heads or tails of this specification. It contradicts itself in too many places, and it buries you in minutia while lacking a clear overview. It's the kind of spec only a bureaucrat could love, because it is perfect for verifying compliance, but makes it nearly impossible to quickly verify that the spec makes sense. It lacks a section on threat models and how it addresses those threats, which is the first thing I'd expect to see.

At this point, I have no idea whether this protects privacy or not. And that's perhaps more disturbing.

It is possible, in theory. But calling this "completely anonymous" is hopelessly naïve, IMO, unless I'm missing something *huge*.

Announcing that this is "technically complete" is laughable. I have not seen a single public white paper on the subject. We should have seen years of back and forth between academics, crypto experts, operational security experts, privacy experts, and other groups, as they all tear apart the design over and over again until it is refined into something that actually provides the claimed anonymity.

The lack of this public discourse leads me to the inevitable conclusion that it almost certainly provides the illusion of protecting privacy, while in fact massively violating it to a greater degree than ever before.

And sure enough, I started skimming the technical specification, skipped the whole first section, which was mostly justification, and almost immediately found a fatal flaw.

Unless I'm missing something, this is a show-stopper, and points to the entire architecture being fundamentally unusable:

What this means is that a user gets a magic token that proves that the person is of a particular age, then submits that token to sites for verification. Here's a list of problems with that approach:

• The same attestation is sent to every site. So the fingerprint of that certificate becomes the *ULTIMATE* tracking cookie. Every adult website will effectively know who you are. They won't know precisely who you are, but they will be able to correlate activity across sites, target ads to your specific behavior across multiple sites, etc.
• It is impossible to regenerate that token, so once your privacy has been thoroughly raped and random websites are showing you adds for hardcore porn, you can never turn it off.
• As soon as you pay for anything with any of those adult sites, your identity is now known, and can be correlated with your activity across all adult sites.

Using the words "privacy rape" to describe this technology is not nearly a strong enough statement, but it is the strongest phrasing I could come up with.

Protects anonymity, my ass.

About the only good thing that can be said about this is that because they didn't specify minimum requirements for storage protection, chances are it will get hacked in the first week, and a few adult users' attestations will show up on the dark web and will get used by a few million underage users' devices, making it useless as proof of age, and hopefully resulting in the folks who thought this approach was adequate quickly shutting it down.

Like I said, give us a public comment process, articles published in multiple reputable journals, etc. and in five to ten years, this will be ready. It's not ready. It's not close. It's not even in the right ballpark.

For this to be completely anonymous, it must not be possible for a government actor with control over infrastructure to perform timing attacks on anonymity, e.g. user requests auth token from government, government knows who that user is, government sees unencrypted DNS request to porn side ten seconds earlier, correlates the requests.

Doing this correctly is genuinely really, really hard. You need:

• A different token sent to every site, with no common data that can correlate accesses across multiple sites.
• No ability to correlate the timing of the user's request for proof and the timing of a user connecting to a website.
• No ability to correlate the timing of the user's request for proof and the timing of a verification request from a website to the verifying authority.

This starts by the verification authorities outsourcing the verification to the "RP" (relying party). Public keys used to verify the signature. That way, the government entity doing verification does not have any record of verifications to correlate with requests.

This continues with the client queueing up a thousand or so pre-signed certs from the signing authority, and requesting replacement certs on a time-based schedule (once per day, with randomization of the replacement rate, with the client silently discarding excess certs so that you maintain a consistent pool size).

This is a starting point. I'm not saying that these things are sufficient, just that they are necessary.

That's the problem. Luls you into a false sense of security, then when you aren't paying attention it fails and you die.