Taylor -

thanks for the response. it is good to hear it from the horse's mouth.

unfortunately, distributing the app without keys/secrets and asking
each user to register their own set of keys is not feasible for my
app. in lieu of a better solution, i will have to remove Twitter
integration for the time being. i look forward to the day when a
better solution is in place and i can re-enable the functionality.

ps: out of curiosity, how are apps like Spaz planning on handling this
situation? i would love to hear any creative ideas.



On Aug 5, 4:41 pm, Taylor Singletary <taylorsinglet...@twitter.com>
wrote:
> 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 Singletaryhttp://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