If you do this, you will literally be forcing app developers to waste users
time and money, especially over metered GRPS/3G connections.
If the user can see the full URL, then why do they need to be "protected"
any more than they are when they use any other service? If anything, you
should be cutting through any and all redirects (shorteners) so that the
application can show the final URL to the user and avoid multiple useless,
latency-inducing redirects that reduce reliability and increase costs for
end-users and network operators. Cutting through all the redirects would
improve security AND improve on the users' privacy, instead of hurting it.
And, what about the user's right to privacy? You're basically forcing every
Twitter app to become spyware. Who wants to create spyware? No developers
with a conscience-and I'm sure that includes you guys at Twitter. Please ask
whoever's making these horrible decisions lately to reconsider at least this
> two things to note: the text of the returned status object doesn't have
> original URL and instead it has a t.co URL, and the entities block now has
> display_url attribute associated with it. what we're hoping is that with
> this data, it should be relatively easy to create a UI where you replace
> http://t.co/s9gfk2d4in the text with the equivalent of
> <a href="http://t.co/s9gfk2d4">http://dev.twitter.com</a>
> this means the user would not see the t.co link, but we all can still
> provide the protection and gather data from the wrapped link. for the
> applications that don't choose to update, the t.co link will be shown (and
> the goal to protect users will be met). i just want to emphasize -- we
> really do hope that you all render the original URL, but please send the
> user through the t.co link. if you do choose to prefetch all the URLs on
> timeline, then, when a user actually clicks on one of the links, please
> still send him or her through t.co. We will be updating the TOS to require
> you to check t.co and register the click.