Not really. That implies Facebook are offering a way to push your phone number and data into third party apps.
What they are infact doing is now allowing third-parties to request extra, and very very personal, information about you using the same dialog that people have effectively now been trained to basically click-through.
I really think this dialog needs two things:
1) Something that highlights the fact you are allowing third-parties access beyond your basic profile. All personal information is not equal.
2) A way for the user to opt out of sharing this extra information. As a result, the app may have to deny you access if it really really does need your address (why it would is hard to imagine), but this "all or nothing" approach seems wrong to me.
1) The fact that there is a second item below "Access my basic information" would seem to make that fact abundantly clear. I'm not sure how much more explicit it can get.
2) While I agree that it would be good to give users a greater level of control, most apps are unfortunately not designed to play nicely with varying levels of permissions. Such a change would require significant advance notice to Platform developers.
While I agree that it would be good to give users a greater level of control, most apps are unfortunately not designed to play nicely with varying levels of permissions. Such a change would require significant advance notice to Platform developers.
They can obviously live without contact info since they haven't had access to it until now.
This is actually an interesting potential solution to the permission dialog problem: force apps to handle certain permissions in a granular way. Always let the user deny those permissions independently. Then the app can be forced to make a specific case for why it needs each of those permissions.
This is kind of a strange viewpoint for a developer to hold (assuming you are one) - requiring permission by permission authentication would cause an exponential increase in the number of test cases that would need to be run.
Of course existing apps can exist without this permission, it's a question of what new possibilities this opens up for app developers. I know it opens some up for me.
I'm a bit baffled as to why this has been voted up so hard, given its extremely conservative viewpoint.
You're basically arguing that the convenience of software developers trumps the privacy concerns / ease of use issues with the end-users. As a user, if I want to play Farmville, but I don't want Zygna to have access to my address and phone number I'm 'screwed' because it would be too difficult for Zygna to handle multiple levels of permissions? This would be akin to saying that 'forcing' all e-commerce sites to operate over SSL connections is a 'backwards and conservative move' that 'limits innovation' because developers now need to worry about SSL handshakes and purchasing certificates.
The fact is that Farmville doesn't need my phone number or address to allow me to play the game, so why should I (as a user) be presented with an all-or-nothing decision? Your answer seems to be that the reason the user is presented with an all-or-nothing decision is because it would be too difficult for a developer to write some more unit tests. Writing unit tests takes away from time building new features, therefore unit tests stifle innovation (though by this logic bugfixes also stifle innovation).
Implementing a permissions system and allowing your program to not need an 'exponential' amount of unit tests is easy+. Just treat everything like a file. Seriously. Treat every piece of data like a file with an ACL allowing certain groups/users to have read/write/no access to the file. It's that easy. Return a standard error when an app tries to perform an operation on a piece of user-data that it doesn't have permissions for. The apps/frameworks should be able to easily handle this.
You don't see desktop apps with billions of unit tests just to cover file access. You don't see webapps with billions of unit tests to cover database access (databases also have permission systems). Why would it be so hard for Facebook apps to do the same thing? Why would it require an exponential number of unit tests?
As a final note, keeping the barriers to entry low when it comes to (apparently not-so) private user-data is a bad thing. Just look at what the 'ease of use' of PHP's database access did for SQL injection attacks on the web. All developers needed to do was to use bind params, but many of them didn't even know what bind params were. Keeping the barriers low to getting access to users' private data will only result in disaster.
There are two orthogonal issues here: allowing apps to access contact information at all, and allowing users to select which of the requested permissions to grant. In retrospect, I glossed over the quoted portion of your comment and your proposed solution, so I assumed you were referring solely to the former. My apologies.
2) it'd actually be quite trivial, no notice required. If the user opts out of sharing a specific type of data, the app just gets an empty entry. Apps already need to deal with the fact a user may not have any photos/friends/whatever-data-they-want-to-access.
1) With many permission requests, there will be far more than just two items on the screen. Look at other dialog boxes for FB permission - just one or two options is not the norm, it's just the example...
What they are infact doing is now allowing third-parties to request extra, and very very personal, information about you using the same dialog that people have effectively now been trained to basically click-through.
I really think this dialog needs two things:
1) Something that highlights the fact you are allowing third-parties access beyond your basic profile. All personal information is not equal.
2) A way for the user to opt out of sharing this extra information. As a result, the app may have to deny you access if it really really does need your address (why it would is hard to imagine), but this "all or nothing" approach seems wrong to me.