The API TOS is currently in development. It is taking longer than hoped as
we are still exploring what we want to give to developers and what we want
to protect as business assets. For now, make sure that you understand the
general TOS we have in place.
We do work with developers if they are willing to answer our attempts to
reach out before shutting them off due to TOS violations. We also try to
understand what developers are doing and how they may be heading against the
grain before issuing whitelisting. Most developers are willing to work with
us which is great and works out for everyone.

Thanks,
Doug



On Tue, Jun 9, 2009 at 6:26 PM, Jesse Stay <jesses...@gmail.com> wrote:

> Doug, where is the developer API TOS?  I think that's part of the problem -
> none of us are being required to enter into an agreement before
> developing, therefore we have no idea what we can and can't do with it.  I
> also don't think most of us even know where any such TOS is, if there is
> one.  I agree that the OAuth application process should make this a bit 
> easier to manage,
> and help developers know more about what they are getting into before
> starting their applications.
> Personally, I want to make sure I'm following the rules of the
> API.  I'd also prefer to know what I'm agreeing to before starting a business 
> on top of it.
>  I feel for the developers of the 2 mentioned apps because, *if* they are
> violating any TOS, they probably had no idea they were doing so before
> spending so much time developing it. (even if I disagree with the premise of
> those apps)
>
> @Jesse
>
>
> On Tue, Jun 9, 2009 at 5:31 PM, Doug Williams <d...@twitter.com> wrote:
>
>> Brant,Thank you for your concern. This is something that bothers us as
>> well.
>>
>> Moving applications exclusively to OAuth-based authentication will
>> certainly help in restricting applications that abuse the service. If you
>> find a service that you think is violating our TOS, please email
>> a...@twitter.com or send a message to @twitterapi and we can take a look.
>> As you mentioned, Del is great but she is but one person. We do have an
>> abuse team forming to help quickly identify which services are violating our
>> TOS. All in all we have a lot of work to do so please do help where you can.
>>
>> Cheers,
>> Doug
>>
>>
>> On Tue, Jun 9, 2009 at 2:43 PM, Brant <btedes...@gmail.com> wrote:
>>
>>>
>>> This message will hopefully get back to the people who run Twitter API
>>> development and spam prevention.
>>>
>>> I noticed there are quite a few twitter applications that are
>>> developed to abuse the service and violate their TOS.  They do not
>>> hide what their purpose is, yet these applications remain active.  I
>>> contacted twitter.com/delbius who heads Twitter Spam prevention and
>>> she said that they do revoke API access to abusive applications.  But
>>> I don't think they are taking an aggressive stance against them.
>>>
>>> Abusive Applications:
>>> http://www.huitter.com/mutuality/
>>> http://www.twollo.com/
>>>
>>> The combination of these two applications is for outright abuse of the
>>> service.  They have been around for several months and are known
>>> applications to abuse the service with.  To make matters worse,
>>> Twitter suspends accounts of the people who use these applications
>>> rather than targeting the root of the problem, the applications
>>> themselves.  (Sound counterproductive? RIAA uses a similar policy by
>>> going after end users.)
>>>
>>> I propose that applications need to be more closely scrutinized and
>>> can even be flagged as abusive by users. Instead of creating
>>> algorithms that detect abnormal user behavior, why not detect abnormal
>>> application behavior.
>>>
>>> Taking a stronger stance against gray area applications could reduce
>>> server load on Twitter (giving real applications faster response time)
>>> and reduce manpower to deal with spam prevention.
>>>
>>> I strongly encourage anyone who develops Twitter applications to send
>>> this link around.
>>>
>>> Thanks for reading,
>>> Brant
>>> twitter.com/BrantTedeschi
>>>
>>
>>
>

Reply via email to