[shuckles]

A third party could implement the PHAsset abstraction over their own implementation of a photo library action sheet and the file provider APIs. It wouldn’t get you to feature parity, but the major differences are but minor frictions if your privacy threat model involves nation state adversaries.

It is not possible to write an app on iOS that has permanent, transparent background network and runtime access, and it’s also not clear allowing such apps would be a privacy benefit for users at large. Apple already makes exceptions to this for certain apps (e.g. it seems like my Verizon Wireless app has background runtime). Are you suggesting that Apple should nominate a few photo services receive the same exception?

[matthewdgreen]

I’m unclear if you’re saying that one can implement a new access mechanism to Apple’s default photo library (the one managed by the Photos app and that the camera saves to by default) or if you’re suggesting that I need to design my own alternative photo album. If the latter, then “but minor frictions” seems… unreasonable.

Not sure what nation state adversaries have to do with a simple question about photo library access.

[shuckles]

If your argument is that Apple should be forced to give everyone access to the proprietary abstractions it builds on its own operating systems, like PHAssets, then we are no longer in the world of privacy and now in the world of “when is it ok to force companies to build features the public [HN posters] wants?” There are many answers to this, but it seems like the current legal regime in most places says: “Very rarely.”

My argument is that nothing stops a photo sync solution from building much of the relevant stack themselves: you can build MGAssets and get apps to adopt your photo library view controller as an action sheet or use File Provider abstractions to build the same in file pickers. 1Password, eg, offers a direct to 1P button as an SDK for 3rd parties to use. Once you separate out what you can’t do easily because it would take a lot of investment to build yourself versus what actual platform features you’d like to force Apple to build, I think your argument that the latter should be done is even less compelling.

[matthewdgreen]

The question of whether Apple should open the "proprietary abstractions it builds on its own operating system" is a major one that is now being litigated in multiple courts and regulatory jurisdictions. My argument is simply that sophisticated iCloud integration falls into this category and should probably receive attention from those same courts and regulatory insitutions.

To the extent this is about privacy, the argument is that Apple has created an opinionated regime for scanning user photos using untested technology -- and has (quite correctly, I think) determined that privacy-conscious users should have the right to opt out. The issue here is that Apple's version of "opt out" does not allow users access to the same functionality through third-party cloud providers. Users who opt out for privacy and security reasons will be substantially worse off than users who opt in. This isn't the only reason that regulators should consider revisiting Apple's cloud integration, but it's a new and important one that did not exist before Apple announced this service.

[lern_too_spel]

It's a benefit for users at large because they get to use services that provide more benefits (like Google Photos search and automatic video creation), services with more privacy (like self-hosted photo services), or services that are cheaper (like Amazon Photos).

Android has demonstrated that there is no need to whitelist this. This is purely a lock-in play for Apple.