Nope, it's because Microsoft just don't care. Wikipedia has 2.5 million articles all in the same namespace and still manage to have nice URLs. It really doesn't take much effort to provide decent URLs for a very large corpus of information - but Microsoft clearly haven't even thought about the problem. Their URLs have always been disgracefully bad.
This is more a disagreement about the value of URLs than about whether Microsoft "cares" about their end users. With a keyword bookmark for Wikipedia, I'm about 50/50 for getting the content I want with simple URLs; I still wind up in the Wikipedia search bar all the time.
For me it's not about finding the information by typing in a URL. It's more about scanning and having a clue what I'm going to see by the url I'm clicking on. A giant random number really has no meaning or value in this context.
HN isn't a reference work like Wikipedia or the MSDN Knowledge Base, so it's less important here.
But the real reason that Microsoft's URLs suck is that the MSDN Knowledge Base is an older product than Google's, built back when the web was new and people didn't realize that their URLs sucked. And one thing that I respect Microsoft for is actually caring about reverse compatibility.
(Sidenote: This is why you should think about your URLs. They are how your website will be presented to the world.)
I didn't mean they don't care about their end users, I meant they don't care about their URLs.
I think the links earlier in this thread are a perfect example of why this is useful. You can tell what you'll get when you click on the Yahoo! and Google ones, but the Microsoft one is totally opaque.
That's kind of a loaded question since a reasonable definition of an enterprise CMS is "one that isn't very good". That said, Ellington (which I worked on a few years ago) is probably expensive enough that it can be considered "enterprise" and ships with nice URLs out of the box: http://www.ellingtoncms.com/
Would Jonathan Schwartz's blog ( http://blogs.sun.com/jonathan/ ) count as an enterprise CMS? That has URLs which include the title. Does Wordpress ( http://www.wordpress.com/ ) count as an enterprise CMS? That also has URLs which include the title.
Jonathan's blog? Maybe.
Wordpress? No. It's pretty clearly open-source and has the "started as a few lines of code" pedigree that makes it not enterprise.
"Your email account is a de-facto master password for your online identity. Most -- if not all -- of your online accounts are secured through your email. Remember all those "forgot password" and "forgot account" links? Guess where they ultimately resolve to? If someone controls your email account, they have nearly unlimited access to every online identity you own across every website you visit."
...and...
"how can I take your privacy policies seriously if you aren't willing to treat your competitors' login credentials with the very same respect that you treat your own?"
This is a huge blunder a lot of companies are making. I was shocked when I saw it on facebook. And now, with all the APIs available, it's simply inexcusable.
I first saw this on Facebook. They did have leverage and they used it without hesitation (quite arrogantly I thought). Then everyone else followed: "if Facebook can do it, why can't we?". It became a standard. That alone made me loose the little respect I had for Facebook. Very early did they screw up. Google still manage to not fall this low.
We have to remember that email-based import is a service aimed at the masses to make life easier for such people.
Although most people on HN and the like will usually opt out or refuse such a request, many people will not care about the privacy/security issues if it means less work for them.
The danger is that this breaks what is supposed to be a taboo, lowers people's resistance to giving out their password by conditioning them to expect that nothing will go wrong, and makes it easier for others to commit fraud.
So people get burned by some Nigerian scammer, decide never to do any business online again, and what good does that do for the YC crowd?
You're saying that it is difficult to educate people, so it doesn't matter if they are taught to do incredibly dangerous things without a second thought. The fact that it is difficult to educate people makes it that much more important that companies like Yelp not do stupid things like this.
First, there have been as many horror stories about the mass-market features built on harvesting email contacts.
Second, there are lots of convenient features that we don't build because they send a terrible message. For instance, it would be really convenient to work with your bank via email.
Third, he's right: many of these services probably do bank your password, which is an absolute nightmare. Almost every web app is going to lose its database to SQL injection at some point in its lifespan.
Exactly. If there is an opportunity to find a way to add features and get more users, any company will do it. This is a no-brainer. Any tech-savvy user will just simply skip this step.
And the contacts API that the major providers are giving are recent. It's not like services like Yelp and FB had the choice before.
Ps.: Jeff Atwood's "from the hip" writing style shows. I'm yet to find one single post from him that seems slightly insightful. Instead of spending so much time ranting, he could spend a tenth of that time thinking about why Yelp keeps that "feature".
Edit: could someone please explain me why of such aggresive downmodding?
Because you completely missed the point. It doesn't matter why Yelp keeps that "feature". It's irrelevant, because his position is that there is no situation where giving a login and password of any sort, but especially e-mail, makes any sense at all.
You said that Atwood should have spent time thinking instead of just ranting, but then you kind of did the same thing....
And that's not to mention giving the "they're a company, anything goes" and "it was the only way back then" excuses; those are meaningless.
It may make no sense to you, to me or to any tech-savvy user. But it does make sense to those who use the damn feature. No one is forced to use that. If they are using it, it's because they think it might benefit them in some way.
The same goes for websites that do such thing. They know that some users might be annoyed by such "feature", but the amount of new users that will be exposed is much higher, so they keep doing it.
What I find hard to believe is that the ones that complain about these kinds of mechanisms don't understand that themselves are not part of the target of said mechanism. Instead of simply ignoring it, they feel "victims" of it.
And I'd like to know where I said "anything goes". If that was the case, I would say that scammers are right to do what they do because they never forced the users to give sensitive data. What I did say is that, if a webservice wanted to provide a way for the user to (semi-)automatically invite people in his contact list, the only way to do that required email and the password.
Sure it makes sense to them, they don't know what they are doing.
What I find hard to believe is that the ones that complain about these kinds of mechanisms don't understand that themselves are not part of the target of said mechanism.
These mechanisms are prominently shown to all users of the web site who want to import contacts, whether they are technical or not. There isn't a banner above them which says, "this feature is aimed only at people who don't understand the security implications."
Making money by teaching someone to compromise their security is a morally bad thing to do, whether that person knows they are being taught to put themselves at risk or not.
I'm sorry, but I just disagree. I don't see any wrongdoing in this, provided they do what they actually state they do. If they take your password and do nasty things with it, than it's a whole other story.
There isn't a banner above them which says, "this feature is aimed only at people who don't understand the security implications."
If you do understand the security implications, then the banner is irrelevant!
Also, they are not saying that you must use the feature either, are they? What happened to freewill? Does everyone think that you are supposed to consume every feature of the service just because it's free and it's there?
And to say they are "teaching to compromise security" is a gross dramatization. They are not teaching anything at all.
The real point is that there are now APIs to get at people's contacts, and several sites still do not use them. That is the issue, and there isn't really an excuse for it.
I agree that some time ago, it may have been a (dubious-yet-) reasonable feature. Now it's just irresponsible.
Don't worry, many people use one password everywhere, so websites like Yelp probably already have lots of email passwords - even those that don't use any of those providers.
It is painful to be reminded of how poorly so many people watch out for themselves. As an uninterested third party, you can shrug and say, "Every man for himself." But as soon as you start designing web applications that assume people behave reasonably, you lose the luxury of being able to ignore the problem.
This isn't as big of a deal as people are making it out to be. The fact is that I DO give out keys to my house to a number of people that I trust. Likewise, I've used this import feature on a few websites that I trust, such as Facebook, and would be willing to do the same on Yelp if I used that. The notion that it's somehow unethical is just silly.
Of course people should be hesitant to give their passwords to random web sites, but then again they should also be hesitant to give they address book out to random websites (I don't want spam just because you signed up for some scammy site). The people most likely to fall for scams probably use the same password everywhere, btw.
"I DO give out keys to my house to a number of people that I trust."
Your house keys are less dangerous than your email password. As jeff points out, with your email password someone can probably take control of all of your web credentials. It's as if you have them your house keys, and then they use those to take control of your snail mail, and then they apply for new credit cards in your name, and order a new set of car keys, and so on.
And of course, we are not talking about giving your house keys to a friend staying with you. We are talking about giving your house keys to the bartender because he says he can help you invite all your friends to have a drink with you.
With my house key, they can get to my email, so email permissions are narrower than house permissions. Someone with access to my house can definitely cause more trouble than someone who only has access to my email. It's not just friends either btw, I also give house keys to the cleaners, etc.
If your email is so super secret, then you probably shouldn't trust Yahoo or Microsoft with it either, btw. I'm not saying that there aren't security issues, but you need some perspective here. Facebook is just as secure as Yahoo, so letting them use your Yahoo password really isn't that big of a deal.
Lots of phraudsters use this sort of technique as well. I started receiving several spam IMs a day from a friend of mine. When I asked what was up, she said that she had foolishly given her account name and password to a service which purported to tell her what other IM accounts had blacklisted her.
Of course, many more accounts blacklisted her once they started receiving the spam messages...
When you ask your employer that 'why' question, what comes next? Suppose the address book API's were unknown to both employer and employee; the employer might say 'go ahead and write the core component that will manage just a list of names and emails'. This is still ethical because in theory it can be connected to a current or future address book API, so the programmer agrees. Later, when the address book API's aren't enough for marketing, an intern or other willing employee is induced to connect it to the full email login and password credentials.
Its stuff like this that makes the first employee want to leave, which leaves the 'salt' effect of remaining employees at the company.
Somehow, the employees (and perhaps students in a school situation) should have some power of a social vote that the boss at least 2 levels up from them needs to acknowledge.
By the way, for those who worry about this... Don't do like I did and try to login to your msn account in a webcafe in china.... It's the same as giving out your passport on untrusted website except that in this case, you can be sure that if they do have keylogger, (like they did in my case) they will spam the hell out of your address book....
And like this, me, who always spent my times complaining against people who are not careful about security, spammed most of my friends :-(
They aren't the only ones asking for this. However, I notice that you have the option of skipping that steps, just as you do on Twitter when it asks for the same info. Just opt out.
I highly doubt that. Freedom of speech covers your right to give out your password to anyone who asks for it :)
If some stranger came up to you in the street and asked for your SSN & bank account number and you were stupid enough to give it to them, who would be at fault? Would that stranger have done anything illegal?
There are probably computer misuse laws which make it illegal to use someone else's identity to gain access to a secured account, just like laws against using someone else's credit card details. Certainly against the TOS of those web sites.
Best temporary solution for those who want the features without risk from all but the most malicious sites: Change E-mail password, give password, change password back.
That's OK if you trust the site as much as you trust your email provider. There's still a mild risk that they'll store data that they obtained when they logged in to screen-scrape for contacts and that data will leak. It's probably worse in gmail and other services that show potentially confidential snippets of emails as soon as you log in.
Google Contacts API: http://code.google.com/apis/contacts/
Yahoo! Contact API: http://developer.yahoo.com/addressbook/
Windows Live Contact API: http://msdn.microsoft.com/en-us/library/bb463989.aspx