A Case Against the 'www' Prefix

[SuperNev]

I wrote an article about the 'www' prefix on websites. It's quite lengthy, so I won't quote it on the forum. You can find the article on my blog (nevi.me) here: http://goo.gl/vN31a.

In summary: I talked about why developers should redirect users so that they don't get the 'page not found' error. I also added examples of a few of the major local sites that have the prefix 'issue'.

Please let me know what you think, thanks

 

[bruce_the_loon]

Regarding internet banking, I'd rather my bank not expose unnecessary ports to outside attack just to save someone having to type in one extra character. Presenting the http://xxx even for a redirect will require an exposure of port 80. And before someone reminds me that it doesn't have to be on the same server, that then exposes a second technology to potential breach via vulnerability.

A banking interface is one of a few classes of site where I'd prefer them to make sure their services are secure and working rather than skate the bleeding edge like some forumites suggest when complaining about banks being behind the times because they don't use JSON or Web 2.0.

 

[SuperNev]

Regarding internet banking, I'd rather my bank not expose unnecessary ports to outside attack just to save someone having to type in one extra character. Presenting the http://xxx even for a redirect will require an exposure of port 80. And before someone reminds me that it doesn't have to be on the same server, that then exposes a second technology to potential breach via vulnerability.

This was a bit hard to understand (guess I haven't been around the block much), but I understand what you mean. Thanks for that, it kinda makes sense why one wouldn't do the redirect. I did mention that I was pushing it with the online banking, and I don't think a lot of people would care to remember the direct link without knowing that it only works via SSL/TSL.

A banking interface is one of a few classes of site where I'd prefer them to make sure their services are secure and working rather than skate the bleeding edge like some forumites suggest when complaining about banks being behind the times because they don't use JSON or Web 2.0.

+1

Web 2.0 could be anything really, and from my experience with JSON and other data types, it could very well be that they're already using them, an example being that all the banks (including Capitec and excluding ABSA [at least until their app goes public]) have cellphone apps, which either use JSON, or SOAP for that matter. Yes, from a security stand-point the probablility of someone being a MITM of a JSON call are there.

 

[Other Pineapple Smurf]

Regarding internet banking, I'd rather my bank not expose unnecessary ports to outside attack just to save someone having to type in one extra character. Presenting the http://xxx even for a redirect will require an exposure of port 80. And before someone reminds me that it doesn't have to be on the same server, that then exposes a second technology to potential breach via vulnerability.

A banking interface is one of a few classes of site where I'd prefer them to make sure their services are secure and working rather than skate the bleeding edge like some forumites suggest when complaining about banks being behind the times because they don't use JSON or Web 2.0.

Had to read it twice before I understood what you said. Never thought about it.

 

[MagicDude4Eva]

In SBSA's case, the www##.encrypt.standardbank.co.za are actually nodes within a cluster of servers - you can pick pretty much any number (I think from www2 - www25) to hit an individual node. I guess the bad thing about this is that users will bookmark a node rather than the cluster address.