Showing posts with label Psychology. Show all posts
Showing posts with label Psychology. Show all posts

Thursday, November 20, 2008

Phishing web sites

I see many phishing emails because of my job.

The conventional wisdom seems to be to treat phishing email as if it were spam. Just add it to the SPAM filter and forget about it. I don't get it. Spam is a commercial nuisance, but phishing is a deliberate, blatant attempt to defraud people. Blocking subsequent emails won't keep people from falling victim to the emails that already made it through-- nor will it keep other people outside of my workplace from being victimized.

I believe phishing deserves a separate and greater response. This is why I use Phishtank (at home), and am so aggressive (on the job) about reporting phishing emails to the security departments of various organizations that fraudsters like to impersonate. I want to see these phishing sites taken offline; I want to see the perpetrators pursued and brought to justice when possible.

Although I feel sorry for the people who fall for these phishing scams, the people I feel even more sympathy for are the ones who are just trying to run a web site . . . and then discover that someone has violated their server security, and is using their platform on the Internet to rip off and hurt other people.

It goes something like this:

The would-be fraudster finds a web server that he or she can compromise. Maybe they were able to sniff an FTP userid/password over a network connection because it was passed in the clear, or maybe the password was easy to guess or derive because it wasn't a very strong password. The precise method of compromise isn't important, because there's more than one way it can be done. The important point is, they have gained illicit access to the web server-- so they create a fraudulent paypal/bank/IRS website and bury it deep inside a subfolder where no one ever looks, like an images folder. Then they send out emails to large numbers of people with links back to that fraudulent web site, and wait to see how many people take the bait and enter their account information. The person who owns/runs the website in most cases has no idea what is taking place under their noses.

I got to speak with such a person this morning. Nice woman-- runs a small web site for her small school. She teaches kids how to design web sites. She had a vague, conceptual understanding of what phishing was, but I'd be highly surprised if she's received any training on server security. Even if she had, it's unlikely her IT group has given her read access to her FTP logs or uses any encryption with their file transfer protocols. There isn't enough time, resources or skilled people available, and the priorities are always elsewhere.

But here's the thing, people. If everyone shrugs their shoulders and says, "This isn't my problem," then the same stupid cycle is going to keep being perpetuated. And one day, the person who gets fooled and taken for a ride will be you.

Sunday, October 26, 2008

Javascript-- Is the third time the charm?

I don't even know where to begin with this post.

Part of the problem is, I tend to think in metaphors and observe similarities and interconnections that other people don't seem to be able to perceive. When I try to demonstrate these connections to other people, they just find it confusing. You'd think I'd learn it's a bad strategy, and yet this is how my mind operates when trying to comprehend something.

Imagine there's this doctor, and he's been practicing medicine for three decades. He's reasonably competent, works hard, but for some reason never kept up with the latest trends and changes in his field. The days roll by, and one day he's suddenly operating in a paradigm that's completely obsolete. And the scary part is, he is so out of touch, he doesn't even realize how out of touch he's become!

With me so far?

Now, imagine the same scenario, but with a web developer-- and let's be honest, a web developer most likely isn't operating with life and death stakes, so he has even less true motivation to keep up with the latest trends and changes in the field. And we all know how quickly things in web development can move and change, right?

Then, on top of all that, what if the web developer works for an organization that is large, where change is glacially slow at best? Where the majority of IT folks are clinging to best practices that have been rendered obsolete years ago-- or even outright ignored because someone decided they just aren't going to do things that way as a matter of personal preference.

I did an inventory of my situation the other day. Basically, because of politics at my workplace, I'm a ColdFusion developer who doesn't really have access to a ColdFusion server. This is sort of like being a magician without a rabbit. Sure, I can get by with static HTML, CSS, a bit of Javascript here and there-- but to really harness the power of dynamic web pages, the best I can do is a Filemaker Pro server on our Intranet.

