Existing url shortners will continue to work just fine. We're not
going to resolve them to their final link and remove them from the
chain.

By redirecting all links, we can protect all users and the entire
ecosystem much faster. The adoption via opt-in would be slower, and
might never reach critical mass.

Apps that don't update will continue to work, they will just display
something different than they do now.


On Tue, Jun 8, 2010 at 9:06 PM, Alex B <alex.boswo...@gmail.com> wrote:
> OK, it's a little confusing naming for display URL, as that implies
> that is what clients should show directly to the users, as most of the
> time I would imagine that field should be cut for brevity.
>
> The difference between having a ping service that can help twitter
> track clicks and a redirect service that can help twitter protect
> users, and having twitter simply force-edit everyone's tweet texts, is
> that instead of providing a new service that developers and users can
> opt to use, you are providing a service that everyone _must_ use or
> add code to work around.
>
> You could have simply provided an extension to posting new tweets that
> identified the real urls of shortened urls, that would have protected
> short url providers who invested in your platform and allowed
> developers to add the improvement on their own time frames.
>
> I like the general idea of embedding real links in the twitter
> metadata even if it adds to an already bloated tweet data payload, but
> Twitter isn't respecting its ecosystem here by forcing complexity on
> all developers and giving a time frame of weeks to change established
> code developed over years.
>
> On Jun 9, 11:18 am, Raffi Krikorian <ra...@twitter.com> wrote:
>> > What's the algorithm for the display url? Ideally it will be a
>> > predictable length, to aid predictability in tweet display code.
>>
>> i'm not sure why the display_url would be of predictable length?  the
>> display_url is -exactly- the URL that the user has sent into the system.
>>  so, that may be of varying length.
>>
>> > If the motive is really to protect us from malicious URLs, what about
>> > giving a service we can call to route links through your protective
>> > redirect servers? Then we can give users the option to be protected by
>> > your malicious detection algorithms if they want.
>>
>> If you want to click track every URL for whatever reason, ask client
>>
>> > developers to hit a ping URL if the user clicks? I'm not sure
>> > otherwise how you will tell in a software client if it's the user
>> > requesting the t.co URL or the software.
>>
>> i guess i'm confused on this as well?  isn't that what t.co does?
>>
>>
>>
>>
>>
>> > On Jun 9, 6:57 am, Raffi Krikorian <ra...@twitter.com> wrote:
>> > > hi all.
>>
>> > > twitter has been wrapping links in e-mailed DMs for a couple months
>> > > now<http://bit.ly/twttldmemail>.
>> > > with that feature, we're trying to protect users against phishing and
>> > other
>> > > malicious attacks. the way that we're doing this is that any URL that
>> > comes
>> > > through in a DM gets currently wrapped with a twt.tl URL -- if the URL
>> > turns
>> > > out to be malicious, Twitter can simply shut it down, and whoever follows
>> > > that link will be presented with a page that warns them of potentially
>> > > malicious content. in a few weeks, we're going to start slowly enabling
>> > this
>> > > throughout the API for all statuses as well, but instead of twt.tl, we
>> > will
>> > > be using t.co.
>>
>> > > practically, any tweet that is sent through statuses/update that has a
>> > link
>> > > on it will have the link automatically converted to a t.co link on its
>> > way
>> > > through the Twitter platform. if you fetch any tweet created after this
>> > > change goes live, then its text field will have all its links
>> > automatically
>> > > wrapped with t.co links. when a user clicks on that link, Twitter will
>> > > redirect them to the original URL after first confirming with our
>> > database
>> > > that that URL is not malicious.  on top of the end-user benefit, we hope
>> > to
>> > > eventually provide all developers with aggregate usage data around your
>> > > applications such as the number of clicks people make on URLs you display
>> > > (it will, of course, be in aggregate and not identifiable manner).
>> > > additionally, we want to be able to build services and APIs that can make
>> > > algorithmic recommendations to users based on the content they are
>> > > consuming. gathering the data from t.co will help make these possible.
>>
>> > > our current plan is that no user will see a t.co URL on twitter.com but
>> > we
>> > > still have some details to work through. the links will still be
>> > displayed
>> > > as they were sent in, but the target of the link will be the t.co link
>> > > instead. and, we want to provide the same ability to display original
>> > links
>> > > to developers. we're going to use the entities attribute to make this
>> > > possible.
>>
>> > > let's say i send out the following tweet: "you have to check outhttp://
>> > dev.twitter.com!"
>>
>> > > a returned (and truncated) status object may look like:
>>
>> > > {
>> > >   "text" : "you have to check outhttp://t.co/s9gfk2d4!";,
>> > >   ...
>> > >   "user" : {
>> > >     "screen_name" : "raffi",
>> > >     ...
>> > >   },
>> > >   ...
>> > >   "entities" : {
>> > >     "urls" : [
>> > >       {
>> > >         "url" : "http://t.co/s9gfk2d4";,
>> > >         "display_url" : "http://dev.twitter.com";,
>> > >         "indices" : [23, 43]
>> > >       }
>> > >     ],
>> > >     ...
>> > >   },
>> > >   ...
>>
>> > > }
>>
>> > > two things to note: the text of the returned status object doesn't have
>> > the
>> > > original URL and instead it has a t.co URL, and the entities block now
>> > has a
>> > > 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
>> > thehttp://t.co/s9gfk2d4inthe 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 a
>> > > 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.
>>
>> > > related to this: the way the Twitter API counts characters is going to
>> > > change ever so slightly. our 140 characters is now going to be defined as
>> > > 140 characters after link wrapping. t.co links are of a predictable
>> > length
>> > > -- they will always be 20 characters. after we make this live, it will be
>> > > feasible to send in the text for a status that is greater than 140
>> > > characters. the rule is after the link wrapping, the text transforms to
>> > 140
>> > > characters or fewer. we'll be using the same logic that is in
>> > > twitter-text-rb to figure out what is a URL.
>>
>> > > look for an update to dev.twitter.com where we'll have a best practices
>> > > document on how to use these t.co links.
>>
>> > > what's the timeline?  "soon" we'll enable this on @twitterapi, @rsarver,
>> > > @raffi, and a few other test accounts so you all have live data to play
>> > > with.  on the timescale of weeks (to potentially a month or two), we'll
>> > roll
>> > > this out to everybody.
>>
>> > > of course, if there are any questions, just feel free to direct them to
>> > > @twitterapi!
>>
>> > > --
>> > > Raffi Krikorian
>> > > Twitter Platform Teamhttp://twitter.com/raffi
>>
>> --
>> Raffi Krikorian
>> Twitter Platform Teamhttp://twitter.com/raffi
>

Reply via email to