IOS9, ATS and legal quagmire - A heads up...

[Rob Willett]

We've just finished porting our software to use iOS9. 

This means that we had to make everything run with ATS, we also managed to get the Content Security Policy meta tag working on Android and IOS at the same time with the same tag. WooHoo :) 

We did not manage to get the browser working yet, so BooHoo :(

Apples new ATS security policy means that everything should run https. Thats fine in principle but we've thought through some issues that we wanted to share.

1. Amazons AWS servers need an exception to the ATS policy as they don't support the right version of software. Its a known problem and is easy to fix.

See here for more details https://mobile.awsblog.com/post/Tx2QM69ZE6BGTYX/Preparing-Your-Apps-for-iOS-9

2. Getting the right flags under the Content Security Policy is hard but doable. We just worked through our app, waiting for something to fail and then fixed it. Adding in URLs is easy, but other stuff makes calls that were very non-obvious. Things like we used expressions in our HTML templates, which made it require 'unsafe-eval' as a flag. Its slow but steady progress. 

3. The biggest issue was that something, we know not what, stopped the IOS device ready event being called when we added the Content Security Policy tag. it was not an issue on Android. This manifested itself as the ios loading screen would simply lock up. Clicking the Home button on the device, and the selecting the app got round the problem, but it was a kludge. An error was then reported on the console saying "device ready not fired for 5 secs".

Further investigation showed other people had had this and it *appeared* to be related to plugins not firing properly with the CSP tag set. All our plugins are needed, we took them out, put them back in, removed platforms and put platforms back in, still the same problem solely on IOS, both on the hardware and the simulator. It appears that the solution was to remove CSP for iOS. 

However we noticed in the plugin list the flag "gap:" with the cryptic statement 

         * gap: is required only on iOS (when using UIWebView) and is needed for JS->native communication

We searched for what gap: did, we searched some more and some more and then a lot more and gave up. We have no idea what gap: is supposed to do. We added it to the default-src element in the CSP and it magically made the bug go away and deviceready now is firing correctly on iOS. Anybody any ideas what gap: does?

4. We then remembered that when you submit an app on iTunesConnect it asks about encryption. Since our previous submission did not have any encryption we said no. However the whole point of ATS is to encrypt all your traffic. This started ringing alarm bells. 

Does this simple act of running https mean we tick the encryption button? We started looking into it. Only one comment appears to have been made by anybody as to the impact of running ATS on export controls and encryption and that was the same question we had. Do we have to register for encryption? 

We've read through the US govt BIS website which determines this

http://www.bis.doc.gov/index.php/policy-guidance/encryption/identifying-encryption-items#Three

We've read through the exemptions to the encrypted items 

-------------

What items are removed from encryption controls?

BIS has amended the EAR by implementing the agreements made by the Wassenaar Arrangement at the plenary meeting in December 2009 that pertained to "information security" items. This rule adds an overarching note that excludes particular products that use cryptography from being controlled as "information security" items. The new note focuses "information security" controls on the use of encryption for computing, communications, networking and information security. Many items in which the use of encryption is ancillary to the primary function of the item are no longer controlled under Category 5, Part 2, of the Commerce Control List (CCL).

The Adoption of Note 4 Decontrols

The decontrols note appears as Note 4 to Category 5, Part 2 of the CCL and provides as follows:

Note 4: Category 5, Part 2 does not apply to items incorporating or using "cryptography" and meeting all of the following:

(a) The primary function or set of functions is not any of the following:
     (1) "Information security";
     (2) A computer, including operating systems, parts and components therefor;
     (3) Sending, receiving or storing information (except in support of entertainment, mass commercial broadcasts, digital rights
          management or medical records management); or
     (4) Networking (includes operation, administration, management and provisioning);
(b) The cryptographic functionality is limited to supporting their primary function or set of functions; and
(c) When necessary, details of the items are accessible and will be provided, upon request, to the appropriate authority in the exporter’s
     country in order to ascertain compliance with conditions described in paragraphs (a) and (b) above.

Note 4 completely removes the decontrolled items from control under Category 5, Part 2 of the CCL.

------

and our reading of this is that everybody who uses ATS, which we believe Apple will soon make mandatory, will have to register their app with the US govt because quite simply your app uses https. None of the exemptions seem to apply to us, we do nothing clever, but ATS forces us to use https therefore you will register your app as the Apple servers are in the US and its deemed that you are exporting your app from the US back to your country of origin. So our app which is for Londoners living in the UK , written by UK people with all the data held on EU servers is subject to US export regulations. Don't you just love extra territorial legal extensions.

Now I'm not a lawyer so I could be completely wrong but I have not read a single site or any comment whatsoever that says we don't have to register. The key facts are 

1. Using https of sufficient strength - i.e. basically anything stronger than rot13. For the technically minded you could use an older encryption library, but it would a challenge to even find a version that would work on a smartphone as its so old. https seems to be all about sending, receiving and storing information so just about all ATS apps will fail at point 4 from the above. 

2. Have your data on a US server. There is no choice as Apple holds all the apps in the US.

I wonder if the US govt is ready for the avalanche of registrations coming their way? More importantly are you ready?

Comments and views welcomed. 

Rob

[Steve Sobol - Lobos Studios]

The error message seems self-explanatory to me.

"gap: is required only on iOS (when using UIWebView) and is needed for JS->native communication"

You have the Javascript layer and the native layer. They need to talk to each other. If they don't, you lose all of the features that make Cordova, Cordova.

Am I missing something here?

--
-- You received this message because you are subscribed to the Google
Groups "phonegap" group.
To post to this group, send email to phon...@googlegroups.com
To unsubscribe from this group, send email to
phonegap+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/phonegap?hl=en?hl=en
 
For more info on PhoneGap or to download the code go to www.phonegap.com
---
You received this message because you are subscribed to the Google Groups "phonegap" group.
To unsubscribe from this group and stop receiving emails from it, send an email to phonegap+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Lobos Studios - Website and Mobile App Design & Development; IT Support; Computer Maintenance
Toll Free  877.919.4WEB - Apple Valley 760.684.8859 - Los Angeles 310.945.2410 - Cleveland 216.242.4010
www.LobosStudios.com * www.facebook.com/LobosStudios * @LobosStudios

[Jesse Monroy]

Rob,

gap: is an extension used by Phonegap Build to extend XML elements in config.xml

It should do nothing in your app. But it could be causing some issues, unknown.

Here is a link to the documentation for PhoneGap Build, and the related issue.

http://docs.build.phonegap.com/en_US/configuring_config_file_element.md.html#Config%20File%20Elements

I'm outside in the pool. If there are any questions, I'll answer them later.

Cheers
Jesse

[Jesse Monroy]

Oh forgot to fix remove the gap: prefix.

Jesse

[Steve Sobol - Lobos Studios]

Jesse, you're not wrong about the XML, but Rob is correct too - PhoneGap/Cordova apps using CORS do require a gap: directive --

http://www.raymondcamden.com/2015/05/25/important-information-about-cordova-5

[Steve Sobol - Lobos Studios]

And I understand that post is about Cordova 5. I couldn't find much else on the subject, for some reason. gap: is also required with current versions of Cordova.

Jesse Monroy wrote:

Oh forgot to fix remove the gap: prefix.

Jesse

[Steve Sobol - Lobos Studios]

Ah, here we go, a canonical reference to gap:

https://github.com/apache/cordova-plugin-whitelist#content-security-policy

:)

