Secret iOS business; what you don’t know about your apps
troyhunt.com
troyhunt.com
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.
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.
Sadly, I doubt the typical user cares that much. Unless the bandwidth difference were significant... (in MB, not %).
But that's just me.
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.)
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.
What's the difference between that and installing Google Analytics on your website?
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.
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 ..
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.
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...
He does make a good point, re developers not caring about anything hidden behind the scenes. Good to see them being named and shamed.
He appears to be using Blogger. Are those buttons forced on everyone using Blogger or is that something he would have added himself?
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.
But the line between what's considered usage pattern analysis or creepy spying is hard to draw.
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.
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.
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.
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.
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.
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.
http://www.flurry.com/about-us/merger/welcome.html
(Thanks Timothee for pointing it out further down the thread)
It would be bizarre if your ideas, beliefs, and opinions didn't reflect themselves in your economic interests.
Engage with the argument and not the arguer.
Surely you can recognize how your financial relation to Flurry colours your comments about them?
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.
On projects who don't have this problem, I turn it on.
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.
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.
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.
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.