6 ms·

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 SN

by 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.

by mapmap 11y ago

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.