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
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
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
-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
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,
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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)
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
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
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
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
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
25 matches
Mail list logo
