4 ms·

What's the status with the US crypto export paperwork that Apple apparently requires for all crypto-enabled apps, even if they just use iOS builtin URL classes

by 0x0 11y ago

What's the status with the US crypto export paperwork that Apple apparently requires for all crypto-enabled apps, even if they just use iOS builtin URL classes with https urls? I know first-hand of several non-US apps where https was dropped just because of the opaque and vague requirements. In fact it seems strange to require non-US developers, who purchased an iOS developer program account from a non-US Apple company, to register with US government for "export permission" when all they want to do is publish their app on a non-US app store.

mapmap 11y ago
It is still a question Apple asks when you submit your app. It's up to the developer to figure out if they need an encryption registration number or not. The SNAP-R process takes about 3 days and can be done entirely online.
- 0x0 11y ago
  For niche one-off apps, like a conference event schedule/program guide, which doesn't process anything particularly sensitive, 3 days with unclear legal paperwork and waiting = https becomes a dealbreaker.
- profmonocle 11y ago
  > The SNAP-R process takes about 3 days and can be done entirely online. True, but last time I looked at it (late 2012) the legalese was intimidating enough that I didn't feel comfortable attempting it without consulting a lawyer. Since the app was just a personal side project, paying for a lawyer wasn't an option and I chose to restrict my app to sale in the US and Canada only. (Which doesn't require any government filing at all.) All because I wanted to access a backend service over HTTPS. It's mind-boggling that my app can be called "encryption software" because it calls a shared library built into the operating system.
  - 0x0 11y ago
    It doesn't? That must be the reason why so many trivial apps aren't available world-wide. I've always wondered why a publisher wouldn't just click the "worldwide" checkbox. French iOS users must be missing out even more. Looks like Apple requires extra paperwork for crypto exported to France specifically.
- dcosson 11y ago
  FWIW just a couple weeks ago we got through the whole SNAP-R process a lot faster, in about 2 hours. It was a strange experience though. It felt like if anything Apple was trying to dissuade us from using encryption by presenting this vague legal hoop with very minimal guidance or concrete examples on what to do. The few other iOS devs I asked didn't remember much about it, the impression I got is that everyone not working for a big company with a legal or compliance team pretty much just checks "No" whether or not they're using https. Some people likely don't even realize using https counts as encryption, it wasn't explicitly called out anywhere on the form (though it does say something about "even if the encryption is built in to libraries provided by Apple", but of course no list of which libraries might include encryption). It feels odd and a bit lazy that Apple hasn't made this process any easier, when they clearly think a lot about encryption if they're going so far as to start requiring it. Maybe the legal requirements force them to keep the explanation generic and not do anything to improve the user experience around it.
mrsteveman1 11y ago
I've spent quite a bit of time reviewing the current regulations and talking on the phone with BIS in the past month about encryption export as part of a contract, it can be complicated or quite simple, depending entirely on things like: Is it infosec software, or a game/kitchen recipe app? Is it using "standardized" algorithms? Can they or the key sizes be changed by the end user? Can the encryption functionality be easily repurposed? Binaries or source code? Which destination country(s)? Who is the intended end user (government vs private entities)? As there can be significant civil and even criminal penalties for exporting an item without complying with the regulations, the best thing to do in all cases is to call BIS[1] and ask to speak with an export counselor, specifically ask about encryption and you'll get routed to someone who knows the regulations and can tell you exactly what your specific software will require to comply. > What's the status with the US crypto export paperwork that Apple apparently requires for all crypto-enabled apps, even if they just use iOS builtin URL classes with https urls? Apple (last time I checked) directs developers to obtain an Encryption Registration Number at minimum, but there can be additional "classification" and reporting requirements depending on the factors I listed above. > In fact it seems strange to require non-US developers, who purchased an iOS developer program account from a non-US Apple company, to register with US government for "export" when all they want to do is publish their app on a non-US app store. An export counselor could give a definitive answer but this is likely because the encryption they're using in iOS/OS X is still considered a U.S. controlled item for export purposes, regardless of where they are or where the software using it ends up being sold. That software may end up being considered a U.S. controlled item itself. I've been told by BIS that re-exporting a U.S. controlled item from a foreign country without complying with U.S. export regulations can come back to bite you down the road, among other things they can completely deny a foreign entity the ability to export or import things to/from the U.S. if they decide export regs have been ignored. [1] https://www.bis.doc.gov/index.php/about-bis/contact-bis https://www.bis.doc.gov/index.php/about-bis/contact-bis

by 0x0 11y ago

mapmap 11y ago

It is still a question Apple asks when you submit your app. It's up to the developer to figure out if they need an encryption registration number or not. The SNAP-R process takes about 3 days and can be done entirely online.

0x0 11y ago
For niche one-off apps, like a conference event schedule/program guide, which doesn't process anything particularly sensitive, 3 days with unclear legal paperwork and waiting = https becomes a dealbreaker.
profmonocle 11y ago
> The SNAP-R process takes about 3 days and can be done entirely online. True, but last time I looked at it (late 2012) the legalese was intimidating enough that I didn't feel comfortable attempting it without consulting a lawyer. Since the app was just a personal side project, paying for a lawyer wasn't an option and I chose to restrict my app to sale in the US and Canada only. (Which doesn't require any government filing at all.) All because I wanted to access a backend service over HTTPS. It's mind-boggling that my app can be called "encryption software" because it calls a shared library built into the operating system.
- 0x0 11y ago
  It doesn't? That must be the reason why so many trivial apps aren't available world-wide. I've always wondered why a publisher wouldn't just click the "worldwide" checkbox. French iOS users must be missing out even more. Looks like Apple requires extra paperwork for crypto exported to France specifically.
dcosson 11y ago
FWIW just a couple weeks ago we got through the whole SNAP-R process a lot faster, in about 2 hours. It was a strange experience though. It felt like if anything Apple was trying to dissuade us from using encryption by presenting this vague legal hoop with very minimal guidance or concrete examples on what to do. The few other iOS devs I asked didn't remember much about it, the impression I got is that everyone not working for a big company with a legal or compliance team pretty much just checks "No" whether or not they're using https. Some people likely don't even realize using https counts as encryption, it wasn't explicitly called out anywhere on the form (though it does say something about "even if the encryption is built in to libraries provided by Apple", but of course no list of which libraries might include encryption). It feels odd and a bit lazy that Apple hasn't made this process any easier, when they clearly think a lot about encryption if they're going so far as to start requiring it. Maybe the legal requirements force them to keep the explanation generic and not do anything to improve the user experience around it.

mrsteveman1 11y ago

I've spent quite a bit of time reviewing the current regulations and talking on the phone with BIS in the past month about encryption export as part of a contract, it can be complicated or quite simple, depending entirely on things like: Is it infosec software, or a game/kitchen recipe app? Is it using "standardized" algorithms? Can they or the key sizes be changed by the end user? Can the encryption functionality be easily repurposed? Binaries or source code? Which destination country(s)? Who is the intended end user (government vs private entities)? As there can be significant civil and even criminal penalties for exporting an item without complying with the regulations, the best thing to do in all cases is to call BIS[1] and ask to speak with an export counselor, specifically ask about encryption and you'll get routed to someone who knows the regulations and can tell you exactly what your specific software will require to comply. > What's the status with the US crypto export paperwork that Apple apparently requires for all crypto-enabled apps, even if they just use iOS builtin URL classes with https urls? Apple (last time I checked) directs developers to obtain an Encryption Registration Number at minimum, but there can be additional "classification" and reporting requirements depending on the factors I listed above. > In fact it seems strange to require non-US developers, who purchased an iOS developer program account from a non-US Apple company, to register with US government for "export" when all they want to do is publish their app on a non-US app store. An export counselor could give a definitive answer but this is likely because the encryption they're using in iOS/OS X is still considered a U.S. controlled item for export purposes, regardless of where they are or where the software using it ends up being sold. That software may end up being considered a U.S. controlled item itself. I've been told by BIS that re-exporting a U.S. controlled item from a foreign country without complying with U.S. export regulations can come back to bite you down the road, among other things they can completely deny a foreign entity the ability to export or import things to/from the U.S. if they decide export regs have been ignored. [1] https://www.bis.doc.gov/index.php/about-bis/contact-bis https://www.bis.doc.gov/index.php/about-bis/contact-bis