Re: [twitter-dev] Re: link wrapping on the API
But if apps don't update and user sends a tweet which is just below 140 characters say, 139, and which contain a link(s) shorter than 19 (or is it 20) characters will mysteriously fail. The user will wonder why the app doesn't let them send the tweet when their app clearly says it's still within 140 characters, because Twitter is now counting the longer 19/20 character t.co link. Is this considered a rare scenario? I wouldn't consider this a rare scenario; in fact, I think this might be common with some clients. The proper way to solve this is to offer a shortener API that a front end can talk to. *cough* -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- We aren't your science project! -- Akane, Ranma 1/2 (OAV 9) --
RE: [twitter-dev] Re: link wrapping on the API
Dewald Pretorius wrote: StatusNet, blog, etc.). If the privacy argument carried any water, then bit.ly would be a far greater privacy threat than Twitter. I agree, and that's why I (and others) were working on solutions to get around bit.ly and other link shorteners. And, Twitter has already developed the ultimate solution to that privacy issue, but they just are refusing to let API developers use it. That is what is so incredibly frustrating. Regards, Brian
Re: [twitter-dev] Re: link wrapping on the API
On Wed, Jun 9, 2010 at 6:48 PM, Dewald Pretorius dpr...@gmail.com wrote: I don't buy the click tracking privacy argument. Twitter will have no more insight into clicks than what bit.ly or any other shortening service has, The difference being that the user who clicks the links in Twitter will have most probably logged into Twitter. Thus, Twitter can directly associate a click with a user. When clicking on bit.ly shortened URLs it is very very unlikely that the user is logged into bit.ly. That is because only people who shorten URLs need a bit.ly account (which is a very small percentage). -- Harshad RJ http://hrj.wikidot.com
Re: [twitter-dev] Re: link wrapping on the API
-totally- the timeline on this is, i think (and i'll check to be sure), sometime like 6-8 weeks. On Wed, Jun 9, 2010 at 1:45 AM, Rich rhyl...@gmail.com wrote: Please make sure the timeline for this is LONGER than 2 weeks please, some of us have to code this and then wait at least a week to get through Apple's approval system. This is especially important when it comes to detecting images, etc. Richard On Jun 9, 4:27 am, Raffi Krikorian ra...@twitter.com wrote: 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. Andy Matsubara -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: link wrapping on the API
Quoting Ron B rbtheron...@gmail.com: Users are accustomed to the fact that use of *free* services is entirely *as is* and at their own risk, so none of us should feel we have to protect their privacy or their security beyond this original expectation. If they don't like the performance, security, or privacy implications of this change, they'll leave Twitter, just like they left Facebook. Ah, but they *aren't* leaving Facebook! They're continuing to join and share. Facebook and its hundreds of millions of users are continuing to co-evolve. And *when* - not *if* - the FUD brigade realizes it can't take Facebook out, it will turn its energies on Twitter. I hope as a community / ecosystem / whatever, we're ready for that. But that is ultimately Twitter's responsibility to control and react to. Our responsibility is to keep rowing collectively in the same direction, or get off the boat. :) Well, to the extent that it's possible, sure. But groupthink can kill a product / service too. There are clearly some *technical* rough edges on link wrapping that need to be discussed / debated.
Re: [twitter-dev] Re: link wrapping on the API
Quoting Ron B rbtheron...@gmail.com: I just had one of those *rough edges* brought to my attention that I think may also have already been alluded to on this thread. Some users use long URLs as a portion or even their entire tweet. This tweet technique is being used significantly in tweets about the Gulf oil spill crisis, for example. (i.e. http://www.grist.org/aritcle/2010-06-08-does-obama-need-more-not-fewer-oilmen-in-his-administration). The author of such a tweet fully expects that this message will be conveyed in the tweet itself, by virtue of the message conveyed by the long URL - not just the URL destination's content. It doesn't sound like this interesting and useful melding of tweet text and tweet attachments will be possible any longer after the t.co wrapper initiative is implemented. That would be a real shame... That particular example looks like a blatant search engine optimization ploy and not the human-to-human communication that is, IIRC, the Spirit of Twitter. ;-) Bonus points for correcting the spelling of article in the link? ;-)
Re: [twitter-dev] Re: link wrapping on the API
On Wed, 09 Jun 2010 12:22:03 -0700 M. Edward (Ed) Borasky zn...@borasky-research.net wrote: Quoting Ron B rbtheron...@gmail.com: I just had one of those *rough edges* brought to my attention that I think may also have already been alluded to on this thread. Some users use long URLs as a portion or even their entire tweet. This tweet technique is being used significantly in tweets about the Gulf oil spill crisis, for example. (i.e. http://www.grist.org/aritcle/2010-06-08-does-obama-need-more-not-fewer-oilmen-in-his-administration). The author of such a tweet fully expects that this message will be conveyed in the tweet itself, by virtue of the message conveyed by the long URL - not just the URL destination's content. It doesn't sound like this interesting and useful melding of tweet text and tweet attachments will be possible any longer after the t.co wrapper initiative is implemented. That would be a real shame... That particular example looks like a blatant search engine optimization ploy and not the human-to-human communication that is, IIRC, the Spirit of Twitter. ;-) Really now, what is wrong with a person expressing themselves by making human readable links? If an application wants to provide the original intent of the user, it is forced (by ToS), to present a link that doesn't go to where it says it does. That is problematic, the application acts as spyware. -- Bernd Stramm bernd.str...@gmail.com
Re: [twitter-dev] Re: link wrapping on the API
Quoting Bernd Stramm bernd.str...@gmail.com: On Wed, 09 Jun 2010 12:22:03 -0700 M. Edward (Ed) Borasky zn...@borasky-research.net wrote: Quoting Ron B rbtheron...@gmail.com: I just had one of those *rough edges* brought to my attention that I think may also have already been alluded to on this thread. Some users use long URLs as a portion or even their entire tweet. This tweet technique is being used significantly in tweets about the Gulf oil spill crisis, for example. (i.e. http://www.grist.org/aritcle/2010-06-08-does-obama-need-more-not-fewer-oilmen-in-his-administration). The author of such a tweet fully expects that this message will be conveyed in the tweet itself, by virtue of the message conveyed by the long URL - not just the URL destination's content. It doesn't sound like this interesting and useful melding of tweet text and tweet attachments will be possible any longer after the t.co wrapper initiative is implemented. That would be a real shame... That particular example looks like a blatant search engine optimization ploy and not the human-to-human communication that is, IIRC, the Spirit of Twitter. ;-) Really now, what is wrong with a person expressing themselves by making human readable links? If an application wants to provide the original intent of the user, it is forced (by ToS), to present a link that doesn't go to where it says it does. That is problematic, the application acts as spyware. -- Bernd Stramm bernd.str...@gmail.com I make my WordPress blog posts SEO-friendly by having the URLs constructed from the title via the WordPress setting that does that. And I use a sitemap plugin and a few other gizmos to alert the crawlers when I make a post. But I *tweet* links to the posts via bit.ly with the title text, or maybe a quotation from the post. When Twitter's link shortener is activated *and* I can get Twitter analytics, I'll use Twitter's link shortener for links in tweets and kick bit.ly to the curb. Hell, if the price is right, I'll get a Twitter commercial account. ;-)
Re: [twitter-dev] Re: link wrapping on the API
Quoting Ken k...@cimas.ch: Not exactly spyware, but deceptive. Don't expect the public to appreciate this. How is this deceptive? Who is being deceived, and how? On Jun 9, 9:45 pm, Bernd Stramm bernd.str...@gmail.com wrote: If an application wants to provide the original intent of the user, it is forced (by ToS), to present a link that doesn't go to where it says it does. That is problematic, the application acts as spyware. -- Bernd Stramm bernd.str...@gmail.com
Re: [twitter-dev] Re: link wrapping on the API
On Wed, 09 Jun 2010 17:13:04 -0700 M. Edward (Ed) Borasky zn...@borasky-research.net wrote: Quoting Ken k...@cimas.ch: Not exactly spyware, but deceptive. Don't expect the public to appreciate this. How is this deceptive? Who is being deceived, and how? How? There is text that is marked as a link, for example http://nasa.gov;, and it does not go to nasa.gov. If a user clicks on the link saying nasa.gov, it goes to t.co, which does business with a third party, not telling the user anything about it. How is that *not* deceptive? On Jun 9, 9:45 pm, Bernd Stramm bernd.str...@gmail.com wrote: If an application wants to provide the original intent of the user, it is forced (by ToS), to present a link that doesn't go to where it says it does. That is problematic, the application acts as spyware. -- Bernd Stramm bernd.str...@gmail.com -- Bernd Stramm bernd.str...@gmail.com
Re: [twitter-dev] Re: link wrapping on the API
On 6/9/2010 7:00 PM, Bernd Stramm wrote: On Wed, 09 Jun 2010 17:13:04 -0700 M. Edward (Ed) Boraskyzn...@borasky-research.net wrote: Quoting Kenk...@cimas.ch: Not exactly spyware, but deceptive. Don't expect the public to appreciate this. How is this deceptive? Who is being deceived, and how? How? There is text that is marked as a link, for example http://nasa.gov;, and it does not go to nasa.gov. If a user clicks on the link saying nasa.gov, it goes to t.co, which does business with a third party, not telling the user anything about it. How is that *not* deceptive? As long as the terms are clearly laid out and Twitter is open about where the user is being sent I see no problem with it in terms of openness. However, what I am wondering is why Twitter would feel the need to wrap other URL shorteners. Won't that increase the time needed to get to the final destination?
Re: [twitter-dev] Re: link wrapping on the API
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
a href=http://t.co/blahblah;http://mycoolsite.com/a
all those URLs should still show through.
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
nowhttp://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/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 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
Re: [twitter-dev] Re: link wrapping on the API
its true, and we understand that.
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
nowhttp://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:
{
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
Re: [twitter-dev] Re: link wrapping on the API
Will we be able to get matches on the original URL through the streaming
API?
For example, I'm tracking act so I can match tweets that link to '
http://act.ly'. Will I still be able to do that?
Jim Gilliam
http://act.ly/
http://twitter.com/jgilliam
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
nowhttp://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/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 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
RE: [twitter-dev] Re: link wrapping on the API
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 the 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 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.
RE: [twitter-dev] Re: link wrapping on the API
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. :( http://mashable.com/2010/06/03/alex-payne-twitter-interview/ Regards, Brian Smith @BRIAN_
Re: [twitter-dev] Re: link wrapping on the API
our hope is to eventually provide this analytics. 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? Thanks -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: link wrapping on the 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. Andy Matsubara
Re: [twitter-dev] Re: link wrapping on the API
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
nowhttp://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/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 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
Re: [twitter-dev] Re: link wrapping on the API
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. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: link wrapping on the API
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.comwrote: 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. Andy Matsubara -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
RE: [twitter-dev] Re: link wrapping on the API
I was basing my statement on the blog post, which indicated that at least some display URLs will be truncated: http://blog.twitter.com/2010/06/links-and-twitter-length-shouldnt.html A really long link such as http://www.amazon.com/Delivering-Happiness-Profits-Passion-Purpose/dp/044656 3048 might be wrapped as http://t.co/DRo0trj for display on SMS, but it could be displayed to web or application users as amazon.com/Delivering-. Will the application be doing the truncation from the full URL to the truncated one (amazon.com/Delivering-), or will the API? And, if the application really will get the full destination URL, then it is even more ridiculous to prevent them (through the ToS) from using it to improve the user's privacy, don't you think? Regards, Brian 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. -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: link wrapping on the API
All links will be wrapped. It's not about length.
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
nowhttp://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
Re: [twitter-dev] Re: link wrapping on the API
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
nowhttp://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 : {
Re: [twitter-dev] Re: link wrapping on the API
On Tue, 8 Jun 2010 22:19:04 -0700 (PDT) Hwee-Boon Yar hweeb...@gmail.com wrote: But if apps don't update and user sends a tweet which is just below 140 characters say, 139, and which contain a link(s) shorter than 19 (or is it 20) characters will mysteriously fail. The user will wonder why the app doesn't let them send the tweet when their app clearly says it's still within 140 characters, because Twitter is now counting the longer 19/20 character t.co link. Is this considered a rare scenario? The right way to do this for twitter would be to count the characters submitted to the API, before twitter changes the content. That way, the API acceptance of a well formed post is predictable. Otherwise it's not, since an application really doesn't know what twitter will do with the content. -- Hwee-Boon On Jun 9, 12:18 pm, John Kalucki j...@twitter.com wrote: Apps that don't update will continue to work, they will just display something different than they do now. -- Bernd Stramm bernd.str...@gmail.com
