Setting ios.non-exempt-encryption to false by default

[pozirk]

ios.non-exempt-encryption is set to true by default, so I had to change ITSAppUsesNonExemptEncryption (at {{app.file}}-Info.plist) manually to false, because otherwise Apple would not approve my app.

Set the value for this key to NO in your app’s Information Property List file to indicate that your app—including any third-party libraries you link against—either uses no encryption, or only uses encryption that’s exempt from export compliance requirements, as described in Determine your export compliance requirements. Set the value to YES to indicate that your app uses non-exempt encryption.

From here: https://developer.apple.com/documentation/bundleresources/information-property-list/itsappusesnonexemptencryption

I guess, false by default makes more sense.

[joshtynjala]

I'm going to merge this. Based on some research, it appears to me that the encryption used by Lime's (and OpenFL's) codebases would be considered to be "exempt encryption" at most. My conclusion is that Lime and OpenFL do not contain non-exempt encryption on their own, and the only reason this should be set to true is if an app developer is adding additional proprietary encryption that is not included with Lime.

Regardless, if someone's lawyers were to conclude otherwise, they'd just need to add this to their project.xml:

<config:ios non-exempt-encryption="true"/>

From Apple's docs:

Typically, the use of encryption that’s built into the operating system—for example, when your app makes HTTPS connections using NSURLSession—is exempt from export documentation upload requirements, whereas the use of proprietary encryption is not. To determine whether your use of encryption is considered exempt, see Determine your export compliance requirements.

And Apple also asks developers this question to determine which kind of encryption is included in an app (exempt or non-exempt):

What type of encryption algorithms does your app implement?

1. Encryption algorithms that are proprietary or not accepted as standard by international standard bodies (IEEE, IETF, ITU, etc.)
2. Standard encryption algorithms instead of, or in addition to, using or accessing the encryption within Apple's operating system
3. Both algorithms mentioned above
4. None of the algorithms mentioned above

The use of proprietary when referring to non-exempt encryption seems to mean a custom encryption algorithm rather than common algorithms like RSA, AES, etc. Though proprietary often refers to software being closed source, I don't think that applies in its usage here. A closed source implementation of RSA, AES, etc. would be considered exempt too. Regardless, Lime's encryption is either all open source or provided by the operating system.

For the answers to the questions, I understand that answering yes to 1 or 3 would mean that the app includes non-exempt encryption, and the ios.non-exempt-encryption flag needs to be set to true. Answering yes to 2 or 4 means that the app contains no encryption or exempt encryption only, and the ios.non-exempt-encryption flag should be set to false.

For Lime, these would be the answers.

1. No. Lime doesn't use proprietary encryption, nor encryption not accepted as standard by international standard bodies.
2. Yes. Lime bundles mbedtls for secure HTTP connections, and I think that includes implementations of exempt common encryption algorithms. If I'm wrong, and mbedtls actually delegates encryption to native functions provided by the operating system, then the answer is No, which is also just as good in terms of changing this default.
3. No, because the answer to 1 is no.
4. No, because the answer to 2 is yes.

With all of the above in mind, since Lime's included encryption is considered except, we can default ios.non-exempt-encryption to false.

[pozirk]

You definetly did more research on that then me. :)
Thank you!