Mac OS X Archive

[Updated with response from Apple] Macs are a privacy nightmare

Update: Overnight, Apple PR sent out an e-mail about this issue to multiple websites and blogs, including me, for some reason. The company has updated its knowledge base article about “safely opening apps” on the Mac with new information, including a number of promises to fix this issue in the near future: Original story: Almost nine years ago, I wrote an article titled “Richard Stallman was right all along“, still one of the most popular, if not the most popular, articles ever posted on OSNews. That’s the very core of the Free Software Foundation’s and Stallman’s beliefs: that proprietary software takes control away from the user, which can lead to disastrous consequences, especially now that we rely on computers for virtually everything we do. The fact that Stallman foresaw this almost three decades ago is remarkable, and vindicates his activism. It justifies 30 years of Free Software Foundation. And, in 2012, we’re probably going to need Free and open source software more than ever before. At the Chaos Computer Congress in Berlin late last year, Cory Doctorow held a presentation titled “The Coming War on General Purpose Computation“. In it, Doctorow warns that the general purpose computer, and more specifically, user control over general purpose computers, is perceived as a threat to the establishment. The copyright wars? Nothing but a prelude to the real war. Yesterday, every Mac user got a taste of what happens when you don’t actually own the computers you pay a lot of money for. Because Apple wants to control everything you do with the computer you rent from them, and because Apple wants to know everything you do while using the computer you rent from them, a random server somewhere going down meant Mac users couldn’t open their applications anymore. Why? Because applications on macOS will only open if Apple allows them to be opened, and that means macOS phones home every time you do anything on Apple’s Mac that you rented. This has some serious privacy implications, as Jeffrey Paul notes: This means that Apple knows when you’re at home. When you’re at work. What apps you open there, and how often. They know when you open Premiere over at a friend’s house on their Wi-Fi, and they know when you open Tor Browser in a hotel on a trip to another city. It gets worse. The data that’s being sent as part of this phone home procedure is sent unencrypted, passes through third parties like Akamai, and since Apple is part of the US intelligence program PRISM, the US government has unfettered access to without the need for warrants. I’ve been warning about the consequences of handing over control of our software and computers to corporations and governments for well over a decade now here on OSNews, and every year, we seem to slide a little farther down the slippery slope, and every time, people wave it away. Yet yesterday, Mac users all over the world were confronted with the reality of being an Apple user today. Macs are not yours. They are controlled, owned, and operated by Apple, and are an absolute privacy and security nightmare. Exactly as the Free and open source software movement has been warning about for 40 years now.

macOS 11.0 Big Sur: The Ars Technica review

And, as is tradition, a new macOS release means a new Ars Technica macOS review. The one to read, as it is with every release, and as it will be forever. So say we all. In a lot of ways, Big Sur is the kind of incrementalist macOS update that we’ve come to expect in the last few years. It’s a collection of tweaks and minor feature upgrades and under-the-hood enhancements that bumps the platform forward but doesn’t radically change it. It simply builds on the foundation laid by the last few releases of the operating system, something I talked about last year. Big Sur makes the Mac look and sound a lot different than it did before! But it’s still close enough to what you’re used to that you’ll use it for a few weeks or months and then it will just be what macOS looks like. I’m obviously much more interested in Big Sur on the new ARM Macs, but for that, we’ll have to wait until next week.

macOS Big Sur launch appears to cause temporary slowdown in even non-Big Sur Macs

Mac users today began experiencing unexpected issues that included apps taking minutes to launch, stuttering and non-responsiveness throughout macOS, and other problems. The issues seemed to begin close to the time when Apple began rolling out the new version of macOS, Big Sur—but it affected users of other versions of macOS, like Catalina and Mojave. Other Apple services faced slowdowns, outages, and odd behavior, too, including Apple Pay, Messages, and even Apple TV devices. It didn’t take long for some Mac users to note that trustd—a macOS process responsible for checking with Apple’s servers to confirm that an app is notarized—was attempting to contact a host named oscp.apple.com but failing repeatedly. This resulted in systemwide slowdowns as apps attempted to launch, among other things. What a brave new world – some server goes down, and you can’t use your applications anymore.

