it's a vnc port, it'd also require the router to have it opened. Reading the article I think the user opened it themselves.
It does get opened automagically on the mac side when screen sharing is turned on.
> The problem is that for my particular use case — a headless, always-on Mac Mini that I primarily access from other computers and my phone through the ChatGPT and Claude apps — macOS is incredibly hostile
> As noted by the NCSC, the vulnerability is being exploited when port 5900 is exposed to the Internet. When screen sharing is turned on, the macOS firewall opens the port. Routers and dedicated firewalls generally block the port unless configured to override that setting.
> Obviously I should have — and will be — using a VPN going forward (the foundation of my entire approach to security is Tailscale); what I will note, however, is that TCC basically leaves me no choice but to have screen sharing enabled if I want to actually use my Mac Mini in the way I want to use it. I use screen-sharing constantly — including from my phone — and almost every time it’s to click “OK” on a stupid prompt that I’ve long since stopped taking seriously.
> Obviously I should have — and will be — using a VPN going forward
That's my takeaway from the article. I have trouble understanding how the author managed to extrapolate all these things about Apple from an obvious oversight on their part. I would never write a 3,000-word article about how bad someone else is because of an issue I caused for myself.
Software WILL have bugs and vulnerabilities, regardless of whether it's an OS or user application, whether it's from Apple or another company, or the update frequency/mechanism. If you can't even follow the most basic security practice on your part, you simply don't have any authority to discuss security otherwise.
Apple's remote access feature, that you would make remotely accessible for obvious reasons, apparently had a critical authentication bug.
Apple did not ship a security patch for this, allowing the vulnerability to be exploited a week later despite "automatically install security updates" being on.
Yes, OP could have prevented this by putting an additional VPN authentication layer in front of the Mac's built-in remote access.
> That doesn't excuse the mistakes on Apple's part.
Let's first establish that Apple definitely has a stake in this.
How long they can come up with a fix and then distribute them, that's a question. You can't expect any company to fix a vulnerability within 5min. Whether one week is too long or their delivery mechanism is good, I can't tell, and I don't think there is a standard in the entire industry.
That doesn't mean it's useful to write an article about "I didn't do my part BUT you are too slow". Even if Apple somehow fixes this within an hour of the disclosure and delivers the update, with the bad configuration, the machine is still vulnerable within that window. Does that change the nature of the narrative?
An actively and easily exploited (just a port scan), and high-impact root RCE needs faster patching than one week.
When there was a more user visible bug (2017, empty root password gives you root, CVE-2017-13872), Apple managed to remotely patch this across all supported macOS versions in about 26 hours + next macOS online, end to end, without user intervention or manual updates.
And that was a decade ago before Apple built “rapid response security updates”
I don't think anyone criticized the timing of the patch.
But I find it egregious that they didn't roll it out as a security update at all, which is why it was not automatically installed in OP's case, even though the fix was already available.
I mean, what else requires a hotfix via security update if not a fatal flaw in your remote access authentication leading to full root access, that is actively being exploited in the wild?
Also, it's not really on the user to gate remote access behind an additional firewall and authentication layer. This is something that just has to work securely.
If it doesn't, that's understandable, but still hardly the user's fault.
> what else requires a hotfix via security update if not a fatal flaw in your remote access authentication leading to full root access, that is actively being exploited in the wild?
> Also, it's not really on the user to gate remote access behind an additional firewall and authentication layer. This is something that just has to work securely.
The thing is that many of these people think they know what they are doing and do not think about security, only how awesome LLMs and AI make their experience until something bad happens.
Even though this was a valid critical bug [1], you need to enable screen sharing and allow connections to and from port 5900 on your router for a remote person to be able to exploit this.
Any security conscious person would probably be using a VPN (Wireguard or Tailscale) to prevent something like this, in the first place.
> almost every time it’s to click “OK” on a stupid prompt that I’ve long since stopped taking seriously.
The line above tells you how seriously this person takes security prompts.
I mean, every time ISPs, NAT, or IPv6 is mentioned you have a LOT of people who are really angry they can't just netcat a random port on their friends' machine to send files to it.
I have no idea about the claim of a backdoor. But here is the source:
Matt Mackall:
"It's worth noting that the maintainer of record (me) for the Linux RNG quit the project about two years ago precisely because Linus decided to include a patch from Intel to allow their unauditable RdRand to bypass the entropy pool over my strenuous objections. "
The fact that Intel Bull Mountain (code name for Secure Key Technology), and NSA's BULLRUN program share the name "bull" is a complete coincidence. I'm sure.
On many systems like Raspberry Pi the <v5.6 kernel /dev/random or /dev/urandom lacked sufficient entropy to properly deploy wifi hostapd WPA2/WPA3 services.
Instead, people used haveged to workaround the issue. Not a conspiracy by some dude, but rather just more budget hardware limitations.
Don't worry about it, there are lots of real dubious things people do already. =3
An acre of alfalfa is typically irrigated at 5.5 AF per year. The standard center pivot field is 130 acres ~ 700 AF of irrigation, to grow alfalfa to ship overseas. Converting to gallons, 210 million gallons, for one field.
80 fields of alfalfa equals all the data center water usage.
USDA estimates that total irrigation uses 55 million AF of water per year.
"In other words, we want UTC noon to be within a second of mean solar noon on the prime meridian."
Why?
If I travel 1 mile east or west of the prime meridian, my solar noon now comes 2-3 seconds earlier/later. It's nearly impossible to have your local time match your local solar noon. For most of the population, solar noon is, on average, 30 minutes off of 12:00 noon.
Um, because it's the prime meridian and that's how UTC is defined?
> It's nearly impossible to have your local time match your local solar noon.
Which is why I specified on the prime meridian, which is the particular local meridian that UTC is defined as corresponding to.
> solar noon varies from day to day by 10-20 seconds.
Which is why I was careful to specify mean solar noon.
I'm not quite sure what your issue is. Yes, we have time zones tied to specific meridians, and the actual sun's speed in the sky varies (which I mentioned in my post, so I'm not sure why you seem to think I'm unaware of it) so in most places local time by the clock doesn't match local time by the sun. Yes, a leap second adjustment to UTC is quite a bit smaller, taken in isolation, than the annual variation in actual solar time vs. mean solar time.
But over time, if we didn't have leap seconds, the difference would accumulate. The accumulated difference now between UTC and TAI is 37 seconds--which is almost twice the maximum variation in actual solar noon from mean solar noon that you refer to. We humans have collectively decided that we don't want that, and that it's better to do the adjustments a little at a time rather than in bigger lumps.
"But over time, if we didn't have leap seconds, the difference would accumulate. The accumulated difference now between UTC and TAI is 37 seconds--which is almost twice the maximum variation in actual solar noon from mean solar noon that you refer to."
No, the 10-15 seconds I mentioned is the daily variation in solar noon.
From the link I posted, in NYC, solar noon on 2026-01-01 is at 11:59am. On 2026-01-31, solar noon is at 12:09pm. In one month, it has drifted 10 minutes. That's much greater than the 37 leap seconds we have added in 60 years.
"We humans have collectively decided that we don't want that, and that it's better to do the adjustments a little at a time rather than in bigger lumps."
Yet we just reversed that decision. No more leap seconds after 2035. After trying it, we decided it was terrible.
> the 10-15 seconds I mentioned is the daily variation in solar noon.
Yes, but averaged over an entire year, it still comes out to zero. The difference between mean solar and atomic time does not. It accumulates over the years.
> we just reversed that decision
We paused it for 100 years after 2035. That doesn't change the physical fact that the Earth's rotation will continue to slow over the long term. We might eventually decide to just not care about that when it comes to civil timekeeping, but that's not what the decision you're referring to did. It just said we can afford to let the difference between UTC and TAI accumulate from 2035 to 2135 (by which time it is predicted to be about a minute) while we figure out what we want to do over the longer term.
> Um, because it's the prime meridian and that's how UTC is defined?
That's an explanation of how it is, not why we should care to preserve it.
The definitions of hours minutes and seconds have changed before, and in recent history.
> Which is why I was careful to specify mean solar noon.
And "mean solar noon" is meaningless to people's lives. Even in the areas where time zones do follow meridians and not country borders that are many minutes off.
> The definitions of hours minutes and seconds have changed before, and in recent history.
In terms of what physical process we use to set the standard, yes. But those very changes were made to try to preserve the same time periods that were important to humans. In other words, to not change what hours, minutes, and seconds mean intuitively to us humans as we go about our daily lives.
I completely disagree. The intuitive meaning is that a day is 24 hours and you can divide that by 60 twice. But that makes the second vary by some parts per billion, so we nailed down the second to make the technical side easier at the expense of relatability.
> The intuitive meaning is that a day is 24 hours and you can divide that by 60 twice.
And that's exactly why the SI second has the length that it has--to be as close as possible in terms of how atomic clocks work to 1/86400 of an Earth mean solar day at a chosen epoch. (Note that the actual definition before the atomic clock one was adopted was in terms of the Earth's tropical year at that epoch--but the fraction of the tropical year that was chosen was to line up the second with 1/86400 of an epoch day.) If we didn't care about "relatability", nobody would have gone to all the trouble of trying to determine how many cesium clock oscillations there were in 1/86400 of an epoch day.
I'm not so sure. The concept of 24 hours in a day originates in civil timekeeping, yes, but not minutes and seconds. Those originally came from astronomy, and corresponded to angles, not times, and those angles are constants; they don't change as the Earth's rotation slows down or as its speed in orbit around the Sun changes over the course of a year. I don't think people's intuitive concept of minutes and seconds is that they vary according to the time of year or the tidal effects on the Earth.
> I don't think people's intuitive concept of minutes and seconds is that they vary according to the time of year or the tidal effects on the Earth.
But if you asked people to choose between "seconds vary by an imperceptible amount, less than your clocks naturally drift" and "an hour doesn't have 3600 seconds" I bet most will pick the former.
And it doesn't have to drift day by day, you can average it over a multi-year period.
It's going to be weird once the earth slows down enough that we'd need a leap second every day or two. Once you can't ignore the drift anymore, the system we chose is significantly unintuitive.
> If we didn't care about "relatability", nobody would have gone to all the trouble of trying to determine how many cesium clock oscillations there were in 1/86400 of an epoch day.
I'm not saying we didn't care about it, I'm saying we didn't put it as top priority. We went with a nice clean fixed-length second that will drift away from the Earth over time. And it wasn't/isn't that hard to determine the number of oscillations since "matching" the Earth's unstable speed has a huge margin you can land within.
> Would you also say that getting rid of leap seconds and allowing UTC to gradually drift away from the sun is making the technical side easier at the expense of relatability?
Yes.
I'm in favor of both, to be honest. But it's a tradeoff, and it's a tradeoff that weakens the layman's definition of a second.
> we nailed down the second to make the technical side easier at the expense of relatability.
Would you also say that getting rid of leap seconds and allowing UTC to gradually drift away from the sun is making the technical side easier at the expense of relatability?
For things that need much more precusion than my lunch, ±1 second probably still isn't good enough, so they need another layer of correction anyway. Given that exists, might as well push leap seconds into that layer too.
The point is that quantizing the range makes it easier for humans to choose colors. But there's already the #ABC hex format, which while less intuitive to non-techies has the huge advantage of being well-established.
But it doesn't make it easier for humans to choose colors. For a specific list of detent colors, it reduces the amount you have to memorize relative to full RGB. But to actually reason about colors, you want a non-arbitrary scale; HSV (for instance) gives you hue direction and then you can slide saturation and brightness around.
I don’t know, but I use #ABC a lot, it’s much more convenient than #ABCDEF, never mind [0, 256) or [0, 1]. There are of course more intuitive coordinate schemes and color models, but I find RGB easy enough when you’re not actually doing serious graphic design. This is not about having a GUI color picker either, this is about hand-typing colors.
Maybe it’s just because I’m old and wrote CSS way before it got HSL or other fancy color functions, but personally, RGB colors are really deeply entrenched in my brain.
I think my thing here is, you can do any notation for colors you want. "Splash" is custom. So you might as well do a better custom. "rrb85" for "red, red, blue, 80% sat, 50% value" for a dark purple --- one step towards red from the midpoint between red and blue. I don't know, something! RGB is kind of bad!
Despite my background in color science, I find RGB more intuitive. With HSV I have to remember the chirality of hue and it's zero point, and when changing hue I find it difficult to reason about saturation. In practice this means I must "nudge and judge" with both systems. With RGB I can always make progress. With HSV I guess hue wrong about half the time. I could probably improve this.
To be fair, I'm also colorblind. That's probably relevant.
Anyway, I'd say the answer to both your questions is: "sometimes"
All you're arguing is that it's easier to memorize primary and simple secondary colors in RGB. No question, it is. Once you've got one of those detent colors locked in, how do you vary it? What does it mean to bring up i% of the first channel, j% of the second, and k% of the third? That's the problem HSV solves.
Why would anyone open up random ports (or even all ports) to the internet?
reply