KyleHasegawa.com

Another letter to Steve Gibson that I'm reposting here in case it's not read on Security Now.

Hey Steve,

Just finished SN200. That was a good one. Just wanted to add a bit of info that you've never mentioned and might be valuable to your listeners.

Leo mentioned that his port 22222 is forwarded to his Skype machine and Skype is listening on that port so he feels it's safe about that hole. What may not be known to some listeners is that good-behaving programs will not bind to a port on which another process is already bound. In other words, if Skype is listening on 22222 then other, possibly exploitable, processes like Windows service host will not be listening on 22222.

It is possible for malware or security tools to listen in on bound ports which is why I said "good-behaving programs" but if you've got malware it's already too late.

I often write in to Steve Gibson to ask questions, provide feedback, or just rant about a security topic. While I have received responses a few times, most go unnoticed due to the volume of feedback Steve receives so I've decided to repost all my feedback to Steve here on my blog.

In response to a comment by Shawn Polson of Middletown, Delaware, Steve and Leo revisit the idea of encrypting all network connections. Shawn states that SSL shouldn't be used everywhere for efficiency reasons since SSL connections are not cached locally nor by proxies. While he makes a good point, Shawn's is not a technical limitation but just an economical issue of bandwidth. Steve and Leo continue on by clarifying their point that it's more of a general wish that all connections for email, web etc are encrypted, not specifically SSL. I agree that all connections should be secure, and Shawn is also right that there will be a bandwidth hit if content is not cached. With that said, I think it should be noted that there is also a technical reason why you can't enable SSL on every site and it has to do with a limitation of name based virtual hosts.

Download the script

5/30/2009 Updated to work http://friendfeed.com (non-beta)

The new Friendfeed UI beta opened to the public on Monday 2009/4/6 and has been getting great reviews from many tech pundits. The UI is so good that I'm thinking of switching from my current favorite FF tool Twhirl to the web UI. The only problem with the web UI is that it's designed to be used in a large browser window. I prefer this type of content in a slim window off to the side of my desktop. Resizing the window results in the sidebar menu squeezing out the content.

New Friendfeed UI doesn't work in a slim window

To remedy this I wrote this "Friendfeed Mini" Greasemonkey script. This is my first GM script so please comment if you find bugs or have any suggestions. It's a work in progress but it's usable. Note: The script is for the beta site. I'll probably need to update the script when the new UI comes out of beta.

The bloggosphere is abuzz today about the new DiggBar but I have my reservations about the new, admittedly cool, multi-purpose link sharing tool. The concern is its impact on SEO ranking for links shared using digg short URLs. URL shorteners like is.gd are popular on Twitter, Facebook and FriendFeed because they look better and save characters. Most URL shorteners use an HTTP 301 redirect to forward browsers to the final URL which is the method recommended by Google. The DiggBar URLs on the other hand point to digg.com/<code> and use framing (nested iframe) to display the target page, a technique that was considered to be a cheap dirty trick to steal content back in the '90s. Example: http://digg.com/u13iq.

framing increases Digg's page rank, not the target

Framing has its advantages, for instance adding a digg button to any page, but it's bad for SEO page rank because search engines will see those URLs as links to digg.com, not the actual page. I thought that Digg might be checking the user agent string to detect the Googlebot, Yahoo Slurp or other indexers but after testing with the User Agent Switcher Firefox add-on and with Javascript completely disabled, DiggBar URLs always use framing.

If page rank is important to you I would suggest that you not use the Digg URL shortener. Instead, choose from one of these that use 301 redirects.

As with most open source projects, the Laconica team focuses much more on development than documentation. That's not necessarily a bad thing for the project but makes it harder for third party developers. I had to use a lot of trial and error when working on the TWiT Army Laconica Plugin.

Here's where I had some trouble:

• Finding the right hook to insert elements in specific places
• Determining the 'action' name for the loaded page
• Figuring out how to remove elements

For the last one, it turns out that returning bool FALSE for some hooks will prevent the default output. That was a good idea by the dev team. As for the first two, I decided to create another plugin that just spits some markers and useful PHP object data. You can see a demo of this plugin on my Laconica test site: laconica.kylehasegawa.com. Some of the markers are not in the HTML body so these markers were added as HTML comments. View the HTML source of the test site to see these markers.

Comments, feedback, and suggestions are more than welcome. Full source code below the break.