macOS Big Sur released

macOS Big Sur, the latest version of the world’s most advanced desktop operating system, is now available to Mac users as a free software update. Big Sur introduces a beautiful redesign and is packed with new enhancements for key apps including Safari, Messages, and Maps, as well as new privacy features. And Big Sur has been engineered, down to its core, to take full advantage of all the power of the M1 chip to make the macOS experience even better for the new 13-inch MacBook Pro, MacBook Air, and Mac mini. The combination of Big Sur and M1 truly takes the Mac to a whole new level with incredible capabilities, efficiency, and more apps than ever before, while maintaining everything users love about macOS. I’m not entirely sure if I like the new interface with all the big UI elements and excessive whitespace, but other than that, this seems like a solid release. You know where to get it.

Can’t you just right click?

Can you distribute Mac software over the internet without signing it, thereby avoiding Developer ID and notarization entirely? Technically, currently, yes, although Apple has indicated that a future version of macOS may not allow unsigned code to run at all. Some people claim that Mac users can “just right click” to run unsigned software. But what does that mean exactly? Let’s look at the user experience, in a series of screenshots. For illustration, I created an unsigned application, “MyGreatApp”, uploaded it to my server, and then downloaded the app with Safari on macOS 10.15.6, the latest public version of the Mac operating system. (The experience is essentially the same on the beta version of macOS Big Sur, except the new iOS style alerts look even worse.) Here’s what you see when you try to open the app normally (double click) in Finder. As a Mac developer, it’s nearly impossible to run a viable software business when this is the first-run experience of new customers. You’ll never get any new customers! This is why every Mac developer I know signs up for Developer ID and ships only signed, notarized apps. It would be financial suicide to do otherwise. Technically, the option is there to “just right click”, but practically it’s not a viable distribution option for Mac developers. From a business perspective, there’s no avoiding the Gatekeeper. For all intents and purposes, Macs and macOS are already entirely locked down and can only run software approved by Apple. macOS Big Sur on ARM Macs will make the rules even stricter – while ARM Macs can still run unsigned Intel code in the way described above, you can’t run unsigned code compiled for Apple Silicon. The screws are being tightened little by little, and just as I predicted and warned way back in 2010 with the introduction of the Mac App Store (and then again in 2011 with the introduction of sandboxing, and then again in 2012 with the introduction of Gatekeeper), we’re very close to a total lockdown of macOS, thereby completing turning the Mac into iOS – appliances you do not control and do not own. You pay a hefty sum for the mere privilege of borrowing your iOS or Mac appliance, but you don’t actually buy them.

Mac OS 8 running as an Electron app emulating a 1991 Quadra

This is Mac OS 8, running in an Electron app pretending to be a 1991 Macintosh Quadra. Yes, it’s the full thing. I’m sorry. Does it work? Yes! Quite well, actually – on macOS, Windows, and Linux. Bear in mind that this is written entirely in JavaScript, so please adjust your expectations. The virtual machine is emulating a 1991 Macintosh Quadra 900 with a Motorola CPU, which Apple used before switching to IBM’s PowerPC architecture in the late 1990s. This exists now.

The super duper universal binary

A question I got repeatedly the last couple days was, now that AARM (Apple ARM) is a thing, is the ultimate ARM-Intel-PowerPC Universal Binary possible? You bet it is! In fact, Apple already documents that you could have a five-way binary, i.e., ARM64, 32-bit PowerPC, 64-bit PowerPC, i386 and x86_64. Just build them separately and lipo them together. You’ll be able to eventually build a binary that contains code for every Mac hardware and software platform starting from Classic all the way up to macOS Big Sur, and from m68k all the way up to ARM. I doubt anyone will use it, but that doesn’t make it any less cool.

Hands-on: 85+ new macOS Big Sur changes and features