Jesse Monroy wrote:

Oh forgot to fix remove the gap: prefix.

Jesse

[Jesse Monroy]

Okay. I got it. They are using gap: in the CSP section and it has NOTHING WHATSOEVER to do with Phonegap Build.

This retarded.

Jesse

[Rob Willett]

Gents

Thanks. I'm sorry but I still have no idea what gap: does. It is used in the meta tag, but there is nothing in the content security policy reference. I know because I have been and read it.

It appears to only be referenced in the whitelist plugin, and whilst the plugin may talk about it doing JavaScript communication, why is it in the CSP tag? The CSP tag is reasonably well documented, gap: appears to be an ios only reference and is not mentioned at all.

It certainly does do something important, at least for my application, but at the moment it appears to be voodoo. It works but there is no doc on it whatsoever as to why AND its in a tag that seems counter intuitive. I can see why putting in URLs and unsafe declarations may fit in CSP, but I still have no idea why gap: is there.

Stuff like this is worrying as since it may be something the plugin author has added and is non standard, it may change. Whilst I don't claim to understand everything about CSP I can tentatively and dimly see how it fits together, gap: doesn't fit at all.

I suppose we'll have to delve into the plugin source code and see what we uncover.

Rob

[Steve Sobol - Lobos Studios]

You'd have to ask the author(s) of the whitelist plugin. I myself am not sure.

'Rob Willett' via phonegap wrote:

[Simon MacDonald]

Hey,

You will need to add "gap:" to your CSP tag on iOS. As per the note in the cordova-plugin-whitelist repo:

gap: is required only on iOS (when using UIWebView) and is needed for JS->native communication

The "gap:" is used as a protocol like "http:" for the iOS side to communicate from JS to native. Basically when Cordova iOS sees "gap:" it intercepts the request and uses it to do the bridging of the two layers. At least that is my understanding of it but it's been awhile since I dove into that area.

Simon Mac Donald
http://hi.im/simonmacdonald

[Jesse Monroy]

Hallelujah!!!

Thanks Simon. I'll add that to my FAQ. Which reminds me. Is someone ready to take-over or help me with this beast?

TIA
Jesse

[Jesse Monroy]

FWIW: The RAW white-list FAQ so far.

RAW RAW RAW
https://github.com/jessemonroy650/top-phonegap-mistakes/blob/master/whitelist-system.md

Jesse

[jcesarmobile]

Simon is right, gap: is just like a protocol used by all the plugins to execute native code.

