"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. Dewald On Oct 13, 11:07 pm, PJB <[email protected]> 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 <[email protected]> wrote: > > > On Tue, Oct 13, 2009 at 3:38 PM, PJB <[email protected]> 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.
