How to submit an app to Apple’s App Store when it uses encryption (opens in new tab)

Some say that this kind of policy is coming back.

   Crypto Wars Part II 
   The Empires Strike Back 
   Kurt Opsahl Deputy Executive Director of the EFF

https://media.ccc.de/v/32c3-7386-crypto_wars_part_ii#video

There is no first part of this specific talk. The talk is only called "Part II" because of the Crypto Wars of the nineties.

If you are interested in the "Part I" history

https://en.wikipedia.org/wiki/Bernstein_v._United_States

is a good starter.

Encryptions is munitions. It is the modern day "arms" that that the spirit of the 2nd amendment to the US constitution was trying to protect as a fail-safe to an overreaching corrupted government.

We don't need to bear arms anymore because we don't walk around dueling people at high noon anymore, but being an information based economy and information based society, encryption is the new gun in the wild world web.

Because you might be exporting it to an un-friendly country.

Don't try to apply logic here -- "But can't they just compile openssl or just use Linux!? or some library..." -- this is government contracting and security world, regular logic doesn't work here.

It was even worse before 2010, which was why Evernote used 64-bit RC2 encryption.

Bureaucratic nightmare? Don't you think that's an exaggeration? Sure, the government's web site UX is atrocious, but at the end of the day, it's just a couple of web forms and E-mail verification, similar to signing up for any web site. Try to legally immigrate to the U.S. and then come back and tell me that this web site is a "bureaucratic nightmare".

I talked to a couple of people at Apple and they explicitly told me that use of HTTPS is not covered under the exception. I think that exception was designed to authenticate licences of software. Programs that phone home, get a toke, and decrypt it to verify you paid for it, but that's just a hypothesis.

I would have thought this covered https.

Back when I was doing hobbyist iOS development (2009-ish) I asked Apple developer support about this, and they said it does. Worst part is it doesn't matter if you use a built-in system library like NSURLSession. Simply accessing an HTTPS URL from inside your app triggers this requirement.

Some people say the paperwork is easy to fill out yourself, but I was a college student and the legalese scared the crap out of me. And there was no way I could afford to consult a lawyer for a hobby project.

My only choice was to use plaintext HTTP for my app (which I wasn't willing to do for this particular app), or to restrict the app to the US and Canada, which doesn't require a government filing. I hated doing it, but I went with option two.

Edit: fixed typo.

I find that hard to believe too since Apple has basically deprecated HTTP is iOS 9 and OS X 10.11.

https://twitter.com/satefan/status/608093548827664384

Yes, it does. I talked to legal as well as export compliance department at Apple and they confirmed this. Maybe they were being overly cautious but so was I.

With HTTPS, what puts you clearly out of every potential exception, is the fact that you are encrypting the requests. Someone asked about this in the blog and I replied with more information.

you'd think that this is a pretty frequently asked question though, no? how could apple dev support personnel not understand/answer basic questions that affect a significant portion of apple devs?

I talked to the export compliance department at Apple. There's a chance that they say "yes, get an ERN" because they have nothing to lose and it's safer for them and in fact, there's no need for it. But I doubt it. I will consult a lawyer to make sure my whole process is good if people want me to get ERNs from them (an idea some people floated with me).

Nope, this is for everyone. Apple is exporting your app from US, so they need this paperwork from you. The only other options are:

* send Apple a paper promising that you will only distribute your app in US and Canada stores, discarding all other markets.

* make your encryption use insecure 64-bit keys.

* make your complete app open source.

* (some other options, such as when using encryption only for authentication)

If you lied to Apple and if US government finds out you export encryption without registration, and if they care enough, they will fine you (http://www.theregister.co.uk/2014/10/17/intel_subsidiary_cry...)

From the blog post the developer's to be based in the UK.

I don't think it matters where the encryption capability comes from.

The iTunes Connect FAQ says: “If your app uses, accesses, implements or incorporates industry standard encryption algorithms 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.”

There are a lot of exemptions, but only using Apple's HTTPS is not one.

Yeah, I'd like to see this answered too. If OP was just using the built in WebKit browser this seems to have all been a big misinterpretation of the rules. If they did indeed roll their own browser with HTTPS, why?

The post is a very good guide to navigating that bureaucratic process either way though.

From the screen shot of Apple's app submission: "Select yes even if your app is only utilizing the encryption available in iOS or OSX."

The OP and his company are based in London.

I would have thought that DRM is a loophole you can drive a truck through. As long as any of your data is of value, you can claim the reason for encryption is DRM. Even if you let the end user have access to all data, you could always send some sort of DRM heartbeat.

Yes this is true, but lots of people sell directly to US customers. As soon as you do you have problems :)

Yeah, that's true. I meant US company app stores. But some other countries have these kinds of rules. I know of France.

To add to that, maybe Apple is more liable because of their promises to check for quality and problems in the store, while Google allows more things in it. That just means a change for them, you, as the app maker, are always liable.

There is an important difference, though. Small companies and individuals often fly under the radar of wacky bureaucratic rules like this, whereas big companies are more visible and are stuck with them. By routing all the small-timers through a big company, they can no longer do that.

You might say, small companies should be following these rules regardless so this is just as well. And I'd probably agree. But it's still a pretty big difference.

No, most people wouldn't.