The way you execute native code from javascript is, you navigate to an url so the webview shouldStartLoadWithRequest is called ( usually creating an iframe with an src like "gap:functionName/params/etc" so the app navigation isn't altered )

gap: is used to make sure the shouldStartLoadWithRequest is called by a plugin and act accordingly

So, as I already told, plugins work navigating to an url that starts with gap:, so you have to tell the CSP it has to allow gap: urls.


About the submission to itunes connect, I always mark that I use encryption because my connections are https, but on the second question I mark that exceptions apply.
First time I tryed to do it the right way, I asked for the snap-r to the BIS and I got it, but I wanted to distribute on France, I had to ask for a French import declaration, and the only way of getting mailing (postal mail) them 3 copies of something (I don't remember what), and we were on a hurry, so we marked the "exceptions apply" and I've been doing that ever since.

I've read that if you use https you have to mark that you use encryption, but the thing is, a phonegap app doesn't use encryption, I don't think connecting to a https server is using encryption, the encryption is on the server, not on the app. Using ATS doesn't add encryption to the app, it's still on the server.

Anyway, the snap-r is easy to get, and the French import declaration seems that isn't mandatory if you just use apple classes, so if you think you use encryption, get the snap-r

[mayor]

I've read that if you use https you have to mark that you use encryption, but the thing is, a phonegap app doesn't use encryption, I don't think connecting to a https server is using encryption, the encryption is on the server, not on the app. Using ATS doesn't add encryption to the app, it's still on the server.

I agree with this.  though for XHR requests to https your headers are getting encrypted - and any post data is getting encrypted -  but the encryption software is in the OS not in Phonegap.

[Rob Willett]

I hadn't realised that gap: is more common than just the usage in CSP. I've never seen it before. I had seen it in the Phonegap Build stuff but discounted it as it didn't seem relevant to this discussion. 

Your explanation of shouldStartLoadWithRequest makes sense as that appeared to be the problem, a plugin was holding up the device ready event. Adding gap: stopped this or putting the app into the background and then bringing it straight back out also works.

I still don't think gap: should be part of the CSP request as it is not documented in the CSP website which is why I was confused. data: is documented so gap: looked like it should be there. Oh well, chalk this up to experience. 

Interested in your submission. We've just had our app approved by Apple (about 15 mins ago), we've released it and them immediately pulled it from sale, so I can say we got it through the process but a <cough>unexpected and undocumented feature</cough> crept through our QA process. We have a new version ready to roll later today which will have all the encryption in and the errr... unexpected and undocumented feature removed.

I have to say I'm dubious about the https exceptions as my reading of the regulations are that very, very few apps will qualify for any exception. Various FAQs state that https is classed as using encryption. I'll look further into this. I'd be very happy to be wrong.

Rob

--

[Rob Willett]

All,

I'm not trying to be difficult (honestly) but everything I have read, including the BIS regulations as thats the definitive guide, states that if you use https you must register with BIS. I know that we are using the https functionality in the OS AND we sitting on top of all that functionality AND its industry standards AND Apple already has approved it, however (as other people have said) common sense does NOT work here. Check the FAQ on the Apple website

https://itunespartner.apple.com/en/apps/faq/Managing%20Your%20Apps_Trade%20Compliance

I'm not going to copy the whole section but the following sections in it seem very clear to me. I have emphasised certain sections. 

I use the encryption available in iOS and/or OS X. Do I still need to obtain U.S. government approval?

You still need to submit your app to the U.S. Bureau of Industry and Security (BIS) for approval because they want to know how you are using encryption in your particular app, even though they have already approved the encryption in the iOS and Mac OS X. You are responsible for obtaining separate approval.

It is not necessary to provide Apple’s source code to the government because it has already been reviewed and approved by the U.S. Bureau of Industry and Security (BIS).

Does my app require ERN approval?

If your app uses, accesses, implements or incorporates industry standard encryption algorithms for purposes other than those listed as exemptions under question 2, you need to submit for an ERN authorization. Examples of standard encryption are: AES, SSL, https. This authorization requires that you submit an annual report to two U.S. Government agencies with information about your app every January.

Apple also lists Sample Scenarios.

Sample Scenarios

Scenario 1: An app uses or accesses only encryption algorithms provided in iOS or Mac OS for its security features

-- Only US Encryption Registration (ERN) will be required (even if the app is distributed in France)

I then went through and read the BIS regulations to check what Apple says. 

http://www.bis.doc.gov/index.php/policy-guidance/encryption/identifying-encryption-items#One.

If you work through this flow chart Flowchart 1 provided by BIS

Q1 - Is the item designed to use cryptography or does it contain cryptography?

Almost all items controlled under Category 5, Part 2 of the EAR are controlled because they include encryption functionality. Items may be controlled as encryption items even if the encryption is actually performed by the operating system, an external library, a third-party product or a cryptographic processor. If an item uses encryption functionality, whether or not the code that performs the encryption is included with the item, then BIS evaluates the item based on the encryption functionality it uses.

Similarly, if the item includes encryption functionality, even if the encryption functionality is not used by the item, then BIS evaluates the item based on the included encryption functionality.

My answer - Yes as it uses the encryption provided by the OS so move to next question

Q2 - Is this hardware or software specially designed for medical end use?

I've not listed the question here as my app isn't for medical use and I suspect very few people's are.

My answer - Yes so move to next question

Q3 -  Is the product described by Note 4?

Note 4: Category 5, Part 2 does not apply to items incorporating or using "cryptography" and meeting all of the following:

(a) The primary function or set of functions is not any of the following:
     (1) "Information security";
     (2) A computer, including operating systems, parts and components therefor;
     (3) Sending, receiving or storing information (except in support of entertainment, mass commercial broadcasts, digital rights
          management or medical records management); or
     (4) Networking (includes operation, administration, management and provisioning);
(b) The cryptographic functionality is limited to supporting their primary function or set of functions; and
(c) When necessary, details of the items are accessible and will be provided, upon request, to the appropriate authority in the exporter’s
     country in order to ascertain compliance with conditions described in paragraphs (a) and (b) above.

Note 4 completely removes the decontrolled items from control under Category 5, Part 2 of the CCL.

Please note that certain products may be controlled under an ECCN elsewhere in the CCL even if they are no longer controlled for encryption reasons.

This is the section that is the most difficult to read. The use of double negatives and the OR's and AND's make it tricky. The key statement to me is (a) (3). We are sending, receiving and storing information. We must be sending and receiving information as we are using a transport protocol, https. There could be an argument made about storing information, but I'd hate to try and argue that one. Even putting something into a variable could be classified as strong it. There is also an argument that the app could be entertainment, so games might be excluded.  Again I'd hate to argue that. I suspect that clause is in there for DRM usage. This means that most apps (IMHO) will not meet all the conditions in Note 4, therefore we are not exempt under Note 4.

My answer - NO so move to next question

Q4 - Is the encryption functionality limited to intellectual property or copyright protection functions?

I'm not 100% clear on this but I am assuming it is due to DRM usage. I can't see how it applies to most apps.

My answer - NO so we have a controlled item according to BIS.

This means that the Item is controlled under Category 5, Part 2 off the EAR. You then follow this flow chart (http://www.bis.doc.gov/index.php/forms-documents/doc_view/328-flowchart-2) to see if you can self classify. I'm not going to get into that flow chart now as this e-mail has gone on long enough. Basically it means you need to register but what type of registration process. 

I would suggest that people actually read all the BIS regulations and the Apple FAQ. The Apple FAQ quotes heavily from the BIS regulations, indeed the cut and paste some of them directly into their FAQ.I have relied more on the BIS regulations as Apple is subservient to them, but Apple backs up my logic as well. 

I'd be over the moon to be wrong and if somebody can show me a statement that contradicts both the BIS and Apple's own FAQ on this I'll freely admit I've made a mistake. I want to be wrong as this means less work for me. However the only way that people do not need to get registered with BIS is if they solely distribute in the US. The rest of the world has to.

Best wishes,

Rob

[Memo]

Rob,

Export controls apply to cryptography developed in the US, not in common use worldwide. Therefore you are not in violation of anything in terms of export controls if you use openssl.  You are not bound by the distribution center under such a circumstance.  It's a lot of hoops to jump through probably because  Apple decided to be special and create their own algorithm; and they must therefore not have learned years of lessons about "obfuscation not being security".  Some day, if apple's implementation shows any weakness in implementation or algorithmic strength, someone will crack it and if they really milk it, they may just switch back to open source standard algorithms shared with the application security and cryptography communities.

If someone were to create an openssl version to replace https communication for phonegap, then you'd be in the clear; from the sound of it though your interpretation seems correct.  OpenSSL will work fine on older phones.

"any encryption algorithm that is yet to be standardized by international standard bodies such as IEEE, IETF, ISO, ITU, ETSI, 3GPP, TIA, etc. or not otherwise published; or standard (e.g., AES, DES, 3DES, RSA) encryption algorithm(s) instead of or in addition to accessing or using the encryption in Apple OS"

Here is a good place to start if that is a road you want to go down.  It's actually advisable, because once again "obfuscation is not security", particularly with encryption algorithms. https://www.andyibanez.com/quick-tip-compile-openssl-arm-arm64-ios/

--

~M

[Memo]

Additionally, if you need an encrypted keystore or other security mechanism you can dodge this apple bullet with Mitre's iMAS http://project-imas.github.io/

--

~M

[Rob Willett]

Memo,

I cannot rewrite https to use OpenSSL. I do not want to have to write my own encryption or use another system, I want to use https and Apple 'encourages' their developers to use ATS when using iOS9. The use of https is covered by the BIS regulations. That is very clear and explicitly stated by the BIS and Apple website. I have not the skill or the time to roll my own encryption, there is a 100% chance I would get it wrong as encryption is very hard. 

The BIS regs are clear and the Apple FAQ is also very clear. The US BIS regulations apply as our software is on the Apple servers, they are in the US, the act of downloading from the Apple servers is an export act, therefore it comes under BIS jurisdiction and regulations. Apple themselves state this in their own FAQ. 

Scenario 1: An app uses or accesses only encryption algorithms provided in iOS or Mac OS for its security features

-- Only US Encryption Registration (ERN) will be required (even if the app is distributed in France)

I also do not think that if somebody replaced OpenSSL in https we would definitely be in the clear. It would depend on the key length as one of the questions gets into this level of detail. I do not know where your quote comes from so cannot comment on it without seeing it in a wider context. 

It is clear to me that if you are using https on your Apple app, then you must register with the BIS people and get a ERN. Apple state this. 

If you disagree please point out where my logic is incorrect. I would be delighted to be shown to be wrong.

Rob

[Memo]

The quote proves you are wrong about openssl:

"any encryption algorithm that is yet to be standardized by international standard bodies such as IEEE, IETF, ISO, ITU, ETSI, 3GPP, TIA, etc. or not otherwise published; or standard (e.g., AES, DES, 3DES, RSA) encryption algorithm(s) instead of or in addition to accessing or using the encryption in Apple OS"

OpenSSL uses algorithms with published industry standards.

You don't need to rewrite your app.  You would need to hack, at a lower level, how an SSL connection is established, which is annoying and possible; http://ios.phonesdevelopers.com/732_16711168/

Personally, I'd rather register the app, unless there is a fee - the moment apple can prove they enforce registration.

[mayor]

ok mehmet, where did the quote "any encryption algorithm that is yet to be standardized by international standard bodies..." come from?

and do we have some objective proof that OS9 uses some non-standard / non-published algorithm for https?  if so, then how can it communicate to my 100% open source server?  does it somehow use different encryption up vs down (which has never happened in the history of https)?

my thinking is that because my server only supports encryption algorythms available via openssl, that even if iOS has some whacky non-standard algorithm for https it would actually never be used since my server does not support it.

[Kerri Shotts]

@Rob,

DISCLAIMER: IANAL!!!!!!

Everything I've seen indicates that simply using HTTPS in our apps would mean that the app would be controlled by Category 5 part 2. Frustrating and _stupid_, especially since nearly all of us would be using components already cleared, but the Government doesn't work that way: it's the final product that is cleared, not the components. Grrrr.

Honestly, I'm not sure there's any good way to enforce this -- Apple certainly doesn't enforce the rule yet, because when I found all this out, I realized that all my apps that are out there fall afoul of this. I answered NO and the apps went straight through, so clearly Apple isn't checking the binaries, but that doesn't mean much (especially in light of the recent discovery of some third party SDK using private APIs to gather too much PII). On my next release, I'll have to rectify the problem and register.

@mehmet,

Your quote indicating that we don't have to do this applies only to French regulations as I read it (based on context), not the US. I'd love to be wrong, but I don't think I am.

[Kerri Shotts]

A couple things (IANAL):

• As I understand from http://robertheaton.com/2014/03/27/how-does-https-actually-work/, the client is definitely performing encryption when sending data over HTTPS.
• Just because we're using OS methods to perform that encryption doesn't mean the Government actually uses any common sense. As I understand it, the Government cares about the finished product containing encryption and less about the fact that we're using libraries that have already been approved (but only as part of other products, i.e., iOS 9). 

I'd love to be wrong, but I think just by virtue of touching HTTPS, we'd be controlled by Cat 5 Part 2. :-( 

[Rob Willett]

Memo,

I have searched for your quote and can only see it in relation to registration for French regulatory approval. If you can supply the web site where that quote comes from I can read it in full and comment. A single line is difficult to respond to. 

Apple is pushing people to use ATS. A quick Google for "Apple ATS" shows a number of documents from Apple and various blogs describing how Apple is pushing https to be the standard over http. Witness the fuss made when Google showed how to get round this. I acknowledge that you can provide exceptions to the ATS policy, but these are just that, exceptions. At the moment Amazon Web Service have issues with Apples implementation of ATS. However https will become very, very common and the norm over time.

I actually have no issues with using https in our app, it's pretty easy to do it in the app and with both our servers and 3rd party servers. We updated our app and put certificates on all our servers to solely use https in less than a day, most of the time was spent working out the Content Security Policy. My concern was that the introduction of ATS (and https) imposes additional regulatory requirements on those of who are not US based and whose app is not solely for the US market that will come as a surprise to many people. 

I stand by my original assertion that anybody who writes an app that uses https that is served to any market outside the US is subject to US export controls as defined by BIS. This means that you have to register with BIS and get a Encryption Registration Number (ERN) through the SNAP-R process. I have yet to see anything that contradicts that assertion. 

https://www.bis.doc.gov/index.php/policy-guidance/encryption/registration

This process does not appear to be difficult but for most app developers who are not wholly in the US it's rather an unexpected burden. e.g. once you have the necessary ERN you have to update two US govt depts about what you are doing with it once a year. 

I accept that Apple may not enforce registration, however most countries do not allow ignorance as a defence in law. The UK certainly doesn't and I believe the US is similar. I have no idea what the legal consequences are if Apple and BIS did check and did decide to enforce these regulations, would it be a low level misdemeanour or a stinking great fine and your app pulled from the Apple store or would the US govt want to make an example of someone. Apple states in their FAQ that you must register and I *believe* that you must submit the ERN if you answer that your app does not meet the Apple exemptions. I cannot state this for certain as we have not submitted our updated app with ATS to the Apple Store, so we haven't gone through the questions yet. Other people may be able to answer this. 

We have made a decision to stick by the letter of regulations and we have already registered for the SNAP-R process and will get an ERN.

Best wishes,

Rob

[Rob Willett]

Wow, as I was writing my reply, other people have commented.

@Kevin,

I don't believe that Apple has a non standard https implementation. We have open source servers using https (Mojolicous anybody), we have commercial (ish) servers and we have proprietary servers. All have connected with Apples https with zero problems to date. I can't see how Apples https implementation can be anything but standard. I accept there may be bugs in the implementation which causes issues and that other parties are not at the same level yet, e.g. Amazon Web Services is one that we have had to put an exception in out app for. 

@Kerri,

I thought Apple would actually check the binaries, its not difficult really, just look at the ports would be a start as many people would use standard ports such as 443. Non standard ports would be more tedious as opposed to difficult, but it doesn't strike me as major brain surgery. 

Your point on the recent pulling of hundreds of apps due to PII could well mean Apple will tighten up on a whole load of things. They have to spend their barrels of cash somehow after all. Going to ATS might mean they start to enforce it properly. 

We will follow what we understand the regulations to be, it'll cost us some time (which is money I suppose) but we'll do the job properly and not worry that one day we wake up and find our app has been pulled from the store and no recourse to getting it back in. 

Rob

[Kerri Shotts]

I just noticed that it sounds like I answered NO to the encryption questions /after/ I found out that I'd need to register in my last response.... Gah -- English! No, at the time, I wasn't aware that using HTTPS would count. Of course, ignorance is no excuse, so my next updates will follow the regulation as well. Better safe than sorry.

@Rob, going by the letter of the law is definitely a good idea. It can't _hurt_, other than wasted time, even if ultimately it is determined one didn't need to register.

[Rob Willett]

Kerri,

I didn't read it that way, however that sound of black helicopters you can hear is the BIS SWAT team coming over to have a quick word with you :)

I am astonished that HTTPS requires an ERN. The BIS database must be creaking at the seams with information on apps. And it will any get worse when ATS takes off.  Hope they upgraded their servers.

Rob

[Steve Husting]

Does this thread refer to accessing https on an external server from the app (such as through IAB), or just when you have https inside the app? Unclear to me. I don't use https in my apps.

[Rob Willett]

Steve

I'm using https to talk to external servers. That's my context. We use https with lots of Ajax calls.

Rob

[mayor]

APPL CEO Tim Cook from his recent discussion with the head NSA spook:

“We’ve said that no backdoor is a must, and we’ve said that encryption is a must,”

“No one should have to decide, privacy or security, we should be smart enough to do both,”

http://fortune.com/2015/10/20/tim-cook-against-backdoor/

so I think y'all are safe... and let's hope Mr Cook puts a few billion of their obscene war chest to cause.  but certainly if your project is high enough profile then you can't not register with the US government.

[Jesse Monroy]

My prediction - Dick Cheney dies, this all goes away.

[Memo]

Regarding the "French" paragraph, it applies to the US as well; I have a master in infosec, so while I am not a lawyer, I am familiar with these points and I can tell you unless the law has changed it mirrors the French law cited on the page.  If the law changed, the entire security community would be in an uproar and I would probably notice that.

The key here is that Apple made claim to a secret, baked it into their SDK and now you are supposed to register if you use their proprietary stuff provided you use it.  While I can't speak officially for Commerce, I doubt the department of commerce wants to be flooded basically with Apple programs that all really point to how they do encryption.  The original law is intended to limit  and control the capabilities of foreign entities to use the encryption the US develops against the US, and registering a bajillion apple apps because they use Apple's SSL masks REAL technologies of significance Commerce probably wants to actually pay attention to.

Apple's lawyers are playing CYA.  It isn't their job to enforce it.  If they do enforce it, it's an odd attempt to cause an archaic law to be mutated by putting enormous pressure on it. Think of it like a denial of service attempt on a law.

Nevertheless in all honesty I would suggest the strongest probability is that this is Apple legal/patents just going way too far.

In short, I don't think Cheney is involved on this one ;-)

On Tue, Oct 20, 2015 at 8:42 PM, Jesse Monroy <jess...@gmail.com> wrote:

My prediction - Dick Cheney dies, this all goes away.

--
-- You received this message because you are subscribed to the Google
Groups "phonegap" group.
To post to this group, send email to phon...@googlegroups.com
To unsubscribe from this group, send email to
phonegap+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/phonegap?hl=en?hl=en

For more info on PhoneGap or to download the code go to www.phonegap.com
---
You received this message because you are subscribed to the Google Groups "phonegap" group.
To unsubscribe from this group and stop receiving emails from it, send an email to phonegap+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

~M

[Rob Willett]

Memo,

I have found the source of the paragraph on the BIS website

8. What is “non-standard cryptography”? 

Non-standard cryptography, defined in Part 772– Definition of Terms, “means any implementation of “cryptography” involving the incorporation or use of proprietary or unpublished cryptographic functionality, including encryption algorithms or protocols that have not been adopted or approved by a duly recognized international standards body (e.g., IEEE, IETF, ISO, ITU, ETSI, 3GPP, TIA, and GSMA) and have not otherwise been published.”

The phrase non-standard cryptography is referenced through the section in the BIS regulations called 

May I self-classify my encryption items WITH an encryption registration?

License Exception ENC – 740.17(b)(1) and Mass Market provision - 742.15(b)(1) allow self-classification of an item and export after submission of a required encryption registration.

One section in it refers to non-standard cryptography

-----------------

Items described in 740.17 (b)(3) include:

• Chips, chipsets, electronic assemblies and field programmable logic devices.
• Cryptographic libraries, modules, development kits and toolkits, including for operating systems and cryptographic service providers (CSPs).
• Application-specific hardware or software development kits implementing cryptography.
• Items that provide or perform "non-standard cryptography".
• Items that provide or perform vulnerability analysis, network forensics, or computer forensics.

Items that are self-classified with an encryption registration per 740.17(b)(1) ALSO require an annual self-classification report.

-----------------

IANAL but my reading of this states that you have to self-classify under License Exception ENC - 740.17(b)(1). 

My French is not up to reading French law so I cannot comment on whether French law mirrors the US. 

>> The key here is that Apple made claim to a secret, baked it into their SDK and now you are supposed to register if you use their proprietary stuff provided you use it.  While I can't speak officially for

>> Commerce, I doubt the department of commerce wants to be flooded basically with Apple programs that all really point to how they do encryption.  The original law is intended to limit  and control the >> capabilities of foreign entities to use the encryption the US develops against the US, and registering a bajillion apple apps because they use Apple's SSL masks REAL technologies of significance 

>> Commerce probably wants to actually pay attention to. 

[Rob Willett]

Rats, pressed the wrong button.

>> The key here is that Apple made claim to a secret, baked it into their SDK and now you are supposed to register if you use their proprietary stuff provided you use it.  

>> While I can't speak officially for Commerce, I doubt the department of commerce wants to be flooded basically with Apple programs that all really point to how they do 

>> encryption.  The original law is intended to limit  and control the capabilities of foreign entities to use the encryption the US develops against the US, and registering a 

>> bajillion apple apps because they use Apple's SSL masks REAL technologies of significance 

>> Commerce probably wants to actually pay attention to. 

Can you expand on this as what secret have Apple baked into their SDK. Nothing I have seen indicates this, my reading is that Apple simply want to use HTTPS and they are following the BIS regulations. I actually think as the BIS websites makes clear, the BIS people DO want to know about who is using encryption on exported US programs. The process is automatic for registration so its not actually an onerous issue for them.

>> Apple's lawyers are playing CYA.  It isn't their job to enforce it.  If they do enforce it, it's an odd attempt to cause an archaic law to be mutated by putting enormous

>> pressure on it. Think of it like a denial of service attempt on a law.

The regulations certainly aren't archaic, they have been updated in the last few years so somebody is going to the trouble of keeping it relevant. I have no idea what CYA means. I also don't consider this an denial of service attempt. I used to work for IBM and we had to pay very, very close attention to US law when we pulled together global deals. We had to go into the ins and outs for each country as part of the deal and almost always had US lawyers from Armonk involved to check and make sure that we kept on the right side of the US and UN regulations. No company wants to get on the wrong side if the US laws. Apple may choose to not put backdoors in their products, thats very relevant this morning, but if the US law said they had to, Tim Cook will tell his company to do so, as would IBM, Cisco, Microsoft and every single other US company. At the moment US law says they don't have to.

>> Nevertheless in all honesty I would suggest the strongest probability is that this is Apple legal/patents just going way too far.

Again what legal/patents are you taking about? I'd be interested in seeing and reading more about this. When Apple has patents and a legal justification it goes out for somebody 100%, witness Samsung. If Apple had any patents on HTTPS or something similar, I have no doubt they would sueing the world.

Rob

[Rob Willett]

Just to close this rather long e-mail trail off with a positive update. 

We applied for our ERN this morning using the documentation from the BIS website and this website

https://www.chatmap.io/blog/iPhone-iTunes-ERN-Encryption.php

We followed the steps, filled the form out, submitted the form. The only winkle is that the form only accepts US style telephone numbers, UK telephone numbers are longer. We put our numbers in the ancillary information box and submitted. About five minutes later, we got a message, our initial assumption was that we had cocked it up. It turned out to be our ERN number. Start to finish around 30 mins to fill the form in and submit and get a response. 

So Jambuster is registered, we have an ERN so we can submit our app for the end of this week as we planned.

Rob

[Memo]

- Can you expand on this as what secret have Apple baked into their SDK. Nothing I have seen indicates this, my reading is that Apple simply want to use  - HTTPS and they are following the BIS regulations. I actually think as the BIS websites makes clear, the BIS people DO want to know about who is using - encryption on exported US programs. The process is automatic for registration so its not actually an onerous issue for them.

Who knows? Perhaps they store the result of a certificate just like everyone else and then XOR it to add a smidgen of more complexity.  The point is they likely made a conscious deliberate decision to be different - whether that is to look special, make reverse engineering or emulation/simulation more obvious or to give patent lawyers more cannon fodder, who can say?  I am not privileged with that info, and if I were, I probably would have signed enough agreements to put my entire family ten generations down the road at risk if I disclosed anything.

The regulations certainly aren't archaic, they have been updated in the last few years so somebody is going to the trouble of keeping it relevant.

The government answers new questions based on the interpretation of an archaic law (archaic in the computing world is a very short time).

 

I have no idea what CYA means.

It's typical business/consulting speak for "Cover your A$$".

 

I also don't consider this an denial of service attempt. I used to work for IBM and we had to pay very, very close attention to US law when we pulled together global deals. We had to go into the ins and outs for each country as part of the deal and almost always had US lawyers from Armonk involved to check and make sure that we kept on the right side of the US and UN regulations. No company wants to get on the wrong side if the US laws. Apple may choose to not put backdoors in their products, thats very relevant this morning, but if the US law said they had to, Tim Cook will tell his company to do so, as would IBM, Cisco, Microsoft and every single other US company. At the moment US law says they don't have to.

Ce la vie

 

Again what legal/patents are you taking about? I'd be interested in seeing and reading more about this. When Apple has patents and a legal justification it goes out for somebody 100%, witness Samsung. If Apple had any patents on HTTPS or something similar, I have no doubt they would sueing the world.

Apple sues their competitors on a regular basis, they settle in various ways like exchanging patents and so forth.  It's the way modern trade works with big tech.  However, China and India are fantastic at reverse engineering.  What they aren't fantastic at is discovering telltale tripwires planted to create a signature proving they reverse engineered something.

I can speculate all day about this and its motivation, but you know, we aren't in a coffee shop. So let's keep it simple.

If a company in the US uses nonstandard encryption, they must work with BIS.

A company would only go through the trouble of working with BIS if they use non-standard encryption (we consider cost).

Apple is working with BIS specifically and submitted source, and put forth BIS's requirement to the individuals using their encryption

Therefore, Apple has secret sauce encryption.

Corollary: If you don't use Apple's secret sauce encryption (e.g. openssl), you are not subject to this issue.

--

~M

[Kerri Shotts]

Rob, that's good to hear that it doesn't take too long or is overly onerous.

So, I've done some more of my own research, and my eyes have lost the ability to focus. Goodness, why in the world does all of this have to be written in such horribly obtuse language? Oh, I shouldn't complain, or those BIS SWAT helicopters might show up at my door again..., and they speak worse legalese yet! ;-)

I think, however, my opinion as to whether or not using HTTPS would require an app to be under EAR has changed yet again, but because of BIS's own FAQ. If you go to http://www.bis.doc.gov/index.php/policy-guidance/encryption/encryption-faqs and read Q#15, there's a whole series of examples of what wouldn't be under Category 5 Part 2. Furthermore, I think a closer reading of Category 5 Part 2 Note 4 is crucial because the note is referring to the item's primary function or set of functions. Now, English is crazy, so there's TWO ways you can read that last, but I think based on the FAQ, the intent is that the "set of functions" be read as "primary set of functions". 

That "primary" makes an important difference, because it appears that as long as the use of the cryptography is ancillary (that is, in support of the primary function(s)) then Note 4 excludes us. I'm going to consider a few examples next, but first, here's Note 4:

(a) The primary function or set of functions is not any of the following:
     (1) "Information security";
     (2) A computer, including operating systems, parts and components therefor;
     (3) Sending, receiving or storing information (except in support of entertainment, mass commercial broadcasts, digital rights
          management or medical records management); or
     (4) Networking (includes operation, administration, management and provisioning);
(b) The cryptographic functionality is limited to supporting their primary function or set of functions; and
(c) When necessary, details of the items are accessible and will be provided, upon request, to the appropriate authority in the exporter’s
     country in order to ascertain compliance with conditions described in paragraphs (a) and (b) above.

Ex A: Game App

Primary function: Gameplay (also would count as Entertainment in Note 4.a.3)

Ancillary functions: Submission, retrieval and storage of high scores

To me all games would be excluded simply because they would be considered entertainment, but even if they weren't for that reason, the transmission and storage of high scores is not the primary function of the app -- they are in support of the gameplay. Since the primary function of a game is neither information security, a computer, solely transmission of information, or networking, and the cryptography is limited to supporting those functions, the app is excluded by note 4.

Ex B: Business Inventory Management App

Primary function: Managing inventory

Secondary function: Submission, retrieval and storage of corresponding data records

Although this is fuzzier with respect to Note 4.a.3 because a business app isn't entertainment, a look at FAQ#15 seems to include items of this type. Although cryptography would be used in the moving of data, the transmission of the data itself isn't the primary function -- managing the business' inventory is. 

Ex C: CURL-like app

Primary function: connecting to servers and returning results

At this point, I think this app would not be excluded by Category 5 Part 2 because the primary function falls both under the transmission of information and the networking section of Note 4. However, if the app was open sourced and that source was online, I think it might still fall out of EAR because it would be publicly available. On the other hand, https://itunes.apple.com/us/app/stone-for-ios/id839896437?mt=8 has quite the export compliance language in the description even though it is open source.

If I'm wrong in any of the above interpretations, please correct me, but FAQ#15 seems to clear a lot up, at least for me. Of course, my reading is no doubt imperfect, so take all this with a HUGE grain of salt.

Regarding a couple other things:

• Apple does indeed use their own implementation wrt cryptography in iOS. This is why iOS wasn't susceptible to the heartbleed attack -- they don't use OpenSSL. 
• As I understand it, though, Apple's implementation IS open source and publicly available. So it's not a secret (in fact, remember the GOTOFAIL bug? https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-apples-ssl-bug-explained-plus-an-unofficial-patch/ has a good analysis, but also links to the source)
• Fundamentally, then using Apple's crypto would put one in the same boat as using OpenSSL. Both are open source and that source is publicly available.
• Whether or not your app falls under EAR, however, would depend upon the primary function(s) of the app (as I understand it). 
• Furthermore, based on Apple's wording on their own site, if your app itself is open source, you fall out of EAR anyway (because your source is also publicly available). Their wording is as follows:
• Please be advised that unless your final product is also open source, incorporating open source software containing encryption into your product may make it subject to U.S. and local country import/export laws. Please consult with your government agencies prior to exporting your product. Information about U.S. encryption export regulations can be found at the Bureau of Industry and Security
  

Finally, I don't think that it hurts anything to go ahead and get an ERN, so if one wants to follow "better safe than sorry", then it shouldn't hurt to register. And given that it only takes like 30 minutes, it's not terribly onerous to do so. And I KNOW we've all spent more than 30 minutes on all of this! ;-)

Hopefully that helps someone though, or maybe it just muddies the water even further. Oh well, c'est la vie!

[Rob Willett]

Kerri,

I read the Note 4 yesterday and my eyes bled trying to work out the language. The double negatives along with AND and OR operations make it a little difficult to understand. I looked at "primary function OR set of functions" and came to the conclusion that it DID apply. My logic was that if it meant "primary function or primary set of functions" it would have said so. I freely admit that it could be read your way and if I had one extra cup of coffee or one less I might well have swung your way, I also might not have done ;)

You may be right re open source, since our product isn't open source and we are using https we didn't look too carefully at that section for an exclusion. As you say though,  that particular app doesn't think its safe from export regulations though.

The other view point is from Apple itself. I've cut and pasted this from my earlier email. 

-------------------------------

I use the encryption available in iOS and/or OS X. Do I still need to obtain U.S. government approval?

You still need to submit your app to the U.S. Bureau of Industry and Security (BIS) for approval because they want to know how you are using encryption in your particular app, even though they have already approved the encryption in the iOS and Mac OS X. You are responsible for obtaining separate approval.

It is not necessary to provide Apple’s source code to the government because it has already been reviewed and approved by the U.S. Bureau of Industry and Security (BIS).

Does my app require ERN approval?

If your app uses, accesses, implements or incorporates industry standard encryption algorithms for purposes other than those listed as exemptions under question 2, you need to submit for an ERN authorization. Examples of standard encryption are: AES, SSL, https. This authorization requires that you submit an annual report to two U.S. Government agencies with information about your app every January.

Apple also lists Sample Scenarios.

Sample Scenarios

Scenario 1: An app uses or accesses only encryption algorithms provided in iOS or Mac OS for its security features

-- Only US Encryption Registration (ERN) will be required (even if the app is distributed in France)

-------------------------------

The highlighted section "exemptions under question 2"refers back to your Note 4. It logically links up and the references are consistent (thankfully). If you think you can swing the exemptions then you could get away with it, especially as Apple doesn't appear to check anything. 

You also make the point that the Apple cryptography is open source and as per OpenSSL doesn't require approval, Apple itself doesn't agree with your assessment, see Scenario 1. Apple believe that you need an ERN just because you use the encryption in iOS or OSX, so Apple doesn't believe that being open source excludes you from obtaining an ERN. You may subsequently be able to swing an exception through Note 4, but according to Apple that can't be because the cryptography is open source otherwise they would state it.

I think at the end of the day, it comes down to what level of risk you want to take. Some people believe the risk is negligible, I do not. Apple has a habit of blowing up over things, certain issues become hot topics for no adequately explored reason. I have spent too many months (years?) of my life trying to build my app business to jeopardise it for not following the rules here. I also spent too many years at IBM working with the lawyers trying to avoid big deals blowing up in my face due to legal issues. I've seen the fallout when people make legal assumptions and get proven wrong. 

The reason I brought this up was because I could not find a sensible answer to the encryption problem, far too many people state opinions on the internet with zero data to back them up. Some people talk complete bollocks about the export regs and I was determined to try and get to the bottom of it. I don't think we have a definitive answer though. I also think it isn't black and white but shades of grey. Get two lawyers to look at this and you'll get three different views, a large bill and a disclaimer that anything they tell you could be completely wrong. I suspect this is the most thorough discussion on encryption regulations on the net now :)

Getting the ERN was painless, I've spent more time discussing it here than actually getting it. It's cost me 30 mins to get it and Apple will be happy. They may pull my app in future but it won't be because I haven't jumped through whatever hoops Apple and BIS have set out for me. I think unless somebody is 100% certain they do not need ERN, and in law there is normally no such level of confidence, people should get the ERN and then they know they have cleared that regulatory hurdle. What's the cost of getting it wrong?

Anyway, I have to get back to work, I have to debug a set of parallel FTP function calls that drop files when run at high speed with PASV mode. <Sigh>

All the best,

Rob

--

[Memo]

Nice research Kerri!  Although is there any way to confirm iOS 9, which I thought Rob said started all of this is using the same open source? There article you cited mentions iOS 7.

I think the use of SSL conforms to FAQ5, cURL style usage. 

--

~M

[Kerri Shotts]

Rob,

I agree, I think the most frustrating thing is that there is no clear guidance on this issue. I get why companies don't just come out and say one way or the other -- CYA and liability at play -- but damn, it's frustrating. Even more so, since the law doesn't really care about your own opinion of the law (and rightly so). Furthermore, your comment about lawyers makes all this doubly frustrating, because you're right: you're almost certainly able to find two lawyers who give you a million different opinions without any assurance whatsoever.

As such, I think the safest direction is to register for an ERN if all the following apply:

• Your app is closed-source
• Your app relies on any cryptographic libraries, open source OR NOT; and this would include using SSL in any vein (including, say, InAppBrowser!)
• Your app is going to be available in any non-US region

I'm not saying that this is the correct direction, just that it's the safest. I'm not sure what it would take to get a clearer direction on what Note 4 really means, and frankly, we've all spent far more time than it would have taken to get the ERN. And we all know time is money, right? ;-)