After going in depth with iOS 14 earlier this week, today we focus on macOS Big Sur. The biggest takeaway from my hands-on time with the follow up to macOS Catalina is that Apple’s latest OS is clearly being designed with the future in mind. Although it’s unmistakably Mac, Big Sur is a departure from previous versions of macOS in terms of aesthetics. Everything, from the dock, to the menu bar, to window chrome, icons, and even sounds have been updated. A good overview of the many, many changes in Big Sur. Interesting sidenote: with both Windows and macOS now heavily catering towards touch use, this leaves Linux – and most of the smaller platforms, like the Amiga or Haiku – as one of the last remaining places with graphical user interfaces designed 100% towards mouse input. Big buttons, lots spacing, lots of wasted space – it’s coming to your Mac.

About the Rosetta translation environment

Rosetta is a translation process that allows users to run apps that contain x86_64 instructions on Apple silicon. Rosetta is meant to ease the transition to Apple silicon, giving you time to create a universal binary for your app. It is not a substitute for creating a native version of your app. To the user, Rosetta is mostly transparent. If an executable contains only Intel instructions, macOS automatically launches Rosetta and begins the translation process. When translation finishes, the system launches the translated executable in place of the original. However, the translation process takes time, so users might perceive that translated apps launch or run more slowly at times. A short overview of Rosetta 2, the translation layer that allows 64bit x86 applications to run on the upcoming ARM-based Macs.

Apple unveils macOS 11

The era of macOS 10 is over, and we’re entering the next era of macOS’s life cycle. This is going to be a massive update, and aside from the transition to ARM, it can be summed up as “macOS: iOS Edition”: the entire graphical user interface has been redesigned to resemble iOS, including massive amounts of whitespace, touch-friendly design, and very white roundrect icons. The new operating system brings the biggest redesign since the introduction of macOS 10, according to Apple. Big Sur borrows a number of elements from Apple’s iOS, including a customizable Control Center, where you can change brightness and toggle Do Not Disturb, and a new notification center, which groups related notifications together. Both interfaces are translucent, like their iOS counterparts. A number of apps have received streamlined new redesigns, including Mail, Photos, Notes, and iWork. Apple has introduced a new search feature to Messages (which organizes results into links, photos, and matching terms), as well as inline replies for group chats, a new photo-selection interface, and Memoji stickers. There’s a new version of Maps for Mac that borrows features from the iOS app, including custom Guides, 360-degree location views, cycling and electric vehicle directions (which you can send directly to an iPhone), and indoor maps. Apple introduced a number of new Catalyst apps as well. I’m not entirely sure about the look, especially since it feels very much like a touch UI that won’t work and feel as well when using a mouse of a trackpad – it looks like a 1:1 copy of the iPad Pro’s iPadOS user interface, for better or worse. Still, judging a GUI by mere screenshots and short videos is a folly, so let’s reserve final judgment until we get to use it. That being said, if you want to try the new GUI now, you can just load up any GNOME-based distribution and apply any of the countless iOS-inspired themes found on Gnome-Look.org. An additional massively important feature is that the upcoming ARM-based Macs will be able to run iOS and iPadOS application unmodified, as-is, much like how Chrome OS can run Android applications. This further underlines how despite years of Apple and its advocates poo-pooing Windows for combining cursor and touch-based interfaces, Apple is now pretty much past any idea of combining the two, and has instead just opted to make everything touch-first, whether you use a mouse or not. Lastly, macOS 11 will come with Rosetta 2, which will allow x86 applications to run unmodified on ARM-based Macs. That’s definitely good news for early adopters, but performance will obviously be a concern with emulation technology such as this.

Apple transitions the Mac to its own ARM processors

Building on its industry-leading A-series chips for iPhones and iPads, Apple wants Macs with its custom silicon to have the highest performance with lower power usage. Apple says the vast majority of Mac apps can be quickly updated to be “universal” with support for both Intel-based Macs and those with Apple’s custom silicon. Starting today, developers will be able to apply for a Mac mini with an A12Z chip inside to help prepare their apps for Apple’s custom silicon. The special Mac mini will be running the macOS Big Sur beta and the latest version of Xcode. The news everyone knew was coming. The transition will take roughly two years, and the first consumer device will become available later this year.

Apple will announce move to ARM-based Macs later this month, says report

