Jess Weatherbed:
It’s been 16 months since a DMA ruling allowed iOS developers like Google and Mozilla to use their own browser engines in the EU, so… where are they?
Open Web Advocacy (Hacker News):
Apple’s compliance did not start well. Faced with the genuine possibility of third-party browsers effectively powering web apps, Apple’s first instinct was to remove web app support entirely from iOS with no notice to either businesses or consumers. Under significant pressure from us and the Commission, Apple canceled their plan to sabotage web apps in the EU.
Both Google and Mozilla began porting their browser engines Blink and Gecko respectively to iOS. […] However there were significant issues with Apple’s contract and technical restrictions that made porting browser engines to iOS “as painful as possible” for browser vendors[…]
[…]
At the DMA workshop last week, we directly raised with Apple the primary blocker preventing third-party browser engines from shipping on iOS. Apple claimed that vendors like Google and Mozilla have “everything they need” to ship a browser engine in the EU and simply “have chosen not to do so”.
Apple has been fully aware of these barriers since at least June 2024, when we covered them in exhaustive detail. Multiple browser vendors have also discussed these same issues with Apple directly. The suggestion that Apple is unaware of the problems is not just ridiculous, it’s demonstrably false. Apple knows exactly what the issues are. It is simply refusing to address them.
Previously:
Antitrust Digital Markets Act (DMA) iOS iOS 18 Web Browser
Jeff Geerling (via Hacker News):
I documented the entire upgrade—along with taking my old M4 mini 1TB SSD and putting it in my Dad’s M4 mini—in today’s video[…]
[…]
Speaking of standards… you have to do a full DFU (Device Firmware Update) restore, because unlike conventional M.2 NVMe storage, the M4 uses a proprietary connector, a proprietary-sized slot, and splits up the typical layout—the card that’s user-replaceable is actually just flash chips and supporting power circuits, while the storage controller (the NVMe ‘brains’) is part of the M4 SoC (System on a Chip). Apple could use standard NVMe slots, but they seem to think the controller being part of the SoC brings better security… it certainly doesn’t bring any cost savings, resiliency in terms of quick recovery from failure in the field, or performance advantage!
[…]
The upgraded 4TB module performed noticeably better in writes, likely because it has more flash chips on it to spread out the write activity. Reads were pretty close to the same, with minor variance in performance across different file sizes and access patterns.
[…]
I was provided the $699 M4 Pro 4TB SSD upgrade by M4-SSD. It’s quite expensive (especially compared to normal 4TB NVMe SSDs, which range from $200-400)…
But it’s not nearly as expensive as Apple’s own offering, which at the time of this writing is $1,200!
Note that this particular upgrade doesn’t work with a non-Pro M4.
Previously:
Apple M4 Pro Hardware Mac Mac mini Solid-State Drive (SSD) Storage
Armin Briegel:
I have also released an update to my CLI tool to set default apps for urls and file types (uniform type identifiers/UTI). utiluti 1.2 adds a manage verb which can read a list of default app assignments from plist files or a configuration profile. You can see the documentation for the new manage verb here and download the latest pkg installer here.
Note, that while you can set the default browser with utiluti, whether you are using the manage option or not, the system will prompt the user to confirm the new default browser.
Previously:
Mac Mac App macOS 15 Sequoia Uniform Type Identifier utiluti
Jeff Johnson (Mastodon):
On macOS 15.2, I was able to drag the exact same downloaded WebP file to TextEdit and BBEdit with no Gatekeeper alert! Thus, it appears that the Reddit poster was correct, and something did change recently.
[…]
I perused the unusually long Apple support document About the security content of macOS Sequoia 15.4, but nothing in there jumped out at me as the probable cause of the Gatekeeper change.
[…]
The appearance or nonappearance of Gatekeeper alerts depends entirely on the downloaded file’s extension. I edited the WebP file with a hex editor to make it into a plain text file, but it still triggered a Gatekeeper alert on opening in an app. On the other hand, when I kept the file contents the same, in WebP format, but changed the file extension to .txt, the Gatekeeper alert no longer appeared.
Overall, this feels like more security theater in macOS.
[…]
My test app will open any and every file type without a Gatekeeper alert, as far as I’ve seen, when the CFBundleDocumentTypes has a single entry declaring the generic public.data in its LSItemContentTypes. The Gatekeeper alerts begin when I add a second entry with certain types, such as com.apple.webarchive or public.unix-executable. With just two declarations, one “safe” type such as public.data and one apparently “dangerous” type such as com.apple.webarchive, I see Gatekeeper alerts when trying to open any file, with any extension: .webp, .png, or even .txt.
He thinks the change in behavior may be a bug.
Thomas Tempelmann:
The problem (which has been around since macOS 10.0) is that it considers any file without a recognized extension to be an executable instead of being conservative and considering it something less. I always thought that to be a bad assumption. You cannot launch such executables directly from Finder anyway, so what’s the use case for this?
Yesterday, I saw a variation on this dialog that was new to me. I was trying to open a compiled nib file with Archaeology, and it said:
Apple could not verify “[file].nib” is free of malware that may harm your Mac or compromise your privacy.
The only two buttons were Done and Move to Trash. This is a document file, not executable code, and the only way I could open it was to delete the com.apple.quarantine xattr.
Previously:
Extended Attributes Gatekeeper Interface Builder Mac macOS 15 Sequoia
