51–58 of 58 posts
Earlier quoted context omitted.
s/users/anonymous devices/
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 perso…
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.
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.
Actually, I find that to be creepy. You are basically stalking your users.
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 ..
Earlier quoted context omitted.
Actually, I find that to be creepy. You are basically stalking your users.
Actually, I find that to be creepy. You are basically stalking your users. What's the difference between that and installing Google Analytics on your website?
Earlier quoted context omitted.
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 adm…
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.
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 Fac…
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.
Earlier quoted context omitted.
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.
Why bother with that? They could just make the images the correct way to begin with.
Earlier quoted context omitted.
Why bother with that? They could just make the images the correct way to begin with.
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.
But that's just me.