Apple will announce that it’s shifting from using Intel processors to its own ARM-based chips this month at WWDC 2020, Bloomberg reports. The developer conference is due to take place starting on June 22nd with an online-only format due to the COVID-19 pandemic. Bloomberg notes that the timing of the announcement could change due to the health crisis. Rumors of Apple switching to using its own ARM-based processors in its Macs have been around for years, but a recent report from Bloomberg claimed that the shift was imminent, and that the first Mac powered by an ARM-based processor would arrive in 2021. The company reportedly has at least three ARM-based Mac processors in development based on the next iPhone’s A14 chip as part of Apple’s “Kalamata” project. While I like ARM bringing the competition to x86, Apple is not the right company to get excited over. ARM in and of itself is already more fragmented and locked-in than x86, and Apple cranks this up a notch. A lot of people are excited over ARM Macs, but I have a feeling they may be in for a very rude awakening. No more Steam. No more Bootcamp. No more Linux or other alternative operating systems. Far more Electron apps and shoddy iOS ports (developers barely wanted to make native x86 Mac apps, even fewer will make ARM Mac apps). No Adobe applications for the coming years. iOS-like restrictions for ARM macOS. Rude awakening indeed.

macOS 10.15: slow by design

Apparently, Apple is making macOS Catalina phone home so much it’s making the operating system slow, laggy, and beachbally, as Allan Odgaard details. Apple has introduced notarization, setting aside the inconvenience this brings to us developers, it also results in a degraded user experience, as the first time a user runs a new executable, Apple delays execution while waiting for a reply from their server. This check for me takes close to a second. This is not just for files downloaded from the internet, nor is it only when you launch them via Finder, this is everything. So even if you write a one line shell script and run it in a terminal, you will get a delay! Aside from the obviously terrible design and privacy implications of your computer phoning home to Apple every time you execute something, this is also another case of Apple only designing for the absolutely optimal use-cases – i.e., people working and living in Cupertino – and that’s it. The less optimal your internet connection or the farther away you are, the worse your experience will be. Apple has a few file system locations that require user permission to access them, for example ~/Desktop, ~/Documents, and ~/Downloads. Surprisingly though, just obtaining the display name or icon for one of these folders will trigger Apple’s code to verify that the client is allowed to access the location. This is done by sending a message to the sandboxd process which sends a message to tccd which calls SecCodeCheckValidityWithErrors and seems to communicate with yet another process, but I can’t find which, and this takes around 150 ms per location. It may not seem like much, but this adds up, and can add more than half a second of delay when opening an application. Like with privileged folders, keychain items also require permission for applications to access them. But again, something is wrong. Specifically calling SecKeychainFindGenericPassword can cause noticeable delays, on a bad internet day I had this call stall for 3.3 seconds and this was with System Integrity Protection disabled! And on other delays in launching applications in general: This is the worst issue, sometimes, things will stall for 5-30 seconds. Mostly though it is when launching applications. Sampling the application during launch shows stalls in ImageLoaderMachO::loadCodeSignature, SLSMainConnectionID, and many references to Skylight and CGS in the stack trace. The current best way to “address” this issue is disabling System Integrity Protection and disconnecting from the internet (!), and especially that second one is of course entirely unreasonable. I wouldn’t touch macOS with a ten-foot pole even before Catalina – it always felt slow and sluggish to me, even on faster Macs, and Mac hardware is terrible value right now – but with all the general complaints about Catalina, and now this, it’s getting ever clearer I’m not missing out on anything by sticking to Linux. At least my computer isn’t calling home to Clement Lefebvre every time I run a tiny script.

Valve drops macOS support for SteamVR

