Figure out what the stdlib should do about apple's new required reason manifest.

[thomcc]

Apple is cracking down on device fingerprinting by apps in the app-store. This is largely a good thing for users, but might be quite problematic for us.

https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api

From Fall 2023 you’ll receive an email from Apple if you upload an app to App Store Connect that uses required reason API without describing the reason in its privacy manifest file. From Spring 2024, apps that don’t describe their use of required reason API in their privacy manifest file won’t be accepted by App Store Connect.

That is, if you call some of the APIs listed, it needs to be for one of the reasons, and you also need to include a manifest file that explains why you're doing it.

This includes a number of APIs we use in the stdlib. I am for the moment going to assume these are only problematic if the APIs are actually called rather than if they are merely present, which will mostly mean we cannot call them implicitly for no reason (e.g. I think if a user calls an API in std that maps directly to one of these, it's fine -- they'll have to justify their usage to apple. But if we implicitly call it without a way to opt out, that's a problem, and if we implicitly call it when another option exists, that's also less than ideal).

The main problems that remain are:

• mach_absolute_time -- we use this in Instant, which is called internally in a ton of cases (many std::thread and std::sync apis, for example).

  Ideally we'd switch Instant to use mach_continuous_time, which doesn't have the same caveat. This switches behavior of Instant when sleeping (but we don't guarantee what that behavior is anyway), although doing this is blocked on Raise minimum supported Apple OS versions #104385.

  Alternatively, the 35F9.1 carveout also applies to our usage:

  Declare this reason to access the system boot time in order to measure the amount of time that has elapsed between events that occurred within the app or to perform calculations to enable timers.

  So we could also issue guidance on which boilerplate people should bundle in apps that use the stdlib. This seems worse to me, since there are APIs we could use that don't require users understand the implementation details of std::sync::Condvar::wait_timeoutor whatever.

• Any file IO which may be performed by things like the backtrace runtime (which users don't have a way of disabling when panics occur). @workingjubilee seems to believe we don't do any of this in the Mach-O codepath. Is there a way we can enforce this to avoid accidentally regressing it?

• Anything else?

[workingjubilee]

Any file IO which may be performed by things like the backtrace runtime (which users don't have a way of disabling when panics occur). @workingjubilee seems to believe we don't do any of this in the Mach-O codepath. Is there a way we can enforce this to avoid accidentally regressing it?

Throwing darts:

• Test runner with strace?
• Design a new lint that can be applied against certain APIs?
• Some way of sandboxing a binary so it can't see any files, then run it and see if it screams?

[jwise]

+1 for this request. We're currently having to build-std ourselves for our iOS library (with a change to mach_continuous_time locally), which we'd obviously rather not do :-) We weren't quite sure whether this happened in the Mach-O codepath or not in our case, so we disable the backtrace feature as long as we're rebuilding std. We'd definitely rather be running a stable, supported Rust, rather than local changes. Do you think that a PR would be accepted that simply makes at least the mach_continuous_time change? If so, I could throw one together.

Thanks!

[knopp]

Isn't instant using CLOCK_UPTIME_RAW instead of directly calling mach_absolute_time? The privacy document only mentions mach_absolute_time and not clock_gettime_nsec_np for example or CACurrentMediaTime() which uses the same clock.