[0] http://www.zdnet.com/blog/btl/6-46-million-linkedin-password...
Also, while rare, the client could theoretically be using something like kerberos to authenticate, even over tls. The password exchange is secret, but the data contents would not be. I don't think the iphone supports kerberos, though.
(All this is not proof that they aren't your storing password, just that it's feasible for linkedin to merely pass it through. And possible, though not probable, for them to never even see the password.)
Encrypting user credentials in JS is probably even worse than parsing HTML with regular expressions: http://stackoverflow.com/questions/1732348/regex-match-open-...
Just send it in cleartext, but over properly verified https.
That being said, look at something like blockchain.info.
It adds javascript security on top of https, and for (what seems like) excellent reasons.
To avoid the "hash is a plaintext password" problem you save double-hashed passwords to your database, once in the browser and once on the back-end, twice on the back-end if JavaScript was disabled in your user-agent.
Of course that doesn't solve the problem above, but it still ought to be common practice.
However, for traditional IMAP/SMTP servers your point is well taken. They must store your credentials in a restorable state, which, however carefully you do, has difficult security implications.
Here's how Mint.com stores your banking credentials: https://www.quora.com/How-do-mint-com-and-similar-websites-a... I assume LinkedIn Intro would be using a similar technique.