Facebook Now Shares Phone Number & Address With Third-Party Apps(readwriteweb.com)
readwriteweb.com
Facebook Now Shares Phone Number & Address With Third-Party Apps
http://www.readwriteweb.com/archives/facebook_now_shares_phone_number_address_with_thir.php?sms_ss=hackernews&at_xt=4d3346d0e7608241%2C0
20 comments
So from now on, we need to remove two more items from our profile.
Well, as long as we are not allowed to partially denie permission requests (which of course would make certain apps not able to share our information to other third parties)
Well, as long as we are not allowed to partially denie permission requests (which of course would make certain apps not able to share our information to other third parties)
Here's the follow-up story...
http://www.readwriteweb.com/archives/facebook_identity_the_c...
http://www.readwriteweb.com/archives/facebook_identity_the_c...
When somebody knocks at your door, peep through the peephole first. It might be some stalker who got your address from an app.
there is always a problem with facebook! I can't trust them ever!
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.
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.
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 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.
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.
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.
> "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.
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.
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.
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.
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.
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"
"Less sensational headline: Facebook Now Allows You to Share Your Phone Number & Address With Third-Party Apps"
[deleted]
Where's the option to choose which items get sent? Looks like all or nothing.
I have been wondering that for a while; why isn't there a conditional permissions system that you can choose what gets shared or not. It wouldn't be that hard for app developers to sanity check for what is available or not, and tell the user if it is an issue.
The all of nothing mentality is flawed, much like most of Facebook's decisions it seems. (imo)
The all of nothing mentality is flawed, much like most of Facebook's decisions it seems. (imo)
It is not flawed by any means - from Facebook POV.
Facebook has refused to provide that option.
They used to provide this option but it actually made the API harder to work with. You could deny or approve one permission at a time and the developer had to handle it (and by handling that really meant always checking for permissions before actions and bugging the user for the permission whenever they tried something that required it). As a developer I prefer the new way, which is also how Android development works. Giving line-item veto to a user is a terrible idea. If they don't like the permissions, don't use the app. It's good for Facebook's api too because now people aren't constantly checking which permissions are available before they do something, probably reducing the stress on the API quite a bit.
Are you serious? A better API would be if it were just a yes or no to send all my information? I couldn't possibly disagree more.
Newflash: I don't give a shit about how hard your job as a programmer is. If you don't like programming take up something else. I care about my security and not having to worry about what effect clicking "OK" is going to have. Plenty of apps ask you things that they don't need to function.
Newflash: I don't give a shit about how hard your job as a programmer is. If you don't like programming take up something else. I care about my security and not having to worry about what effect clicking "OK" is going to have. Plenty of apps ask you things that they don't need to function.
I love being an engineer. You have a chip on your shoulder. I recommend not using Facebook at all given your concerns. I do not maintain a Facebook account myself for anything but development.
I have a chip on my shoulder? I'm speaking as a customer. You're giving me excuses as to why I should compromise my own convenience and security to make your job easier. Why on earth would I care about making your job easier?
Facebook provides value and poor, lazy anti-security undermines that value and puts me in the inconvenient position of thinking of a move [1]. And for what value? So developers don't have to write a switch statement? Seriously?
[1] It's not as simple as "just take your business elsewhere". The only purpose of facebook for me is connecting with friends and family. So going while they all stay is rather pointless. Getting other people, who have a different circle of friends/family, to move with me would be practically impossible.
Facebook provides value and poor, lazy anti-security undermines that value and puts me in the inconvenient position of thinking of a move [1]. And for what value? So developers don't have to write a switch statement? Seriously?
[1] It's not as simple as "just take your business elsewhere". The only purpose of facebook for me is connecting with friends and family. So going while they all stay is rather pointless. Getting other people, who have a different circle of friends/family, to move with me would be practically impossible.
[deleted]
Interesting, I didn't know that.
> Giving line-item veto to a user is a terrible idea.
Giving the user choice about whether or not they want to give up their personal information is a great idea. Suppose I don't want the app to have my email and phone number. Without finer-grained control, my only option is to say no to the entire app -- so they lose me as a user.
> Giving line-item veto to a user is a terrible idea.
Giving the user choice about whether or not they want to give up their personal information is a great idea. Suppose I don't want the app to have my email and phone number. Without finer-grained control, my only option is to say no to the entire app -- so they lose me as a user.
They'll gain more users by reducing options which make things less confusing than they'll lose because they didn't give fine grain control.
As I remember, permissions on FB used to be exactly this back in the olden days of connect (you'd get a dialogue for each permission with an accept/reject, rather than a batched one). I can see why they removed that implementation because clicking "Allow" 5 times was obnoxious, but it's not exactly impossible for them to put a checkbox next to each one instead.
That's half true. It's all or nothing on first use, but you can revoke any non-required permissions later: http://www.facebook.com/settings/?tab=applications
You can't take back the data tha you already gave to the app, however. Revoking permissions prevents the app from accessing your info in the future, but it's sort of limited once you've already given that data to the app
The app has to warn you as to what is getting sent; you then get to decide if you want the app or not.
In other words, it's not really "all or nothing" as much as "whatever this particular app asks for, or pass on this app."
In other words, it's not really "all or nothing" as much as "whatever this particular app asks for, or pass on this app."
Exactly. Give this app "all" of the information it is requesting or give "nothing." People want more granular control.
People who read HN, myself included, want more granular control, sure. I don't think most of Facebook's users would care or understand about the granular control -- I think a simple yes/no like Facebook has right now is probably the best option for most users.
I don't have a Facebook account so I may not be the best person to judge, but it seems like whether "most of Facebook's users would care or understand about the granular control" might not be the best basis for making a decision. In fact, I will go ahead and say that I disagree strongly that Facebook should base privacy control decisions on what most users want.
Most users of any service or product won't fully understand every single configuration option available to them. That doesn't mean we should give up on allowing configuration. And using the interface to subtly educate and inform users about their options is a worthy goal. But that doesn't seem to be in Facebook's immediate best interests.
Android also has a similar dialog when downloading/installing new applications that provides "all-or-nothing" control just like this Facebook dialog. I think it's bad there as well.
Most users of any service or product won't fully understand every single configuration option available to them. That doesn't mean we should give up on allowing configuration. And using the interface to subtly educate and inform users about their options is a worthy goal. But that doesn't seem to be in Facebook's immediate best interests.
Android also has a similar dialog when downloading/installing new applications that provides "all-or-nothing" control just like this Facebook dialog. I think it's bad there as well.
Unfortunately it doesn't work that way -- users are foolish and will shoot themselves in the foot quite often, all while blaming you. If there were an option to, for example, disallow sharing of X on app Y, users would click it without understanding why. Then, months later, since X isn't shared, feature Z of app Y doesn't work. But the user doesn't understand how this works (messaging in the app might make it better, but not all apps are going to do it right and not all users will understand anyways). Since it's broken, the user will blame Facebook -- Facebook is broken!! Except the silly user did it to themselves.
This has happened. Since most things on the site are an app, Photos is an app. There used to be an option which ultimately disallowed an app to post certain kinds of stories to your stream (I don't recall the details). You could set this option on the Photos app, meaning you would never see any more photo stories in your stream. The option was very buried, so people had to specifically go to Photos and turn on the option... and silly users did this, forgot about it, and then complained that Facebook was broken since they never saw photos stories. Nevermind that it was their own fault. This option has since been removed in one of the Platform permissions revamps recently (IIRC it was simply forced to "off" for all apps, with Photos and similar internal ones special-cased to be forced "on".)
This has happened. Since most things on the site are an app, Photos is an app. There used to be an option which ultimately disallowed an app to post certain kinds of stories to your stream (I don't recall the details). You could set this option on the Photos app, meaning you would never see any more photo stories in your stream. The option was very buried, so people had to specifically go to Photos and turn on the option... and silly users did this, forgot about it, and then complained that Facebook was broken since they never saw photos stories. Nevermind that it was their own fault. This option has since been removed in one of the Platform permissions revamps recently (IIRC it was simply forced to "off" for all apps, with Photos and similar internal ones special-cased to be forced "on".)
You are arguing against bad design and lazy development, not against allowing users to control their data.
iPhone apps would apparently have this problem. Simple solution? If the app can't do some function because of a user setting it pops up an alert with a button pointing to the place to change the setting.... pretty simple.
If you explain in terms of what it actually means, a large subset of people will and do care. "Huh? Farmville wants my phone number? What the heck for?"
Wow, what a cop-out.
No, they don't. And most likely, you don't want them to have it, either.
As a developer, you are responsible for asking for the information your app requires to function properly. You are required (by the Facebook TOS) to specify what information you will get, and how you will use it.
The user than has to choose if it is worth it or not, for this particular app.
If Facebook offered the users "more granular control" over what would be sent, this would result in apps not knowing in advance what information would be available to them, which would result in a pretty crappy user experience.
As a developer, you are responsible for asking for the information your app requires to function properly. You are required (by the Facebook TOS) to specify what information you will get, and how you will use it.
The user than has to choose if it is worth it or not, for this particular app.
If Facebook offered the users "more granular control" over what would be sent, this would result in apps not knowing in advance what information would be available to them, which would result in a pretty crappy user experience.
I seem to remember that not so long ago it was standard advice not to give out your address or phone number to people you don't know on the internet.
With a multi-billion dollar valuation, I'm sure that the majority of Facebook's value is in all information it gathers about you. Is this any surprise to anyone? One way or another Facebook is trying to monetize your info. Maybe it's just me but there always seem to be some kind of news fading away about Facebook privacy. I'm my theory that's why they are worth so much. Don't think they are going to stop doing this anytime soon.
Opt-out..hahaha maybe opt-out of only the really obvious ways Facebook is selling your info.
Opt-out..hahaha maybe opt-out of only the really obvious ways Facebook is selling your info.
ReadWriteWeb-sponsered submission? Check the URL, it has a tracking string (for want of a better word) with "hackernews".
If you look at the bio of the submitter, he writes for ReadWriteWeb and, I believe, wrote the article. Nothing wrong with that; people often submit their own work here.
You are correct. I write for ReadWriteWeb, wrote the article and I think that the URL has that code in it because I clicked on the Hacker News button on the article to share it.
:)
:)
Perfectly good! I have no issue with it, I just thought it was worth pointing out as I had seen the same URL tweeted.
But how many people have added their full address and phone number to their Facebook profiles anyway? I would bet that the majority of people have their city/town set and not their full address and won't have specified their phone number at all.
However, this really could be quite useful if used legitimately, i.e. Facebook commerce, having shipping address available; location aware apps etc.
However, this really could be quite useful if used legitimately, i.e. Facebook commerce, having shipping address available; location aware apps etc.
http://www.facebook.com/friends/edit/?sk=phonebook
Very easy way to check which of your friends has published their phone number.
Very easy way to check which of your friends has published their phone number.
Anecdotally, something like 30% of my friends list (not particularly tech-savvy skewed) probably share their phone numbers.
It's also one of the most useful features of the whole site, if I'm out somewhere and realise I suddenly need to call someone whose number I can grab from Facebook.
It's also one of the most useful features of the whole site, if I'm out somewhere and realise I suddenly need to call someone whose number I can grab from Facebook.
I use Facebook for my friends. Why wouldn't I add my real contact details?
I'm not afraid of my friends.
I'm not afraid of my friends.
I've been developing Facebook Connect applications for a long time, and I'm wondering - hasn't facebook had this feature already for email addresses?
One of the permissions read: "Send me email" (optional: send through a facebook proxy)
So now, you can also let the apps know phone number through the graph? I don't find that too big of a step. CAN-SPAM still applies. Perhaps they should set up proxies for the phone number, though.
What I find more funny is that ReadWriteWeb writes:
"Thankfully, this sort of information cannot be shared via your friends' careless actions, unlike other profile information."
which is in direct opposition to the attitude that blogs had on the same issue when Google complained that facebook was "trapping your contacts" by not letting you export them. Now they are thankful facebook doesn't do this :)
One of the permissions read: "Send me email" (optional: send through a facebook proxy)
So now, you can also let the apps know phone number through the graph? I don't find that too big of a step. CAN-SPAM still applies. Perhaps they should set up proxies for the phone number, though.
What I find more funny is that ReadWriteWeb writes:
"Thankfully, this sort of information cannot be shared via your friends' careless actions, unlike other profile information."
which is in direct opposition to the attitude that blogs had on the same issue when Google complained that facebook was "trapping your contacts" by not letting you export them. Now they are thankful facebook doesn't do this :)
Who owns your online identity is a completely different thing than letting this sort of contact information leak through the carelessness of your friends. Other profile information of yours, if you don't correct FB's settings, can be given to third-parties by way of your friend saying okay.
That is, thankfully your friend can't decide they want to share there contact information with some app and vicariously share yours too.
Big difference.
That is, thankfully your friend can't decide they want to share there contact information with some app and vicariously share yours too.
Big difference.
Letting your friends export your information through a facebook feature is substantially different than letting any shady "Platform" app get it.
The idea of allowing users to control what individual permissions they have is good in theory, very hard in practice. It faces two main challenges that I can think of:
1) There are UI issues that have been raised elsewhere in this thread - mainly, that users get confused when shown a set of complex options. Having watched usability studies where users are given a lot of relatively complex options, I'd suspect that a model where users have to pick among the permissions to give an app is going to fail massively (ie, user turns on everything without actually understanding anything, turns off everything by default or just cancels out of the app install altogether.) A model where apps request permissions right when it's needed will be annoying users with all the dialogs needed.
2) Some apps don't work if they don't get all the permissions they need (imagine an address book app for an email program - if you don't get email address it just doesn't work.) Adding a lot of conditionals to change how your app works based on what permissions they get can be expensive and adds a lot of unnecessary test cases.
In my opinion, Facebook's decision give more granular permissions, but to make it an all or nothing proposition allows them to protect their users by removing spammy/malicious apps, and simplifies the applications built on their platform . This puts responsibility on them to actively remove malicious applications, and on developers to pick only the permissions they need. Given that users tend to make bad decisions given a set of complex options that they don't understand, it seems like they made a rational choice. AppStores on the various phone platforms have a similar decision to make as to how to best protect users from apps, and there isn't consensus as to the best model in that arena either.
They do need to step up their activity to remove malicious apps in light of giving regular applications this option.
1) There are UI issues that have been raised elsewhere in this thread - mainly, that users get confused when shown a set of complex options. Having watched usability studies where users are given a lot of relatively complex options, I'd suspect that a model where users have to pick among the permissions to give an app is going to fail massively (ie, user turns on everything without actually understanding anything, turns off everything by default or just cancels out of the app install altogether.) A model where apps request permissions right when it's needed will be annoying users with all the dialogs needed.
2) Some apps don't work if they don't get all the permissions they need (imagine an address book app for an email program - if you don't get email address it just doesn't work.) Adding a lot of conditionals to change how your app works based on what permissions they get can be expensive and adds a lot of unnecessary test cases.
In my opinion, Facebook's decision give more granular permissions, but to make it an all or nothing proposition allows them to protect their users by removing spammy/malicious apps, and simplifies the applications built on their platform . This puts responsibility on them to actively remove malicious applications, and on developers to pick only the permissions they need. Given that users tend to make bad decisions given a set of complex options that they don't understand, it seems like they made a rational choice. AppStores on the various phone platforms have a similar decision to make as to how to best protect users from apps, and there isn't consensus as to the best model in that arena either.
They do need to step up their activity to remove malicious apps in light of giving regular applications this option.
"Remove malicious apps" doesn't undo the damage they caused. A reactionary approach only works until the first gigantic breach occurs, at which point people will finally start to ask "why do I have to give ShittyGame every permission under the sun?"
It's the same on Android. Why do I have to give any app that wants to display ads in my face permission to read my phone number and device serial number? Hell, on some carriers that's all you need to clone the phone and steal service from it. What possible reason could there be for that? It's poor design, and there's no reason I need to give "Bob's Fun Game" my telephone number just so it can have a unique ID to datamine later. Generate one on startup and use that.
The problems are similar and the solutions are similar - line-item veto for permissions, period. If your app can't handle it, crash - I'd rather have a broken app than risk my privacy for it.
It's the same on Android. Why do I have to give any app that wants to display ads in my face permission to read my phone number and device serial number? Hell, on some carriers that's all you need to clone the phone and steal service from it. What possible reason could there be for that? It's poor design, and there's no reason I need to give "Bob's Fun Game" my telephone number just so it can have a unique ID to datamine later. Generate one on startup and use that.
The problems are similar and the solutions are similar - line-item veto for permissions, period. If your app can't handle it, crash - I'd rather have a broken app than risk my privacy for it.
Just because it is difficult in practice does not make it any less important. That sounds like a Facebook problem more than a user problem.
Just in case anyone else is wondering...
http://webapps.stackexchange.com/questions/1/how-do-i-delete...
http://webapps.stackexchange.com/questions/1/how-do-i-delete...
No, Facebook doesn't share this information - you do! Let's be clear here. Those who are dumb enough to put their PII data on Facebook and the alike are sharing their information. My God, can we stop blaming someone else for our stupidity?
Facebook is in a weird middle spot between totally public and totally private. You log in, and you primarily interact with friends, but then a friend can allow an application to programmatically access your data... People have problems parsing the situation. Further, Facebook used to be much more private, and the constant adjustment of goalposts doesn't help.
I wonder if Facebook developed this functionality to aide companies bringing their ecommerce efforts directly onto Facebook (as Amazon and hundreds of others are now doing).
As I recall, Facebook still won't let the app/script that I run myself save the email addresses of my friends that they choose to share with me (I can manually save each shared email-address of each friend of my hundred friends but the terms of service prohibit any bulk downloading of this information).
So the assumption is that I, as a user, am naturally more willing to share my contact information with anonymous application X than I am with my friends.
Naturally, this is indeed a transparent effort at lock-in.
So the assumption is that I, as a user, am naturally more willing to share my contact information with anonymous application X than I am with my friends.
Naturally, this is indeed a transparent effort at lock-in.
You know who else shares my phone number and address? The phone book!
You know who else shares my phone number and address? The phone book!
but the phone book doesn't call up the websites you visit to tell them that it's you that's visiting them. It's not about the specific information being available; it's about the context it's available in and what other information it could be connected to.
but the phone book doesn't call up the websites you visit to tell them that it's you that's visiting them. It's not about the specific information being available; it's about the context it's available in and what other information it could be connected to.
And you can opt out of being in a phone book while continuing to use your phone.
Not to mention phone books have been sliding down a steep slope of irrelevancy for the past 10 or 15 years as cell phones increased in popularity.
Not to mention phone books have been sliding down a steep slope of irrelevancy for the past 10 or 15 years as cell phones increased in popularity.
I'm sure my relative would appreciate her abusive ex getting his hands on her phone number. (And given past problems with third parties, I have to think this information -- speaking generally if not specifically -- is going to leak.)
You use the cell phone number as part of password recovery / identity verification (as I understand it). And then you do this?