--
Twitter API documentation and resources: http://apiwiki.twitter.com
API updates via Twitter: http://twitter.com/twitterapi
Change your membership to this group: http://groups.google.com/group/twitter-api-announce?hl=en
On 9/06/10 8:57 AM, Raffi Krikorian wrote:
> "url" : "http://t.co/s9gfk2d4",
> "display_url" : "http://dev.twitter.com",
> "indices" : [23, 43]
Any chance of getting the title of the resolved URL added in here too if
available?
Then we could display a link like :
<a title="Twitter Dev" href="http://t.co/s9gfk2d4">
http://dev.twitter.com
</a>
or :
<a title="http://dev.twitter.com" href="http://t.co/s9gfk2d4">
Twitter Dev
</a>
This would give even more context to users, without having to follow the
redirect path, & load and parse the page to extract it as well.
Thanks,
JB.
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/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.comOr like this:
3) In the above scenario, will the 'display_url' contain 'http://bit.ly/abcd' or 'http://domain.com'?
4) Why redirect all URLs, btw? Why not just redirect the malicious ones?
Thanks!
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)?
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 9/06/10 9:57 AM, Raffi Krikorian wrote:
> that would be an awesome service!
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 :
"Hey check out www.mysite.com/evil_page"
and :
"Hey check out mysite.com/evil_page"
I imagine many clients will currently link these out as urls and link
them up automatically?
Thanks again,
JB.
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_____
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_____
Andy Matsubara
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.
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.
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/0446563048 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
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.b...@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....@gmail.com>
hi all.twitter has been wrapping links in e-mailed DMs for a couple months now. 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:{
"text" : "you have to check out http://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 the http://t.co/s9gfk2d4 in 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 that is in twitter-text-rb to figure out what is a URL.look for an update to dev.twitter.com where we'll have a best practices document on how to use these t.co links.what's the timeline? "soon" we'll enable this on @twitterapi, @rsarver, @raffi, and a few other test accounts so you all have live data to play with. on the timescale of weeks (to potentially a month or two), we'll roll this out to everybody.of course, if there are any questions, just feel free to direct them to @twitterapi!
--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi
> Awesome, thanks for the quick response!
>
> Those are the right answers, too. : )
>
> 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...!)
>
> -DeWitt
Well ... while we're on the subject ... since we're talking *tweets*
and not arbitrary text from just anywhere, why do we have to waste
seven characters with the "http://"? Can't it just be "t.co/abcdef"?
After all, the receiver got the message from Twitter, not from thin
air, and can easily supply the "http://". You're never going to have
an "ftp://t.co", "file://t.co", etc., right?
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 * cka...@floodgap.com
-- We aren't your science project! -- Akane, "Ranma 1/2" (OAV 9) --------------
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
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,
> 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.
> 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? ;-)
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....@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". ;-)
> 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.
Hello,
I'm displaying my own tweets on my own Website. Am I allowed to remove t.co links and send the user directly to the URL I entered?
How will twitter detect if i really use t.co, since there is no Application to download and no public source?
When - exactly - will t.co go live for ALL links posted on Twitter?
Gruß,
Felix Kunsmann - <fe...@kunsmann.eu>
--
Blog: <http://felix-kunsmann.de/>
Galerie: <http://galerie.kunsmann.eu/>
> Not exactly spyware, but deceptive. Don't expect the public to
> appreciate this.
How is this deceptive? Who is being deceived, and how?
> 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....@gmail.com>
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?