In short, if someone were to ask my opinion of whether or not they should register, I'd have to say "to be safe, yes."

So I don't think we've come to any perfect answer -- my opinion is that most apps probably don't need an ERN, but it costs very little time to get one, so one may as well in order to be certain of their standing. I'd rather be safe than sorry, so given that, I see no real downside to registering as you have done. Perhaps if enough devs do it, BIS might actually qualify their wording and decide it for sure one way or the other down the road. Although that might be too optimistic! ;-)

Ain't encryption controls fun? ;-)

All the best, and good luck with your app! 

[Kerri Shotts]

Well, As far as I know, iOS 9 uses the same framework as iOS 7, so I doubt it's changed. But Apple doesn't list any security framework directly under iOS, just under OS X. Because iOS uses a lot of OS X stuff, I'm guessing that Apple is just employing DRY and only listing the frameworks once. BUT that's my opinion, and so it's entirely possible that Apple has since decided to go with some completely secret sauce. I doubt it, but my opinion has no bearing on reality.

Also, if you look in the documentation, the secure transport docs look pretty similar for OS X and iOS. Although it's possible for Apple to have kept the same public API and done some secret sauce internally, that seems an awful lot of work, so I'm doubting that. As such, my guess is that the security libraries available as open source under OS X are the same as those under iOS (note that even iOS 7 doesn't list using the security library, but we know it did because of GOTOFAIL).

Of import, of course, is that the most recent releases (10.11 and 9.1) are NOT YET POSTED on Apple's open source page. So, anything is possible there! ;-)

In short -- my head hurts! I think I'm going to go off and do some coding now, where things are more cut & dry! ;-)

phonegap+unsubscribe@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/phonegap?hl=en?hl=en
 
For more info on PhoneGap or to download the code go to www.phonegap.com
---
You received this message because you are subscribed to the Google Groups "phonegap" group.

To unsubscribe from this group and stop receiving emails from it, send an email to phonegap+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
-- You received this message because you are subscribed to the Google
Groups "phonegap" group.
To post to this group, send email to phon...@googlegroups.com
To unsubscribe from this group, send email to

phonegap+unsubscribe@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/phonegap?hl=en?hl=en
 
For more info on PhoneGap or to download the code go to www.phonegap.com
---
You received this message because you are subscribed to the Google Groups "phonegap" group.

To unsubscribe from this group and stop receiving emails from it, send an email to phonegap+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

~M

[Rob Willett]

Kerri,

We've both come to the same conclusion. I cannot say for certain that we MUST register, I cannot say for certain we have NO NEED to register. The downsides of registering is 30 mins of time, the downside of not registering could be prosecution under US law, or even worse, removal of app from Apple Store :) 

I would like to see BIS tidy up their act and provide simple, clear guidance, but having worked with UK civil servants for so long I have no expectation of that happening.

I suggest we draw this discussion to a close. Its currently over 40 posts long, which might be a record. 

Rob

--