Hi Everyone,

The key exchange "solution" will not be ready for the cut
off, unfortunately.

If you want to distribute an open source application or library, it should
either:
  - consume only public resources not requiring authentication
  - be distributed without consumer keys and secrets.

If your API key has been afforded any kind of privileges, such as xAuth, we
ask that you be especially vigilant in not exposing your application secrets
in easily accesible ways. I hope the logic in that is self-evident.

We know this isn't ideal. This will be easier some day -- we want it to be,
open source developers & consumers *need* it to be, and the push for a more
"frictionless" user experience across platform products demand it to be so.

But we're supporting OAuth 1.0a right now, and for the safety of our users,
for the ecosystem, and for you: please don't distribute API tokens and
secrets in your open source projects.

Taylor Singletary
http://twitter.com/episod

On Thu, Aug 5, 2010 at 1:34 PM, briandunnington
<briandunning...@gmail.com>wrote:

> i have seen it stated a few times that this solution is still being
> evaluated and it sounds like it might not see the light of day (which
> is fine by me - it seemed kind of convoluted to begin with).
>
> however, the oAuth deadline is fast approaching - what options do open
> source apps have in order to make the switch in time? requests to
> @twitterapi have gone unanswered and there have been no further
> updates as to how to proceed.  i will implement whatever alternative
> is offered, but since the key exchange is not publicly available and
> may never be, what is the recommended approach for keeping the
> consumer secret a secret?
>
>
>
> On Jul 19, 7:21 am, Taylor Singletary <taylorsinglet...@twitter.com>
> wrote:
> > We're continuing to experiment with the feasibility of this feature, and
> SSL
> > support is one gating factor among a few others. There are future
> solutions
> > that we can envision that would obviate the need for this
> less-than-friendly
> > model.
> >
> > Taylor
> >
> > On Sat, Jul 17, 2010 at 12:35 PM, Abraham Williams <4bra...@gmail.com
> >wrote:
> >
> >
> >
> > > There is an open issue for SSL support on dev.twitter.com -
> > >http://code.google.com/p/twitter-api/issues/detail?id=1665
> >
> > > Abraham
> > > -------------
> > > Abraham Williams | Hacker Advocate |http://abrah.am
> > > @abraham |http://projects.abrah.am|http://blog.abrah.am
> > > This email is: [ ] shareable [x] ask first [ ] private.
> >
> > > On Fri, Jul 16, 2010 at 06:41, Decklin Foster <deck...@red-bean.com
> >wrote:
> >
> > >> Excerpts from Cameron Kaiser's message of Fri Jul 16 01:00:55 -0400
> 2010:
> > >> > Actually, no. The process creates a completely new app key and
> secret
> > >> > cloned from the original one. They do not have anything in common
> with
> > >> > each other apart from the name and branding (and the user can change
> it
> > >> > later; it's just a regular old app key). You can see this in action
> by
> > >> > looking at TTYtter, which uses the process. They are not the same
> key
> > >> > and secret at all.
> >
> > >> When was this process turned on? (I just checked out TTYtter and
> > >> indeed, it works.) I asked for an update a couple weeks ago but I
> > >> hadn't seen anything here or on the announce list, so I assumed other
> > >> things had taken priority.
> >
> > >> --
> > >> things change.
> > >> deck...@red-bean.com
>

Reply via email to