Archive for December 31, 2020

Thursday, December 31, 2020

NSURL/SMB Precomposed Character Bug

Thomas Tempelmann (tweet):

So, if a user on a Linux system creates a folder that contains an Umlaut such as “ü”, it’ll end up precomposed on the (ext4) file system.

Now, I can nicely access files in such a folder from macOS, as long as I only use POSIX functions (which includes the shells such as bash and zsh).

However, when I use NSURL operations, some work and others give me a -260 error. For instance, getting NSURLCanonicalPathKey fails, even in macOS 11.1. Other higher-level functions fail as well, such as trying to open the item with [NSWorkspace openURLs:…]. The NSURL’s path property does still hold the original precomposed name, and if I get the path and pass it to a POSIX function, it works. And some of the more basic getResource accessors work as well. Just not the more complex ones.

This is not a surprise because, before relenting and adding Unicode normalization support to APFS, Apple tried to solve the problem in the Cocoa layer. But that only ended up being a partial solution, the result being that some APIs never worked properly until file system support was added. Now it seems that same code is doing unwanted conversions before the paths make it down to the lower level APIs.

Previously:

Tiny Open and Save Dialogs in Big Sur

Jon Gotow:

Yes, the Open and Save dialogs keep appearing at their smallest possible sizes in Big Sur 11.1. It’s not just you, and it’s not something you’ve done wrong – it’s a bug in Big Sur.

[…]

Sadly, resizing the dialog so it’s larger only works on the current one. Every time you’re presented with an Open or Save dialog, it’ll be back to its uselessly small size again because Big Sur doesn’t remember the past size like it’s supposed to.

To work around this problem until Apple fixes it (hopefully in Big Sur 11.2), you can set Default Folder X to force dialogs back to the size you dragged them to.

Previously:

Fired App Reviewer Sues Apple

Pham v. Apple (PDF, via Llyod Chambers):

After plaintiff Pham approved the Guo Media App, the Chinese government contacted defendant Apple and demanded that the Guo Media App be removed from defendant Apple’s App Store. Defendant Apple then performed an internal investigation and identified plaintiff Pham as the App Reviewer who approved the Guo Media App.

In or around late September 2018, shortly after defendant Apple provided plaintiff Pham with the DCP, plaintiff Pham was called to a meeting to discuss the Guo Media App with multiple defendant Apple supervisors and managers. At this meeting, defendant Apple supervisors stated that the Guo Media App is critical of the Chinese government and, therefore, should be removed from the App Store. Plaintiff Pham responded stating the Guo Media App publishes valid claims of corruption against the Chinese government and Chinese Communist Party and, therefore, should not be taken down. Plaintiff Pham further told his supervisors that the Guo Media App does not contain violent content or incite violence; does not violate any of defendant Apple’s policies and procedures regarding Apps; and, therefore, it should remain on the App Store as a matter of free speech.

[…]

Defendant Apple became aware of plaintiff Pham’s criticism and defendant Apple’s managers responded by retaliating against plaintiff Pham and ultimately terminating plaintiff Pham.

The court doesn’t agree that he was harassed but seems to be taking other claims seriously.

See also: Courthouse News, Eugene Volokh.

Tim Hardwick:

Sunday’s NYT report claims that Eddy Cue, Apple’s senior VP for internet software and services, has informed Apple TV+ partners that “the two things we will never do are hard-core nudity and China.”

Previously:

Update (2021-01-01): See also: Hacker News.

The Case of the Extra 40 ms

John Blair:

I reported my discovery to the integrator and the chip vendor (look, it’s the Android Thread scheduler!), but they continued to push back on the Netflix behavior. Why don’t you just copy more data each time the handler is called? This was a fair criticism, but changing this behavior involved deeper changes than I was prepared to make, and I continued my search for the root cause. I dove into the Android source code, and learned that Android Threads are a userspace construct, and the thread scheduler uses the epoll() system call for timing. I knew epoll() performance isn’t guaranteed, so I suspected something was affecting epoll() in a systematic way.

At this point I was saved by another engineer at the chip supplier, who discovered a bug that had already been fixed in the next version of Android, named Marshmallow. The Android thread scheduler changes the behavior of threads depending whether or not an application is running in the foreground or the background. Threads in the background are assigned an extra 40 ms (40000000 ns) of wait time.

A bug deep in the plumbing of Android itself meant this extra timer value was retained when the thread moved to the foreground. Usually the audio handler thread was created while the application was in the foreground, but sometimes the thread was created a little sooner, while Ninja was still in the background. When this happened, playback would stutter.

Google Authenticator 3.1

Oliver Haslam:

Google Authenticator for iPhone has had some attention lavished on it, with the new app featuring a redesigned interface that also includes support for dark mode for the first time.

Alongside the new look, Google has also added a new feature that allows users to export their accounts for use on another device – a huge deal for those who regularly switch phones.

Paul Haddad:

How was this not a 1.0 feature? I’ve basically stopped using this when I can just because this was missing.

AppForce1:

I must say the migration / export is cumbersome. You need to have two devices present when performing the migration. No way to create an off device store.

I have been using 1Password for one-time passwords, because it syncs and I can easily back it up myself. But it’s admittedly less secure to have both the password database and “2-factor” on the same device (albeit in separate apps).

Rosyna Keller:

Google literally wanted users to create a new key for every account on every device they owned.

They considered it more secure, not taking into account human nature that results in users choosing less security over frustrating QR code generation that’s very hard to access.

Copyright © 2000–2024 Michael Tsai.