The first part of this article is all about apps doing unnecessarily large network requests. The lack of gzip, optimized images, and redundant requests are more a sign of developers having not enough time or knowledge in the area of bandwidth optimization.
The second half of the article is much more interesting with a discussion of the horrible security practices in apps (or lack thereof). It is an indichtment of Facebook, flurry, and any other app that is leaking data (including passwords) without the user's permission.
It got me wondering if it might be possible to compete with a similar app by just illustrating how much less bandwidth your app uses. Except for Sprint and people on grandfathered plans, people pay per GB for bandwidth on their mobile devices. If you can show your app uses 10% of the bandwidth of another would that make an impact on the typical buyer?
The security stuff is really worrisome. Apple ought to be vetting this stuff in their review process, as having a bunch of high profile identity theft start happening to people using iPhone apps is not going to do anything good for Apple.
I find it very interesting that apps are downloading images that are an order of magnitude larger (in file size) than they need to be. First we use expensive bandwidth to download the image, battery life to use the radio longer, and then more battery life to resize this image on the device. One easy thing they could do is resize and optimize images server side.
As a developer, I am guilty of using flurry too much. But its just so damned useful to be seeing what your users are up to with your app! I am addicted to checking my flurry console every day and watching the event logs, looking at session lengths.. even the world map of users is something I can look at longingly every morning.
While I agree that these development practices are pretty awful, they aren't particularly iOS specific. You can easily do the same thing in a web/desktop/Android app.
How many websites submit password forms over HTTP or store them in plaintext on the backend or make large, unnecessary downloads or spew tracking data all over your browser?
Unfortunately, many developers are too lazy to bother learning best practices and this is what you end up with.
Quite funny from a chap who has google+, twitter, digg and facebook button on his page. At the very least, the facebook one tracks users even when they are logged out.
He does make a good point, re developers not caring about anything hidden behind the scenes. Good to see them being named and shamed.
Sure, but firstly, you know they're tracking you (the degree of iOS tracking would be a big surprise to many) and secondly, you can disable the tracking if it bothers you (not so in iOS).
On the one hand this is a great article with great research.
On the other hand it shows extreme naïvety.
As bad as this may seem, almost every company I have ever worked for - and I have worked for at least a dozen of the world's biggest most profitable companies - none of them care about security in practice. Publicly it's a different story, but back in the security department this happens:
1) security is always an afterthought on every project even if someone put it in the plan
2) the security department covers the entire organisation, that is: all processes, functions, applications, buildings, staff, hardware and software
3) the people that work in the security department cannot possibly have the kind of in-depth knowledge of every one of these and practically never have deep knowledge of any single one, to make the right decisions
4) the power of "No" is used in the place of finding out what is really needed from the real experts who don't work in security - ie they don't listen to anyone who doesn't work in their function
The result is that most companies are vulnerable at almost every turn, but take the view that they only need to shut the barn door after the horse has bolted. And it makes perfect economic sense, as long as the horse has not bolted.
If it has bolted then the decision makers go into damage limitation. That's how companies work so it does not surprise me at all that skilled knowledgeable people can expose these issues with ease.
It's inevitable that what we saw at Sony will happen again and again. Perhaps this was the root cause of Blackberry's recent woes too. We may never know.
Charles (http://www.charlesproxy.com/) is another http proxy that works well. It runs on Windows, Linux and OS X and can read Fiddler logs. I use it all the time to test my iOS apps and look into SSL traffic.
Excellent article. It really made me think about the responsibility we (programmers) have for protecting user information.
I wonder how this problem could be solved, though. Apple is already widely criticized for their tight control over applications (even though this article clearly shows that this control is not _that_ tight).
I do believe however, that right now Apple would be the only company who could change this trend with their App Store model; they already check every single application they offer for sale.
But the line between what's considered usage pattern analysis or creepy spying is hard to draw.
In August I ended up using 100MB in one day for whatever reason (I imagine Netflix even though I was home) and started to think about having a proxy service to help me cut down on bandwidth use as well as being able to monitor how much each individual app uses.
I don't know if that's at all possible or if that exists but I realized that it'd be hard to make that a paying product since, with AT&T at least, it costs only $10 extra to go to the next bandwidth cap. You'd most likely need to go under these $10 to see any real interest… That would actually allow you to cut Flurry et al off completely.
They have an iOS app that configures your device to use their proxy servers. I haven't tried it myself since I'm a bit hesitant to route all my traffic through a third party, but it does sound promising.
With the content-based apps, development is often outsourced to an external company. BigContentCo then gives the developers a content feed that's optimized for web (big PNG images etc).
Yes, it would be nice to implement a caching and resizing service for the feed - but there's often not the budget nor time to implement one. And BigContentCo is not willing to pay the developers to host and supply bandwidth - especially when the app is free.
It would be nice if the OS could expose at least a rough idea of how much / when data per app is used. People don't realize until they see nice graphs. Once they know where to look, it would put much more pressure on application developers.
> First off, let's clear up what it means for Apple to 'deprecate' this identifier. A deprecated function or software component is not yanked out immediately; it's simply been flagged by the developer of the platform (or app, command line tool, what have you) as something that will be going away in the future, eventually.
IOS is singled out because iOS is what all the test cases featured in the post were done on. The author does mention the issues are likely endemic to all mobile app platforms.
As a word of unsolicited advice, It's best to set your emotional attachments to a platform aside if you want to engage or broaden the discussion on legitimate technical matters.
Excellent use of Fiddler... I'm going to try this on a few apps that have seemed terribly slow, even on wi-fi. I take that back: I need to use this with every app that I've been semi-trusting.
For development, this seems like a great catch-all tool to make sure expected best practices are actually working........ or if someone completely ignored them / forgot to implement.
[+] [-] magicseth|14 years ago|reply
The second half of the article is much more interesting with a discussion of the horrible security practices in apps (or lack thereof). It is an indichtment of Facebook, flurry, and any other app that is leaking data (including passwords) without the user's permission.
[+] [-] ams6110|14 years ago|reply
The security stuff is really worrisome. Apple ought to be vetting this stuff in their review process, as having a bunch of high profile identity theft start happening to people using iPhone apps is not going to do anything good for Apple.
Finally, I've added flurry.com to my /etc/hosts.
[+] [-] anon-e-moose|14 years ago|reply
[+] [-] seclorum|14 years ago|reply
[+] [-] RexRollman|14 years ago|reply
[+] [-] stevenwei|14 years ago|reply
How many websites submit password forms over HTTP or store them in plaintext on the backend or make large, unnecessary downloads or spew tracking data all over your browser?
Unfortunately, many developers are too lazy to bother learning best practices and this is what you end up with.
[+] [-] MichaelGagnon|14 years ago|reply
The most bandwidth-hungry app in the sample downloaded 12 MB in the first 30 seconds. Most apps used far far less. Details are in http://www.neildaswani.com/wp-content/uploads/2011/08/Mobile...
[+] [-] megablast|14 years ago|reply
He does make a good point, re developers not caring about anything hidden behind the scenes. Good to see them being named and shamed.
[+] [-] RexRollman|14 years ago|reply
He appears to be using Blogger. Are those buttons forced on everyone using Blogger or is that something he would have added himself?
[+] [-] troyhunt|14 years ago|reply
[+] [-] chris_dcosta|14 years ago|reply
On the other hand it shows extreme naïvety.
As bad as this may seem, almost every company I have ever worked for - and I have worked for at least a dozen of the world's biggest most profitable companies - none of them care about security in practice. Publicly it's a different story, but back in the security department this happens:
1) security is always an afterthought on every project even if someone put it in the plan
2) the security department covers the entire organisation, that is: all processes, functions, applications, buildings, staff, hardware and software
3) the people that work in the security department cannot possibly have the kind of in-depth knowledge of every one of these and practically never have deep knowledge of any single one, to make the right decisions
4) the power of "No" is used in the place of finding out what is really needed from the real experts who don't work in security - ie they don't listen to anyone who doesn't work in their function
The result is that most companies are vulnerable at almost every turn, but take the view that they only need to shut the barn door after the horse has bolted. And it makes perfect economic sense, as long as the horse has not bolted.
If it has bolted then the decision makers go into damage limitation. That's how companies work so it does not surprise me at all that skilled knowledgeable people can expose these issues with ease.
It's inevitable that what we saw at Sony will happen again and again. Perhaps this was the root cause of Blackberry's recent woes too. We may never know.
Like he says... we live in interesting times.
[+] [-] elfred|14 years ago|reply
[+] [-] antalkerekes|14 years ago|reply
But the line between what's considered usage pattern analysis or creepy spying is hard to draw.
[+] [-] Timothee|14 years ago|reply
I don't know if that's at all possible or if that exists but I realized that it'd be hard to make that a paying product since, with AT&T at least, it costs only $10 extra to go to the next bandwidth cap. You'd most likely need to go under these $10 to see any real interest… That would actually allow you to cut Flurry et al off completely.
[+] [-] rgsteele|14 years ago|reply
http://www.onavo.com/
They have an iOS app that configures your device to use their proxy servers. I haven't tried it myself since I'm a bit hesitant to route all my traffic through a third party, but it does sound promising.
[+] [-] nikatwork|14 years ago|reply
Yes, it would be nice to implement a caching and resizing service for the feed - but there's often not the budget nor time to implement one. And BigContentCo is not willing to pay the developers to host and supply bandwidth - especially when the app is free.
TL;DR development does not happen in a vacuum.
[+] [-] zimbatm|14 years ago|reply
[+] [-] gyardley|14 years ago|reply
[+] [-] maukdaddy|14 years ago|reply
[+] [-] driverdan|14 years ago|reply
http://www.flurry.com/about-us/merger/welcome.html
(Thanks Timothee for pointing it out further down the thread)
[+] [-] Turing_Machine|14 years ago|reply
[+] [-] vijayr|14 years ago|reply
[+] [-] pooriaazimi|14 years ago|reply
[+] [-] LiveTheDream|14 years ago|reply
From the linked article:
> First off, let's clear up what it means for Apple to 'deprecate' this identifier. A deprecated function or software component is not yanked out immediately; it's simply been flagged by the developer of the platform (or app, command line tool, what have you) as something that will be going away in the future, eventually.
[+] [-] dahart|14 years ago|reply
[+] [-] spinchange|14 years ago|reply
As a word of unsolicited advice, It's best to set your emotional attachments to a platform aside if you want to engage or broaden the discussion on legitimate technical matters.
[+] [-] lolwutreddit|14 years ago|reply
For development, this seems like a great catch-all tool to make sure expected best practices are actually working........ or if someone completely ignored them / forgot to implement.