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.
> 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?
Sadly, I doubt the typical user cares that much. Unless the bandwidth difference were significant... (in MB, not %).
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.
The script would be for huge amounts of images that may change, if they are provided from a third party. Most thumbnail scripts implement caching, so effectively they are only doing the work once too.
That's a good point. My values would require that I run the thumbnail script myself and not the first visitor to see the image. Shoot, a Photoshop action could much the same thing.
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.
You can't compare a mobile app with a web application. One of the author's points was that "view source" world as we know it in the web doesn't work anymore on mobile apps. That's why he had to resort to Fiddler to see what is going on under the hood.
The better question is: What's the difference between this and a desktop application that gathers your data?
If the same thing happened with a desktop app (spying on your every click, "calling home"), it was labeled as spyware within days.
Well, I'm not doing it for sexual or violent gratification (what I associate the word 'stalking' with) but I am looking to see how people are using the apps .. and it has definitely helped me identify trouble areas with usability, improvements over versions, and so on. Without flurry analytics, I probably wouldn't be able to identify improvements and tweaks that I can make that will benefit the whole, and would have to rely on a very small percentage of users giving me feedback, which may in fact not be of any benefit whatsoever to the larger whole.
Its a delicate situation, but as a developer I have to be trustworthy - and I think this is best reflected in the changes I make that make users think my app is worth using, more and more ..
I don't think it's that unusual. Woopra lets you see your users in real-time, and even start chats with them as they browse your site. http://www.woopra.com/features/live-map/
One sees small bits of information every now pop into HN about how they might not be as anonymous as expected, to put it mildly, but it would be nice to have an overview of how trackable your vanilla smartphone is or isn't.
My intuition right now is that they're pseudonymous at best, and that the average user is very quick to provide credentials that would associate the pseudonym to their actual names and other personal info.
Can anyone provide an assessment (or better yet, a link to one) on just how anonymous those anonymous devices are?
(@saddino: this response is not directed at you partly because I'm not sure whether you're being technical or sarcastic — or both.)
>One sees small bits of information every now pop into HN about how they might not be as anonymous as expected, to put it mildly, but it would be nice to have an overview of how trackable your vanilla smartphone is or isn't.
Its very trackable. You can get a unique ID, user name, location, and so on. There is no anonymity with cell phones, really - its a farce.
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.
Of course I could. I could do a lot of other things that wouldn't be as effective, too.
When you use something for free that requires money to produce and maintain, of course every damn aspect of your life and buying habits is going to be cross-correlated, as long as this is legal and profitable in aggregate. (Often it isn't profitable. People dramatically overestimate how interesting and/or valuable they are.)
Seriously, you've been handed something for free and I don't look like Santa Claus. What'd you expect?
Are you talking about the app here? Because the price of the app has nothing to do with it, since I'm sure many paying apps use analytics tools as well.
The problem is not the use of analytics to improve the app either, but the fact that Flurry can track you specifically over multiple apps.
If you're talking about Flurry being free, the major problem is that, as a developer, you get the functionality for free but it's the user that pays by giving away behavioral information. You're making the decision for the user that it's ok to use a service that will track you over multiple apps.
edit: I admit that I use Google Analytics on websites, so I'm no better… (though I don't have any "real" sites) Ideally, there would be cheap (or better: FOSS) analytics tools you can set up on your own servers that are good enough for most basic tracking. Or to go with analytics tools that don't have an advertising arm. (do they exist at all?)
(…)
Ok, I just looked at your profile. I feel it's important to note that you co-founded a company (Pinch Media) that was acquired by Flurry. Seems like a relevant disclosure.
You could use something like Piwik for your Google Analytics problem - it's open source - although I don't believe it or any of the other open-source solutions scale well beyond a single box, so if your website takes off you'll have trouble.
Many analytics tools exist that don't have an advertising arm - in fact, most don't. They charge developers directly. Mobile device analytics are a bit of an aberration, mainly for historical reasons, although paid solutions there also exist.
For the user to 'pay' by giving away behavioral information, they'd have to suffer some sort of economic loss. They don't. (As an aside, a lot of the arguments made in favor of music or application piracy are surprisingly relevant to the collection of behavioral targeting data.)
I believe that ideas should stand on their own, so I generally don't disclaimer up my posts. For example, I'm always irritated when someone dismisses a politician's stance because of his donors, as if to suggest he was bought. In the politician's case, he has the donors he does because of his ideas, not the other way around. In my case, I have the economic interests I do because of my ideas - again, not the other way around.
> People dramatically overestimate how interesting and/or valuable they are.
Regardless of how "uninteresting" or "worthless" my interests, browsing habits, purchases, etc. are, they point is that they are mine and I never gave my consent.
Your interests, browsing habits, purchases, etc. are still yours, even though you may have also given them to someone else. They're not physical goods. When you 'give them away', you don't lose them.
I'm not familiar with every mobile platform's current agreements with its users, but back when I was, most had you agree to a pretty broad policy regarding third-party apps to spare their developers the need to write their own terms of service and privacy policy. That's generally where the consent happens. In the exceptions, the developers do provide terms of service, which you consent to as a condition of installing the app.
You almost certainly didn't give your fully informed consent, mind you, unless you enjoy reading legal documents - but that's the current state of the industry both online and off, and in my mind far superior to an extensive batch of lengthy in-your-face disclosures you'd have to agree to before viewing any website. You may disagree, and you may wish that things were different, but that's just how the world works right now.
Actually, in your case it is precisely the arguer who can be dismissed, while leaving the argument alone, maybe to be picked up by someone else without the vested interest.
Surely you can recognize how your financial relation to Flurry colours your comments about them?
> 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.
Deprecation warnings are a huge issue in 3rd party libraries. You'd have to rewrite those the way iOS works basically if you do turn on "Warnings as errors". I wish it were not so, but sadly, it is.
On projects who don't have this problem, I turn it on.
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.
As a legitimate technical matter, the title of this article is downright misleading, and it was made that way intentionally. This is clearly not a case of a bunch of random app picks that all just happened to be iOS apps. The title drew a conclusion that is wholly unsupported by the article, there is no "secret iOS business". The title is also the most important line in the article, it doesnt matter if the author admitted his guilt later.
My like or dislike of iOS has nothing to do with this, I simply want to find links to higher quality, more honest content on HN. Next time consider keeping your unsolicited advice to yourself.
How exactly were you or anyone else mislead? The guy ran a bunch of iOS apps with an HTTP proxy and posted the results (screen captures) and a requisite analysis.
He didn't say or present the post as a comprehensive overview of the entire mobile app data/security model, but did offer that even though this was just a look at one platform, it was probably pervasive on all of them.
As for the headline, he showed tons of data on the apps phoning home to Flurry, a 3rd party app analytics company, with his device ID and location across several unrelated apps. He then provided a link to Flurry's site and used their own language to describe what they do.
"Secret Business" can also refer to that fact that all of this stuff is obscured by the app model and can't be readily observed or controlled by the user like it can in a web browser. Nothing about this is untrue, even if it is applies to other mobile app platforms. And again, he's "guilty" of saying that it does.
All iOS apps are reviewed and approved by Apple before they're available. They hold themselves and their apps to a higher standard and if anything open themselves to more scrutiny than others for this reason. That's my opinion, not the authors.
I saw your green username (new account) and that it was your first comment and was just trying to be helpful. Good luck in your search to find more "higher quality content" and discussion on HN than you already have.
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.
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.