When I started the process of getting the ERN, I quickly notice it was going to be a long and arduous process and that other people could benefit from the lessons I was learning the hard way, so I decided to document it all in a long blog post.
This is probably one of my most researched pieces ever. The whole process took about two months from the start, researching this thing called ERN, to getting the app published in the Mac App Store, satisfying that what I did was (more or less) correct.
Crypto Wars Part II
The Empires Strike Back
Kurt Opsahl Deputy Executive Director of the EFF
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
is a good starter.
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.
One fuck up and you've got death, permanent pain, or some other outcome that's pretty fucking unpalatable. (I assume that at least cops in the US have gold plated health insurance...?)
Here is my question. How much of the problem endemic to US police is on account of a culture of fear. Citizens should not fear the police, but that works both ways.
I'm just spitballing here.
The spirit of the amendment may have been in the right place and surely worked when the constitution was written but we live in a very different world now and if you still think the an armed citizenry will avoid tyranny, you need to go to youtube and see what the military can now do.
Only half kidding.
It is unlikely for a paramilitary organization to compete with the armed forces, but in a state where the country is stressed and divided, I don't think the armed forces would stand as a fully united organization. However, while I do concede that my argument is weak, I also assert that it is not nil.
There is no possible way that the military of today, with all its tanks and bombs and drones and planes, could even attempt to hold any large portion of America under martial law.
Pennsylvania State Constitution, 1776: "The right of the citizens to bear arms in defense of themselves and the State shall not be questioned."
New Hampshire State Constitution, 1783: "All persons have the right to keep and bear arms in defense of themselves, their families, their property and the state."
And, of course, the second amendment itself: "A well regulated militia being necessary to the security of a free state, the right of the people to keep and bear arms shall not be infringed."
The supreme court disagrees with you (see District of Columbia vs. Heller) re your need to bear firearms. But if encryption is the new firearm, that might be an important ruling for crypto.
He's talking about his need to bear firearms. SCOTUS in Heller was talking about his right to bear firearms. There's no disagreement here at all.
- I don't need firearms.
- I need encryption, as it is the equivalent of a weapon in the information age.
- I have a right to bear arms
- The Feds consider encryption to be a munition.
If these assumptions are true, I think you can make an argument that wielding strong encryption is conceptually equivalent to having a rifle.
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.
Note that the OP said that the list was the effort of months of trying to understand and negotiate the system. Just because it appears to be 'a couple of web forms and email verification', it's in no way similar to signing up for a web site because it's behind so much opacity. You can't judge the effort involved in producing something simply by its final output.
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.
So either you asked the wrong question, misinterpreted the answer, or you simply talked to someone who didn't understand your question or otherwise just didn't know themselves.
I specifically asked them if using NSURLConnection (the standard, built-in URL library before NSURLSession) to access a URL over HTTPS qualified under the registration requirements. They told me, in no uncertain terms, that using any cryptography, including cryptography built into the operating system, meant I needed to register if I wanted to export the app outside of the US and Canada. I promise you, I didn't misinterpret. Though as you say, it's very possible the person I spoke to was wrong, or that their interpretation of the law was overly cautious and they've changed their policies.
Obviously the App Store is using HTTPS, so it's not. The App Store is a program by Apple and I'm sure Apple has an ERN to cover their asses.
When it comes to Apple, they don't check for this, they just want you to be on the record with either an ERN or the claim of no encryption, so that it's not their fault if the US government comes and says "hey, about all those apps you are exporting, are they using munition-level tech?"
However, if your app's main purpose has anything to with information security or sending/receiving/storing information, then you probably need ERN.
If you're not sure, and don't want to risk it, either do the ERN or get a lawyer to tell you it's not needed.
And that's why it's madness.
It's quite simple to implement an instant messaging app on top of CRUD, so "it's just CRUD" is not a valid counter against this type of politics.
Then they're breaking the law. Which is unsurprising, since the law is way more complicated than anyone expects, but unless you have a lawyer who has said "No, that's clearly not what the law means," you shouldn't expect that the law is sensible.
I read a lot of blog posts and looked at a lot of information and there's a general advice of "just pretend not to use encryption" or "https doesn't count" which is just wishful thinking from people that didn't want to use ERN and when you go dig deep enough it doesn't hold any water.
Debian's archive software used to send an automated mail to the US government every time a new package is accepted, just in case it involves crypto:
(Looks like the government told them "Okay, okay, we don't care" at some point, but that was what they determined their legal obligation was after consulting with lawyers about what the law actually said.)
I'm beginning to wonder if the ACTUAL policy Apple is trying enforce w.r.t. HTTPS is if you were to roll your own suite of encryption tools (i.e. as opposed to using the OS's TLS/SSL implementations).
That would be far more reasonable. Especially considering, with iOS 9, HTTPS is now the default configuration for all traffic.
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.
* 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...)
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.
What about custom crypto then?
On the other hand, custom crypto will almost certainly be defective, so why bother prohibiting it it?
The post is a very good guide to navigating that bureaucratic process either way though.
Starting in iOS 9.0 and OS X v10.11, a new security feature
called App Transport Security (ATS) is available to apps and is
enabled by default. It improves the privacy and data integrity
of connections between an app and web services by enforcing
additional security requirements for HTTP-based networking
requests. Specifically, with ATS enabled, HTTP connections must
use HTTPS (RFC 2818). Attempts to connect using insecure HTTP
fail. Furthermore, HTTPS requests must use best practices for
Does that mean that in the future nearly every App will need the ERN?
Given this, it would seem odd that you would need to apply for an ERN (is this true for app outside of the US?)
The TP pool memo in Neal Stephenson Snow Crash seems sane by comparison.
A big part of our app was "sending, receiving, and storing information", so we weren't sure this exemption would apply to us. So, we did the ERN anyway, and it took a couple of days calendar time, and a couple of hours of working time, IIRC.
By the way, nowhere does it say that using HTTPS is fine if you just use Apple's APIs and frameworks. I don't think it's relevant here.
> (a) The primary function or set of functions is not any of the following: [...]
> ...... (3) Sending, receiving or storing information (except in support of entertainment, mass commercial broadcasts, digital rights management or medical records management);
Triple negative - now that's something. And DRM and the entertainment industry gets a special case, isn't that great?
Not sure. This looks like a US-centric, bureaucratic thing. I doubt that F-Droid https://f-droid.org/ requires this kind of nonsense when submitting apps.
Apple is required the ERN to cover their asses, I believe. The ERN is required by the US government, so, if you don't have it, you are breaking the law whether you are using Google Play or Apple. So, you should get it for Google Play too.
The second problem was a lot of jargon that was in my opinion unnecessary and was internal US government leaking to the end users and you had to learn it to understand the documentation about what to do. Figuring out what SNAP-R stood for took me way to long and it's nothing more than a website registration (from my point of view).
Am I legally exporting crypto from the US if am not in the US?
Remember when you could distribute software yourself without getting threatened? Remember when platform vendors didn't take a 30% cut of everything you earned just because they wrote an OS? Not even Microsoft was that evil.
I hope you enjoy the world you've built, hipsters.
 See the f.lux Apple distribution debacle
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.