Tim Hardwick:
OpenAI has issued an update to its ChatGPT app for Mac, after a developer discovered the app was locally storing users’ conversations with the chatbot in plain text.
Pedro José Pereira Vieito told The Verge’s Jay Peters: “I was curious about why OpenAI opted out of using the app sandbox protections and ended up checking where they stored the app data.”
It’s not clear why ChatGPT isn’t sandboxed. It could be that they just chose not to or that it’s relying on an API or functionality that doesn’t work in the sandbox.
As the developer of several non-sandboxed apps, it seems like the right thing to do is to make every app sandboxed, potentially with some extra entitlements that wouldn’t be allowed in the Mac App Store. In other words, run with only the permissions that the app actually needs. However, I have not seen much written about how to accomplish this sort of migration. It’s not always clear what private entitlements are needed or whether they even exist. What will break after migrating the app’s files into a container? What if the customer wants to go back to the previous version of the app? What if something changes in macOS or the sandbox such that the extra entitlements no longer do the job? Until recently, there have been a lot of potential headaches for little apparent benefit (protection against bugs in your app causing damage outside its container to files that it wasn’t intentionally given access to).
Nick Heer:
Virtually all media coverage — including Peters’ article — has focused on the “plain text” aspect. Surely, though, the real privacy and security risk identified in the ChatGPT app — such that there is any risk — was in storing its data outside the app’s sandbox in an unprotected location. This decision made it possible for apps without any special access privileges to read its data without throwing up a permissions dialog.
I’ve seen lots of quoting of Vieito’s statement that macOS 10.14 and later have blocked access to private user data, which I interpreted as saying that there are longstanding protections that ChatGPT should have taken advantage of. However, these protections only applied to certain built-in apps from Apple. With macOS Sonoma, Apple announced that macOS would prompt the user when accessing files inside another app’s container. Thus, while, historically, sandboxing app A would only restrict what A could do, now making A sandboxed could also protect it from app B (whether or not B is sandboxed). macOS Sequoia expands this protection to group containers.
I don’t think I ever saw one of these prompts, so I figured that Apple had at some point backtracked. And, after seeing the above discussion, I wrote a quick test app that accessed files in lots of sandboxed apps’ containers—without generating any prompts. Where’s the protection? The answer seems to be that only containers of newly installed apps are protected from other apps. If you had first installed the app prior to updating to Sonoma, other apps can access its data, same as always. But, with ChatGPT being a new app that requires macOS Sonoma, sandboxing would have offered the protections, such as they are, to everyone.
Miguel Arroz:
Mostly everything stores your data in plain text on your Mac. Data is protected via full disk encryption from anyone who steals your Mac, but not from other apps.
[…]
Everyone seems happy the latest update encrypts stored chats. Haven’t seen anyone asking the obvious, where’s the key? If the key is randomly generated and stored on the Mac’s keychain, I have bad news for you.
Jeff Johnson:
This seems like much ado about nothing. Very little app data on Mac is encrypted on disk at runtime.
Sandboxed apps (e.g., from Mac App Store) can’t access the data anyway. And if you’ve installed a non-sandboxed malware app on your Mac, then frankly you’re screwed no matter what. Non-sandboxed apps can get you in a million different ways. There’s no reliable protection. Be careful of what you install. Plus there are approximately infinity TCC privilege escalation bugs.
And, I think it’s rather easy for sandboxed apps to trick users into granting access that they didn’t intend.
Drew McCormack:
I think the local data storage is the least of your worries with these companies. All that data has to go to the cloud too. That is a much bigger risk IMO.
Joshua Nozzi:
I still don’t see the scandal specific to ChatGPT.
I don’t either. People should be more worried about their Chrome history, for example.
Previously:
ChatGPT Google Chrome Mac Mac App macOS 10.14 Mojave macOS 14 Sonoma macOS 15 Sequoia OpenAI Privacy Sandboxing Transparency Consent and Control (TCC)
Brandon Vigliarolo:
CocoaPods, an open-source dependency manager used in over three million applications coded in Swift and Objective-C, left thousands of packages exposed and ready for takeover for nearly a decade – thereby creating opportunities for supply chain attacks on iOS and macOS apps, according to security researchers.
[…]
As noted above, the CocoaPods team has patched the issues – and appeared to do so months ago – though specifics weren’t widely known until EVA published its research today.
None of my apps use CocoaPods (or other package managers).
Reef Spektor and Eran Vaknin:
A 2014 migration process left thousands of orphaned packages (where the original owner is unknown), many of which are still widely used in other libraries. Using a public API and an email address that was available in the CocoaPods source code, an attacker could claim ownership over any of these packages, which would then allow the attacker to replace the original source code with their own malicious code.
An insecure email verification workflow could be exploited to run arbitrary code on the CocoaPods ‘Trunk’ server (manages the distribution and metadata of Podspecs), which would allow an attacker to manipulate or replace the packages being downloaded.
By spoofing an HTTP header and taking advantage of misconfigured email security tools, attackers could execute a zero-click attack that grants them access to a developer’s account verification token. This would allow attackers to change packages on the CocoaPods server and result in supply chain and zero day attacks.
Previously:
CocoaPods Exploit iOS iOS 17 Mac macOS 14 Sonoma Open-source Software Programming Security
Jonas Dreßler (via Hacker News):
There’s a security vulnerability (CVE-2024-27867) in the firmware of Apple AirPods. Anyone who knows the Bluetooth MAC address (which is somewhat public) can connect to your AirPods and listen to the microphone or play music.
[…]
Fast Connect is a proprietary and US-patented protocol by Apple that creatively uses the “ping” feature of the Bluetooth specification. Its main purpose seems to be reducing the time it takes to establish a connection between two Apple devices from roughly 1 second down to about 0.5 seconds.
[…]
Turns out that Apple (most likely) forgot to do some checks in the separate code paths that implement Fast Connect. Some very important ones: The AirPods forget to check the security level of the connection, i.e. “did the other side actually authenticate itself and turn on encryption?”
So anyone can connect to your AirPods and use the microphone to record your local environment, as well as engage in more creative mischief. This is fixed in a firmware update, but if your AirPods only connect to non-Apple devices you would need to go to an Apple Store to update the firmware.
AirPods Android Bluetooth Exploit iOS iOS 17 Mac macOS 14 Sonoma Microphone Privacy
Chrome Security Team (via Jeff Johnson, Hacker News):
Over the past six years, we have observed a pattern of compliance failures, unmet improvement commitments, and the absence of tangible, measurable progress in response to publicly disclosed incident reports. When these factors are considered in aggregate and considered against the inherent risk each publicly-trusted CA poses to the Internet ecosystem, it is our opinion that Chrome’s continued trust in Entrust is no longer justified.
[…]
Blocking action will begin on approximately November 1, 2024, affecting certificates issued at that point or later.
Blocking action will occur in Versions of Chrome 127 and greater on Windows, macOS, ChromeOS, Android, and Linux. Apple policies prevent the Chrome Certificate Verifier and corresponding Chrome Root Store from being used on Chrome for iOS.
[…]
We recommend that affected website operators transition to a new publicly-trusted CA Owner as soon as reasonably possible.
Previously:
Google Chrome iOS iOS 17 Mac Mac App macOS 14 Sonoma Security Web
Joe Rossignol:
In a WWDC 2024 coding video last week, Apple highlighted a recently-introduced API that allows developers to offer built-in Translate app capabilities in their own apps on iOS 17.4, iPadOS 17.4, macOS Sonoma, and later.
Apple:
Discover how you can translate text across different languages in your app using the new Translation framework. We’ll show you how to quickly display translations in the system UI, and how to translate larger batches of text for your app’s UI.
Sequoia still doesn’t bring the Translate app to the Mac, so I’m hoping someone will use this to make a standalone app so that I don’t need to read translations within a tiny popover.
Kyle Howells:
The new Translation API is such a massive disappointment.
It’s a purely SwiftUI API.
Even the programatic API to get back Strings from Strings (no UI) requires you to get a session object via SwiftUI to do so.
[…]
Really hope this isn’t a pattern Apple is going to use going forward in the future.
TranslationSession:
You don’t instantiate this class directly. Instead, you obtain an instance of it by adding a translationTask(_:action:) or translationTask(source:target:action:) function to the SwiftUI view containing the content you want to translate, such as a Text view. When you do, the function passes you an instance of a translation session in its action closure which triggers as soon as the view appears. After you receive this instance, use one of the translate functions to translate one or more strings of text.
Kyle Howells:
I wonder if these sort of horrible API designs are a consequence of Apple building features with SwiftUI natively now?
UIKit allows UI to be presented fairly freely from around your code, due to the view controller hierarchy being easily accessed.
SwiftUI needs an element anchored to a View to do anything.
If that’s true, eventually virtually all APIs will need to be invoked via a method on View and I’m going to really hate the next few years of Apple API releases.
Previously:
Update (2024-10-07): Danny Bolella:
Curiously, the manner in which Apple forces developers to use Translation is strikingly passive aggressive: it can be accessed by SwiftUI only. This has been confirmed by an Apple Engineer who suggests UIKit apps would need to host a SwiftUI View if it would like to access Translation.
[…]
There are strong implications and signals to take from all this, even if a translation feature doesn’t apply to you. In fact, it has some of the strongest messaging regarding Apple’s recent stance on UIKit and SwiftUI.
[…]
There’s no doubt that UIKit and AppKit are not to be deprecated any time soon (or ever). But Apple has made it abundantly clear the tide will eventually turn towards SwiftUI, and they will make it so.
[…]
Translation also offers a glimpse into how Apple wants developers to view the relationship between concurrency and SwiftUI. When we obtain a TranslationSession through the programmatic route, it’s done so through a translationTask and offers function calls that are all async.
iOS iOS 18 Language Translation Mac macOS 15 Sequoia Programming SwiftUI Translate.app
