Archive for October 9, 2019

Wednesday, October 9, 2019

Settings URLs Supported by iOS and iPadOS 13.1

Federico Viticci (tweet):

A few weeks ago, I came across a post on Reddit claiming that Apple had restored the ability to launch specific sections of the Settings app via Shortcuts in iOS and iPadOS 13.1. I was inspired by that discovery to finish working on a project I had long been putting off: documenting all the URLs supported by the Settings app in iOS and iPadOS.

After some a lot of trial and error, I’ve collected 120+ URLs that can open individual pages and sub-sections of the Settings app. In this post, I’m going to share the complete list of URLs that are supported as of iOS and iPadOS 13.1 (specifically, iOS 13.1.2), as well as a custom shortcut to launch them.

For example, you can open the iCloud Backup settings using prefs:root=CASTLE&path=BACKUP.

The equivalent Mac System Preferences URLs start with x-apple.systempreferences.

Matthias Gansrigler:

So, using @viticci’s iOS Settings URLs (prefs:root) will get your app rejected. Figures.

Now, I’m not sure if it’s the prefs: url scheme itself, or if it’s prefs:root= that they’re having an issue with.

I’m guessing the latter, because before, I used prefs: to launch, and that wasn’t rejected.

I’d even argue using public APIs to open a URL constructed from a string doesn’t really constitute using “private API”, but what do I know..


Update (2020-02-26): Craig Hockenberry:

PSA: If you’re using a URL that begins with “prefs:” or “App-Prefs:” you will be rejected.

It doesn’t matter if you’re trying to help a customer navigate a byzantine maze of switches and knobs to do the thing they want. You will be rejected.

Craig Hockenberry:

In this specific case, I want someone to know that Dynamic Type settings can be adjusted to make the app work better for them.

In a way, Apple is preventing me from making things more accessible for a customer.

Update (2021-01-05): sindresorhus:

Many apps need the ability to open a specific pane in System Preferences. The most common use is to direct users to manually enable some kind of privacy permission or to toggle an app extension. I also use it to help the user change some system settings, like in “Language & Region”. Some panes support a URL scheme x-apple.systempreferences:, while for others we have to open /System/Library/PreferencePanes/\(name).prefPane. And to open sub-panes of the Extensions system preferences, our only choice is to use an API which is now deprecated (FB8910479). This results in a large amount of boilerplate. It would be nice if the system provided a unified API to open System Preferences panes and sub-panes. This would save developers a lot of time and headache.

Update (2022-10-27): Rich Trouton:

Along with this change [in macOS 13 Ventura], a number of previously-known commands for opening individual System Preferences preference panes from the command line no longer work with System Settings.

However, it looks like the underlying command line functionality wasn’t changed by Apple. You just need to know what the new options are to enter. For more details, please see below the jump.


File System Events Privacy Protections Bypass

Jeff Johnson (tweet):

Two months later, Apple has shipped major updates to all of their operating systems. Yesterday, macOS 10.15 Catalina was released. And yet, the new bug bounty program has not opened. Perhaps the public assumes that the bug bounty program has already expanded, but it has not. To this day, there’s still no Mac bug bounty program. Apple announced the expanded bug bounty program while their major OS updates were still in beta testing, but Apple did not open the bug bounty program during the beta testing period. The irony is that the new program was announced to offer increased bounties for bugs found in pre-release software, but no opportunity was given for that to occur.


I did not give Apple a deadline, but many security researchers give vendors only 90 days before they disclose a reported vulnerability. I reported mine to Apple 8 months ago, so they’ve had a lot of time.

Apple has since said that this vulnerability is not eligible for the bounty (because it’s only for privacy, not security?), so he’s disclosing it and saving the other two that he found until the bug bounty program opens:

An app without special permissions can register for notifications of file system events that occur in directories that are supposed to be protected. These file system event notifications can disclose private information that the app should not have access to.


I said, “a malware app could secretly violate a user’s privacy by examining their web browsing history.” How is this possible with file system events? If you look inside the directory ~/Library/Safari/LocalStorage, you’ll see that Safari saves local storage files that are named after their associated web sites, for example, The File System Events API can’t see the file contents, but it can see the file names! And because Safari names files after the web sites you visit, the File System Events API can be used to determine your web browsing history.


Taiwan Flag Removed from iOS Emoji Keyboard in Hong Kong

Kris Cheng (via Daniel Sinclair):

According to an article on Hiraku, a blog about Apple devices, any device model with “CN” or “ZA” region – denoting China and Hong Kong – will not have access to the Taiwan emoji via the keyboard.

