App with com.apple.security.files.user-selected.executable=True rejected from App Store

Apple seems to be stepping up the security lately. At least some people thought that this entitlement should have been deprecated two years ago (https://forums.developer.apple.com/thread/71800). At any rate, it is clearly something that is appropriate for a sandboxed app that is not in the Mac App Store (if such a fanciful beast exists). Going forward, developers should consider how a given feature would work on iOS and use that approach. If that doesn't make any sense for macOS, then drop that feature entirely or leave the Mac App Store.

The entitlement "com.apple.security.files.user-selected.executable" is not deprecated as of today. It makes totally sense to use it, e.g. any edit application that allows editing executables should have it. Even Apple is using it with the application "TextEdit". Other editors in the Mac App Store like "BBedit" use it as well.

So, if some apps are allowed to use this entitlement in the App Store today and others are getting rejected, I would like to understand the rules behind it. What are the guidelines to use this entitlement as long as it is not deprecated?

The sad implication here is there is no difference betwen what iOS and macOS are tasked to do. In otherwords, hauling 1 ton of gravel in the back of your Hoda Accord is perfectly reasonble. In otherwords, while I use both iOS and macOS, there are tasks I do in macOS that are not at all reasonable to even attempt to do in iOS.

"com.apple.security.files.user-selected.executable" set to true is reasonable under some conditions. That, or the poorly thought out rules for setting the quartine bit need to be re-examinded and fixed.

I fully agree with you regarding the ruleset for quarantining.

In the meantime I have released the app in the macOS App Store with the entitlement "com.apple.security.files.user-selected.executable=false", because Apple has not granted the right to use it yet. At the same time I have opened a support case, because for the specific app, not to use the entitlement introduces a security issue from my point of view.

The app implements file level deduplication for APFS and replaces all duplicate files with clones, in order to free up disk space. After replacing a file with a clone of a duplicate, the app replaces all metadata of the clone with the metadata of the previously removed file. This works fine, other than that the quarantine extended attribute is set if I don't use the entitlement. As a result the deduplication app overwrites all existing quarantine extended attributes of deduplicated files, which may be a security issue for the user. The user gets warnings that files were downloaded by "diskDedupe", even though the file was actually downloaded by another possibly dangerous app. My app does not change a single bit of any file, it performs only cloning of existing files and changes metadata like timestamps etc. still unfortunately the quarantine extended attribute is set by the OS. I have published a workaround on the apps website to remove the quarantine bit for now, but it would be much better, if macOS would not create quarantine bits for clones at all.

The Apple support engineer agrees with my point of view and is currently trying to convince the app review team to grant the entitlement for security reasons. But the app review team is not responding since weeks now (the app is "in review" since more than 4 weeks now without any notice).

Update: Apple has finally rejected the app with "com.apple.security.files.user-selected.executable" set to true. I released diskDedupe without the entitlement and published a script to remove the quarantine flag on the support website.

The Mac App Store is designed to provide a higher level of security, albeit at a reduced level of functionality. You have made what sounds like a clever app. But what most honest developers don't realize is the staggering scale of fraud in the industry. It isn't a question of whether you will abuse this entitlement, it is a question of how it could be abused by other developers. If your entitlement is allowed in the store, a malware developers will come right along with a "diskUndupe" app and cite your app as precedence. The problem is that "diskUndupe" also creates malware. How is random App Reviewer supposed to tell the difference between them? It is trivially easy to see the dozens of posts here in the forums by these scamware developers complaining about having their apps rejected because XYZ apps are already in the store.

There is nothing wrong with releasing your app outside of the Mac App Store.

I fully support Apple in making the Mac App Store a safer place. To achieve this, Apple should fix their bad implementation of setting quarantine attributes, as NoiseTECH pointed out.

Why is setting a timestamp on a file overwriting the quarantine attribute? Why is cloning a file with Apple’s standard library overwriting the quarantine attribute? I don’t see how these actions could introduce malicious code? But by overwriting the quarantine attribute, marked malicious code (e.g. downloaded by Safari) will lose important information.

I do understand that the use of this entitlement is only a workaround to circumvent this peculiar behaviour of quarantining. But I don’t understand why I should be forced to release diskDedupe outside of the Mac Apple Store in order to make it more secure.

Apple’s policy to approve apps that use this entitlement seems to be not consistent (there are recent updates of apps in the App Store that use this entitlement). This arbitrariness does not improve the level of security in the Mac App Store.