The same PF bug is breaking one of OrbStack's networking features. I found it hard to believe when I narrowed it down to this, but I guess I'm not alone. Really hoping this is fixed before the stable release.
I didn't get a chance to report this to Apple until yesterday, but I think it's a fairly recent regression, probably from around beta 6.
PF is supposed to be a last-match firewall but it's almost like macOS is doing first-match now: an earlier "block" rule (without "quick") is overriding "pass" rules in a different anchor, which obviously breaks things.
"really hope" is too weak. This has to be fixed before release. A stable release with this would be unacceptable and would be reason for me to abandon Mac OS. You don't deliver a product with this kind of regression if you want it to be used for any kind of serious business
Maybe you don't deliver products like that, but Apple delivers them all the time. Then you have to desperately raise noise on all possible forums, and hope to catch the eye of someone who actually works at a relevant team at Apple, before your customers get too tired of the issues caused by the bug and abandon you.
This is not an Apple-specific issue either, Microsoft works just the same. Large OS releases are a massive undertaking, and the release train don't stop for a
firewall bug - no matter how severe the bug is for the people it does affect.
I remember the time around iOS 5-6, they made some delays and probably it fired back on them and since they have delay related PTSD as an organization. I think since then they just have to push whatever it takes. I remember after iOS 7 I almost left the ecosystem it was so buggy and almost unusable. They probably measured it because after maybe iOS 9-10 they started to be very proud of fixing and stabilizing stuff even in product announcement and iOS is very stable now, not recognizing an issue for years maybe. But this had a price, they paid it, now they seem very aggressive on schedules until the next major clusterfucky year.
Half the time I hear of Mac OS updates, it's people having their Macs bricked because they didn't wait for patches to the main release to come out. Every major release seems to have major issues. At least this doesn't render your Mac completely useless.
Great writeup, very succinct and informative, they even have a simple reproduction of the bug.
I love Mullvad!
Tangentially, MacOS has had a lot of weird firewall bugs in the last few releases in general, I wonder what drive them to rip up and redo (I assume? so much of it recently.
The rewrite was definitely influenced by the mandatory migration from kernel extensions to userspace System Extensions, specifically NetworkExtension, between Catalina and Big Sur: https://developer.apple.com/documentation/networkextension
For a firewall I'd ideally want some degree of formal verification. It's not something you fuck around with if you're serious about creating a secure product - like an operating system.
There are caveats, but not "you cannot verify interfaces" or anything else that would somehow disqualify validation of network packet processing - something a mere unit-test could handle.
The real counter to formal verification is that it is too much work and not a normal thing to do.
In the case of formal verification done with proof assistants or similar, I believe the way it works is something like this.
The people who develop such software start out writing a verifier for a much system of logic or programming than what the final system will handle. This first system is sufficiently simple that the verifier that can verify programs in that system is very small and straightforward, so that if several humans look at it and can't see any bugs it is almost certainly correct.
Then they write a verifier for a more expressive system. This verify isn't as small or straightforward and so even if humans don't see any bugs we can't be confident that there none. They then use the first verifier to verify the second verifier. The formal proof of correctness might be long and difficult to develop because it can only use the reduced logic of the first verifier, but once they manage that and the first verifier verifies it, they can be confident that the second verifier is correct.
If the system the second verifier still isn't expressive enough to verify the things they ultimately want to handle they write an even more expressive system, and use the second verifier to verify that.
Repeat until you've got the system you wanted in the first place.
You know having some bugs in there is not that problematic as even if they stay in the shadows, most product bugs are catched anyway. Also these make false alerts, then instead of fixing the nonexistent bug, they fix the test suite.
While this is worthwhile, there is an opportunity for the math to violate your assumptions in a way you didn't understand. Let's talk briefly about TLS 1.3 Selfie attacks.
TLS 1.3 is the first TLS in which experts built a formally verified model of the protocol before they shipped the standard. There are models of earlier TLS versions, but nothing learned from them could be incorporated into the corresponding standard because they were an afterthought - like writing unit tests after shipping version 1.0
TLS 1.3 has a mode intended for applications where some nodes which have a pre-existing relationship communicate, in this case we don't need the Web PKI ("SSL certificates") instead we use Pre-shared Keys (PSKs) - that is all the parties know the keys anyway, which clearly couldn't work for the open web but is fine for my boiler and its remote thermostat since duh, I don't want some random other person's thermostat talking to my boiler. PSKs are also used when you connect to the same server again later, but that doesn't matter here.
The mathematical proof seemed to say exactly what the designers wanted, and it passed. So TLS 1.3 is exactly what we wanted... right? Well, almost. Designers were thinking of symmetries like "Alice talks to Bob" and "Bob talks to Alice" as one conversation, but the proof thinks that's two conversations. So the proof thinks Alice and Bob need two keys, the Alice->Bob key and the Bob->Alice key, while humans assumed they only need a single key, an Alice-x-Bob key. And so the RFC documents (prior to errata) the human assumption but the protocol actually requires the machine assumption.
The result is the Selfie Attack. In our scenario Alice, and Bob have a Cat. The Cat, like many cats, would like more food, but Alice and Bob use a secure protocol to ensure they only feed the cat once.
Bob has fed the cat and left. The cat is sat by an empty food bowl looking plaintive. Alice sends Bob an encrypted message, "Did you feed the cat?". The Cat intercepts the message, it doesn't have the Alice-x-Bob key so it can't decrypt this message nor directly answer it, but it doesn't need to. The Cat simply sends Alice's own message back to her. Receiving a message encrypted with the Alice-x-Bob key, Alice concludes it's from Bob. "Did you feed the cat?". So she replies "No, I did not feed the cat". The cat receives this message too, and directs it back to Alice as well, now Alice has what appears to be a reply to her first question, "No, I did not feed the cat" encrypted with the Alice-x-Bob key. So, Alice feeds the cat again because the cat was able to trick her into answering her own question.
I like your simplified example, but it does miss an important nuance: Alice has to act as both a client and a server, must use the same PSK for both roles, and must not (or not be able to) check the sender or intended recipient of any message.
TLS handshakes were never designed to be symmetric. Every TLS connection is clearly between a client and a server. Alice and Bob, both running a client and a server, where both servers use the same PSK, is not a TLS setup. It's two (2) separate TLS setups.
The math was never intended to verify if sharing PSKs across independent unrelated servers is safe. In fact, the Selfie attack is not really a "selfie" attack; it works even if Alice hosts only a client and no server, as long as there exists an Eve that hosts a server (but not necessarily a client).
> Designers were thinking of symmetries like "Alice talks to Bob" and "Bob talks to Alice" as one conversation ...
I strongly doubt that. A TLS connection, once established, is symmetric, sure, but a TLS handshake isn't. The failure mode in Selfie isn't in the post-handshake domain. It's not like Selfie allows you to take packets from an already established connection and play it against an unsuspecting server that has no connections, and thus making it think it has a connection.
The failure is literally this: Alice says "Hey I wanna talk to you" intended for Bob but doesn't specify who, exactly, are "I" and "you". The Cat records Alice's speech and replays it to her, making her believe someone is trying to initiate a new, separate conversation.
The verifiers writing the proofs would be acutely aware of the asymmetrical nature of TLS handshakes. In fact, I strongly doubt they even considered any case where the same entity hosts both a TLS client and a TLS server for a shared purpose.
This is Hacker News, where people who know nothing about a topic come to tell each other about their expertise. You believe no-one would make this type of mistake, I know they did and I have just provided you a link to the paper at the time. Alas some people will believe you, and they will assume that they too are infallible and the rest is inevitable.
Thank you for reminding me to read the original report again. However, I still don't see any evidence to support your claim that the designers assumed TLS connections to be symmetric in their establishment.
Maybe I'm reading the report differently from you, or maybe I'm misreading it or missing sth — though I did honestly try to read it from your perspective — but I just don't see anything in the report where session establishment or resumption ignores the role of a participant. A client is still a client that cannot receive new connections and a server is still a server that cannot initiate connections.
The report does support my reading of the issue though:
1. That Selfie would not be possible if a server checked the intended recipient of any handshake message it received; and
2. That Selfie would not be possible if the assumption that a PSK is a secret known only to one client and one server were not violated. How it is violated — whether by reusing the client and server host nodes and deploying the opposite roles on each (your symmetric case), or by setting up two extra, completely unrelated and independent host nodes (no symmetry here) — does not matter. They are both violations of secrecy of PSK and thus vulnerable to Selfie either way.
----
> You believe no-one would make this type of mistake
I did not "believe no-one would". I "strongly doubted" (which is subtly, but importantly enough, different from belief) whether a proof writer who's intimately familiar with TLS handshake (again, not "no-one") "would".
> Alas some people will believe you, and they will assume that they too are infallible and the rest is inevitable.
I ... don't see where this is going. Or why.
> What did Dorothy Parker say about Horticulture ?
Okay, you've definitely lost me.
----
Look, I'm not arguing that mathematical proofs are infallible to modeling inaccuracies, or that they should be trusted blindly. Or that people can be perfect if they have enough expertise. Absolutely not. I only disagreed on some nuances of the specific example you provided.
But you may not be interested in that. Especially given how you generalised my words above (and thus erased them of all nuance), I'm going to read the signs I see, write this whole thing off as basically an exercise in pedantry, and end this here.
Thanks for your example. I am not very familiar with it, so I learned a few things.
I guess I see the point of OPs question now.
The formal verification can only prove that something works according to a specification, not that it (or the specification) does what x stakeholder wanted.
In this sense, it makes the error surface smaller, but does not remove it.
There are a lot of errors and faults that show up in Console on a brand new MacBook just sitting on the desktop. And with every version the number seems to increase. So it's not even their test suite that's the issue.
For me, it's a benchmark of a well made system - the lower bandwidth of log output you get when a user machine is idling, the better. I have seen some Android phones produce megabytes of logs just sitting there - you can test this by running `<whatever command outputs logs> | pv`.
It's also a good metric to signal an anomaly after a deployment. On my desktop machines, the current culprit for most of the logs is pipewire/alsa, generating multiple lines per second.
Maybe in some scenarios it shows a fault that is absolutely unnoticeable, but every real world case I've seen was at least theoretically noticeable by the user.
My system's running fine with no noticeable issues. I opened Console to check for faults and after running with logging on I eventually got a couple, all tied to Safari trying to read a preference from a domain it didn't have permissions to. No performance issues or other user-detectable impacts.
#define os_log_fault(log, format, ...) \
os_log_with_type(log, OS_LOG_TYPE_FAULT, format, ##__VA_ARGS__)
It's literally just an os_log with the "fault" type set. You can call it whenever you want. Most libraries have a couple sprinkled in for things that someone should probably check at some point but there is no actual semantics to it to mean that something is necessarily broken.
On the contrary, I find your position to be confusing. It's just a function that anyone can call. If you go on GitHub you can see many people who are using it for whatever logging they think is appropriate. Why do you think it has anything to do with correctness? This isn't like a crash or a OOM where you're generally pretty sure something is seriously wrong, because you can just trigger this whenever you want.
When my computer can't even stay up for a full week without crashing, or suffer an inexplicable lag spike, etc., I become more motivated to closely examine everything to see what's causing the crash.
My M2 pro gets plugged in to the work monitor most days and then unplugged and taken home and plugged in to my monitor at home - 10 or so screen configuration changes a week... I've never found I've need to restart due to any issues with any regularity with this one or my old 2015 MBP that this replaced.
I installed the most recent update five days ago, would have been weeks since the last reboot. From my experience, I'd probably put it down to some software they've installed, or yes, possibly an actual hardware fault with that particular unit.
My Macs stay up for months and have since Jaguar days. I use them for around 7-8 years, after that hardware starts to glitch or get obsolete. I can count on one hand the number of kernel panics I’ve had on each during this time.
My previous mac would crash every few days inexplicably. I thought it was mac os x becoming less stable. Then I switched to a new mac (the m1) and stability improved significantly so yes that does make sense.
If there's an issue, how are they supposed to know about it? Via osmosis? Even if they should have found it earlier, they didn't, so now what? You should tell them, so they can fix it.
Some of us who came up on the ops side routinely check logs. It is both how you spot problems other monitors might miss and partly how you learn how your system works (or doesn't). Especially with MacOS, where the documentation quality ranges from shit to nonexistent and the source is unavailable.
"Clarity" is not a word I would use to describe the macOS logs.
The number of log entries shown in the console is overwhelming. All the background services constantly log ~100 messages per second, so the log entries you are looking for disappear immediately.
You can use the search filters to narrow down messages if you know what you are looking for, but if you don't already have a suspicion where the problem is coming from, then the macOS logs are close to useless.
Apple made logging “cheap” in Mavericks, IIRC. They made a big deal that by coalescing and compressing writes, using a database instead of flat text files, it would use little memory and battery, or something like that.
Anyway, Console.app got way more verbose after that. I don’t like it, it’s too noise for me, but it doesn’t necessarily mean that lots of things are breaking under the hood.
No he means from the Console app on macOS. It's not the same as the Terminal app, which it sounds like you're referencing. It's a log viewer that's installed by default but tucked away in Applications/Utilities. It's similar to dmesg I guess.
I think this pretty accurate. After messing around with the .0 versions of macOS a few times I also learned that the common wisdom is to only install OS updates on .1 versions.
If you're concerned about these kinds of bugs on your local OS platform you may consider "abstracting away" your local connection point via a remote browser. This way, whatever your local machine and OS, you can have a dedicated server that you run your browsing through. Granted it doesn't enclose your entire network connection: only your browsing, but what it does there is change your IP address, mask your location, and add protection from browser 0 days.
We're constantly adding new features add BrowserBox to respect and protect privacy and improve the overall experience. It's open source so you can change it how you want too. If you don't like AGPL-3.0 you can get a commercial license. Come take us for a spin: https://github.com/dosyago/BrowserBoxPro
If you don't want something open source, but prefer the joy of a large company I think Mullvad also has their Mullvad Browser which does something similar!
Yeah, thank you. It does actually have use cases for regular folk!
About the IP: No actually. I'm not sure why that is, but I assume because a lot of premium VPN services and proxies need to end up going through IP blocks used by cloud providers as well these days.
Most of the blocking I've seen comes down to how well the browser presents as a regular browser. If it looks like an automated bot browser (just raw headless, or whatever) it's more likely to get blocked in my experience than from the IP address.
Although you certainly get some IP blocks or individual IPs that are more likely to get blocked. No offence to DO, but I've noticed their IPs are less reliable. I've never really had an issue with AWS, GCP, Vultr, Linode or Hetzner, except for the odd machine that somehow has an IP address that must be on a ban list, I'd estimate it around 5% probability of getting such an IP from the regular providers tho.
It's not macOS firewall, but Apple's implementation of OpenBSD's pf used in Apple's macOS. Mullvad is clearly pointing at a bug in OpenBSD's "packet filter", mentioning that it's used in macOS.
Mullvad's article lacks proper wording and shits on the wrong target.
You're way off base and I can see you feel quite frustrated by what you perceive as a slight against OpenBSD. I know and have used "pf" in OpenBSD. Not once while reading the article did I think Mullvad were referring to pf as a technology as opposed to the macOS implementation of pf where the bug resides.
Unless there is an equivalent OpenBSD bug, why would it be their issue? Low level components often are patched by Apple to work with Xnu. If the same bug isn’t showing up in OpenBSD, it’s more likely Apple’s integration or a “feature” added by Apple.
Maybe there isn't such a huge intersection between BSD and Mullvad users? It would seem though that Mullvad might try to see if the problem narrows down to the BSD implementation, but that's hard to know if they haven't stated that explicitly.
The OpenBSD OS is roughly as relevant today as it ever were. The OpenBSD project has significantly grown in relevance since inception through OpenSSH, LibreSSL and dozens of other high-quality implementations.
I don’t know if related, but immediately the last two MacOS upgrades I was unable to get my networking to work. I could connect to Wi-Fi / Ethernet / Hotspot. But nothing would actually connect (e.g. browser, pings, etc) , not even to my router.
The fix both times was to open the Mullvad VPN app just once and everything worked again. No idea why just opening the app would fix the issue.
No wonder, I recently installed the latest sonoma beta and couldn't for the life of me get Mullvad to work. Glad to hear Mullvad is working on a workaround. I even considered downgrading back to Ventura this morning. I feel validated!
Went to look at tailscale vpn and didn't realize it was a service entirely contained within tailscale, so I can't use my existing Mullvad account or credit tailscale with my already-purchased Mullvad credits :(
I don't think the service is so much "tailscale for mullvad users" but the other way around, it's intended for existing tailscale users to get an "exit node" of sorts in their tailscale network without having to set it up themselves.
Tailscale's business model has never been anonymity, last I used them they even required either a Google or O365 account to even use the service.
You might want to look into Headscale[1] instead, it's a server-side implementation of Tailscale that you can self-host. It comes with its own drawbacks but from what I've seen it's worth it if you want more control over the network.
I have seen a case where they substituted the credits on Mullvad to the add-on for Tailscale, but this might not be a regular thing.
Although, it is also still in Beta and issues have been reported/known, so similarly if you look for a stable solution it might be best to hold out for now.
MacOS has had a host of these types of issues with their network stack over the last few years. They are almost always related to some "Magic" technology Apple is introducing such as AirDrop (raw wifi frames), Siri (multipath tcp) et. al. Essentially Apple have been introducing these new components with special elevated privileges which allow them to bypass or have priority access to the network stack in order to implement whatever brand of cross-protocol hoodoo they may require to function. At best, it's maddening, but at worst its a huge red flag that Apple seems ready and willing to accept these compromises into the functionality of their system. It is impossible to achieve total software control over the network stack in MacOS today.
Not publicly that I have seen, but I can assure you networking and cybersecurity companies (and others) saw this pretty quickly when the bug was first released. I was just glad to see a relatively big company calling out this rather egregious issue.
Security companies should be much more open about these issues, rather than quake the notion that if they go public, they’d lose their hush hush secret contacts at Apple that give them private entitlements for private functionality. (Source: first hand experience)
Those are public capabilities that require explicit approval from Apple in the form of an entitlement. That’s not what I am saying.
I’m talking about capabilities Apple officially denies having, or only gates to “partners”, and vends them using private header files and entitlements. One example is VPN service, which, before the NetworkExtension, were limited to the “Cisco”-branded user UI in Settings and MDM configuration files. Unless you had the (legacy) network manager private header files and a super private entitlement in you provisioning profile, allowing you to create VPN on-device without any MDM or configuration profile (or user consent), there was no way for an App Store app to create a VPN tunnel. We used to get these by mailing a contact inside Apple, asking for the latest headers before each major and minor iOS release. Before NetworkExtension, any public inquiry about creating VPN tunnels was denied by Apple and only officially supported by the Cisco app at the time.
Over the years, I’ve heard of many other such “features” only available to big “partners”.
Question: if pflog1 isn't created, does pf work as expected?
Since tcpdump presumably isn't logging anything going out of pflog1, it implies that the data isn't being sent to pflog1. That implies that it's something upstream from there.
Was pflog1 plumbed and/or pulled up? Back in the day you used to have to plumb and pull up an interface manually. Does MacOS do that for you?
Granted, isolating this isn't the bug reporter's job. But at some point the engineer will be asking these questions, so you might as well answer them.
On Ventura 13.5.2 ifconfig create creates the interface UP:
bash-3.2# ifconfig pflog1 create
bash-3.2# ifconfig -a
pflog1: flags=1<UP> mtu 33072
But I don't think tcpdump will see anything because there's no IP associated with that interface. On some devices (Broadcom) the OS will just dump stuff out of an interface, but I'm not sure what MacOS does in this case.
Mullvad has been working okay for me in Sonoma betas (I had to click "Connect" twice), and appears to work perfectly in the final 14.0 release (23A339). A test with ipleak.net looks normal. What am I doing right/wrong?
In Linux you can use eBPF. See https://github.com/iovisor/bcc for an easy way to write eBPF, or look for something in the tools/ dir that does what you want. You distro might have these packaged in bcc-tools or similar.
If you use their wireguard servers, you can use wireguard directly (no Mullvad) app, and this is probably not an issue? I'm not certain and don't have a (modern) Mac, so I can't test. Just a reminder that it's nothing proprietary and the app is optional I suppose.
I would presume that the thing Mullvad are (rightfully) doing with firewall rules in their app, is to prevent non-VPN traffic from flowing whenever the VPN is enabled. The whole “leaking your IP through DNS / privileged connections to OS update servers / etc.” issue.
I'm not saying there's no value in the app, but there must be other ways of achieving that (though, maybe they're broken by the same). Do you have `ip netns` on macOS? Fwmark? There's the WireGuard app too of course, I wonder if that's similarly broken.
The way of achieving that is through the Packet Filter, which is what is broken. It seems unlikely you can block system-level traffic with anything except system-level APIs.
I'm not in any way excusing the bug, but what about routing? Even if the firewall is broken, if you have a wg0 interface and your only route is through that interface, wouldn't that also achieve the same goal?
Speaking of macOS's firewall being broken, there's a bug (or "feature"?) in the NetworkExtension framework which causes connections to get initiated (SYN, leaks your IP address) even if there's an explicit rule to deny that connection. This affects LittleSnitch, Lulu, and all the other apps building on top of the framework. Bug reports have been filed and as usual ignored by Apple.
> Apple doesn't seem to care that much about privacy applications of their OSes.
If I remember correctly, macOS (iOS as well?) also sends information about the application you are launching back to Apple from time to time. It doesn't contain the application's name directly but it does contain information about the developer of the app (their certificate; multiple apps can technically share the same developer though). They do this to be able to prevent the app from launching in case the developer has been done something nefarious. Bonus points go to Apple for making these requests over plain text connections, no pesky TLS - let the whole network see!
Apple committed on April 30, 2021 to sending these revocation checks over a new encrypted protocol within one year. AFAIK that turned out to be a lie, as there have been two OS releases since then and plaintext OCSP remains a thing.
ARM macOS also still gets boot tickets from the TSS server (which include permanent HW serials like chip ECID) via plaintext tcp/80 HTTP on every OS update.
I wish they’d just stop with the yearly major releases.
Unlike the iPhone, there’s no magic date in September when all the year’s new Macs drop and require support for all the new hardware capabilities. Sure, there are changes to system apps on iOS like Notes that want feature parity on the Mac, but you could do those in a point release. Or even better, decouple those apps from the OS and update them individually via the App Store.
They clearly don’t have enough resources allocated to macOS anymore to have a big yearly release without spending the next n months fixings problems. Just release the damn thing when it’s actually ready. They didn’t do yearly releases when the Mac was still their major focus, I don’t see why they need to today.
Unfortunately Apple is a services company now and they have to release all platforms with iCloud (ie all platforms) roughly in lockstep as they add new functionality in iOS that then needs to also be supported on desktop.
Naturally you need to be able to view your stereoscopic 3d videos on your Macbook, or something.
I see more and more complaints about bugs, anyway. I use it all day every day without issues, though. Not sure what to make of that. It’s not that I don’t believe those who are affected. I’m just not sure one can conclude that it’s getting more buggy with each release. Maybe the number of unusual use cases increases with popularity?
For me personally it’s not bugs as such. Bugs usually do get fixed fairly quickly (though something like this making it into a release candidate is concerning).
It’s half-baked features that don’t get revisited for years. We all know the new System Settings sucks; Sonoma hasn’t meaningfully improved it. The Notification Centre redesign introduced 3 (?) years ago is so much worse than the old design, but it hasn’t been touched since. Disk Utility is a shadow of its former self.
macOS is an established operating system, I would prefer them leave perfectly good features alone unless they can actually make them better.
> Yet, macOS seems to get buggier and buggier between releases. Something about the way it's being developed right now is going very wrong
This is a common trend in the SW development in the last decade. Aparently bug fixing is hard and expensive, that's why they concentrate on new features or, in extreme cases, complete rewrites (GTK).
> Yet, macOS seems to get buggier and buggier between releases.
i wonder how much of that is a side effect of constant rewrites of already existing features... i'm reminded of when they tried to replace mdnsresponder amd all the chaos that ensued, or even just swiftui and all its regressions... the dock being rewritten in swift or system preferences etc...
What gives you the idea that macOS doesn’t have big changes between releases? Every single release has a huge amount of change in it, even if you don’t happen to notice.
They're releasing macOS a whole month earlier than usual, with fewer beta releases than usual. I believe this is the first time they will have released macOS and iOS on the same date.
not surprised. we've filed dozens of bug reports as every new macOS release gets worse and worse. i've given up on filing reports now, since they won't get fixed or even looked at anyway. i see the problem with triaging when around 4k issues are filed per day, but it's not like Apple is hurting for cash.
I've basically given up reporting bugs with Apple as they just seem to be ignored and either never fixed, or fixed some years later when the corresponding component is completely rewritten.
I basically resent filing bugs with companies that have enough money to do proper testing, I don't want to work for them for free, especially if there is no answer, or a 1st-level answer who hasn't even tried the filed repro case. However, I am happily reporting bugs with open source projects.
I raised a bug in the image capture framework which prevented scanning from sandboxed apps and it was fixed 3 betas later. But probably because Preview.app was also affected and I asked all users of my software to file a bug for the Preview app.
I see this sentiment a lot amongst fellow devs that develop for Apple platforms, but it’s a self-defeating premise.
A bug that goes unreported and unnoticed by Apple engineers will by definition never get fixed.
Whereas filing a report at least brings with it the chance that it gets fixed.
Based on my own experience the majority of what I report gets fixed.
I just don’t get a thank you card, or other communication in most cases, which seems to be especially a sore spot for most.
I don’t really care and I wonder how realistic it is for them to reply to everyone.
Their automation and triage engineers try to link duplicate reports so that an automated message goes out, regardless many will still slip through the cracks.
I’m also not sure if throwing more money at the problem will noticeably improve things with the way the process is designed and the sheer volume they’re dealing with, especially since they started the public beta program and taking into account automated reporting.
I personally think they should get back to the drawing board and redesign the process to one that separates some of the streams.
That said, I’d suggest anyone who regularly reports to build report with relevant engineers that are active on a variety of social media, to make use of labs and other interaction moments if you’re dealing with something that affects your work because the engineers are always eager to pluck your report out of the pile and take a look and to also make use of the DTS credits you get to highlight an issue (they’ll refund you the credit once they confirm it’s a bug).
They can’t, they’re just presuming because Apple doesn’t communicate anything unless more information is needed or the bug is addressed in a build the reporter has access to.
The more macOS seems to break user control of networking, the more I wonder what kind of "separate box" solutions are out there that can intermediate _outgoing_ traffic.
e.g. Something like LittleSnitch on a router, where it notifies the Mac when it detects a new outgoing connection.
Do things e.g. pfSense support that already? "Hold" an outgoing connection from the moment the SYN is observed, notify whatever client, and only allow if the user clicks?
> Do things e.g. pfSense support that already? "Hold" an outgoing connection from the moment the SYN is observed, notify whatever client, and only allow if the user clicks?
Not that I am aware of.
This is a desktop centric workflow where the user can react live to an application that is sending traffic.
Your typical network firewall will apply a set of static rules and the decision to log/reject/drop is done ASAP. Waiting for user input is impossible.
Some systems can show logs of recent blocked traffic, and allow an admin to quickly generate an exception/allow rule for blocked traffic but that's pretty much it.
With some work you could integrate the two; create an external box paired with an app on your source machine. When the source machine can see more info about the connection it can cooperate to pass it along to the middlebox, and if the middlebox sees something the source system has no idea about, well, that's useful info to annotate the network connection with.
Most of the alternatives that aren’t marketed to the consumer immediately have something. I ran openwrt for years and used its firewall to block a bunch of traffic and now I’ve switched to Ubiquiti because of wifi issues.
pf’s `divert-to` can be used to divert packets to a local port; `getsockname()` will return the original destination address, so you can either close the connection, or proxy it in userspace.
Alternatively, you could possibly use a divert(4) socket — coupled with a targeted firewall rule — to divert only the initial SYN packet, and if the connection is to be permitted, re-inject it and allow connection to proceed normally.
OpenBSD supports using divert(4) sockets with pf; unfortunately, FreeBSD divert(4) sockets only work with the older ipfw firewall.
Not sure I'm understanding you correctly - by captive portals do you mean the "challenge" that renders in a browser/webview context, commonly when joining a new network?
I'm not sure that would be suitable for what I describe above.
What makes LittleSnitch/Lulu/similar nice is they listen for "all" outgoing traffic types TCP/UDP/ICMP/etc, and show UI immediately, including for non-browser apps, e.g. games, VoIP, P2P apps, whatever -- it tends to be covered. Unless I'm mistaken I don't believe a captive portal can be triggered when "just any" process originates traffic.
That's the strength of LittleSnitch/similar, but the major weakness with host-level filtering they rely on, is you're 100% at the mercy of Apple's networking stack, and this Sonoma issue isn't the first time Apple moved the goalposts. Not too long ago Apple exempted their own services from whatever LittleSnitch hooks [1] and it could of course happen again with any macOS update.
In my view this is precisely why a separate box is appealing. Ideally it'd have as tight of a UI as the incumbent apps, including the same metadata (process name + app icon, protocol, port #, most recent previous attempt, etc).
We, the old Windows developers, welcome you, the current Apple developers, to the 90's, when Windows was shittier and shittier with each version. Get ready for the next decade when workarounds and basically underground techniques will be your only survivability.
As MacOS becomes more popular, it seems it has to go to this shitty phase, as Windows did back in the day. We got rid of this phase with Windows XP release, so around 7 years. For you, who knows, hopefully shorter.
Windows is still shitty. After three years of using an M2 MacBook Pro for work and having my own M2 MacBook Air, using a Microsoft Surface laptop is a death by a thousand cuts
> Everything causes the hourglass cursor to pop up - even just clicking on a button in Outlook
As someone who had to use a very slow 10-year-old iMac recently, I would prefer if macOS showed more indicators that it was busy. The macOS UI seems to assume things are near-instant that in that environment weren't even close.
For example it "reopened" XCode after a reboot, and after a while it seemed the system was done doing background stuff. I clicked the System Settings and another app because I was going to need them, then tried to interact with XCode. Then the window turned gray and a spinner showed up that took a few minutes to disappear. It wasn't done at all. It turns out showing a screenshot to seem more responsive only works if you can very quickly back up the lie when necessary.
It isn’t so much a screenshot as it is the system suspending (parts of) apps that aren’t used or visible and aggressively compressing and decompressing memory.
So up until you tried to interact with it, it wasn’t frozen as far as the system was concerned, only then did it ran into an issue and did it convey that issue to you.
I don’t know by heart what the last macOS (or even OS X) version and Xcode version is that would be supported by a decade old iMac, but I can’t imagine it being a pleasant experience.
I have way more issues with MacOS than with windows and here just a small part of issues I must deal with:
- The keyboard layout and shortcuts are non-standard compared to other operating systems.
- Many keyboard shortcuts require more keystrokes than their Windows/Linux counterparts. For example, CMD+SPACE vs. WIN, OPTION+CMD+SPACE vs. WIN+E.
- I experience frequent system crashes—about twice a month, which is significantly more than I've had with high-end Windows laptops.
- Integration with Android devices is lacking due to the absence of apps like Phone Link.
- The window management is subpar. Third-party apps like Rectangle that attempt to improve this are buggy.
- Mouse scrolling defaults are reversed. If adjusted in settings, the touchpad scrolling direction is also inversely affected, without separate configuration options.
- The gaming library is limited.
- I experience glitches with my monitor optimized for Mac. About once every hour, the screen goes blank for a few seconds. This issue doesn't occur with Windows.
- Global environment variables are not available unless an app is initiated via the command line. This means apps started via Spotlight can't have assigned environment variables.
- Docker performance is suboptimal. For instance, a PostgreSQL backup that takes 5 minutes on Windows requires 2 hours on macOS due to slower write speeds to the host filesystem from inside Docker.
- I encounter issues with my non-Apple headset and need to disconnect its dongle from my MacBook approximately once daily to rectify it.
- Docker doesn't run in Parallels VMs. Unlike Windows, where nested virtualization can be enabled with a PowerShell command, macOS doesn't provide this flexibility.
- There's no straightforward method to turn off the laptop monitor when an external monitor is connected, without closing the laptop lid.
- Working with virtual machines is cumbersome. For example, the OS still reacts to some shortcuts even when a VM is in focus.
- Multi-user mode has significant shortcomings. Several brew programs malfunction when multiple users access the system. Docker, especially on the ARM version of macOS, exhibits issues in multi-user scenarios and doesn't function properly in VMs.
- To execute scripts via right-click, one must create a quick action and navigate to a secondary menu—a non-intuitive process.
- Several CLI utilities differ from their Linux counterparts. Making them GNU-compatible requires installing numerous utilities via brew and then prioritizing them over the native commands.
- Finder lacks the robustness and versatility of Windows Explorer.
- Hardware upgrades are exorbitantly priced. For instance, upgrading from 512GB to 2TB SSD costs €700, whereas a 2TB SSD can be found on Amazon for around €70.
- Post macOS updates, certain configurations, like fingerprint authentication for command-line apps, revert to default settings, necessitating frequent reconfigurations.
- macOS doesn't perform well on low-resolution screens, in contrast to Windows.
- The OS is restrictive. Outside of macOS, no other systems can be installed.
- My printer only operates wirelessly. USB-C connectivity fails, forcing me to disconnect from the internet to print.
- When connecting to a printer via WLAN, macOS often disconnects initially, mistaking it as a primary internet connection.
- The ARM architecture still exhibits flaws, especially when interfacing with virtual machines.
- Mouse acceleration isn't as refined as on Windows (excluding the touchpad).
- During Playwright e2e tests, tab navigation gets cluttered with icons from test browsers—a problem absent on Windows.
- An increased number of macOS software options are paid. For instance, while Windows offers free VM tools, macOS users might need to purchase Parallels.
- macOS lacks an official package manager akin to Windows' winget or Debian's apt-get, though third-party options like brew exist.
- The Windows taskbar offers superior functionality to the macOS dock, including hover previews.
- Apple doesn't provide convertible laptops or touchscreen devices.
- Some enterprise features are absent or underdeveloped.
- Legacy software support is limited, which might expedite OS development but poses compatibility challenges.
- The laptop tends to overheat during intense processes, seemingly prioritizing quieter fan operations over cooling efficiency.
- Unpurchased Apple Cloud Plans result in advertisements within System Settings and the Music App.
I think I can help you with a couple of those things if you're interested!
You can remap the keyboard shortcuts in macOS easily. Go to System Settings - Keyboard - Keyboard Shortcuts. The one you specifically mentioned for WIN + E is in the Spotlight section under 'Show Finder search window'. Double-click on the key chord shown and type in what you'd prefer. (Incidentally, the Finder search window is atrocious and I hate everything about it. But I get wanting a shortcut to just open Finder in general.) Another neat thing you can do here is assign keyboard shortcuts to any menu item in any application.
You might also look into BetterTouchTool for gestures, keyboard shortcuts, and a billion other things. One option BTT provides is inverting the scrolling for the mouse only. It's a quick and easy checkbox in the prefer-- settings.
Parallels is good and all, but I personally use VMWare Fusion. It's free and I've not had any issues with it that would compel me to pay a subscription for Parallels.
It's been 23 years (to the day!) since the release of the OS X public beta, and it's a mature product. I'm not sure it's getting "shittier and shittier," I think there are still refinements and improvements, they just aren't as big as they used to be.
Apple no longer appears to be able to keep a consistent focus on the Mac. They have some really great fits and spurts in particular areas (e.g. hardware, they’re absolutely nailing it with Apple Silicon at the minute) but it’s far too common for widely-reviled issues to linger unaddressed for literally years.
The new System Settings is an obvious one; Sonoma hasn’t really touched that at all despite its glaring issues. But Notification Centre has been borderline useless ever since they redesigned it back in what, Big Sur? I saw a Mastodon post recently [0] that highlighted how bad it is today compared to the old design, yet it’s barely been touched in 3 years.
macOS is stable and established and unlike iOS a lot of people rely on it to do actual work, I would rather them not mess with stuff than half-ass it and leave it unfinished.
For me, it certainly is getting less stable & more frustrating to use with each update. even elements of the ux, such as the settings app, has degraded over the years
That's just modern software in a nutshell, nothing is ever "good enough" for designers/companies and they must change it no matter what.
The settings app for example was perfectly fine, it worked well for what...near 20 years with only slight tweaks. Now I have to use the search bar for settings, because it's not obvious at all where to find a lot of them.
And yet things that would be useful like a volume mixer are still nowhere to be found.
I mean, there were definitely iterative improvements I think could have been made to the settings app, as with nearly all software. Instead, apple threw out the design for a ux that was clearly optimized for palm sized screens that you operate by touch in order to unify the interface between two entirely disparate forms of interaction.
Every time anything breaks in macOS, people come out to claim that the Mac is dying and Snow Leopard [which shipped with a bug that deleted lots of users' home folders] was the one true version. This wouldn't have happened if Steve Jobs were still alive. Netcraft now confirms that the BSD-based macOS is dying.
Strongly disagree. Apple’s obsession with making things like scroll bars and window chrome harder to see has been a usability nightmare for me over the last few releases.
Frequently these days, with lots of overlapping windows I try to click the top of a window only to find out I’ve clicked on part of the window behind.
Yes having everything one colour is lovely and ‘clean’ but horrible to use
also all the icons now being the same shape (like ios) i find myself scanning over and over missing apps i used to find so easily before... such a usability regression (though it does look pretty)
I will confess I miss skeuomorphism, but even if Apple never embraced flatness, Ventura's System Preferences.app is horrendous. I've become reliant upon the search bar to find most things in there, which I rarely had to do before.
Feels like this is true only for Apple Silicon macs. Intels are getting more are more terrible with each upgrade, most noticeable is insane UI latency when doing literally anything — opening an app or a window can take seconds. Changing the tab in Settings app takes a second before the new one is rendered! And that's with a fresh system installation and no resource-hungry apps opened. And it's definitely not just me — colleagues have the same issues and internet is full of such reports.
Yeah I moved to FreeBSD myself because macOS pissed me off too much. It's becoming too closed, too opinionated, too much like iOS.
What I loved about macOS originally was that it was a great Unix style OS but with a consistent UI and major desktop apps.
Also most major headline improvements in recent macOS releases rely on iCloud and because I've always been a multi-os person these are not something I can use. Some iCloud stuff works on windows but most doesn't. And pretty much none of it works on Linux or BSD. Any service I use must work on all.
So after years of getting more and more annoyed with Apple removing powerful options and replacing them with dumb on/off sliders I just can't deal with it anymore. I still use it for work but that's it. At the same time KDE is now mature enough to work great. And it doesn't eschew lots of configuration settings. So it's become my daily driver instead.
> We got rid of this phase with Windows XP release
I assume you were talking about consumer versions like Win 95, 98 and Me (the release we don’t talk about)?
The NT based ones like NT 4 and Windows 2000 seemed decent when they came out. I guess MS realized that as well and started using NT for the consumer releases as well with XP.
The lack of unification between NT and Win9x before XP was abysmal. Basically you had to have 2 partitions, one for gaming, one for business. NT was unable to have games, Win9x was unable to be useful for business due to sheer blue screens. So yeah, I include NT 3.5, NT 4.0 and W2k in that shitty phase as well. I know it very well because I've lived through it. XP ended that. Hence why, after 20+years, you still have the majority of ATM's and plenty of other KIOSKs around the world still running XP.
If you're concerned about this kind of thing, and OK with the reduction in surface, you may consider just using your browser as the way you are protected. With a normal browser, this doesn't exactly work, as obviously it doesn't change your IP, still tracks you, and any zero days still expose your machine.
But at dosaygo, we're working on something called a remote browser, which runs on a remote machine, and therefore you have a different IP address. You can incorporate a proxy service or VPN if you want but it already is 1 layer removed from your local machine, which is great for protecting you from browser zero days too. Check us out, we're open source but you can also get licenses for commercial use cases where you don't want AGPL-3.0: https://github.com/dosyago/BrowserBoxPro.git
Thanks! Oh geez, this is embarrassing. When I started the company I meant for it to be called : DO SAY GO...but somehow in the incorporation form I accidentally transposed it. I guess it still happens! :) haha
It's doubly bad because as unique as dosyago is, I think I still prefer the name dosaygo. I don't know how to change it tho! :..(
Lookup "doing business as". Also your product's name, your domain name. your marketing slogans, taglines, trademarks, etc. do not have to match your incorporated name. Just use `dosaygo` everywhere... not sure what made you think you have to match your incorporated name exactly.
Ah..might be too confusing. And I kind of what to have it correct so someone else can't have that.
And also just because I really like the original name, it's the values (do, say, go the most common verbs in many languages besides to be; and it's like I think the company should help people with what they do, where they go and what/how they say), but it shouldn't tell them who they should be so; for me it's really core) kind of important to get right ha ha
Isn't there some way to just change it? I don't know...
I think DBA would work for first-class products or whatever...but not for the name when it's so close.
Windows is still 100x shittier than macOS. Try to do anything like the repro demo from the command line on Windows as you'll immediately realise how terrible the OS is for simple tasks.
Feels fairly oscillatory for me, 95 98 nt*.0 were mediocre, 2k was great, me was horrible, xp was decent, xp64 was useless, vista was awful, 7 was better, 8 felt spammy, 10 was ok, 11 is bad again.
Not really. The biggest unpopular change was the polarizing UI that was simple to toggle off for those who hated it. Besides that, you just got win2k plus much better compatibility with apps written for the 9x series.
But it's not a misconfiguration, it's a bug as the article explains. And it's not the author's fault that Apple named their firewall the same as OpenBSD.
It's not a case of naming something similarily to other software. OSX used FreeBSD's ipfw and around the time they renamed the OS to macOS, they switched to OpenBSD's pf.
Now they've screwed up either configuration or implementation but to me - it doesn't read like a bug in pf.
I believe Apple used FreeBSD's implementation of pf, as it also has the same syntax. OpenBSD pf has evolved since then and their are minor syntactic differences for some rules between freebsd pf and openbsd pf.
This kind of cynicism is tiresome. The test case involves pinging Mullvad, not Apple. If Apple wanted no filtering to be possible, they would simply remove pf entirely.
I don't see any action points in blog post so I'm not sure if they do it, but some warning in app when specific version of MacOS is detected or even blocking functionality that is known to be leaky would be great for anyone that might track blog posts. plus maybe link to this blog post in case MacOS resolves issue but app will not be updated
[edit my scanning the article missed that they answered this :D]
The obvious answer question is whether they reported this to apple already and are using this post to draw attention to it, or if they’ve found the bug in the betas (which is why betas exist) but then not reported it directly (defeating the purpose of betas)
If you read the article, they mention that they’ve reported the bug in previous versions of the beta and it has still not been fixed in the latest version. They’re cautioning their users against upgrading in two weeks when the release comes out of beta unless there is confirmation that the bug has been fixed.
I didn't get a chance to report this to Apple until yesterday, but I think it's a fairly recent regression, probably from around beta 6.
PF is supposed to be a last-match firewall but it's almost like macOS is doing first-match now: an earlier "block" rule (without "quick") is overriding "pass" rules in a different anchor, which obviously breaks things.