Apple is still adding large amounts of new Objective-C code in each new macOS version [0].
I haven't found any language usage numbers for recent versions of Windows, but Microsoft is using Rust for both new development and rewriting old features [1] [2].
It should be noted that Objective-C code is presumably a lot less prone to memory safety issues than C code on average, especially since Apple introduced Automatic Reference Counting (ARC). For example:
• Use-after-frees are avoided by ARC
• Null pointer dereferences are usually safe (sending a message to nil returns nil)
• Objective-C has a great standard library (Foundation) with safe collections among many other things; most of C's dangerous parts are easily avoided in idiomatic Objective-C code that isn't performance-critical
But a good part of Apple's Objective-C code is probably there for implementing the underlying runtime, and that's difficult to get right.
I found the evolution of programming languages article you sourced very interesting.
Just to summarize the article, it shows that writing completely new code in memory safe language, while maintaining non-memory safe code, results in a steep reduction in memory safe errors overtime even though it results in an overall increase in unsafe code. It says that most memory safe vulnerabilities come from completely new code not maintained code and thus argues you can get the most of the benefits of memory safe code without rewriting your entire code base, which I think is the main takeaway from the article.
I’m not sure that’s totally happening in MacOS from reading your article, but it kind of is, so I think my hypothesis is correct that MacOS will likely have less vulnerabilities as it transitions many newer projects to swift although its important to note that important vulnerable projects such as webkit are still written in C++.
It also adds a new permission prompt for screenshot and screen recording apps that doesn’t allow a user to permanently grant permission, but requires a weekly re-authorization.
I hate the periodic location permission prompts on iOS. Big tech companies are increasingly paternalistic with this stuff, like their users are all idiots who need to be managed like little children. Some other examples I've recently encountered:
- 1Password requires supplying a password hint when changing the master password.
- Unifi OS enforcing password quality requirements even when locally/self hosted.
- "Set up later" (instead of "No") as the negative option for various "helpful" feature prompts in iOS.
It’s worth keeping in mind that in the case of Apple platforms, a lot of this has roots in the revelation a decade and change ago that third party software on mobile platforms can and will exploit every affordance the operating system offers to extract data, often silently. It’s no different on desktop OSes, but users have been more acclimated to it there since full blown access to everything has been the norm there longer than it hasn’t.
That said I can certainly see the argument that Apple isn’t going about handling this set of problems correctly, but ignoring it or pretending it doesn’t exist isn’t right either.
> It’s no different on desktop OSes, but users have been more acclimated to it there since full blown access to everything has been the norm there longer than it hasn’t.
This is a problem with proprietary software markets in particular. You can largely escape this dilemma if you source your software from a free software distribution like a Linux distro, Conda, Pkgsrc, F-Droid, etc., because they have their own processes and standards for curating, vetting, categorizating and sometimes even patching software.
One of the reasons that desktop Linux has lagged with app sandboxing and binary attestation compared to macOS is that proprietary apps are marginal and few on most Linux desktops. Linux users are not choosing the bulk of their software from a giant pile of borderline malicious shitware like users of mobile apps generally are. (It's a good thing that Linux is catching up in this respect because some proprietary crap, like Discord, Google Chrome, VSCode, Steam, and Zoom, is extremely sticky for new users coming from proprietary operating systems where proprietary apps are the norm as well as strongly incentivized by powerful network effects. Vendors of such software have proven that they can't be trusted to follow reasonable conventions with DEB or RPM repositories, and Flatpak will suits untrustworthy vendors and other third parties better.)
> I can certainly see the argument that Apple isn’t going about handling this set of problems correctly, but ignoring it or pretending it doesn’t exist isn’t right either.
Apple is understandably prioritizing the realities of the ecosystems that the bulk of their existing users navigate, namely one of publishers selling software as commodities and services for financial profit. But it's not the only conceivable path forward because not all ecosystems of usable software are dominated by producers facing such incentives. You can answer the proprietary hellscape by stepping away from it instead of letting yourself be hampered by shit like this on your own machine.
Most people would not have an easy time completely eliminating proprietary software from day to day usage. Reducing the amount of it is certainly possible (though may come with caveats WRT ease of use/UX; F-droid for example is not fun to try to comb through to find the good bits), but some amount is going to linger even if it’s just games the user plays to blow off some steam at the end of the day.
Even if full-FOSS were practical, I’d still want robust sandboxing and permissions to help limit the blast radius if some malicious executable manages to find its way in and to feel confident that nothing is poking around where it shouldn’t be. There’s not really a good reason for everything to have access to everything except for convenience.
But if you're looking for a way out from Apple's paternalism without giving up too much practical security, getting your software from free software distributions as much as possible and treating F/OSS as your 'home base' is a doable first step for readers of this site that will go some distance. For example, on macOS, disabling Gatekeeper for software that you install via a package manager whose repositories have a code review process and which cryptographically verifies what it downloads is not a big deal. (Homebrew does such verification, but not for all packages. You can tell it to refuse to install what it can't verify in this way, though. So all my Homebrew apps get installed only if the package has a checksum in the repos, and when installed they get --no-quarantine.)
And if you can switch to Linux on the desktop, it's reasonable to approach app sandboxing in an opt-in way. It's nice to be able to do that, especially as some of the UX pain points are still being worked out. It's also nice to know that no matter what nice capabilities your OS offers for securing your system by treating apps as untrusted by default, you'll ultimately be in control.
Sandboxing is also somewhat a separate issue from code signing and notarization, and idk what's even really practically available on the Linux desktop for that. But I'm not really sold on those so much for use of those outside the enterprise. I imagine most people here would opt out of those given the choice.
>like their users are all idiots who need to be managed like little children
Most are.
But the OSes could be designed way better for this stuff too.
Give the user security but also total visibility. A central place to grant/revoke app permissions, and to check what all apps ask for, click to see their "privacy policy" or lack thereof, has an easy way to filter to see e.g. "which apps use the camera, when they last used it", etc.
When some app is blocked and you wonder why it doesn't work, it should be easy to see a list of "blocked apps" and sort them by "when they were blocked" and other such things.
I'm not; it's passive-aggressive. Any dialogue of the form "Yes"/"Ask Later" is a framing that prevents you from saying "No, go away forever, I don't want this ever".
Not exactly what you describe, but there's Yuka for processed products (food and cosmetics). You scan a barcode and it gives you a score based on the product composition, it's quite helpful: https://yuka.io/en/
I mean, I’ve found Apple support has become incredibly disappointing in the last 5 or so years, and Lenovo support has actually improved, though you usually have to mail your device in.
I’m legitimately unsure what changed in Apple to make their support go from “pretty damn good” to “honestly a waste of damn time”.
You can disable JIT in Chrome (which also enables CET [1], just like in Edge) by executing it with
--js-flags="--jitless"
You can also disable JIT in Firefox by setting javascript.options.baselinejit, javascript.options.ion and javascript.options.native_regexp to false in about:config, although you won't get CET.
The Linux desktop technology stack lags behind Windows and macOS when it comes to security. The causes are both technical (see this comment [1] for an overview) and non-technical, often stemming from a fragmented development model where there are no clearly defined security boundaries. For example:
- There is no real concept of base system because distros are usually a patchwork of software from diverse sources. This means stuff like proper secure boot is not really feasible on any distro (although AFAIK the systemd/Fedora people are working on it with signed UKIs and immutable OS images).
- Some features that could live in userland for improved security are instead implemented in the kernel, while both Windows and macOS generally keep moving exploitable features like font rendering to userland.
- Distros often disable or disregard security features such as SELinux or mitigations like CFI.
Here [2] is a more detailed article examining the lack of security of Linux desktops in case you're interested.