If users have a device from another region, but they set the region to Hong Kong or Macau, the Taiwan emoji will also disappear.


Last year, HKFP reported that the names of some Chinese state leaders and activists were deemed “inappropriate words” and censored shoppers hoping to engrave their iPad, iPod Touch or Apple Pencil with a custom message.

Jeremy Burge (Hacker News):

Previously restricted on Chinese iOS devices, all other regions of the world have continued to enjoy access to all flags in the iOS emoji font, until now.


Notably, the emoji 🇹🇼 Flag: Taiwan is still supported by iOS in Hong Kong. As of iOS 13.1.2, released last week, this is now hidden from the emoji keyboard but remains available by other means.


Apple’s Hong Kong approach differs from the complete ban on the emoji in China.


Update (2019-11-27): Tim Cook:

“China really hasn’t pressured us, and so I I don’t envision that,” he added.

John Gruber (Slashdot, The Talk Show):

If China hasn’t pressured Apple, why was the Taiwanese flag emoji removed from iOS devices in Hong Kong?

Adobe to Ban Users From Venezuela

Adobe (Hacker News, Reddit):

The U.S. Government issued Executive Order 13884, the practical effect of which is to prohibit almost all transactions and services between U.S. companies, entities, and individuals in Venezuela. To remain compliant with this order, Adobe is deactivating all accounts in Venezuela.


We are unable to issue refunds. Executive order 13884, orders the cessation of all activity with the entities including no sales, service, support, refunds, credits, etc.


You have until October 28, 2019 to download any content that you have stored in your Adobe account. After this date your account will be deactivated.

I’m not sure what happened to the English version of this page that was originally at the linked URL; it now only shows Spanish.


What makes this even worse is that this is only a huge issue because Adobe moved to the whole ‘Creative Cloud’ thing rather than the old ‘buy each product outright’ model. With the old model, it wouldn’t hurt these creators all that much if their accounts got deactivated, since the software would just not get updates. Now on the other hand… they’re screwed. It’s a ‘brilliant’ example of how these ‘cloud’ based services are a bad deal for the user, because it puts them at the risk of getting locked out their own purchases due to legal hassles like this.

And the old non-subscription version is stuck at 32 bits and so won’t work with Catalina.

Sergiu Gatlan:

Microsoft-owned GitHub also banned users from Crimea, Cuba, Iran, North Korea, and Syria following previously imposed U.S. economical sanctions.


One Year After “The Big Hack”

Nick Heer:

It sounded like the information security scoop of the decade — except there’s virtually no proof that any of it is true.

At the time of the story’s publication, representatives from the named companies denied Bloomberg’s reporting in statements that left virtually no wiggle room. Tim Cook called for the story’s retraction — a call that was soon echoed by Amazon and Supermicro. Michael Riley — who reported the story alongside Jordan Robertson — took to Twitter on October 5 to point out that the physical evidence would make it “hard to keep more [details] from emerging”.

So far, that has not happened.


Most upsetting is that we don’t know the truth here in any capacity. We don’t know how the story was sourced originally other than the vague descriptions given about their roles and knowledge. We don’t know what assumptions were made as Riley and Robertson almost never quoted their sources. We don’t know anything about the thirty additional companies — aside from Amazon and Apple — that were apparently affected, nor if any of the other nine hundred customers of Supermicro found malicious hardware.

William Gallagher:

Mind you, if it were true, there would also be proof.

This was the one thing lacking from the Bloomberg piece, though you would think it would be the first thing that this or any publication would have insisted on. You would at least, at the utter least, expect Bloomberg to have one of these motherboards and show us this spy chip. Instead, we got an illustration by artist Scott Gelber.

It’s not as if the company would have had to go far —the Bloomberg company itself owns some Super Micro servers.


There is this one exception, but it’s not that anyone agrees with the story, it’s that we do not know the outcome of this other investigation. That’s because it was done by Bloomberg itself, after publication, and its findings have not been published.


Co-author Michael Riley was promoted in September 2019 to oversee all of Bloomberg’s technology security coverage.

John Gruber:

With not one shred of evidence emerging in a year, it seems very clear that this was, in fact, “the biggest reporting fuck-up of its type”.


Update (2019-12-30): See also: Hacker News.

GyazMail 1.6.1

GyazMail is now 64-bit, just in time for macOS 10.15 Catalina. This version also improves its SSL support, so it can work with mail servers that have more stringent security requirements.

I’ve always been impressed by how many OS versions it supports. The prior version worked all the way from Mac OS X 10.1 through macOS 10.14. The new version drops PowerPC support but still works all the way back to OS X 10.6.

GyazMail has built-in support for SpamSieve.