Joel Spolsky on the Stack Overflow podcast last week:

The trouble with Twitter though … as soon as the conversation threatens to become actually real, the 140 k limit [sic] and the fact you don’t want to just sit there and tweet all day actually forces you to stop. Then you’re not having any kind of real conversation.

It’s time to escalate.

One of the greatest bits of inspiration for me coming out of the #futureruby conference was this notion of just replacing things. You don’t like it? Change it. Build a new thing. Launch a thousand ships against the ebays and amazons and apples of the world. That clever Panic fellow has the right idea.

There has been growing, vocal discontent from iPhone developers on the net in the last couple of weeks, with many high-profile developers throwing in the towel, declaring Apple’s somewhat draconian platform too risky for serious investment, or simply too odious.

Today, Gruber posts:

Apple censored an English dictionary…. Apple requires you to be 17 years or older to purchase a censored dictionary that omits half the words Steve Jobs uses every day.

This does not inspire confidence in the platform. It seems like the hits keep coming daily, and Apple continues to blatantly ignore all criticism, sometimes with outright hostility and arrogance.

Every time we consider a new app idea here at Zetetic, it’s mitigated by fears that taking the time to invest in building it out, and building it well, may end up being months flushed down the toilet. There are a number of neat projects that we are unwilling to pursue because there’s a high likelihood of having the app rejected or pulled from the store for what seem like incredibly inconsistent and/or competitive reasons. No code written is ever a waste, but who wants to design and build an ornate structure only to see it washed away like some sand castle? More importantly, who can afford to?

We’re going to continue to develop applications for the app store (we’re about to submit Codebook, actually), but we’re really leery of starting anything new, as it seems that none are immune to the king’s whims. In fact, the continued bad press (especially with regard to the exclusive US carrier AT&T) is extremely bad for the platform as a whole, and threatens its growth and viability in the marketplace.

“Export laws require that products containing encryption be properly authorized for export. Failure to comply could result in severe penalties.”

Anyone who has developed an iPhone application will recognize that quote from the first screen of the App Store submission page. If an application is using encryption technology then it’s necessary to provide documentation to Apple that demonstrates review by the Department of Commerce (DOC) Bureau of Industry and Security (BIS) and classification of the application a mass market encryption item.

What does that really mean? For starters, your company is required to document and submit details of your application, including the specific ways it is using encryption, to the DOC and the “ENC Encryption Request Coordinator” (the NSA) for review. Your submission will be used to determine whether it meets the US government’s Export Administration Regulation (EAR) criteria for a mass market encryption item.

More practically, it means that you have a pile of paperwork to complete. A typical submission will require review of several EAR guidelines, completion of multiple online forms, and preparation of 7-10 pages of supporting documentation. You could spend days navigating the maze of information on the BIS site. Oh, and the review can take 30 days or more to complete, so get started early!

The good news is that this article will save you most of the headache by walking through the entire process from start to finish. We’ve created stepwise instructions and even prepared templates for critical supporting documentation.

Step 1. CIN and PIN Request

There are two ways to submit an application to the DOC, either using a snail mail submission or electronically. For the purpose of this discussion we will cover electronic filing only because its faster for repeat filings.

The first step is to apply for a PIN to access the DOC Simplified Network Application Process – Redesign system (henceforth referred to as SNAP-R). Head over to the PIN request page, where you’ll find a PIN request template. The DOC expects the template to be printed on your “company letterhead”, so copy and paste the text into a word document that includes your company logo, address information, etc.

Take care to fill out each of the fields with correct information, especially the table at the bottom of the document. You’ll need to fill out one row in the table for each individual requiring a PIN. Each person should sign and date their individual row, and an officer of the company must sign and date the document as a whole.

Print off a copy and create a cover that includes your contact information (the DOC processors will call you if they have questions) and make sure the subject reads something like “Company Certification Letter for SNAP-R”. Fax the document over to to the number listed at the bottom of the PIN request page.

It will take one or two weeks for the DOC to process each PIN request. A coordinator will make contact once the approval is complete to communicate the Company Identification Number (CIN) and Personal Identification Number.

Step 2. Create a SNAP-R account

The CIN and PIN alone are not sufficient to access the SNAP-R site. Navigate over the the Login ID And Password Setup Page and enter the required values, along with a username and password of your choice, to create a SNAP-R account.

Step 3. Online Application

With a SNAP-R username and password in hand online we can begin the application process. Start at the SNAP-R login screen and enter the username and password created in the previous step along with the CIN number assigned in Step 1.

Click Create Work Item on the main SNAP-R screen to start a new application.

Select Commodity Classification Request from the Type select box. Then enter a reference number of your choice into the next field. The reference identifier should be seven characters long, consisting of three letters followed by 4 numbers. It’s usually a good choice to use the first three letters of your company name, followed by an incrementing sequence, for example, ZET0001.

