... While my father was technical in his day...post stroke, he's not quite as fast as he used to be...mom was never technical.

The entire problem is basically lazy programmers who want to pretend unix time is utc and let someone else deal with the problems*. It isn't. Changing to leap minutes actually makes this problem worse because it is even easier to ignore. Also the it being too easy to ignore is genuinely getting worse even with leap seconds. The idea was that there would be a leap second around once every 1-3 years, so everyone would deal with them regularly and it would be no big deal. But the Earth's rotation unexpectedly stopped slowing down, and then in 2020, started speeding up. (see this plot where the jumps are leap seconds) So there was no leap second between 1999 and 2006 and there hasn't been one since 2017 and there is unlikely to be one soon. There is actually discussion of whether we will need a negative leap second. That is in the spec, but has never been used and is almost never implemented because nobody thought it could happen. So the whole discussion of a leap minute is either essential or almost irrelevant because a negative leap second would break everything but we may not need one for 15 years or more.

* The problem being that the number of SI seconds between unix time of noon Jan 1 2020 (1577880000) and noon Jan 1 2010 (1262347200) is not (1577880000 - 1262347200) = 315532800, it is 315532803 SI seconds (including three leap seconds). i.e. you cannot subtract unix times to get a long time interval. Just like you can't subtract year*365+dayofyear to get the number of days between two dates. Unix time is not the number of SI seconds since 1970, it is the number of (utc) days since 1970 times 24*60*60. Exactly when those ticks happened on any given day is not well defined in the spec and different implementers have made different decisions (some repeat the last second of the day, some stretch the second for some amount of time before and/or after the leap second, sometimes the issue is ignored and the clock was just reset at some arbitrary time). Even the man page for "date" is misleading because the author was too lazy to sort this out and explain it. The simple fact is that a unix second and an SI second are not the same thing and the unix second is not even a uniform measure of time.

Not cold dark matter (cold here meaning the typical particle thermal speed is slow enough to be trapped in a galactic gravity well), since neutrinos would have had highly relativistic energies when they decoupled from other matter and the universe has not stretched nearly enough since then to make them non-relativistic yet.

They mean chirality, although it's related to spin. The weak interaction only works between left handed fermions and right handed anti-fermions. Since we can only observe neutrinos through the weak interaction we've only ever observed left handed neutrinos and right handed anti-neutrinos, although there's no particular reason to think the opposites don't exist (and some reasons to think they do).

I'm paying for a domain (including email) and I love it. However, gmail is useful in some legacy applications when you have to talk to a clerk and they ask for an email which you have to spell. If it's not one of the usual free offers they know (gmail, hotmail...) they won't spell it right or look weird at you.

Once I complained to the electric company I stopped receiving the monthly invoice. The clerk said probably because my email was "an old one I was not checking anymore", asked for a gmail address.

So here am I, regenerating an OAUTH token every week so I can use getmail6 to fetch my messages from gmail with POP3 and read them with mutt. At least, no ads.

Really? That's not my experience. I've been using it since 2005 and could probably count all spam messages on two hands

Create a model that will reliably distinguish spam from non-spam...

No need. Here's a post from over four years ago claiming 99.9% spam detection (presumably the model is even better now): * https://workspace.google.com/b...

Am I misunderstanding ? If so, please enlighten me...

You can bet the government will want to be informed about it.

Clearly the way to go is to have a trained machine learning model local to the app vet each image prior to acceptance. Benefits: * No dodgy images on your device * Probably stable use of space on your device

" .... The images can be encrypted with the regulator's public key."

That brings absolutely no useful value. A simple hash would give the same result and be much smaller. Encryption only has value if there is Decryption, without that all you need is a hash. Why in the world would you want to send millions of regulator content vice one user content, that's crazy!

"It is possible to do a series of Fuzzy Hashes to determine near matches but that begs the question of exactly what is near."

"I don't think it is possible to create a fuzzy hash for illegal images that will not either miss some illegal images or incorrectly identify legal images as illegal."

You apparently don't understand that you are arguing by repeating the same statement rephrased.

How much abuse would this stop? Probably none at all. This is about _pictures_ of child abuse being _sent_. It is not concerned with the creation of those pictures. And children that have their abuse not being documented (probably the vast majority) are apparently not a concern at all. The whole thing is a big, fat lie.

Apparently, new child sexual abuse images are expensive to produce. Most trading in such images is done with existing material, which is in the database.

Perhaps for now, recent examples of machine learning 'art' suggest this may not hold for long. In which case you might not want to publish any picture at all of your kids, anywhere.

snake

That might take quite a while, and necessitate expanding the phone's storage a bit. If they encrypt, changing even a single pixel on the image to be sent would make the comparison fail or they would have to use encryption so weak that the system might itself legally constitute distribution of child porn.

If they're serious about stopping the problem, they're just going to have to put their coffee or tea down and go check on the wellbeing of children.

Of course, they could also try following up on the evidence they already have from the whole Epstein debacle.

You think all phones should have an encrypted folder containing all known CSAM images/videos?! Constantly updated, I assume. You say storage is cheap, but we'd be talking about many, many terabytes of space. This is the most asinine thing I have ever heard.

There's no reason that the local app couldn't have the hashes if all you really care about is not being able to send copies of existing material that's been identified. There are also plenty of algorithms that produce hashes which don't depend on single pixel or other common types of changes that are designed to handle these types of common manipulations.

It hardly matters either way. Criminals will always find a way to break the law. That and any kind of database of existing media to watch for won't stop anyone from sending newly created content.