Lessons Learned: Selective Reading and Human Nature

Psychologists will tell you that humans "see what they want to see", "hear what they want to hear". They also "read what they want to read".

That's why police identification lineups of suspects are notoriously flawed. When I publish my articles on our developer site, eggheadcafe.com, I almost always put one of my little article-specific discussion boards at the bottom of each article. I do this because I want to encourage feedback. It gives the reader a sense that if they have something to say, they are free to do so, and I've gotten a lot of good suggestions from some of their posts, many of which have helped me to become a better writer. Once a month or so, I run a little cleanup SQL Script that lets me get rid of the relatively few "ASDF" "ASDF" posts left by mindless curiosity seekers (I say mindless because they never quote Shakespeare or Chaucer, it's just "ASDF").

On one recent article, "ASP.NET: Obfuscating the QueryString", I got a surprising number of negative comments. By way of explanation, I had answered a newsgroup post at the MS C# Language group to somebody who wanted to pass a "connection" on the querystring to a new application, and I had answered that they could pass the connection STRING, and use that on the receiving end to recreate the same connection. Another MVP posted that it wasn't a good idea to try to pass connection strings on the querystring for security reasons, which is of course, correct.

I got interested in the concept and wrote this article about obfuscating the querystring. The fact is, you couldn't pass a connection string as a querystring item anyway because they contain "=" equals signs which would totally bomb out your querystring.

So after some experimentation I came up with an ASCII-Hex / Hex-ASCII arrangement that allows you to pass whatever you want on the querystring, obfuscating both the names and the values, so all you would see is something like:

WebForm2.aspx?636F6E6E737472696E67=7365727665723D78797
A3B64617461626173653D796F64613B7569643D6A6F636B6F3B7
077643D796F756265746368613B


That's not encryption (although there is nothing to stop you from say doing 3DES encryption and then obfuscating the result). But, it is sufficient to keep your "stuff" from prying eyes, and it has a number of uses that don't necessarily involve anything to do with sensitive data that shouldn't be on the querystring. I took care to write a whole paragraph in this article explaining in plain English that it is not a good idea to put something like a connection string on the querystring or any other sensitive data for that matter. In fact, in this one paragraph, I actually made this point not once but two times:

"If you truly need strong encryption, my suggestion is -- don't use the querystring at all; find another way." and,

"But the bottom line is, it's best not to put sensitive data on the querystring at all -- there are other ways to pass the data."


One would think that after making this point not once but two times very clearly in plain English that I DO NOT recommend puttiing connection strings or similar sensitive data on the querystring, that the point would get across, right? Nope! Regardless, there were several nasty comments from readers who pretty much had decided in advance (although possibly it was subliminal) that no matter what I wrote, they were going to "put me down". Some Examples:

"Encouraging bad solutions"
In what scenario could you possibly want to pass a connection string via querystring? This seems so ridiculous to me, and justifying it by obfuscating the querystring is worse. I would expect more from an MVP with 20 years of experience.

"Decent idea for non-sensitve data, but otherwise you're a joke"
wow, what a joke of a mvp.

"You are actually a complete joke (Part II)"
Hi, How is it possible for an MVP with a PH.D. to have so little regard for security. This is the most rediculous [sic] article I have read in years. Regards C.M.


There were a much larger number of positive comments, some "Thank you"''s and a few that felt it necessary to respond to the nasty people by defending me, the poor author. Plus, I had some fun jabbing in a couple of retorts of my own. But, I wasn't nasty; I was respectful.

The Bottom line? People approach certain situations in print, as they do in social environments, with certain predispositions that prevent them from seeing -- or at least comprehending -- what is in front of their own eyes. We as writers and developers need to be mindful of this so that these contextual choices don't inadvertently throw off the reader onto a "slanted perspective" that prevents them from absorbing the intended meaning or information.

The next time I write an article about a subject like this, you can be sure I won't use a connection string as the example case, even if it represents the useful purpose of bringing the article into the proper evolutionary context, as it did with the above-captioned article.



Comments

  1. Anonymous7:28 PM

    Peter,

    Good artical, I've actually found myself in a number of situations where the content that I'm asking someone a question on, is the version of the content that I read and not what the content actually said. The minds eye, in a number of senarios is supprisingly powerful. Best to protect yourself in the future from unwanted comments like you got there. Although you may want to hope that the type of people who would send comments like that dont bother visiting again. Clearly short of thinking capacity (my opinion only!).

    ReplyDelete
  2. Anonymous7:53 PM

    Peter,

    You get it alot easier than Raymond Chen. Half of the respondents on his blog are commenting on what they THINK he said, as opposed to what he ACTUALLY said.

    Slashdot has alot to answer for. ;-)

    ReplyDelete
  3. Hehe. And Digg is just as bad!

    ReplyDelete

Post a Comment

Popular posts from this blog

Some observations on Script Callbacks, "AJAX", "ATLAS" "AHAB" and where it's all going.

IE7 - Vista: "Internet Explorer has stopped Working"

FIREFOX / IE Word-Wrap, Word-Break, TABLES FIX

System.Web.Caching.Cache, HttpRuntime.Cache, and IIS Recycles

FIX: Requested Registry Access is not allowed (Visual Studio 2008)