Hacker News new | ask | show | jobs
by Jayasimhan 5234 days ago
Singling out Path in this issue is not right. Instagram fixed the same issue in their new release. Ditto with Voxer. And more app updates to come. Its sad that one company is being shown all the heat. The issue is pervasive and the problem is not with the apps but with the platform, iOS. It would make much better sense and workout better if we take the issue to Apple. But I'm sure Apple will close this loophole in the next release. Until then, lets leave the app developers alone.
2 comments

No, don't leave the app developers alone. Apple has merely failed to protect its customers; it is Path, Instagram, Voxer, and whoever else who have actively taken advantage of this lack of protection to abuse the trust of their users. Yes, Apple could do more to protect their customers, but the fault lies with those people who are uploading address books without permission.

When I install an application on my computer, I do not expect it to upload arbitrary information from my disk to the developer's servers. If an application did, I would be quite upset, even though any application that I run on my computer will generally have access to all of my data with no substantial platform-provided protection.

Why should I suddenly give the developers a break because the application is running on the computer I carry around in my pocket, instead of the computer I put in my lap?

Would you forgive a company if their application grabbed your cookies, and uploaded those to their server, so that they could log into your Gmail account to find your contact information? Decided to upload all of your documents to their servers and convert them to a convenient HTML format to make it easy for you to share them with one click to your friends? Rooted around your hard disk, uploading your tax information to their servers?

So why do you say that we should forgive companies for making the deliberate decision to grab private information from your phone, and upload it to their servers, just because the platform vendor never implemented a feature to explicitly forbid that?

one might argue that by not protecting the user's personal data by default, when how to protect such information is quite well known, the vendor and market maker is clearly the liable party
Would you argue this for your desktop or laptop as well? For any breach due to you installing an application from someone who abused your trust to read your files and upload them, that your OS vendor (Microsoft, Apple, your Linux distro, or whatnot) is the liable party?
It's Apple's fault that developers took advantage of an API to abuse their users' trust and privacy?

No. It's Apple's fault for failing to protect their customers that buy into their walled garden, but even then, there isn't exactly a hugely black and white list of things that Apple considers to be "fair use" and "evil" in privacy contexts.

The app developers CHOSE to use, upload, store and reuse this data, not Apple. Shifting the blame to Apple is making extreme excuses for app developers.

>Until then, lets leave the app developers alone.

I can't begin to wrap my head around this viewpoint. At all. Let's give them a free pass. Despite them violating my implicit privacy, they can't be blamed. If they can, they should be able to, that's what you're saying...

It is not just violating privacy. It is unauthorized access to a computer system, aka malware, aka hacking/cracking. If you did that to Path it would be a felony and you would go to jail. Why is it not a felony in the other direction?
Because this access is authorized? I would argue that the presence of an API (whose purpose is to provide access to the data they consumed) constitutes "authorized" access. The app doesn't intrude or circumvent the privacy protections of iOS.

On the other hand, if an app was able to forcibly allow itself access to Location Services and ignore the iOS setting, I would argue that is unauthorized.

Granted, I have absolutely no idea what the context of unauthorized is from a purely legal standpoint.