It got me to thinking-- what's the point of learning Python or Ruby or PHP, when I'm never going to have access to a server that supports these languages? (Yes, I know, I can install Python on my local computer and leverage it without having a server-- but you know what I mean.) I need to flesh out and expand the depth of knowledge I have about tools I can realistically expect to have access to first, before I start spending time and energy learning "the fun stuff" I will never get to see.

So, I'm sorting through my mental inventory and the first thing that pops into my head is Javascript. All major, modern web browsers have support for Javascript, so if I put time and energy into learning that-- really learning it, mind you, not just learning enough to solve the current task I've been assigned-- then that ought to have the highest payoff in terms of being able to assist people at my work place. (Microsoft Access is second on my list, by the way, even though I'd be using it strictly on a network share, not a true web server.)

I made a trip to Borders this weekend and picked up a copy of Shelley Powers' "Learning Javascript" book. It has a copyright date of 2007, so I expect the information in it will be still fresh and current. I was even able to use a gift card I'd received at Christmas to pay for most of it.

(long pause) Um, did I happen to mention I hate Javascript?

See, I tried to learn Javascript a very long time ago (I think it was still in version 1.2, as I recall). I ran into a lot of problems with cross-browser support being . . . lame. (It's a highly technical term-- couldn't possibly explain it further.) I'd write a javascript that worked on one version of one browser, but then bombed horribly everywhere else. You'd have to write four different versions of your code, and then have some horribly kludgey way to "sniff" out which version of javascript you'd encountered and then play traffic cop to get the broswer to the specific version of code designed for it. Then a new version of one browser would come out, and things would break, and you'd need to revisit the whole damn program again.

Who can learn under those conditions? Where's the success? Where's the reward feedback loop?

A few years go by, and the ECMA ratifies a version of javascript, along with an API that should bridge most of the browser differences. I start dabbling with it again out of necessity (adding a "characters remaining" counter notice under a text box, as I recall) and still find it difficult going, although it's better than it was. Then, suddenly everyone and their brother wants their sites to have AJAX-- including the people who'd still be creating their relational databases as one gigantic flat file if it wasn't for me.

Which brings us to current day. I read Chapter 1 in Ms. Powers' book yesterday. It's well written, and it was an eye-opening experience. I found out that the things I had learned back in the day as "best practices" (e.g. using HTML comments to "cloak" your Javascript from browsers that don't support Javascript) are not only currently irrelevant, but can actually cause problems if you plan to use XHTML in your web pages!

(Damn, and to think that less than a year ago, I was taking Google to task for putting out Javascript code in their Google Analytics products that broke valid web pages-- and the solution I suggested was that Javascript cloaking trick. I'd like to thank the patient folks at Google for not sending me flaming emails, calling me a fossilized hacker wannabe.)

Today, I sat down and reread Chapter 1, while taking detailed notes in one of those black and white composition books. I'm hoping that rereading and writing down my observations will somehow ingrain the knowledge in my brain a little deeper-- maybe make it easier to break off my bad habits, as well as pick up new habits that are current best practices. It takes longer than just reading the chapter once would, of course, but if I want to be better than just an average web developer, I need to get to the point where I'm dreaming about this stuff in my sleep.

On the plus side, I'm at least savvy enough to have discovered an error in Chapter 1 on my own. (I'm sure it was a simple oversight and has already been detailed in some errata file on O'Reilly's web site somewhere.)

Man, wouldn't that be a dream job? Being one of the "technical proofreaders" who goes through the texts prior to publication, and get hands on with all the exercises and lessons-- making sure they work properly. Hmm, on second thought, you'd probably be stuck with the responsibility of fixing them somehow when they didn't work properly. Maybe not so cool after all.

I also need to figure out where the changes in trends related to Javascript would originate from (perhaps the ECMA?) and sign up for an RSS feed or email bulletin or something that will keep me from falling back out of date again if/when I do finally internalize this latest material.