I posted recently about why we no longer need to enter “www” when visiting websites in a browser. The topic is evidently an emotional one as I’ve received a ton of feedback on the matter. For those that missed it, here’s the basic argument:

The reason for using the “www” hostname prefix when entering websites is now a matter of history. It’s old. Deprecated. Outdated. Antiquated. Like websites that only work in Internet Explorer, sites that break when you use the domain alone should be firmly encouraged to join the 21st century. It’s wasteful to type, and it’s cumbersome to pronounce. Consider that it takes nine syllables to properly enunciate three characters.

Some argue that there is still a good reason to separate traffic destined to web servers from that destined to the domain itself. I think this is precisely the idea that’s become obsolete. The reason for that differentiation in the past was that the other protocols were as prolific (or even more prolific) than HTTP at the time. HTTP was just one of many, so it made no sense at the time to give any type of traffic a preference by pointing the root of a given domain to the system that hosted that content.

Things are different now. HTTP is utterly dominant. Any site interacting with the public on any serious scale does so via a web server, so making this the default is a matter of obvious practicality. This doesn’t mean we should abolish the use of hostnames. Hostnames are excellent tools for separating traffic and making meaningful associations with users. The argument here is simply for having the root point to the web content.

Compatibility

There are four basic levels of no-www compatibility:

1. Your site is available via www.domain.tld only. If you use the domain alone your request will fail.
2. Your site is available via both www.domain.tld and domain.tld, but www.domain.tld does not redirect to domain.tld.
3. Your site is available via both www.domain.tld and domain.tld, and www.domain.tld does redirect to domain.tld.
4. Your site is available only via domain.tld and www.domain.tld will break.

I personally recommend webmasters implement #3, and don’t advise #4 for any reason. The discussion here is about improving usability through simplification, not breaking things for the satisfaction of being pedantic.:

It’s no longer necessary to use “www” when referring to websites. It’s a waste of storage, a waste of ink, and it takes 2-5 times as long to pronounce as saying the domain by itself. Enter no-www.

No-www is an initiative to make all websites accessible from both the http://www.example.com/ and http://example.com/ forms of their names. The reason behind it is to standardize domain names providing web content and to avoid typing unnecessary letters. — Wikipedia

The reason for using the “www” hostname prefix when entering websites is now a matter of history. It’s old. Deprecated. Outdated. Antiquated. Like websites that only work in Internet Explorer, sites that break when you use the domain alone should be firmly encouraged to join the 21st century. It’s wasteful to type, and it’s cumbersome to pronounce. Consider that it takes nine syllables to properly enunciate three characters.

Some argue that there is still a good reason to separate traffic destined to web servers from that destined to the domain itself. I think this is precisely the idea that’s become obsolete. The reason for that differentiation in the past was that the other protocols were as prolific (or even more prolific) than HTTP at the time. HTTP was just one of many options, so it made no sense to give any type of traffic a preference by pointing the root of a given domain to the system that hosted that content.

Things are different now. HTTP is utterly dominant. Sites interacting with the public on any serious scale does so via a web server, so making this the default is a matter of obvious practicality. This doesn’t mean we should abolish the use of hostnames. Hostnames are excellent tools for separating traffic and making meaningful associations with users. The argument here is simply for having the root point to the web content as a matter of convention.

As for people who include it when speaking, there’s no need to be rude when correcting them. Just kindly inform them that it’s faster if they just go to the domain itself, and that the “www” isn’t needed.

For more information, check out the no-www FAQ, and feel free to fly their sitecon seen above.:

[Edited 07.27.07]

I just finished a short write-up on IMAP IDLE — a system that’s often called an email “push” technology. Here are a couple of excerpts:

IDLE is not — according to my definition above — a true push technology. IDLE actually requires an active connection in order to work, and that connection cannot be initiated by the server.

[Update]: Yahoo! uses P-IMAP, not IDLE to implement “push”…[ Link: An Introduction to IMAP IDLE ]

The Beauty of the Diffie-Hellman Protocol

