Hacker News Reader

Comment by ssclafani | Hacker News Reader

Less sensational headline: Facebook Now Allows You to Share Your Phone Number & Address With Third-Party Apps

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.

> "They can obviously live without contact info since they haven't had access to it until now."

This is such an illogical statement that I'm not quite sure how to respond to it.

Huh? How can an app depend on access it has never had? Has the app always been broken waiting for this feature?

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.

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.

+ For various levels of easy.

I was assuming that such a change would apply to all permissions - not just phone numbers.

1) explicit != highlight

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

Right, but the point RWW was trying to make is that the dialog doesn't exactly scream "we're sharing your phone number!" It looks very similar to any other dialog 90% of the Internet might click through without so much as a glance.

Exactly, and what I really don't like about this is not that they are doing it, but they won't share it with their users unless the tech world makes a big deal out of it, which they will. So they announce it on the dev blog, but not the public blog, which I think is poor form at a minimum.

I looked through my profile info and I didn't see a way to hide my phone or address from applications, which means that I have to choose to not post them on Facebook, or provide access any time I want to use an app that requests them.

Obviously, this is much more useful to developers than it is users.

The next thing to do would be to wait for them to swap the defaults and make it so that you have to specifically opt-out of the scheme, or have your contact information casually shared with a set of third parties. Then we could scream for privacy and spread instructions on how to disable that using this week's user interface to the privacy settings.

Yes, this is exactly the danger here and something Facebook has done to its users several times already.

>implies content actually isn't worth sensationalizing

If this is true, then why was it announced to developers and not users?

It's announced to users where it matters: when they are asked for permission to share their data.

Ok, so tell me -

1. Does this apply to current developer/client connections? 2. Will the connection request specify that you are giving consent to address & phone #? 3. Will you be given the option to specify which data you give to applications or will it continue to be all or nothing?

I'm not a user advocate, but I can tell you this - I'm tired of FB constantly glossing over the details.

Just want to add that the parent, which I've been downvoted for, was in response to this, and not the OP:

"Less sensational headline: Facebook Now Allows You to Share Your Phone Number & Address With Third-Party Apps"

Reply on news.ycombinator.com