| The problem is that it is not black and white. People will often get presented with some hair-raising proposition, turn it down, and later get presented with something slightly bad and go "well that's much better" and consider it acceptable even if perhaps it's pushing boundaries. I agree with you, and e.g. in the UK we have the BCS, which does have ethical rules you are expected to know and apply (their membership is just a small proportion of the UK tech industry, though; in part because it is not prestigious enough for e.g. employers to ask for, while requirements for membership makes it a hassle to join for a lot of people), but at the same time it is not sufficient. Especially give that a lot of things first become truly problematic in aggregate. E.g. Developer #1 gets asked to ensure you pull in the phone contact list to tie your local contacts to your Facebook friends, to enable extra functionality (lets say a "call" button when you view their profile) that seems entirely benign. Then developer #2 gets asked to match on phone numbers that have already been pulled in, possibly without even being aware that the phone numbers he is working on are not necessarily just phone numbers of Facebook friends but also unrelated contacts. You can say that they should have verified, but often it is very easy to assume that it's fine, and not think about consequences. E.g. it doesn't seem so unreasonable to suggest friend-of-a-friend. The problem in the article is that it is not suggesting friend-of-a-friend but contact-of-a-contact, which is an entirely different relationship. But if you're told "here you can find a bunch of phone numbers for each user", build a "friend-of-a-friend" recommendation feature, it is not that strange if people assume it's actually "friend of a friend" - people like to assume the best. Here's an example from my own past, that I did stop, but only at the last minute, when I realised what was about to happen: And old boss asks me for a database dump from a "sort-of-still-client" that was leaving us. Nothing odd with that - they kept asking for more up to date copies to make their migration easier, and kept paying us for a year after they'd migrated their site in order to be able to continue to use their old reporting facilities. So I prepared the database dump. Then I asked him how to deliver it, and he asked me to pass it to X. X was not the client, but someone in a new corporate parent. If my boss had instead asked me to deliver it to him instead of X, I'd have done it without further questions, and he would have passed it to X and the damage would have been done. What X wanted to do was to mine it for potential customers. The almost-ex-client were not in any way competing with the new corporate parent, so it would not harm them was , but apart from likely violating our contracts with them, it was also a blatant Data Protection Act violation (UK). My former boss thought this wasn't a problem because we were passing the data internally in the same company and we held the data in our system legally anyway. But the point is the data had been provided by the customers of our client for a specific purpose, and was handed to us for a specific purpose, and that purpose no longer existed. We certainly had not been given permission to use the data for sales. It was hair-raising when I realised what he wanted to do. He accepted it when I explained why, but it was rather shocking that it took an explanation for him to realise it in the first place. He was stupid to think his suggested use was remotely ethical, and that's the only reason I caught it: If he'd realised how unethical (and illegal) it was, and he still wanted to do it, he'd have asked me to provide the data to him, which I would have - that'd have been routine. If he'd asked me to put it up for download and provide a username and password, I also would have - assuming reasonably enough he was intending to pass that info to the client. Though after that incident I started being more sceptical about providing him with data without knowing the purpose first, and making sure the client had actually requested it. |