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.
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.