Valve has announced it’s ending support for macOS for SteamVR. SteamVR has ended OSX support so our team can focus on Windows and Linux. We recommend that OSX users continue to opt into the SteamVR branches for access to legacy builds. Users can opt into a branch by right-clicking on SteamVR in Steam, and selecting Properties… -> Betas. Apple announced SteamVR coming to the Mac at WWDC in 2017, so support from Valve lasted for a mere three years. This shouldn’t come as a surprise though, since the macOS ecosystem simply isn’t geared towards gaming and VR in any way, shape, or form. Most Mac users have to settle for Intel integrated graphics, and even the Mac users with a dedicated video card have to settle for subpar and overpriced AMD cards, since Apple refuses to support NVIDIA. On top of that, Apple has deprecated OpenGL and wants developers to use their proprietary Metal API instead. In a world where most game developers use DirectX or OpenGL/Vulkan, that just doesn’t make a lot of sense. And let’s not forget that the writing is on the wall for macOS as a general purpose operating system anyway, since Apple will most likely use the move to ARM processors in Macs to further lock down macOS, making it more like iOS. While macOS might be more popular than Linux in absolute numbers, the cold and harsh truth is that the Linux userbase simply has a far larger group of skilled developers, programmers, and tinkerers willing to put the effort into making non-native games work on Linux and to improve support for things like VR devices. These are exactly the kind of people Apple seems to have a deep-rooted disdain for. Expect more of these kinds of announcements over the coming years, as game companies (and other developers) have to decide whether or not to support an isolated and locked down platform like macOS on ARM – a platform without first-party OpenGL or Vulkan support, with a steward actively pushing you to use a proprietary API that you can’t use anywhere else.

Apple aims to sell Macs with its own chips starting in 2021

The Cupertino, California-based technology giant is working on three of its own Mac processors, known as systems-on-a-chip, based on the A14 processor in the next iPhone. The first of these will be much faster than the processors in the iPhone and iPad, the people said. Apple is preparing to release at least one Mac with its own chip next year, according to the people. But the initiative to develop multiple chips, codenamed Kalamata, suggests the company will transition more of its Mac lineup away from current supplier Intel Corp. I wonder just how locked-down these ARM Macs will be. Will it be App Store-only? Can you change default applications on ARM macOS? Can you install a browser engine other than WebKit? Do you have access to the file system? Will it ship with a terminal? I’m not so sure macOS users should be excited about ARM Macs.

Deprecated kernel extensions and system extension alternatives

Just another heads up that kernel extensions on macOS will soon stop working. This has been known for a while, but you might not even know you’re using kernel extensions in the first place. System extensions on macOS Catalina (10.15) allow software like network extensions and endpoint security solutions to extend the functionality of macOS without requiring kernel-level access. At WWDC19, we announced the deprecation of kernel extensions as part of our ongoing effort to modernize the platform, improve security and reliability, and enable more user-friendly distribution methods. Kernel programming interfaces (KPIs) will be deprecated as alternatives become available, and future OS releases will no longer load kernel extensions that use deprecated KPIs by default. If you use macOS, run kextstat | grep -v com.apple to see how many third party kernel extensions you have running. Things like VirtualBox, controller support for Steam, DropBox, Little Snitch, and more all come with kernel extensions, so there’s definitely chances you might be running some without even realising it.

Is Catalina a good upgrade yet?

We’re now past Catalina’s midpoint: with four versions already released, there’s only three more to go before we prepare for the first release of 10.16. That’s a stark fact, that we’re now at the point where the more cautious should consider whether they’ll run 10.15. Unusually for macOS, there are many Mac users with Catalina-compatible Macs who are no more able to upgrade now than they were back in October. These include the many who still have to rely on 32-bit apps, and those whose Mac doesn’t start up from an SSD. There’s still a lot of trepidation about Catalina, even among the Apple faithful in popular podcasts like ATP.

Phoenix: a lightweight macOS window and app manager scriptable with JavaScript

A lightweight macOS window and app manager scriptable with JavaScript. You can also easily use languages which compile to JavaScript such as CoffeeScript. Phoenix aims for efficiency and a very small footprint. If you like the idea of scripting your own window or app management toolkit with JavaScript, Phoenix is probably going to give you the things you want. With Phoenix you can bind keyboard shortcuts and system events, and use these to interact with macOS. Pretty cool.

Undocumented Catalina file access change

It’s well known that if you drag a file from Finder and drop it into Terminal, the full path of the file will output in Terminal. The same behavior occurs with copy and paste too. This has always been a very convenient but innocuous operation… until macOS 10.15 Catalina. I’ve discovered that on Catalina, pasting a file from Finder not only outputs the file path in Terminal, it also invisibly and permanently grants Terminal access to the file, bypassing any macOS privacy protections! This is such a weird bug… Or feature?