DansNetwork

There’s a new Insteon controller out there that uses a built-in web server to control your Insteon devices. It’s called NetLinc and has a price tag of $119.99 from SmartHome (of coarse). I believe that this is going to be one of SmartHome’s biggest Insteon products yet. In the past, Insteon controllers have been pretty locked down as far as user manipulation is concerned. With an HTTP controlled device such as this one, there isn’t going to be anything to hide. I can already see the numerous custom interfaces being made for any device that has a web browser. This will also open a new market for custom floor plans that can be developed using common web design techniques (GET or POST requests). For a more complex interface, you might be able send XHR(AJAX) requests to the NetLinc to turn on, off, or check the status/state of a device!

SimpleHomeNet has already manufactured a few products that aimed to achieve the same functionality as the NetLinc. They are all quite a bit more expensive though:
EZSrve Insteon/X10 Home Automation Gateway ($209.99)

EZBridge PLM Combo ($199.99)

I’ll be ordering my NetLinc soon and can envision my Insteon USB PowerLinc on EBay shortly after!

There is a growing number of websites out there that require its members to login on a fairly regular basis. Many times these numerous user names and/or passwords will slip our minds and we’ll be forced to click on the “Forgot My Password (click here if you’re an idiot)” link. Yes, I am a regular clicker of these types of links. How many times, after proceeding with this shameful process, have you received an email containing your password? No, not a link to change your password or questions about your account that only you would know (that would eventually allow you in), your actual password in plain text! This could tell you a lot about how your favorite website is handling your password. Oh, and by the way, a bank, credit card company, etc. should never be able to send you your password in an email. This means that they are not securely storing your password. Here’s how it works:

Secure Password Storage
When you sign up for your new account and enter your password for the first time, your password is hashed (one way encryption) and stored into the database. This hash is a one way avenue. It can’t (in most cases) be decrypted, thus no way for anyone to retrieve the original password. So, if you can’t see the original password then how are you able to log back in? When you revisit the site and enter your password, it is hashed, using the original algorithm, and then it’s compared to the stored (hashed password). If the two match, you are granted access.

Original Password -> SHA-1/MD5/Other Hash -> Database Storage
Login Password -> SHA-1/MD5/Other Hash -> Result is Compared to Database (Hashed)

Unsecure Password Storage
When you sign up for your new account and enter your password for the first time, your password is sent directly to the database. In some cases it might be encrypted using a weak algorithm that can be unencrypted or decrypted. When you revisit the site to log back in, the password that you enter is compared directly to the one (or decrypted one) stored in the database.

Original Password -> Database Storage
Login Password -> Result is Compared to Database (Plain Text)

Let me start off by saying that this has got to be one of the easiest ways to add “Live Chat” functionality to a website. I searched around for a while and I knew that I wanted to tie the live chat to my Google account (GTalk/Jabber), but didn’t realize that Google already provides an API for doing this. It’s called Chatback and you can create a Chatback Badge in one or more of the following flavors:

Either one can be seamlessly integrated into your site using an iFrame or a simple image/link combination. To create your badge code, visit: http://www.google.com/talk/service/badge/New This page will allow you to create and customize one of the various Chatback Badges for your site.

I’ve recently put together a page that included over 550 thumbnails that were set to load dynamically. They were grouped together to be viewed throughout several “pages”. Originally, if you went to the second page without waiting for the first to finish loading, you’d be unimpressed with the presentation. The second page would begin to load only after the first was finished and so on. I needed to come up with a way to stop the thumbs from loading when you went to the next page and here’s what I came up with. It works with Firefox, Safari, and the troublemaker…Internet Explorer.

Using Mootools:

function stopLoad()
{
   $try(
      function(){window.stop()},
      function(){document.execCommand('Stop')}
   )
}

Using Prototype:

function stopLoad()
{
   Try.these(
      function(){window.stop()},
      function(){document.execCommand('Stop')}
   )
}