There's no need to risk a Rick Roll: http://bit.ly/info/1628nB - and most Twitter clients can preview shortened URLs.
Point still taken though.
sull
· 4 months ago
this goes back to domains 101. get a short one word domain if you can. now that we have more vanity tld options, it's like an opportunistic reboot.
a short url is a good thing. in fact, it's better to use keywords instead of useless hash ids even if you end up with longer urls.
tinyurl was popular before twitter because many websites, including mainstream news, jammed in as many url parameters as they could to make their bloated convoluted website backend work properly. you could experiment and remove pieces of a url and see if it still landed on the page you wanted to share but who is going to bother? and often the url would break. so shorterning a url even for an email message (where sometimes long urls would wrap and break apart) or in a forum post etc was preferable.
enter twitter and the micro-messaging phenomena and a new army of url shorteners. bit.ly so far declared as king.
and in these times, their is a greater risk due to the security vulnerabilities of masking urls now that a new and easily accessible massive medium for proliferating evil links is laid out like a red carpet for all the script kiddies to piss on.
with this, their are two main points of focus. one is the current lack of preventative tech deployed by the most popular/successful url shorteners - most notably, BIT.LY. if they want the crown, they need to get on the ball and scan and clean every url that goes through their little engine. we need a safe.ly proxy. and that is a task that is probably just as hard if nto harder than email spam handling/prevention. a business that i would not want to be in, personally.... but with their success comes this kind of demand.... real-time url store/scan/clean/release.
the other focus is entirely the opposite. the total removal of the need to have url shorteners to preserve characters in short messages that need to be less than ~160 chars long. this is done by FIXING the platforms that do not allow for additional metadata to be associated with a message. metadata such as a URL. think RSS. once the actual long url can be included outside of the micro-message but made accessible as metadata and exposed in any UI that supports the parsing of such metadata, then their is really no need to shorten a url. some might still prefer to shorten a url but their is no motivating factor left.
your points, andrew, are right on as well. especially the fact about stats and raw logs etc.
All Comments
Point still taken though.
now that we have more vanity tld options, it's like an opportunistic reboot.
a short url is a good thing. in fact, it's better to use keywords instead of useless hash ids even if you end up with longer urls.
tinyurl was popular before twitter because many websites, including mainstream news, jammed in as many url parameters as they could to make their bloated convoluted website backend work properly. you could experiment and remove pieces of a url and see if it still landed on the page you wanted to share but who is going to bother? and often the url would break. so shorterning a url even for an email message (where sometimes long urls would wrap and break apart) or in a forum post etc was preferable.
enter twitter and the micro-messaging phenomena and a new army of url shorteners. bit.ly so far declared as king.
and in these times, their is a greater risk due to the security vulnerabilities of masking urls now that a new and easily accessible massive medium for proliferating evil links is laid out like a red carpet for all the script kiddies to piss on.
with this, their are two main points of focus. one is the current lack of preventative tech deployed by the most popular/successful url shorteners - most notably, BIT.LY.
if they want the crown, they need to get on the ball and scan and clean every url that goes through their little engine. we need a safe.ly proxy. and that is a task that is probably just as hard if nto harder than email spam handling/prevention. a business that i would not want to be in, personally.... but with their success comes this kind of demand.... real-time url store/scan/clean/release.
the other focus is entirely the opposite. the total removal of the need to have url shorteners to preserve characters in short messages that need to be less than ~160 chars long. this is done by FIXING the platforms that do not allow for additional metadata to be associated with a message. metadata such as a URL. think RSS. once the actual long url can be included outside of the micro-message but made accessible as metadata and exposed in any UI that supports the parsing of such metadata, then their is really no need to shorten a url. some might still prefer to shorten a url but their is no motivating factor left.
your points, andrew, are right on as well. especially the fact about stats and raw logs etc.