Loading Profile...
Stop asking for Twitter passwords
Is it really necessary that the "Twitter this" widget asks for people's password? It is *not* okay to ask for the password for one site on a completely different site.
Now I know that the Twitter API doesn't provide any OAuth-style authentication but for this situation, you don't even need to do that. You just need to create a link on the fly:
http://twitter.com/home?status=Your+m...
Please stop teaching people that it's okay to throwtheir passwords around like confetti. You are teaching people how to be phished.
http://adactio.com/journal/1357
http://microformats.org/wiki/social-n...
http://www.codinghorror.com/blog/arch...
http://adactio.com/journal/1513/
Now I know that the Twitter API doesn't provide any OAuth-style authentication but for this situation, you don't even need to do that. You just need to create a link on the fly:
http://twitter.com/home?status=Your+m...
Please stop teaching people that it's okay to throwtheir passwords around like confetti. You are teaching people how to be phished.
http://adactio.com/journal/1357
http://microformats.org/wiki/social-n...
http://www.codinghorror.com/blog/arch...
http://adactio.com/journal/1513/
I’m disgusted
64
people like this idea
I like this idea!
Tell me when this idea gets some attention.
The more people who like this idea, the more it gets noticed.
The more people who like this idea, the more it gets noticed.
The company implemented this idea.
The best point from the company
-
I'm with Scott, here. Let's figure something out together. Be reasonable. Be just a tiny bit patient. We're a small and resource-constrained company, and that impacts our ability to stop everything and meet the sudden demands of the more forward-looking and vocal members of the technical community.
We do our *best* to be upstanding members of that community (which was Ted's point, for the record.) We built the Twitter thing long before there was any general consensus among the technical community on the whole anti-pattern line, well before OAuth made this sort of thing much safer, and certainly before we knew about the approach Jeremy suggested above. When we recognize changes in the environment like this one we always make sure to get them on the schedule, but they can't happen overnight.
Let me ask you this: You guys are here, haranguing us, insisting we listen to you, not giving us the benefit of the doubt, and we're some of your strongest supporters on the company side. Any surprise that we've gotten so defensive? And if we're struggling to deal with your chosen approach, how in the world do you expect to convince the rest of the world?
#3 and #5 of the Company-Customer Pact are definitely relevant here. Time and benefit of the doubt. Please and thank you.
I’m frustrated
3 people think
this is one of the best points
The best points from everyone
-
Scott and Ted, I'm kind of surprised by the push-back from you guys. As your rightly pointed out, you have done *excellent* work on implementing OpenID and hCard subscription in your sign-up process so I would have that the negative effects of the password anti-pattern would be self-evident to such savvy developers.
I can't provide you with too many examples of direct phishing attacks based on the password anti-pattern. Here's one:
http://www.codinghorror.com/blog/arch...
Then there are the less extreme cases like the MyNameIsE example mentioned above:
http://getsatisfaction.com/e/topics/a...
That was an example of (mild) identity theft rather than direct phishing.
But as so many have already pointed out, the real problem isn't direct cause and effect phishing, it's the message being sent out that it's okay to hand out passwords from one site (Twitter) on a completely different site (Get Satisfaction). If—or should I say when—this practice becomes commonplace then phishing and identity theft become so much easier ...even if it remains hard to measure directly.
Right now, Get Satisfaction are basically aligning themselves with sites like this: http://twitterawesomeness.com/
(though this is done as a joke whereas Get Satisfaction are doing it in all seriousness).
Now, the usual response to pleas for removing the password anti-pattern (e.g. Slideshare, Pownce, LinkedIn) is that they desperately need to be able to import people's address books. In the case of Get Satisfaction, you aren't even trying to do that! All you want to do is allow people to post a message to Twitter. For that, you *do not* need anybody's password.
Ted, you asked me to provide a solution. I made very sure to do just that in my original post. Simply make your "Twitter this" an actual URL that points to http://twitter.com/home passing it a query string with a variable called "status" pre-populated with the message you want to post.
The current solution isn't just bad practice and bad for the web, it's kind of over-engineered, don't you think?
P.S. to everyone else who is rightly upset by this, please remember: Ted and Scott really are top-notch developers who have done great things with OpenID support and hCard subscription.
I’m surprised
9 people think
this is one of the best points
-
@ted, i think adactio DID offer you a solution. Use the ?update= there is no reason you NEED the persons password except for YOUR convince not theirs. You are now in-control of sensitive information!
there have been plenty of examples of people being phished. Quetchup and Plaxo being just two examples. You give them your name and password in good faith and they go and spam your whole address book. There are probably plenty of other examples that have gone UN-noticed as well.
"hello my name is e" is another example of being phished by a company. You gave your twitter name and password to them to allow them to find your social network friends. Behind the scenes they were posting to twitter on your behalf. Just search for "hello my name is e" http://hellomynameise.com/ and you will quickly see how many people got burned by entering their passwords. It could have been MUCH MUCH worse because people are stupid and use the same password for multiple services!
I am concerned that you are so quick to dismiss "benefit out-weighs any perceived harm", isn't just one person's bank account being completely emptied because of password phishing bad enough?
A solution was offered that solves the problem without having to use a password, and infact is ALOT less code to maintain. That should be your benefit! That certainly out-weights the liability of your service, or an evil employee, taking user passwords and exploiting them across the web.
I’m frustrated
11 people think
this is one of the best points
-
You're asking for someone's password. You're giving the casual web user the impression that giving passwords out to 3rd party sites is ok. There are now dozens of twitter apps doing this and making it seem like 'the norm' and that there's nothing to worry about.
What about all those casual web users who use the same user/pass combo across a load of sites? It only takes one fake twitter app with a pretty interface (or a duplicate of your interface) to harvest such details and then go around testing them against all the major social networks, paypal, ebay, bank websites and so on until they find one that lets them in.
I’m appalled
4 people think
this is one of the best points
-
@Scott: It isn't in my opinion. Phishing attacks are as sophisticated as they need to be. Teach people wrong habits and it gets easier to trick them. And that is what password anti-pattern does. It teaches them it is OK if they leave credentials on website that hasn't issued them.
@Ted: Jeremy already mentioned solution. It's called OAuth or in case of Twitter, which regretfully doesn't support it yet, it's a simple enough to build link. I'd say that is constructive enough and to insinuate otherwise is just tasteless.
I’m angry
4 people think
this is one of the best points
-
Inappropriate?presumably, the reason alot of people still ask for a username and password to do this is for self promotional purposes (via the API, it'll show the client name which will click through to the website).
This doesn't excuse this, of course. If anything, it makes it even worse.
I’m sad
-
Inappropriate?Hi adactio,
Thanks for the feedback. I'll add this onto the list of fixes that we need make, after consulting with our design team about what they think.
Since it seams like you're very passionate about this issue, while I've got your ear I was hoping you could answer a quick question for me. Have you seen any studies done regarding the increase in successful phishing attacks with the introduction of these types of forms? Almost every phishing attack I've ever seen dupes a page such as yahoo, ebay, paypal, etc. and I don't follow the argument that third party password forms make people more or less vulnerable to this kind of attack.
I'm aware of many of the other arguments against this type of interaction, and I agree with the principal in general, but the phishing one seems very tenuous to me.
I’m thankful
1 Comment Add a comment
This is one of the best points
-
The point adactio is making is that it encourages users to be more frivolous with their passwords. You should only ever have to use a password for an account with a particular service when directly interacting with that service.
If Get Satisfaction, as a reputable web service, makes it look like its okay to plug your passwords for other services into websites outside the original service's domain, they'll be more likely to fall victim to the kind of typical phishing scam you describe. Plain and simple. -
Inappropriate?@adactio I was going to respond via twitter, but couldn't get it to fit in 140 chars.
I hear you thrashing a lot of companies about this (Slideshare, LinkedIn, Pownce, Get Satisfaction,) but don't hear much in terms of a solution.
Are you thinking about a solution or are you just trying to spread the gospel?
Personally, I think the benefit out-weighs any perceived harm. I have to agree with Scott. Where is the research here?
Without the 'teaching people to be phished' argument. Are we worried about a credible site such as facebook, or one of the sites listed above doing something malicious with our data?
The point you brought up about passing ?update= is a good one, and I would be happy to add that as a optional method of sending your tweet from GSFN.
Cheers,
-Ted
1 person thinks
this is one of the best points
-
Inappropriate?@Scott: It isn't in my opinion. Phishing attacks are as sophisticated as they need to be. Teach people wrong habits and it gets easier to trick them. And that is what password anti-pattern does. It teaches them it is OK if they leave credentials on website that hasn't issued them.
@Ted: Jeremy already mentioned solution. It's called OAuth or in case of Twitter, which regretfully doesn't support it yet, it's a simple enough to build link. I'd say that is constructive enough and to insinuate otherwise is just tasteless.
I’m angry
4 people think
this is one of the best points
-
Inappropriate?You're asking for someone's password. You're giving the casual web user the impression that giving passwords out to 3rd party sites is ok. There are now dozens of twitter apps doing this and making it seem like 'the norm' and that there's nothing to worry about.
What about all those casual web users who use the same user/pass combo across a load of sites? It only takes one fake twitter app with a pretty interface (or a duplicate of your interface) to harvest such details and then go around testing them against all the major social networks, paypal, ebay, bank websites and so on until they find one that lets them in.
I’m appalled
4 people think
this is one of the best points
-
Inappropriate?As an aside, there's a request pending with twitter to enable "from" attribution for tweets sent via the web rather than the API: http://code.google.com/p/twitter-api/... -
Inappropriate?@ted, i think adactio DID offer you a solution. Use the ?update= there is no reason you NEED the persons password except for YOUR convince not theirs. You are now in-control of sensitive information!
there have been plenty of examples of people being phished. Quetchup and Plaxo being just two examples. You give them your name and password in good faith and they go and spam your whole address book. There are probably plenty of other examples that have gone UN-noticed as well.
"hello my name is e" is another example of being phished by a company. You gave your twitter name and password to them to allow them to find your social network friends. Behind the scenes they were posting to twitter on your behalf. Just search for "hello my name is e" http://hellomynameise.com/ and you will quickly see how many people got burned by entering their passwords. It could have been MUCH MUCH worse because people are stupid and use the same password for multiple services!
I am concerned that you are so quick to dismiss "benefit out-weighs any perceived harm", isn't just one person's bank account being completely emptied because of password phishing bad enough?
A solution was offered that solves the problem without having to use a password, and infact is ALOT less code to maintain. That should be your benefit! That certainly out-weights the liability of your service, or an evil employee, taking user passwords and exploiting them across the web.
I’m frustrated
11 people think
this is one of the best points
-
Inappropriate?Seriously? I'm a big fan of Get Satisfaction and don't mean to cause offence, but I'm amazed you feel we need research to disprove such an obviously wrong practice.
Users should never give a web app password to another web app. It's that simple. The banking industry, which knows a great deal more about user security than the web industry, follows exactly this practice. They implore users never to reveal their PIN to anyone, and refuse to cover losses caused by ignoring this advice.
The ideal solution is to continue to pressure Twitter to support OAuth, but this really needs the help of third parties rejecting the unpleasantness of the password anti-pattern. It'd be great if Get Satisfaction could be part of this movement.
I’m somewhat shocked
-
Inappropriate?"Personally, I think the benefit out-weighs any perceived harm."
Seriously? You actually think this? I'm speechless.
If we were talking about bank account PIN numbers we wouldn't be having this conversation. You would never ask someone for their PIN no matter how amazingly awesome your application would be for them if they gave it to you.
Why are users passwords any different?
I’m astonished
1 person thinks
this is one of the best points
-
Inappropriate?I don't see that the benefit of retweeting something straight from the page out-weigh the *actual* (not perceived) harm caused by spamming expeditions like that of Quechup or similar.
I’m disappointed
-
Inappropriate?"Perceived harm"? Seriously? Under what circumstance would teaching an end user to give sites passwords from one site on another not be a harmful exercise? Even *if* you don't abuse that information, you're helping them form a habit that *will* cause them grief in the future when they do it with a genuinely malicious site.
I’m disgusted
-
Inappropriate?I'll just say this.
Where we have been able to use o-auth we have. We've supported it since the beginning. We support OpenID and Windows LiveID. We invented hcard profile importing. And we'll continue to support these things.
We're not talking about banking here. We're talking about sending a tweet.
I’m thankful for all the work our team has put into this effort
1 person thinks
this is one of the best points
-
Inappropriate?What the hell makes your Twitter password so damn special? And why do you trust Twitter with that password but no one else? You trust LinkedIn with a password, but only for LinkedIn? What really makes Twitter so special that you don't trust with LinkedIn or other third parties? Do you think LinkedIn is going to do something bad with your Twitter account, I'd believe Twitter would sell me and my Twitter account out way before someone like LinkedIn would.
It is nice to be logged into Twitter via the API used from other third party applications, like Twitterific for example. How annoying would it be to have Twitterific only show my tweets and NOT let me respond via the app but send me to twitter.com via the home?status= ??
You completely trust the people behind Twitterific? Or are we not to use any third party applications that allow functionality that can only be controlled when logged in?
I’m frustrated
1 person thinks
this is one of the best points
6 Comments Add a comment
This is one of the best points
-
My Twitter password is no more special than any of my other passwords.
-
"And why do you trust Twitter with that password but no one else?"
I trust Twitter with my Twitter password because (assuming they are following best practices) they are storing it using non-reversible encryption. If someone gets hold of Twitter's database then they don't get my password.
Someone like Get Satisfaction or Twitterfeed, on the other hand, can't store my password using non-reversible encryption. They need the password in plain text in order to use it to make posts on my behalf. If their database is somehow compromised, everyone's Twitter password is visible.
That's the difference between giving your password to the web site that it's meant for and giving it to a third-party web site that uses it to perform services for you.
I'm not in the habit of leaving my passwords on post-its in every cyber-cafe I use. Why would I want to leave in it plain-text in various random databases? -
Just to be completely clear Dave, Get Satisfaction *never* stores anyone's password from a 3rd party service in our database.
-
Scott,
I've very happy to hear that. And, of course, there's no reason why this particular service needs to.
But do you really think that the average user draws a distinction between the way that Get Satisfaction interacts with Twitter and the way that something like Twitterfeed does?
And, to be completely frank about this, we only have your word for that. I'm happy to believe you (but then I'd never give you any of my passwords anyway) but you have no way of proving that. -
I think there'a actually 2 separate issues here:
- for the purposes of getsatisfaction, there is no real need to ask for a username and password, since it could done the non-API way that @adactio suggests in his initial post. However, if you still want the "from" attribution, you'd need to lean on twitter to implement http://code.google.com/p/twitter-api/...
- a service like twitterfeed (which I should say I run) and some others don't have this option, as posts are not posted via a web site. And as Dave rightly says, I can't use one-way encryption of passwords in the database, because for posting twitter requires basic auth, so there's a need to be able to decrypt passwords when posting on the user's behalf. In this case, all I believe we can do (apart from being as secure as possible in protecting the database) is lean on twitter to implement oAuth ASAP. -
Mario,
"all I believe we can do [...] is lean on twitter to implement oAuth ASAP"
I certainly agree that leaning on Twitter as much as possible would be a good idea. But I think that there are two other things that we can do.
1/ Individual users can refuse to use services that ask for a Twitter password. Personally, I'd love to use Twitterfeed, but I won't until it can use OAuth. I realise that my boycott won't change anyone's policies, but it would be interesting if some of your better known users (Charles Arthur and Jemima Kiss for example) stopped using the service.
2/ Services could stop posting to Twitter until they implement OAuth. I know that posting to Twitter is the sole reason for Twitterfeed's existence, but I think you would make a huge statement if you withdrew the service until Twitter implemented OAuth. Or even if you threatened to do so. -
Inappropriate?Really? So how about you email me your twitter password? I promise not to abuse it and hell, even if I did, it's just a tweet, right?
I’m astonished
2 people think
this is one of the best points
1 Comment Add a comment
This is one of the best points
-
what's your email? ;)
-
1 Comment Add a comment
This is one of the best points
-
But of course! I'm upset at the bad practice, not at you guys personally. You guys are teh awesum! :-)
-
Inappropriate?
We're not talking about banking here. We're talking about sending a tweet.
That suggests you don't understand the cause of our concern. With a user's Twitter login, an Evil DevTM could get their email address. From there they could have a decent stab at logging into Paypal. It only has to work once out of tens of thousands of harvested users.
I’m crying on the inside
1 person thinks
this is one of the best points
-
Inappropriate?@Marko, if you gave me a good reason to give you my Twitter password other than to just prove a point, than yes, absolutely. I am not about to give up Twitterific, and apparently neither is a large group of people ... Twitter clients are a large and popular way to communicate using Twitter; are all of you really going to Twitter.com to do this?1 Comment Add a comment
This is one of the best points
-
No, but I actually check what my client sends. Beside, if password has to be stored somewhere, I prefer it to be on MY computer.
-
Inappropriate?@martin twitterific, running on my local machine, is something I can watch the network traffic coming to and fro, should I choose to. I can verify that it is doing nothing naughty and that it's not storing a password somewhere where someone other than I can get to it.
I cannot verify what anyone else does with my password.
3 Comments Add a comment
This is one of the best points
-
I don't think that makes a difference when discussing who is affected by this: the casual user. You may be smart and with it enough to monitor your outgoing network traffic, but most are not. I would postulate that wether it is a desktop app abusing their password or a web app would make no difference.
-
It actually does. It can be independently checked by anyone, while website can't. It's not necessary for everyone to check app if others have done it before them.
-
Interesting point. I'd counter that casual users tend to have anti-virus and anti-spyware software, where they don't tend to have anti-phishing software.
-
Inappropriate?"We're not talking about banking here. We're talking about sending a tweet."
It's irrelevant what the final action is (sendind a tweet, getting into your personal bank account, etc.): what is wrong is telling the users that it is ok to type a u/p at a third party site.
In fact, unfortunately,it will soon be too late... users have seen this practice too many times already.
Please just re-read more carefully Adactio's and Brian Suda's contributions: it's all there.
I’m shocked by the stubbornness
1 person thinks
this is one of the best points
-
Inappropriate?Regarding the request for research... I was in no way asking you all to "prove it before we change our mind"; I was simply curious about the issue, and since you no doubt have spent much more time that I have thinking about this issue I figured that you would have some better educational resources for me. Most of the blog posts out there have a lot of assumptions in them, and I was curious about whether anyone had backed it up with real methodology. No harm intended.
The share-this twitter form was created as tool to help people tweet topics that are important to them with as little overhead as possible and with as low development cost as possible. We're not facebook with a thousand developers, and so we have to constantly make trade-offs. Some of those trade-offs involve making value judgements for our users and then correcting our mistakes after the fact. This is no doubt one of those cases.
Frankly, I'm rather surprised at the responses in this thread. There's no room for error with some of you guys... how about a little cooperation and friendly discussion. There's no need to dogpile at all.
1 person thinks
this is one of the best points
5 Comments Add a comment
This is one of the best points
-
I'm sorry, for my part, if I seemed unfriendly. I don't know if I was one of those you refer to. However, it's worth noting that the somewhat... robust response back from getsatisfaction was probably what caused alot of people to join in the conversation. Perhaps there are lessons for all of us to learn here.
-
You're quite right, Scott. I really don't mean to come across like I'm dogpiling all this on you guys. Sorry if it came across that way.
-
@Mark Ng: No doubt I will learn. One part of my personally philosphy is that I put it all out there at the risk of making myself look like an idiot with the idea that people cannot educate me unless they know that I need it.
-
You can't get any more "low development cost" than using the ?status= link solution that Jeremy suggested. Hope it's a quick fix! :-)
-
"There's no room for error with some of you guys... how about a little cooperation and friendly discussion."
Sorry but there are certain issues, you could leave "room for error", but not here! And in fact those people here ARE cooperating with YOU (offering several solutions), but YOU aren't cooperating with them! That's the fact, sorry. -
Inappropriate?I'm with Scott, here. Let's figure something out together. Be reasonable. Be just a tiny bit patient. We're a small and resource-constrained company, and that impacts our ability to stop everything and meet the sudden demands of the more forward-looking and vocal members of the technical community.
We do our *best* to be upstanding members of that community (which was Ted's point, for the record.) We built the Twitter thing long before there was any general consensus among the technical community on the whole anti-pattern line, well before OAuth made this sort of thing much safer, and certainly before we knew about the approach Jeremy suggested above. When we recognize changes in the environment like this one we always make sure to get them on the schedule, but they can't happen overnight.
Let me ask you this: You guys are here, haranguing us, insisting we listen to you, not giving us the benefit of the doubt, and we're some of your strongest supporters on the company side. Any surprise that we've gotten so defensive? And if we're struggling to deal with your chosen approach, how in the world do you expect to convince the rest of the world?
#3 and #5 of the Company-Customer Pact are definitely relevant here. Time and benefit of the doubt. Please and thank you.
I’m frustrated
3 people think
this is one of the best points
4 Comments Add a comment
This is one of the best points
-
You're right, Lane, and I hope I don't mean to come across like I'm piling it on you guys. Like I said, you guys—Ted and Scott—have done great work with technologies like OpenID, hCard and OAuth and you are absolutely deserving of the benefit of the doubt.
Sorry for coming on so strong. -
For my part, the distress comes not from the use of antipattern here (which is disappointing but fixable), but rather the initial responses of the employees which suggested they just didn't consider this as an issue to be concerned about. That's alarming, especially coming from otherwise experienced and clever developers.
-
we do care, and we will fix it, it's just human nature to get defensive of your actions in these situations. fortunately everyone in this topic is pretty reasonable and we seem to be coming to a good consensus. :)
-
"Be reasonable. Be just a tiny bit patient."
I think the people are "reasonable", because their reaction is the only reasonable one! And: They are patient, but patience doesn't mean to excuse to not to something because of whatever reason. Why are you discussing so long, instead of just solving the issue?? It is just my impression, that you do NOT WANT to solve this, the way it was proposed! Stubbornness!
"We're a small and resource-constrained company..."
blah. See here: http://microformats.org/wiki/social-n... -
Inappropriate?Scott and Ted, I'm kind of surprised by the push-back from you guys. As your rightly pointed out, you have done *excellent* work on implementing OpenID and hCard subscription in your sign-up process so I would have that the negative effects of the password anti-pattern would be self-evident to such savvy developers.
I can't provide you with too many examples of direct phishing attacks based on the password anti-pattern. Here's one:
http://www.codinghorror.com/blog/arch...
Then there are the less extreme cases like the MyNameIsE example mentioned above:
http://getsatisfaction.com/e/topics/a...
That was an example of (mild) identity theft rather than direct phishing.
But as so many have already pointed out, the real problem isn't direct cause and effect phishing, it's the message being sent out that it's okay to hand out passwords from one site (Twitter) on a completely different site (Get Satisfaction). If—or should I say when—this practice becomes commonplace then phishing and identity theft become so much easier ...even if it remains hard to measure directly.
Right now, Get Satisfaction are basically aligning themselves with sites like this: http://twitterawesomeness.com/
(though this is done as a joke whereas Get Satisfaction are doing it in all seriousness).
Now, the usual response to pleas for removing the password anti-pattern (e.g. Slideshare, Pownce, LinkedIn) is that they desperately need to be able to import people's address books. In the case of Get Satisfaction, you aren't even trying to do that! All you want to do is allow people to post a message to Twitter. For that, you *do not* need anybody's password.
Ted, you asked me to provide a solution. I made very sure to do just that in my original post. Simply make your "Twitter this" an actual URL that points to http://twitter.com/home passing it a query string with a variable called "status" pre-populated with the message you want to post.
The current solution isn't just bad practice and bad for the web, it's kind of over-engineered, don't you think?
P.S. to everyone else who is rightly upset by this, please remember: Ted and Scott really are top-notch developers who have done great things with OpenID support and hCard subscription.
I’m surprised
9 people think
this is one of the best points
-
Inappropriate?Perhaps a better place to discuss this would be this discussion on the Twitter Get Satisfaction forum.
I’m frustrated
-
Inappropriate?http://code.google.com/p/twitter-api/... - twitter have fixed the ability to specify source. This will probably help with making improvements with this issue.
1 person thinks
this is one of the best points
-
This reply was removed on 01/06/09.
see the change log -
Sorry, but this doesn't seem to be about this topic.
-
Inappropriate?I'm just running specs right now, and so these fixes should get deployed in the next couple of days.
-Scott -
Inappropriate?Hey, you guys did it! (and I didn't even notice ...sorry)
Thank you, thank you, thank you!
You guys rawk!
I’m thrilled
1 person thinks
this is one of the best points
1 Comment Add a comment
This is one of the best points
-
Thanks adactio, and thanks double for bringing it up.
-
Inappropriate?What a happy ending! And the discourse? Reasonable and polite to say the least. No rantings? Exceptions make the rule. Do not think Adactio was spreading his gospel. I think he wanted to help because he cares, but then the response from Scott at the end more than compensated that. What a great crowd. I was more than once at Twitter, but never joined. Had doubts. Now it is different. Count me in. Pleasure to follow you folks!
I’m happy
EMPLOYEE
EMPLOYEE
EMPLOYEE
