Hacker News Reader

Comment by dangero | Hacker News Reader

Are you sure HTTPS counts? That seems insane to me.

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.

That cannot possibly be true. I guarantee you virtually every REST app in the store uses HTTPS and none of them went through all of this. In the latest version of iOS you can't even load HTTP by default and must use HTTPS unless you put a special exception in your Info.plist. Everybody uses HTTPS, and nobody has to go through any of this.

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.

Thank you! It is definitely a misinterpretation. Apple makes https mandatory now and there is no way every developer would have to go through this process.

I think "only" apps that allow communication are affected. Websites that only pull generic data are safe.

If you are pulling through http and http only, yes. If you are using HTTPS, you are encrypting the requests that may contain arbitrary amount of data and the exception doesn't apply to you anymore.

Why do you say there's no way? This is US law, not Apple's policy, and US law is fully capable of being that dumb. (Whether Apple allows developers to lie to Apple and violate US law is beside the point.)

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:

https://github.com/Debian/dak/blob/master/templates/process-...

(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.)

It's quite likely they don't enforce it very well.

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.

Well, all apps in App Store are encrypted/signed. So they literally all use cryptography in that sense. Does not make sense.

I suspect the distinction is that the cryptography for encrypting and signing apps is done by Apple (and they've done all the paperwork for themselves).

First, if all your app does is download encrypted information and decrypt it, you might be covered under one of the exceptions.

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.

They don't enforce it at all. Not even the US BIS really looks at your application to approve it as far as I can tell, because mine was approved instantly. They do have a lot of checks to make sure the record of your company and app are somewhat well formed.

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?"

It is true. There are a lot of exemptions, and not all uses of HTTPS require export registration.

However, if your app's main purpose has anything to with information security or sending/receiving/storing information, then you probably need ERN.

Define information, since information traditionally is just the meaningful analysis of some data.

It's whatever they mean by that word here: http://www.bis.doc.gov/index.php/policy-guidance/encryption/...

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.

I'm not disagreeing with you, I'm pointing out that querying a RESTful page with any of the C, R or U parts of the CRUD process would involve transacting information, so you basically need to keep it as HTTP.

And that's why it's madness.

I don't disagree with you, either. But I'm pretty sure the legislative intent is to be able to thwart encryption in, say, instant messaging apps. Because terrorism, national security, etcetera. I don't agree with the means (it's futile), but being able to wiretap communications between people is the intent here as far as I can tell.

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.

I understand the intent, my point is that there's very few situations where you are not transmitting information if you have any connectivity whatsoever, so the law appears overly ambiguous and far-reaching. It should be more specific about its aims.

+1.

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.

This is all pre-snowden, so I'd venture a guess that the ACTUAL reason is, well, NSA.

> That cannot possibly be true. I guarantee you virtually every REST app in the store uses HTTPS and none of them went through all of this.

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.

This is true, and I think a lot of this applications are breaking the rules. You can easily claim your app doesn't use encryption and Apple will accept it. They don't check to see whether it does or doesn't use encryption. But should something happen, Apple is clear of guilt because they asked you and you would be the one producing a false statement.

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.

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.

Reply on news.ycombinator.com