Contact Information

The following commodity classification request screen is divided into six sections. Start by filling in the contact information for the application.

License Information

In the second License Information section enter the at Special Purpose of “Mass Market Encryption”. It’s absolutely critical that the special purpose contain that exact value or it won’t be routed properly for approval and the request may be delayed.

The bulk of the Applicant information section will be pre-filled based on the CIN request data from Step 1. Populate the Employer Identification Number (EIN) field if this submission is on behalf of a US company.

Export Item

The Export Item section is of the critical importance:

1. Select the “5D992” code for the ECCN. This code corresponds to mass market software.
2. Leave APP blank
3. Enter the software application name into the Product / Model Number as it would appear in the App store, for instance “STRIP”
4. Leave CCATS Number blank, unless requesting an update to a previously approved application
5. Enter your company name as the Manufacturer

Finally, a short technical description is required. This exact text will be printed on the final approval documentation so it must include details of the software including it’s purpose, algorithms used, etc. The description should be brief, as the description is limited to 250 characters. Here is an example we used in a submission for STRIP:

STRIP is a secure database application for the iPhone/iPod touch that can store sensitive personal data like passwords and financial information. Strip uses a password based key and AES-256 to encrypt data before it is written to it’s database.

Click the Add Export Item button to attach it to the request.

Additional Information

The Additional Information section must include the final details of the submission, including descriptions of the supporting documents that will be prepared and attached in the following steps. The description should clearly point out how each document addresses the relevant EAR requirements, for instance:

This submission includes three attachments.

The first is a letter of explanation and a request for Mass Market Encryption certification. This letter directly addresses Note 3 requirements for Supplement 1 of Part 774.

The second attachments is a technical specification for the product and directly addresses all items under Supplement 6 to Part 742.

The final attachment is a screen capture of our product website that we will be using for marketing purposes.

Save the application as a draft after completing the additional application section. We’ll revisit it after preparing the supporting documentation.

Step 4. Document Preparation

The online application is just a high level summary for the DOC. The real content and application descriptions must be prepared in separate supporting documents.

The exact requirements are spelled out in parts, 742, 744, and 748 of the EAR. The requirements are buried within about 250 pages of regulations, but we’ve done most of the hard work by creating document templates based on our previous submissions to meet the requirements:

1. Introduction Letter addressing Note 3 requirements for Supplement 1 of Part 774
2. Technical specification addressing Supplement 6 to Part 742

These documents are intended to provide a foundation and outline for submissions. They also contain specific language for applications built using our SQLCipher encrypted database library. If you’re not using SQLCipher and OpenSSL you’ll need to modify the appropriate section.

Carefully read each document, section, and question. Make changes as necessary to ensure the response addresses the details of your application specifically and accurately. While we’ve successfully had previous applications approved using similar documents, your mileage may vary. DO NOT JUST SEARCH AND REPLACE THE APPLICATION NAME AND SUMBIT THE RESULT – it is YOUR RESPONSIBILITY to make sure the supporting documents are correct. Make sure you answer all questions accurately and make truthful statements. For instance, don’t answer ‘no’ if the user actually can alter the method of encryption just to get approval. Bad things can happen.

The DOC also wants to review applicable marketing materials as part of the classification process. Screenshots of the product website or App Store page can be used as supporting documents to meet this requirement.

Once all of the supporting documents are completed and reviewed for accuracy the should be uploaded into the SNAP-R. Note that the system requires that all documents be converted to PDF before submission. Open up the draft work item and click View and Manage Supporting Documents.

Convert each document to PDF and upload it to the system. Each document should be assigned a descriptive title, author, publication date, and docuent types such as “Letter of Explanation”, “Technical Specification”, or “Other” respectively.

When you are finished the work item form will list out all of the attachments.

Step 5. Submission

Take one final pass through the Work Item to make sure all items are complete. Click Check For Errors and if everything is fine then Preview Work Item to Submit. Review the final application document and then submit.

Finally,fill out the electronic signature information on the next screen to finalize the submission.

All most done!

Step 6. Hardcopy!

Unfortunately, the online forms aren’t sufficient to complete a submission. The final step is to make hard copies of all application materials and mail them to the ENC Encryption Request Coordinator at Ft. Meade. Astute readers will recognized the address as NSA headquarters.

First, print off a copy of the online work item application from SNAP-R. Then print each of the supporting documents and the screenshots or marketing materials. Paperclip each document together.

Within 2-3 hours of submission SNAP-R will have assigned an Application Control Number (ACN). Each document must also have this ACN written on the top of it. Log back into SNAP-R and click List Work Items from the left navigation. Look for the ACN column of the work item list. It should contain an identifier starting with ‘Z’, like “Z234567”. If the column is blank wait a bit longer, or call the DOC coordinators for a status. Take the Z-number and write it on the top of each document, like so:

