Putting aside the issue that much of this data shouldn't have been sent anywhere in the first place, I'll never understand why, in 2012, SSL is still not used by default when sending any sensitive or private data across the network.
It's even more puzzling when we're talking about background data upload when the potential SSL handshake latency isn't going to pose any UX issue. This has boggled my mind for years actually. Why?
Maybe it's not an issue for LinkedIn, but the iOS app submission process requires developers to do a lot of paperwork with several governments (US, France) for export compliance when using any kind of crypto.
I can easily see smaller developers deciding to go for HTTP instead of HTTPS just to avoid dealing with all that bureaucracy.
Going through CCATS is pretty painless; can't imagine that a public company with a good legal team like LinkedIn would have any issue getting through it if mom & pop shops can DIY without issue.
To this day, LinkedIn's web site still doesn't appear to use SSL by default (I haven't used the mobile app in years after not only snooping my own proxy to see that everything was in clear-text but also finding that it recommended bunches of contacts it shouldn't have; Support was not cooperative in helping me determine why/how they acquired that contact info or how to stop it--I assume the culprit was a surreptitious Address Book siphon). Clear-text access to the Web site is a fantastic feature for employers who want to know what their employees are up to on LinkedIn all day, among other things...I would love to know why they still haven't implemented site-wide SSL by default.
I should go back and take a look at the exact wording of the Apple App Store rules but I never had problems submitting apps that use SSL.
There's one step of the submission process that asks about the use of cryptography and I've always picked the option that doesn't require submitting any additional paperwork - never had problems. I forgot the exact wording but I always worked under the assumption that SSL isn't what Apple is talking about when they ask about the use of cryptography.
If developers had to file paperwork with various governments just to use SSL in their app, then simply using one of the many third party APIs that require SSL (e.g. the Foursquare API) or even just embedding a web browser view that may end up loading an https URL would require the developer to go through the paperwork route to get their app approved. That wouldn't make sense.
You would think so, but I've never been able to find a definitive answer, in public at least. Some forum posts seem to imply you should answer YES if you utilize HTTPS/SSL even if it's just through the iOS standard frameworks. Whether anyone _really_ cares remains to be seen. The vague wording is probably Apple's way to C.Y.A. should any problems arise later.
It's even more puzzling when we're talking about background data upload when the potential SSL handshake latency isn't going to pose any UX issue. This has boggled my mind for years actually. Why?