Archive for May 6, 2024

Monday, May 6, 2024

SteerMouse 5.7

Plentycom Systems:

SteerMouse is a utility that lets you freely customize buttons, wheels and cursor speed. Both USB and Bluetooth mice are supported.


You can assign a function to combinations of a button and modifier keys ( command shift option control ). In addition to it, you can assign a function to combinations of buttons. Your mouse will have unlimited potential.


System Settings only allows adjustment for the Tracking Speed. SteerMouse allows adjustment of the Sensitivity on top of that. By adjusting both values, you can move the cursor just like you move your hand.

Via John Gruber:

I’ve been using and wholeheartedly recommending SteerMouse for nearly 20 years.

It’s also the case that even with a third-party mouse, you might not want any third-party driver software at all. MacOS’s built-in mouse software recognizes most mice. I rely on SteerMouse not because my mouse has lots of buttons (it doesn’t), but to get fine-grained control over the speed and acceleration of the pointer. SteerMouse lets me set my mouse to go way, way faster than the built-in Mouse panel in Settings does — something I’ve done for decades to reduce wrist fatigue and pain. I can move my pointer from corner to corner across my Studio Display by moving my mouse just a few centimeters.

iOS 17 Calendar Search Failures

keldwink (via Ric Ford):

Updated my 15pro to 17.0.2 and I can no longer search in the calendar app. No matter what I search for, it comes up with “no results”

The replies list various potential fixes. It’s not clear to me whether something is specifically broken with iOS 17 or this is just typical Spotlight behavior. My advice is to use Fantastical, even if you don’t need the fancy features, because the basics work so much more reliably.


Apple’s Third-Party SDK List for Privacy Manifests


Starting May 1, 2024, new or updated apps that have a newly added third-party SDK that‘s on the list of commonly used third-party SDKs will need all of the following to be submitted in App Store Connect:

  1. Required reasons for each listed API
  2. Privacy manifests
  3. Valid signatures when the SDK is added as a binary dependency

Antoine van der Lee:

While Apple provides rich documentation, it’s hard to understand what you must do. Therefore, I decided to simplify the process and added a frequently asked questions section to help you.

Donny Wals:

In this post, I’d like to show you how you can add a privacy manifest file to your app so that you can resolve rejections related to ITMS-91053.


Adding a privacy manifest file is a new requirement from Apple that, in my opinion, could have been handled better. Manually working on plist files is a tedious job and the keys and values aren’t that easy to manage.

Privacy Manifest Generator:

Since editing the file by hand is somewhat tedious, this site will help you generate the file instead so you just select which items you need to include and we do the rest!

Jesse Squires (Mastodon):

But then… you see that the list contains UI libraries that haven’t seen significant updates or any activity for multiple years, like SVProgressHUD. Why does a library that provides a single UI component need a privacy manifest? Is it as concerning and as potentially privacy invasive as the Facebook SDK? Some of the UI-only SDKs on the list haven’t seen significant updates (or any updates at all) within the last 4-5 years. Furthermore, even AFNetworking hasn’t had an update in 4 years because it was deprecated long ago after being supplanted by Alamofire. The AFNetworking repo on GitHub has been archived and read-only for over a year! Who’s going to bother adding a privacy manifest to that?


And then… you know what’s even more bizarre about this list? There are no links! There are no links to the SDK project homepages or GitHub repos. It is a plain text list of names, and in some cases, seemingly random names like “file_picker”. Ok LOL. SDK and library names are not necessarily unique. How are you supposed to know exactly which SDKs they are referencing with so little information? Searching for “file_picker” or “image_picker_ios” or any of the other obscure names on both CocoaPods and the Swift Package Index returns no results!


As many readers have pointed out, there are also a number of popular SDKs that really should be on this list if Apple is concerned about privacy. For example, the TikTok SDK, GoogleAds, and the Unity Ads SDK are all missing from the list, just to name a few. How strange!


When Apple imposes new privacy regulations in such a slipshod manner, how are we, as developers and as users, supposed to take this seriously? This feels like more bureaucratic security and privacy theater.

Nick Heer:

I assumed this list would be dominated by SDKs for analytics, authentication, logging, advertising, and other potentially sensitive use cases. […] This list of SDKs contains seemingly few such packages. As of writing, there are 87 SDKs on Apple’s list and fully one-quarter of them — by my count — are Flutter packages intended to simplify cross-platform development.


As Squires writes, any documentation about why these SDKs are on Apple’s list would be helpful.

Talal Haj Bakry and Tommy Mysk:

In practice, we analyzed the network traffic of several popular apps that were updated after May 1, when this new requirement took effect. We focused on the API that retrieves a device’s boot time, or system uptime. It is the elapsed time in seconds since a device was restarted. Combined with a few other signals, the system uptime leads to generating a very accurate fingerprint of a device.


All the approved reasons emphasize that information retrieved by the APIs may not be sent off-device.


Our testing shows that Facebook still sends the system uptime off-device.

So do Google Chrome, Instagram, Spotify, and Threads. Like privacy nutrition labels, privacy manifests seem to be privacy theater.


Update (2024-05-07): Thomas Claburn (Hacker News):

The Register asked Google, Meta, and Spotify whether they are in fact using these “required reason APIs” for iOS device fingerprinting and beaming that data off to backend servers, and we’ve not heard back from the last two. A Google spokesperson confirmed it is looking into the report, but didn’t immediately have a response.


Although Apple’s rule plainly states that uptime data cannot be sent off-device, Google Chrome appears to be doing just that, based on network data analysis from Bakry and Mysk. The rule does allow for an exception, but one that doesn’t apply to Chrome.


Cupertino did not respond to a request for comment.

Swift’s Native Clocks Are Very Inefficient

Wade Tregaskis (Hacker News):

In a nutshell, the problem is that Swift’s Clock protocol has significant overheads by design. If you look at a time profile of code like this, you’ll see things like[…]

That’s a lot of time wasted in function calls and struct initialisation and type conversion and protocol witnesses and all that guff. The only part that’s actually retrieving the time is the swift_get_time call (which is just a wrapper over clock_gettime, which is just a wrapper over clock_gettime_nsec_np(CLOCK_UPTIME_RAW), which is just a wrapper over mach_absolute_time).


The downside to calling mach_absolute_timedirectly, though, is that it’s on Apple’s “naughty” list – apparently it’s been abused for device fingerprinting, so Apple require you to beg for special permission if you want to use it (even though it’s used by all these other APIs anyway, as the basis for their implementations, and there’s nothing you can get from mach_absolute_time that you can’t get from them too 🤨).

This matches my experience that intuition is often wrong regarding Swift performance. Sometimes what seems like it would be a simple virtual call has more overhead than an Objective-C message send. Various dynamic stuff involving checking types/protocols can also be much slower than with Objective-C. The good news is that Date is fast, not even calling down to NSDate, and that there’s a pull request to inline some of this.