This cascade of comments is missing the point. It's like someone is pointing out the darker shade of clouds at the horizon and saying, "I think a storm is coming," and everyone here is just going, "Well, it could also be nightfall. I mean, the night has to roll on in at some point too."
Yes, it's just an initial check. But is it necessary? What exactly is the use case basis for Apple transmitting and logging data on every application you run on an operating system you have a consumer guarantee of zero-tampering post-sale.
So, let's work this out: How easy is it to not upgrade macOS, retain consistent performance as usual, and not lose support if the userbase remains unsatisfied with Apple's change to an exchanged good? By my understanding, as with Windows 10, Apple will eventually require you to upgrade. If you're upgrading to a system that maintains the same performance and does not introduce express limitations to the product post-sale, that's great! Go for it, live merry. However, in this case, the userbase has zero clarification on both co-owned data transmission and a remote check that appears to trigger a constraint on workflow. There's no use case basis that makes sense for doing this, because Apple has established guarantees for decades prior to this new process that claim macOS is not susceptible to malware. So, it begs the question: Was Apple violating consumer protections by making false guarantees, or is Apple violating consumer protections by limiting the function and utility of the product post-sale?
That's what people are asking right now. We don't care about the nuance of the check. We care about the basic characteristics of, and more importantly the legitimacy of any use case for this check, given promises made to consumers at a prior time of purchase.
macOS is, in fact, susceptible to malware. (A notable example hit HN just the other day [1].) I don't think Apple has ever literally claimed that it isn't susceptible, though they may have sort of hinted at it (especially at the height of the "Get a Mac" campaign). To be fair, there has not been very much macOS malware then or now, though it's questionable how much that has to do with macOS's design as opposed to factors like the size of the target userbase.
As drawfloat pointed out, Apple doesn't have to explicitly guarantee no susceptibility to malware. The FTC Act considers anything from an Elon Musk tweet about flamethrowers to a casual joke at Apple's Keynote, and weighs whether a reasonable consumer would expect the product to reflect that claim. That doesn't mean implied guarantees are as easily prosecuted. But it does mean that when Tim Cook or Steve Jobs, or another named executive, is on stage and says something along the lines of, "We don't have the same problems as Windows," and a reasonable audience member understands he's referring to malware risk on macOS vs Windows, that's enough to say Apple has made a legal guarantee to the consumer. The law is open-ended like this because promises can look like anything, from outright printing FREE SAME-DAY SHIPPING to printing in an FAQ that most orders arrive within 7 days. If it wasn't cost prohibitive, you could actually file a small claim against, say, Amazon, for a two-day Prime delivery not arriving within two days.
The broader point though, is that Apple has established the belief that macOS is not susceptible to malware. That's why people don't "need" a virus scanner running in the background.
And this belief is widespread enough that it warrants questioning the basis of a use case for this check: Why does macOS need to send my data to a remote server upon initial load of each application to verify it with Apple's whitelist (approve-list? what's the right term these days?), if the operating system's existing protection has to date fulfilled the implied guarantee by CEO, Tim Cook, and former CEO, Steve Jobs, of zero or limited, but otherwise insignificant, exposure risk to malware?
For code itself, which is what this change affects, code signing is verified by the kernel at page-in time. Combined with W^X, there's no way to bypass it. Verifying associated resources is done separately by userland and is a somewhat messier process.
More details here: https://eclecticlight.co/2019/07/09/understanding-signature-...