Figure out what the stdlib should do about apple's new required reason manifest. · Issue #114186 · rust-lang/rust (original) (raw)

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?