While listening to an academic debate on Atheism the other day I came across one of the coolest words I’d seen in years: Shibboleth.

Shibboleth is the Hebrew word that literally means “ear of wheat”. In the Hebrew Bible, pronunciation of this word was used to distinguish members of a group whose dialect lacked a “sh” sound from members of a group whose dialect included such a sound. The consequences of getting it wrong were fatal: Today, “shibboleth” refers to words and phrases that can be used in a similar way—to distinguish members of a group from outsiders.

So basically, a Shibboleth is something that you prompt for, and based on the way the response is given you can tell whether the person is part of the secret club or not. The cool part about it is that, at least in the traditional sense, the person being tested was not physically able to say the password correctly.

Very cool stuff.

I’ve just added a brief ICMP primer to my /study area.

> An ICMP Primer 

Many people are familiar with the concept of a mnemonic [nəˈmɑnɪk] — a memory device that uses a phrase based on the first letter of words in a list. Perhaps the most popular of these in the field of networking is the one for the OSI Model. The mnemonic is:

All People Seem To Need Data Processing.

Well, for those that deal with TCP a lot, I thought it might be helpful to have a mnemonic for the TCP flags as well. What I’ve come up with is:

Unskilled Attackers Pester Real Security Folks

Unskilled = URG Attackers = ACK Pester = PSH Real = RST Security = SYN Folks = FIN

The way this helps me the most is when isolating traffic to capture using Tcpdump. It’s possible, for example, to capture only SYNs (new connection requests), only RSTs (immediate session teardowns), or any combination of the six flags really. As noted in my own little Tcpdump tutorial, you can capture these various flags like so:

Find all SYN packets tcpdump 'tcp[13] & 2 != 0′

Find all RST packets tcpdump 'tcp[13] & 4 != 0′

Find all ACK packets tcpdump 'tcp[13] & 16 != 0′

Notice the SYN example has the number 2 in it, the RST the number 4, and the ACK the number 16. These numbers correspond to where the TCP flags fall on the binary scale. So when you write out:

U A P R S F

…that corresponds to:

32 16 8 4 2 1

So as you read the SYN capture tcpdump 'tcp[13] & 2 != 0′, you’re saying find the 13th byte in the TCP header, and only grab packets where the flag in the 2nd bit is not zero. Well if you go from right to left in the UAPRSF string, you see that the spot where 2 falls is where the S is, and that’s how why you’re capturing only SYN packets when you apply that filter.

Remembering these flags and how to isolate them can go a long way in helping low-level network troubleshooting/security work by isolating what it is you want to see and/or capture. And of course the more you can isolate what you want to see, the faster you can solve the problem. I encourage anyone not making use of this powerful feature already to go ahead and add it to their repertoire.

An Illustrated Guide to IPSec

For a customer project, I had to dive into the IPSec protocols at a very low level, and it was a real learning experience for me. I’d been using IPSec to set up network-to-network VPNs for a long time,…

(Source: Steve Friedl)

So as per my previous post on the matter, and the buzz in general, I decided to go ahead and give the official client a whirl. I started using the new service via iChat and Adium last night, but wanted to see how the actual Google client looked and take a peek at how it works.

As you’ve probably heard, the system is based on the Jabber protocol — which is basically a set of standards built on streaming XML. Here are some details if you’re interested.

Anyway, my curiousity is focused around the authentication piece, so I fired up a sniffer and watched myself login. My side first sent an “auth xmlns” that included an X-GOOGLE-TOKEN (I can’t include the actual content since WordPress is eating the XML) which consisted of a very long alphanumeric string. The server then responded with a “success xmlns” response. After that the exchange of information ensued.

One key piece of information here is the fact that Google’s Jabber implementation doesn’t currently support encryption. From their website:

Google Talk currently does not encrypt chats or calls. But we are working hard to make many improvements to Google Talk while it is in beta, and we plan to fully support encryption of chats and calls before our official release.

No big deal — it’s still beta.

Anyway, I have to get back to work but I’ll be looking more into this later…