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.
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 the http://t.co/s9gfk2d4 in the text with the equivalent of
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!
I'm fine with everything up to the new 140 character count.
If you count the characters *after* link wrapping, you are seriously
going to mess up my system. My short URLs are currently 18 characters
long, and they will be 18 long for quite some time to come. After that
they will be 19 for a very long time to come.
If you implement this change, a ton, and I mean a *huge* number of my
system's updates are going to be rejected for being over 140
characters.
On Jun 8, 7:57 pm, Raffi Krikorian <ra...@twitter.com> wrote:
> 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.
> 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/s9gfk2d4in the text with the equivalent of
> 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!
*1)* Will the redirect from t.co -> domain.com be a 301 Moved Permanently or a 302 Found response?
*2)* Will the t.co URL redirect point to the URL in the original tweet, or will it point to the ultimate resolved URL?
I.e., if I post "Check out my site at http://bit.ly/abcd" where bit.ly/abcdredirects to domain.com, and the resultant tweet becomes "Check out my site at http://t.co/abcd", will the t.co URL redirect like this:
On Tue, Jun 8, 2010 at 3:57 PM, 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 out > http://dev.twitter.com!"
> a returned (and truncated) status object may look like:
> 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 the > http://t.co/s9gfk2d4 in the text with the equivalent of
> 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!
How will this affect links for third party services that clients
handle natively, such as Twitpic (and obviously TwitLonger, which
already has shorter dedicated short urls for its posts)?
I'll also be interested to see how this goes down with the privacy
types who will now be paranoid that Twitter is tracking the sites
they're going to, even if they are going through a third party client.
If I'm clicking a link on a desktop client, should Twitter really be
getting that information?
What about links through bit.ly etc? Will I still be able to see the
analytics that they provide for my links? If so, does that mean there
will be at least two levels of redirection from the ultimate
destination?
On Jun 8, 11:57 pm, Raffi Krikorian <ra...@twitter.com> wrote:
> 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.
> 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/s9gfk2d4in the text with the equivalent of
> 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!
> I'm fine with everything up to the new 140 character count.
> If you count the characters *after* link wrapping, you are seriously
> going to mess up my system. My short URLs are currently 18 characters
> long, and they will be 18 long for quite some time to come. After that
> they will be 19 for a very long time to come.
> If you implement this change, a ton, and I mean a *huge* number of my
> system's updates are going to be rejected for being over 140
> characters.
> On Jun 8, 7:57 pm, 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:
> > 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
> > 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!
> *1)* Will the redirect from t.co -> domain.com be a 301 Moved Permanently > or a 302 Found response?
301!
> *2)* Will the t.co URL redirect point to the URL in the original tweet, or > will it point to the ultimate resolved URL?
> I.e., if I post "Check out my site at http://bit.ly/abcd" where > bit.ly/abcd redirects to domain.com, and the resultant tweet becomes > "Check out my site at http://t.co/abcd", will the t.co URL redirect like > this:
> a) t.co/abcd -> domain.com
> Or like this:
> b) t.co/abcd -> bit.ly/abcd -> domain.com
we're not modifying or tampering with URLs - if you send us a bit.ly link, we will wrap that bit.ly link. analytics will still work, etc.
> *4)* Why redirect all URLs, btw? Why not just redirect the malicious > ones?
in the case of malicious URLs, you sometimes don't know it at the time of tweet creation. or the URL may eventually become malicious. this allows us to do shutdown after tweet creation.
> On Tue, Jun 8, 2010 at 3:57 PM, 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 out >> http://dev.twitter.com!"
>> a returned (and truncated) status object may look like:
>> 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 the http://t.co/s9gfk2d4 in the text with the equivalent of
>> 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!
> How will this affect links for third party services that clients > handle natively, such as Twitpic (and obviously TwitLonger, which > already has shorter dedicated short urls for its posts)?
that's why we are providing all the data back out in the API. while the tweet itself may have t.co, we do include, in the entities, the original URL. our hope, honestly, is that final users never have to see t.co -- we want to provide enough data back to developers so they can create URLs that look like
> What about links through bit.ly etc? Will I still be able to see the > analytics that they provide for my links? If so, does that mean there > will be at least two levels of redirection from the ultimate > destination?
yes - we won't be touching the original URL. all analytics that users want to see on bit.ly will still be there. this is what we do on URLs in DMs right now.
> On Jun 8, 11:57 pm, 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:
> > 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/s9gfk2d4in the text with the equivalent of
> > 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!
On Tue, Jun 8, 2010 at 4:53 PM, Dewald Pretorius <dpr...@gmail.com> wrote: > This is not unique to me. This will be problematic for anyone who uses > a shortening service that shortens URLs to less than 20 characters.
> In these cases, you are basically adding characters to the submitted > text, and then rejecting the submitted text as being too long.
> On Jun 8, 8:33 pm, Dewald Pretorius <dpr...@gmail.com> wrote: > > Raffi,
> > I'm fine with everything up to the new 140 character count.
> > If you count the characters *after* link wrapping, you are seriously > > going to mess up my system. My short URLs are currently 18 characters > > long, and they will be 18 long for quite some time to come. After that > > they will be 19 for a very long time to come.
> > If you implement this change, a ton, and I mean a *huge* number of my > > system's updates are going to be rejected for being over 140 > > characters.
> > On Jun 8, 7:57 pm, 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.combut 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:
> > > 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
> > > 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!
So what are you saying? Suck it up? That's what I am hearing.
I have a work-around for the problem, in that I can simply adjust my
in-house shortening service to start generating 19-character URLs. But
other developers don't have that option.
On Jun 8, 8:58 pm, Raffi Krikorian <ra...@twitter.com> wrote:
> just to correct my previous post, however -- t.co links are 19 characters.
> On Tue, Jun 8, 2010 at 4:53 PM, Dewald Pretorius <dpr...@gmail.com> wrote:
> > This is not unique to me. This will be problematic for anyone who uses
> > a shortening service that shortens URLs to less than 20 characters.
> > In these cases, you are basically adding characters to the submitted
> > text, and then rejecting the submitted text as being too long.
> > On Jun 8, 8:33 pm, Dewald Pretorius <dpr...@gmail.com> wrote:
> > > Raffi,
> > > I'm fine with everything up to the new 140 character count.
> > > If you count the characters *after* link wrapping, you are seriously
> > > going to mess up my system. My short URLs are currently 18 characters
> > > long, and they will be 18 long for quite some time to come. After that
> > > they will be 19 for a very long time to come.
> > > If you implement this change, a ton, and I mean a *huge* number of my
> > > system's updates are going to be rejected for being over 140
> > > characters.
> > > On Jun 8, 7:57 pm, 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.combut 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:
> > > > 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/s9gfk2d4inthetext with the equivalent of
> > > > 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!
On Tue, Jun 8, 2010 at 4:33 PM, Dewald Pretorius <dpr...@gmail.com> wrote: > Raffi,
> I'm fine with everything up to the new 140 character count.
> If you count the characters *after* link wrapping, you are seriously > going to mess up my system. My short URLs are currently 18 characters > long, and they will be 18 long for quite some time to come. After that > they will be 19 for a very long time to come.
> If you implement this change, a ton, and I mean a *huge* number of my > system's updates are going to be rejected for being over 140 > characters.
> On Jun 8, 7:57 pm, 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:
> > 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/s9gfk2d4in the text with the equivalent of
> > 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!
Though there's an inconsistency with returning 301's and also requiring every click to go through the t.co link (as required by the ToS). A 301 means that the redirect is cacheable by any intermediary (because it is permanent and will never change).
The 301 also implies that you actually *can* replace only the malicious links, (not every link), because clients will already have resolved and cached the 301 redirects (which again, can never change), so you won't be able to change the redirect down the road anyway.
So, I think you might actually have meant to use 302's, not 301's, if redirecting every click is the goal.
But then again, 301's really are the (philosophically? morally?) right answer, so maybe I *don't* want you to fix that. : )
Or better still, resolving *all* URLs upfront and returning the full URL inline, making tweets longer than 140 characters, and stopping this whole URL shortening nonsense to begin with. (But you knew I'd say that...!)
On Tue, Jun 8, 2010 at 4:54 PM, Raffi Krikorian <ra...@twitter.com> wrote: > *1)* Will the redirect from t.co -> domain.com be a 301 Moved Permanently >> or a 302 Found response?
> 301!
>> *2)* Will the t.co URL redirect point to the URL in the original tweet, >> or will it point to the ultimate resolved URL?
>> I.e., if I post "Check out my site at http://bit.ly/abcd" where >> bit.ly/abcd redirects to domain.com, and the resultant tweet becomes >> "Check out my site at http://t.co/abcd", will the t.co URL redirect like >> this:
>> a) t.co/abcd -> domain.com
>> Or like this:
>> b) t.co/abcd -> bit.ly/abcd -> domain.com
> we're not modifying or tampering with URLs - if you send us a bit.ly link, > we will wrap that bit.ly link. analytics will still work, etc.
>> *4)* Why redirect all URLs, btw? Why not just redirect the malicious >> ones?
> in the case of malicious URLs, you sometimes don't know it at the time of > tweet creation. or the URL may eventually become malicious. this allows us > to do shutdown after tweet creation.
>> Thanks!
> that's what i'm here for :P
>> -DeWitt
>> On Tue, Jun 8, 2010 at 3:57 PM, 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 out >>> http://dev.twitter.com!"
>>> a returned (and truncated) status object may look like:
>>> 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 the http://t.co/s9gfk2d4 in the text with the equivalent of
>>> 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: Never mind. I just saw the Twitter blog post. The motivation
for this is to get metrics for Promoted Tweets and Resonance. Hence,
the answer is: Suck it up.
DeWitt: Yikes, discarding all shortens between t.co and the final link
will seriously mess with the click stats of a few million people.
Currently we use one our own services (http://metauri.com/) to do this for http://trendsmap.com/. In addition to the title, it also gives the content type, which can be useful in determining how, or if to use the link in your display.
I was just wondering if Twitter were going to possibly supply this extra data, as it would remove a time & resource intensive step in the tweet analysis process :).
Another question, will you wrap links that have no protocol in tweets, eg :
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 one.
Sincerely,
Brian Smith
@BRIAN_____
> 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
> 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.
> On Tue, Jun 8, 2010 at 4:33 PM, Dewald Pretorius <dpr...@gmail.com> wrote:
> > Raffi,
> > I'm fine with everything up to the new 140 character count.
> > If you count the characters *after* link wrapping, you are seriously
> > going to mess up my system. My short URLs are currently 18 characters
> > long, and they will be 18 long for quite some time to come. After that
> > they will be 19 for a very long time to come.
> > If you implement this change, a ton, and I mean a *huge* number of my
> > system's updates are going to be rejected for being over 140
> > characters.
> > On Jun 8, 7:57 pm, 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:
> > > 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
> > > 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!
I don't see how this feature could impact user privacy more than what
it is right now. Today Twitter stores all links for all users and they
can spy on them and the t.co shortner is not changing that :)
My question is, will developers have access to analytics from t.co
through API?
What's the algorithm for the display url? Ideally it will be a
predictable length, to aid predictability in tweet display code.
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.
On Jun 9, 6:57 am, Raffi Krikorian <ra...@twitter.com> wrote:
> 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.
> 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/s9gfk2d4in the text with the equivalent of
> 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!
Sami wrote: > I don't see how this feature could impact user privacy more than what it is right > now. Today Twitter stores all links for all users and they can spy on them and the > t.co shortner is not changing that :)
Right now, Twitter can see all the links that users *post*, but they don't see which links users *click*.
In order to implement this feature, Twitter has already built the framework that does all the hard work that applications need to protect users' privacy against (link-shortener) click-tracking. Twitter will be withholding that final URL from applications, preventing us (through the ToS) from implementing our own anti-click-tracking privacy measures. If, instead, they gave the final URL to the application and let the application use that URL, then applications could implement anti-click-tracking privacy measures with an even greater degree of privacy than they could by using a third-party service.
In other words, instead of Twitter using their existing link-unshortening technology to let applications tell *fewer* companies what links your users are clicking on, they are using it to force applications to tell *more* companies what your users are clicking on.
Only advertisers could build a privacy-improving technology and using it for the exact opposite purpose. :(
On Tue, Jun 8, 2010 at 7:14 PM, Sami <sami.ben.romdh...@gmail.com> wrote: > I don't see how this feature could impact user privacy more than what > it is right now. Today Twitter stores all links for all users and they > can spy on them and the t.co shortner is not changing that :)
> My question is, will developers have access to analytics from t.co > through API?
Raffi wrote: > 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.
I guess this change will make frontend text handling more difficult. Counting characters in a text box must figure out what is a URL. I hope Twitter will publish JavaScript library for realtime character counts. I also want APIs to make shortened URL.
> 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:
> > 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/s9gfk2d4in the text with the equivalent of
> > 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!
> Right now, Twitter can see all the links that users *post*, but they don't > see which links users *click*.
> In order to implement this feature, Twitter has already built the framework > that does all the hard work that applications need to protect users' > privacy > against (link-shortener) click-tracking. Twitter will be withholding that > final URL from applications, preventing us (through the ToS) from > implementing our own anti-click-tracking privacy measures. If, instead, > they > gave the final URL to the application and let the application use that URL, > then applications could implement anti-click-tracking privacy measures with > an even greater degree of privacy than they could by using a third-party > service.
hey brian - just wanted to point out - the "Twitter will be withholding that final URL from applications" is NOT true at all. we are providing, as part of the "entities" the original URL back to the developers. stated another way - we are giving all the data back and we are not withholding the data.
yeah - its definitely case that counting characters will become a bit more subtle. i hope that we can provide a really good and easy way to help you all out. at the very least we are going to update documentation, but i know we can do better than that.
On Tue, Jun 8, 2010 at 8:17 PM, Andy Matsubara <andymatsub...@gmail.com>wrote:
> Raffi wrote: > > 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. > I guess this change will make frontend text handling more difficult. > Counting characters in a text box must figure out what is a URL. I > hope Twitter will publish JavaScript library for realtime character > counts. I also want APIs to make shortened URL.
