"I've previously asked for guidelines on what our responsibilities are
in terms of self-policing.  No answer."

Add to that the clear and unambiguous definition of things. Yeah sure,
"Twitter cannot clearly define things because that will aid the
spammers." Bullshit. It is their responsibility to define what exactly
is acceptable to them. That will not assist the spammers. It will
assist us to not inadvertently, through wrong interpretation or
assumption, provide a platform that spammers can leverage.

Up until the first email I received from Twitter on October 8th, I was
monitoring the level of duplicate tweet rejection that the API was
giving, and I consequently concluded that the users of my service was
not producing a large amount of duplicate tweets. Seems like their
internal definition of duplicate content is far wider than the
interpretation of the Platform Team when they wrote the code to reject
duplicate tweets.

I still do not know exactly what is "duplicate content" and what is
not. Do you? I guess not. Nobody knows.


On Oct 13, 11:07 pm, PJB <pjbmancun...@gmail.com> wrote:
> Chad:
> Sorry, I didn't see you had posted in here, and not sure if my
> subsequent posts properly answered you.
> I mean that Desktop apps, not being bound by a whitelisted IP,
> wouldn't be limited by restrictions limiting API access to OAUTH
> only.  Namely, a desktop client could use a Mozilla user-agent, scrape
> Twitter.com, grab an "authenticity_token", and then do a simple HTTP
> form submission with plaintext username/password.  From there, the
> client could do whatever "outlawed" actions aren't possible from Web
> apps.
> While you could presumably find some commonalities with these logins
> for a time, probably the only effective way to counter this approach
> is to introduce login captchas.  And that's an ugly barrier to entry
> for the average user.
> Restricting Web-based apps will presumably shift the policed behavior
> to such desktop apps, where it would probably morph into something
> even more destructive.
> As a web-based developer, I've previously asked for guidelines on what
> our responsibilities are in terms of self-policing.  No answer.  And
> it's really disheartening to hear that carte blanche limitations are
> now being imposed.
> There are obvious legitimate uses for recurring dynamic tweets (e.g.,
> NBC announcing show schedules/guests, or fitness apps tweeting how
> many miles you ran).  Blocking such behavior across the board seems
> incredibly short-sighted and limits further important business-
> oriented development in this area.
> PB
> On Oct 13, 12:47 pm, Chad Etzel <c...@twitter.com> wrote:
> > On Tue, Oct 13, 2009 at 3:38 PM, PJB <pjbmancun...@gmail.com> wrote:
> > > Wrong.  Basic Authentication will obviously ALWAYS be an option for
> > > desktop clients, regardless of whether or not it is via API.
> > Please explain this statement?
> > -Chad
> > >> Furthermore, the app in question explicitly offered the option of a
> > >> recurring tweet which is a violation of the TOS. Regardless of whether or
> > >> not that provides a useful service -- I'm not going to start debating 
> > >> that
> > >> -- the fact of the matter is it *is* a violation of the TOS. Plain and
> > >> simple. Why shouldn't they be "allowed" (as if we have a say what a 
> > >> private
> > >> company does with their own resources) to ban an app that violates the 
> > >> TOS
> > >> with one of their own options?
> > > I see, so then sites like mapmyrun and others that, for example, tweet
> > > "Bob ran 10 miles today in 2 hours", "Bob ran 12 miles today in 1
> > > hour", and other templated text, are also in violation of the terms?
> > > Or what about hootsuite where I can queue up 100 tweets with the exact
> > > same text to fire off every hour, perhaps interspersed with a second
> > > tweet?
> > > The bottom line is that this situation isn't as black and white as you
> > > think, and Twitter's approach is wrong-headed.

Reply via email to