Reference ACN: Z234567

Package up the application form, supporting documents, and marketing material printouts. Take them to the Post office and send them via overnight mail to the Encryption Request Coordinator address at the bottom of this DOC page, currently:

    Attn: ENC Encryption Request Coordinator
    9800 Savage Road, Suite 6940
    Ft. Meade, MD 20755-6000

These documents must go out via overnight express mail the same day the application is submitted to the DOC or the the application could be delayed or rejected.

Step 7. Patience…

The approval process will take between 30 and 45 days to complete. If everything goes well the DOC will send out an email indicating the approval of the application and will mail you a classification document containing the CCATS number.

Step 8. Submit to Apple

If you’re lucky at this point it’s been about 40-50 days since starting the application process. Now it’s time to submit the software to Apple for review.

Log into iTunes Connect and start an application submission. On the first screen will ask 4 questions related to the software’s encryption.

Answer yes to each, and then click “Choose File”. Upload a high resolution scan of the commodity classification document and continue with your application upload. This will flag the iPhone application for additional scrutiny by Apple’s export team. Expect an an additional delay of 3-4 on top of the normal application review period.

Conclusion & Disclaimer

We have successfully used this process to submit multiple applications to the DOC for review. However, we must caution that your experience may be different. Every application is reviewed and approved on an individual basis.

If you have trouble there are a number of other resources at your disposal. There are detailed instructions online and a dedicated helpdesk for SNAP-R. BIS Export Counselors are available to answer questions about the review process and specific EAR requirements. They really are very helpful. You can also consult an attorney that specializes in export law.

One final reminder – we aren’t attorneys or export control experts. We are just a company who had to figure out this complex process to sell our own software. We decided to document it to save you the trouble, but we are providing this information AS IS, with no warranty whatsoever. Use this information at your own discretion and consult an expert if you need guidance. If you follow these steps but still end up inside a federal penitentiary, or worse, Guantanamo Bay, don’t come crying to us!

We’ve been getting a lot of emails recently asking about our plans with regard to Strip and Palm’s new platform WebOS. We really appreciate the inquiries! At the current time we don’t have any plans to build a port of the new SQLCipher-based Strip to WebOS / Palm Pré. It’s not that we don’t want to do it, it’s more a matter of a lack in the SDK.

Palms Mojo development framework, the SDK they are providing for developing apps on the Palm Pré, only provides for development in Javascript, HTML, and CSS. There is at this time no support for developing native applications, or applications with access to native libraries. SQLCipher is a specialized build of SQLite, written in C and using OpenSSL, that provides for transparent, page-based encryption of an embedded database, and it’s at the core of Strip. Without a native SDK, we simply can’t compile it for the platform and get to work.

We have made inquiries, and we’ve heard of some development shops getting special access, but so far we’ve not heard anything. If you’re a fan of Strip and you want it on your Palm Pré, it probably couldn’t hurt to chime in and send Palm your support for this.

We agree with that assessment. When the iPhone 3GS was announced, Apple listed hardware encryption and better security among the new features, aimed at getting a better foothold in the enterprise marketplace where Blackberry tends to be the dominant mobile platform, and where corporate security policies can effectively shut out insecure technologies.

Surprising no one, details from Apple are scant, but based on their carefully worded statements it would appear that full-device hardware encryption (with the key on the device) was being employed to provide fairly scant security features. In fact, it poses the appearance of security with the potential for many considerable attack vectors. At the time of the announcement, Stephen wrote:

While there is no doubt that the encryption features will enhance iPhone device security, it remains to be seen how the practical improvements will compare to the launch hype. I strongly suspect that highly sensitive information storage will still require dedicated security applications.

More information is now coming to light. Brian X. Chen has an article in Wired titled, Hacker Says iPhone 3GS Encryption Is ‘Useless’ for Businesses, further making the case that what Apple is providing isn’t what security-conscious professionals really require:

Apple claims that hundreds of thousands of iPhones are being used by corporations and government agencies. What it won’t tell you is that the supposedly enterprise-friendly encryption included with the iPhone 3GS is so weak it can be cracked in two minutes with a few pieces of readily available freeware. “It is kind of like storing all your secret messages right next to the secret decoder ring,” said Jonathan Zdziarski, an iPhone developer and a hacker who teaches forensics courses on recovering data from iPhones. “I don’t think any of us [developers] have ever seen encryption implemented so poorly before, which is why it’s hard to describe why it’s such a big threat to security.”

Obviously, we have a vested interest in making the case for our own security applications for the iPhone and why we think they are so useful and provide such better security. But the most glaring thing about all this is Apple’s lack of disclosure, and poor implementation with the appearance of security. It’s not suitable for our own personal use, never mind in the enterprise environment.