[twitter-dev] Re: Why is Basic Auth still enabled on some sources?
I appreciate the response, Ryan. I'll say that it's a bummer to find out about this in that way. Twitter made a big deal about how Basic Auth was being shut off, so finding out that there were exceptions like this is confusing and disconcerting. No matter the intent, it is hard to feel respected when you discover this kind of thing. In the end, whether that matters is up to Twitter (as an entity, not the individuals who work there, to whom I'm sure it does matter). -- Ed Finkler http://funkatron.com @funkatron AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.com On Sep 14, 12:09 pm, Ryan Sarver rsar...@twitter.com wrote: Ed, As part of the migration we worked with many developers to help them with the transition and some of them, including our own Android app, had some extenuating circumstances that made them unable to make the date. For those few exceptions and extreme cases we granted them a stay of execution as long as they provided a reasonable timeline to make the transition. It pained us to do it for one of our own applications, but I'll give you some detail to help you understand why we needed to. And to be clear, we did this for a number of non-Twitter applications as well if we deemed their situation to be one that needed the stay as well. In the end all of the apps that got the stay were mobile apps that were unable to flash new versions out to devices on their own schedule and that includes the Android app on a number of devices. We have a hard shut-off date from Google which is only a few weeks away and from every other app that was given an exemption. Rest assured that EVERY app will be moved over in a timely fashion, so using their keys will only give you a short window to continue to use Basic Auth. When looking at all the possible options and scenarios, we think this was the right decision in order to move the entire ecosystem over to the new authentication model while also being reasonable when we needed to be. Best, Ryan On Mon, Sep 13, 2010 at 1:40 PM, funkatron funkat...@gmail.com wrote: Read on this post:http://blog.nelhage.com/2010/09/dear-twitter/ Tested just now:http://gist.github.com/577273 If I pass source=twitterandroid, it appears to work on all API methods. In light of basic auth being disabled, why does this work? -- Ed Finkler http://funkatron.com @funkatron AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.comxmpp%3afunkat...@gmail.com -- Twitter developer documentation and resources:http://dev.twitter.com/doc API updates via Twitter:http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
[twitter-dev] Why is Basic Auth still enabled on some sources?
Read on this post: http://blog.nelhage.com/2010/09/dear-twitter/ Tested just now: http://gist.github.com/577273 If I pass source=twitterandroid, it appears to work on all API methods. In light of basic auth being disabled, why does this work? -- Ed Finkler http://funkatron.com @funkatron AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.com -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
[twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
A solution, maybe, for desktop folks who can C+P a large string (although I'm willing to bet you'll have a lot of breakdown there), but it will fail miserably on mobile apps. The string is way, way too long. This will get screwed up badly by non-technical users. (Yes, some people make open-source mobile apps 8) -- Ed Finkler http://funkatron.com @funkatron AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.com On Jun 11, 6:56 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Developers, As has been discussed on the list recently, OAuth and Open Source applications are a difficult combination because token secrets shouldn't be embedded in widely distributed code. We're pleased to announce that we've devised a solution to this problem. Next week, we plan to release a new extension to the Twitter API that will allow Open Source applications to obtain OAuth consumer keys and secrets for their users, without having to distribute an application secret. Approved Open Source client applications will have an easy to implement ability, through dev.twitter.com, to generate new client tokens secrets to be used specifically for each new instance of the application. While completing the process does require the end-user to complete a few extra operations, we think this is a good compromise. The source tag on tweets published by the child applications generated with this approach will be a variation on the originating application's name. For examples, if the name of the parent application was AdventureTweet and the user's screen name was @zork, then the child application's name would be AdventureTweet (zork). The work flow for these applications will be something like this: 1. You store your API Consumer Key in your application distribution (but never your secret!). 2. A user downloads/installs/checks out your open source application and runs it for the first time 3. Your application builds a URL to our key exchange endpoint, using your consumer key. Example:http://dev.twitter.com/apps/key_exchange?oauth_consumer_key=abcdefghi... 4. You send the user to that URL in whatever way makes sense in your environment. 5. That user will have to login using their Twitter credentials (if they aren't already), and then approve your application's request to replicate itself on the user's behalf. 6. The approval will require that the user agrees to our terms of service, as this process results in them having control of their own application 7. The user is presented with a string that they are asked to paste into your application. The string will contain ah API key and secret, in addition to an access token and token secret for the member: everything that's needed to get the user up and running in your application. 8. The user pastes the string into your application, which then consumes and stores it to begin performing API calls using OAuth. The string containing the keys will be x-www-form-urlencoded. To keep the string brief, it will contain abbreviated key names. An example: ck=KIyzzZUM7KvKYOpnst2aOwcs=4PQk1eH4MadmzzEZ1G1KdrWHIFC1IPxv1kXZg0G3Eat=5 42212-utEhFTv5GZZcc2R4w6thnApKtf1N1eKRedcFJthdeAats=FFdeOEwxOBWPPREd55 dKx7AAaI8NfpK7xnibv4Yls Where: ck - consumer key, cs - consumer secret, at - access token, ats - access token secret This kind of key requisition service is new to the Twitter ecosystem, and we're going to be closely monitoring it for abuse. Once we announce its availability, we'll begin taking requests for Open Source applications that would like to offer the feature in their application. We're excited to offer this solution to the open source community. Thanks everyone! Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod
[twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
As it was explained to me (I think the API team would do well by discussing this stuff out in the open so we don't have to answer for them), the concern is having keys available in plain text. with OSS, you have that in 1, and potentially 2, situations: 1: Source code distributions/repos 2: end-user packages of non-compiled apps (like apps based on Python or JavaScript) The answer to #1 is to not include your keys in the source. That's fine for me. The answer to #2 is to either obfuscate your code (compiling, or intentional obfuscation) or to not include any consumer keys/secrets, and just use the above API. -- Ed Finkler http://funkatron.com @funkatron AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.com On Jun 12, 4:59 am, Jef Poskanzer jef.poskan...@gmail.com wrote: I don't understand why you are suggesting this only for open source programs. Were you thinking that an attacker would be incapable of decompiling an executable and extracting the secret?
[twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
I think you're missing the point, Taylor. It's not a matter of validation, but actually being able to copy such a long string. I have trouble with this on mobile, and I think I'm a pretty savvy user. I *guarantee* you the rate of failure, and giving up on the process entirely, will be much higher than current auth. I can't code some way to sit over the user's shoulder and tell them click this, now click that, now spread your fingers… a bit wider… -- Ed Finkler http://funkatron.com @funkatron AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.com Some users might screw up the copy paste step. Code defensively. Scrub the input. Verify that it's in the format you think it should be before assuming it's correct. After you parse the tokens, do a verify_credentials API requests or something similar to test if it works. If it doesn't work, try sending the user through the process again (they'll get the same result as the first time).
[twitter-dev] Re: Coming soon: a solution for Open Source applications using OAuth with the Twitter API
Yeah, it's really the step of manually getting that long string of seemingly-random characters from one app to another. a callback url makes sense for web-based apps. Something like PIN auth that would allow a desktop/mobile app to make an HTTP call and recover the string programatically would be good, I think. Typing 4-6 characters is much, much easier than copying and pasting that long string. -- Ed Finkler http://funkatron.com @funkatron AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.com On Jun 12, 3:57 pm, Cameron Kaiser spec...@floodgap.com wrote: I think you're missing the point, Taylor. It's not a matter of validation, but actually being able to copy such a long string. I have trouble with this on mobile, and I think I'm a pretty savvy user. I *guarantee* you the rate of failure, and giving up on the process entirely, will be much higher than current auth. I can't code some way to sit over the user's shoulder and tell them click this, now click that, now spread your fingers_ a bit wider_ If it's a problem with the way the credentials are transmitted, maybe a different or alternative way of transmitting them? E-mail them at the same time, perhaps? A callback URL? -- personal:http://www.cameronkaiser.com/-- Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com -- If a seagull flies over the sea, what flies over the bay? --
[twitter-dev] Re: Twitter Source Stats gets some JSON output love
Just as a little micro-update, Twitter Source Stats now has it's own domain: http://twittersource.info I've done a bit of tuning on the code, so things might be a little faster. Or not. Anyway, if you're using the JSON data, I'd be interested to hear about it! Drop me a line. -- Ed Finkler http://funkatron.com @funkatron AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.com On Apr 25, 1:54 am, funkatron funkat...@gmail.com wrote: Some of you may be familiar with my Twitter Source Stats project: http://funkatron.com/tss/ I've recently added the ability to get the ranking data back as JSON. You can just add .json to the end of the URL, and it'll spit it out. For example: http://funkatron.com/tss/lasthourhttp://funkatron.com/tss/lasthour.json I have pushed most of this code to github, although the code for stats collection isn't there right now -- it's done on another site atm. I'll try to pull that together soon, as well as clean up a bunch of unused code and scripts that are in there now. http://github.com/funkatron/twitter-stats-tracker Hit me up on Twitter if you have q's; I don't check in here a lot. Enjoy! -- Ed Finklerhttp://funkatron.com @funkatron AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.com -- Subscription settings:http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
[twitter-dev] Twitter Source Stats gets some JSON output love
Some of you may be familiar with my Twitter Source Stats project: http://funkatron.com/tss/ I've recently added the ability to get the ranking data back as JSON. You can just add .json to the end of the URL, and it'll spit it out. For example: http://funkatron.com/tss/lasthour http://funkatron.com/tss/lasthour.json I have pushed most of this code to github, although the code for stats collection isn't there right now -- it's done on another site atm. I'll try to pull that together soon, as well as clean up a bunch of unused code and scripts that are in there now. http://github.com/funkatron/twitter-stats-tracker Hit me up on Twitter if you have q's; I don't check in here a lot. Enjoy! -- Ed Finkler http://funkatron.com @funkatron AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.com -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
[twitter-dev] Re: Final Hack Day schedule for Chirp with discount code
I actually would consider buying these tickets, but 5 days notice; that's not so good for non-locals. Thanks for trying to make it affordable to mailing list folks, tho. -- Ed Finkler http://funkatron.com @funkatron AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.com On Apr 10, 9:18 pm, Ryan Sarver rsar...@twitter.com wrote: Hey all, Wanted to let you know that we have finalized the schedule for Hack Day sessions at Chirp. We're really excited about the content and would love to have you there. Also, each session has a Google Moderator section setup so you can get your questions in ahead of time. Be sure to add your questions so the speakers know what to talk to:http://bit.ly/dbpnXZ Hack Day tickets are still available and we're providing a 50% discount for the first 100 registrations from the mailing list. Please don't share this outside of this listhttp://chirp.eventbrite.com/?discount=DEVTALK10 Hopefully see you next week! Best, rs *Quick Agenda for Hack Day* *Apr 14th* - 6pm - Hack Day registration, dinner and drinks - 8pm - Ignite Chirp hosted by Brady Forrest - 9pm+ - Hacking for the night owls *Apr 15th* - 8am - 10am - Registration and breakfast (Registration is open all day) - 10am - Welcome with Ron Conway - 10:15am - 5pm - Sessions start and go all day with a lunch you shouldn't miss - 5pm - App Showcase with Marissa Mayer, Paul Graham and Philip Kaplan. Moderated by Jason Goldman (@goldman) - 9pm - Chirp Party at 1015 Folsom *Hack Day Sessions* *Twitter Streaming API Architecture and What's Next* #chirpstream with John Kalucki *Eating our own Dogfood: Designing Twitter Mobile Web* #chirpmobile with Leland Rechis *We Have Faith In (Most of) You: How Twitter Crafts Policies to Allow Good Apps to Thrive* #chirppolicy with Del Harvey *Office Hours: Twitter Platform Team* with Ryan Sarver, Doug Williams, Raffi Krikorian, Mark McBride, Dana Contreras, Isaac Hepworth, Marcel Molina, Taylor Singletary, Todd Kloots, Wilhelm Bierbaum *Office Hours: Design/UX *with Doug Bowman, Zhanna Shamis, Britt Selvitelle, Patrck Ewing, Mark Trammel, Vitor Lourenço, Mark Otto, Coleen Baik *Integrating @anywhere* #chirpanywhere with Todd Kloots, Dustin Diaz, Dan Webb, Russ D'Sa *Effective Use of the Twitter Search API *#chirpsearch with Eric Jensen *Analyzing Big Data at Twitter* #chirpdata with Kevin Weil *Office Hours: Working at Twitter* @jointheflock with Oliver Ryan, Bernadette Coh, Jamie Narva, Michelle Gale, Morgan Missentzis, Olivia Watkins *Office Hours: The Electronic Frontier Foundation* with Marcia Hofmann, Kurt Opsahl, Cindy Cohn, Fred von Lohmann *Twitter, Media, and Kanye's Exploding Head* #chirpmedia with Chloe Sladden, Robin Sloan *Too many secrets, but never enough: Twitter OAuth *#chirpoauth with Taylor Singletary, Raffi Krikorian *Changing Engines Mid-flight: Moving Twitter from MySQL to Cassandra*#chirpcassandra with Ryan King *Birds of a Feather: Real-Time Search* with Doug Cook *Office Hours: Trademark Policy and Branding Guidelines *with Jillian West, Jeremy Kessel, Francesca Helena, Tim Yip, Bakari Brock *The How and Why of Scala at Twitter* #chirpscala with Alex Payne *What's happening? to What's happening here?* #chirpgeo with Raffi Krikorian *Thinking in Streams: Patterns for Stream Processing* #chirpstream with John Kalucki *Meet and Greet: Founders* with Evan Williams and Biz Stone *Office Hours: Twitter Corp and Business Development* with Elizabeth Weil, Doug Williams, Isaac Hepworth, Bakari Brock, Jessica Verrilli *Billions of Hits: Scaling Twitter* #chirpscale with John Adams *Twitter International* #chirpintl with Matt Sanford *All Aboard? Turning Users into Active Users* #chirponboard with Josh Elman *Meet and Greet: Funding* with David Cohen, Paul Graham, Ron Conway *Birds of a Feather: Media Curation* with Chloe Sladden and Robin Sloan -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: Fred Wilson article on Twitter API
And so it's time for Twitter and its developer ecosystem to work together to create entirely new things that will shape the Internet in the coming years. I'm excited to see it happen. Because Twitter's gonna be taking over all the shit you've been doing so far! Welp, like used to say 3 years ago: you don't have a legal contract with Twitter, so don't build a business on it. Good thing no one here did that! Right? -- Ed Finkler http://funkatron.com @funkatron AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.com On Apr 9, 5:01 pm, Dewald Pretorius dpr...@gmail.com wrote: Raffi, It will be wise of Twitter to release an official statement regarding continued developer support. Perhaps in the form of an Evan blog post. When you read the commentary on tech blogs following Fred's post, it should be clear that it is not only developers who see the threat of Twitter now screwing them by taking ideas they came up with and implemented, and building those ideas into the Twitter core. On Apr 9, 12:33 pm, Raffi Krikorian ra...@twitter.com wrote: 100% On Fri, Apr 9, 2010 at 7:11 AM, Nigel Legg nigel.l...@gmail.com wrote: There will always be room for developers on the fringes, and novel ways of using twitter. I would hope that twitter will concentrate on the maintenance and development of the core system, and allow us to add the bells and whistles as required by our own set of users. On 9 April 2010 13:56, Dewald Pretorius dpr...@gmail.com wrote: With Fred being a Twitter board member, and with the enthusiasm for the article that was displayed by Twitter employees: 1) Do we all need to stop right now with developing any further gap filler type of functionality or apps? 2) Is there only a future in the ecosystem for the very minute handful of developers who happen to chance upon the idea of a killer app? 3) Can we now expect Twitter to drive most of us out of business or existence by building into Twitter the functionality that we built into our apps? -- To unsubscribe, reply using remove me as the subject. -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi-Hide quoted text - - Show quoted text -
[twitter-dev] Re: Twitter buying Tweetie
Twitter did this to BB clients too, today. You think this is the last platform they'll do an Official Client on? Take a look at the OS X music playback app market to see the future of Twitter clients. Here's the shirt for the Chirp keynote: http://spaz.spreadshirt.com/ Have fun in SF next week, everybody! -- Ed Finkler http://funkatron.com @funkatron AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.com On Apr 9, 10:18 pm, Dewald Pretorius dpr...@gmail.com wrote: It's great for Loren. But, there's a problem, and I hope I'm not the only seeing it. Twitter has just kicked all the other developers of Twitter iPhone (and iPad) clients in the teeth. Big time. Now suddenly their products compete with a free product that carries the Twitter brand name, and that has potentially millions of dollars at its disposal for further development. It's really like they're saying, We picked the winner. Thanks for everything you've done in the past, but now, screw you. This would not have been such a huge deal if the developer ecosystem did not play such a huge role in propelling Twitter to where it is today. Please correct me if I'm wrong. On Apr 9, 10:41 pm, Tim Haines tmhai...@gmail.com wrote: Before anyone rants, let me say congratulations Loren, and congratulations Twitter. Awesome! Totally awesome! :-) Tim.
[twitter-dev] Re: What happened, happened.
It would be awesome if some of those opportunities were offered to people who aren't able to afford to travel to SF. Of course, a lot of things would be awesome, but I'm not optimistic about them. Alas. -- Ed Finkler http://funkatron.com @funkatron AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.com On Apr 9, 11:26 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Let there be no doubt that not only will Chirp be an opportunity for developers to learn and talk to platform developers Twitter employees directly about what will obviously be a hot topic on everyone's mind, but Chirp will also in itself be a platform for Twitter to clarify existing capabilities and introduce new platform opportunities available to our obviously instrumental developer community. No one Twitter experience will ever define Twitter. No one app will ever define a platform. Not all use cases, analytical opportunities, clients, redefinitions, evolutions of, extrapolations on, libraries for the API of, insights for, integrations of, thoughts on, run-on-sentences-written-about, financial opportunities, or choices offered to consumers in the Twitter universe have been explored. @episod
[twitter-dev] Re: What happened, happened.
It looks like it will be great if you want to have VCs and pundits talk to you for several hours. -- Ed Finkler http://funkatron.com @funkatron AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.com On Apr 9, 11:36 pm, Isaiah isa...@me.com wrote: It would be great if Twitter would clarify things online. I'm sure I'm not the only one who thinks that it's time to cut losses and move on - starting with Chirp. Frankly I'm not sure I see much point in attending Chirp any more. Isaiah On Apr 9, 2010, at 8:26 PM, Taylor Singletary taylorsinglet...@twitter.com wrote: Let there be no doubt that not only will Chirp be an opportunity for developers to learn and talk to platform developers Twitter employees directly about what will obviously be a hot topic on everyone's mind, but Chirp will also in itself be a platform for Twitter to clarify existing capabilities and introduce new platform opportunities available to our obviously instrumental developer community. No one Twitter experience will ever define Twitter. No one app will ever define a platform. Not all use cases, analytical opportunities, clients, redefinitions, evolutions of, extrapolations on, libraries for the API of, insights for, integrations of, thoughts on, run-on-sentences-written-about, financial opportunities, or choices offered to consumers in the Twitter universe have been explored. @episod -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: Twitter buying Tweetie
StatusNet is in an interesting position. They can't, and I don't think have to, compete directly with Twitter. Offering both SAAS and self- hosted opportunities is compelling, and they have a pretty strong dev community. They already have Twitter and Facebook two-way bridges built in, which means you can run your own thing and still interact with both of those services. I'm interested in the idea of complementing StatusNet in a similar fashion on the client side, as a true FOSS tool, extensible via a plugin architecture. -- Ed Finkler http://funkatron.com @funkatron AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.com On Apr 9, 11:42 pm, M. Edward (Ed) Borasky zn...@comcast.net wrote: On 04/09/2010 08:22 PM, funkatron wrote: Define energy. Spaz has been out there and FOSS since mid 2007. Moving off AIR and doing lots of other good things have been in my plans for a long time, but open source in no way means people want to help you. No one will be even close to your own interest level. Open source depends on the fact that it is in the interest of major corporations like IBM, Novell, Oracle, Google, Dell and others to support it. I quite frankly don't know why some other large corporations don't join the party - there are just so many wheels you can re-invent before your bottom line goes to Hell in a hand-basket. FWIW, I'm leaning towards deploying Spaz as a hosted FOSS web app -- that is, you could use my server, or DL and host it yourself. It would focus on providing a good experience for touch-based clients particularly. When that will happen is pretty much dictated by who else takes interest. I should look at Spaz, I guess, although I'm dead-set against ever installing AIR again. I loaded one of the AIR-based Twitter desktops - I don't remember which one - and the process was brutal. The client itself sucked too, so there was no reason to keep it or AIR. I'm not sure I'd use a web-based client other than Twitter's at this point. HootSuite and CoTweet are moving towards being marketing / CRM add-ons to all the social networks. If that was what I was doing, I'd simply use SugarCRM (another fine open-source corporate project) with Twitter and Facebook plug-ins. ;-) Integrating well with StatusNet's server software seems pretty appealing right now. Yeah, I keep meaning to look at StatusNet, although I'm not sure when I'll find the time. They've got a huge wall to climb. -- M. Edward (Ed) Borasky borasky-research.net @znmeb A mathematician is a device for turning coffee into theorems. ~ Paul Erdős -- To unsubscribe, reply using remove me as the subject.
[twitter-dev] Re: Twitter buying Tweetie
It is, of course, possible to find niches here, and we can of course come up with ideas that could work. I certainly am not debating that. But you have to admit that this is a big, big bomb to drop in the development community; bigger than anything since *maybe* the Summize acquisition, and the whole shebang was a lot smaller then. And Summize was doing work that most developers couldn't do, because of the technical issues involved. And I might also suggest that choice and diversity is generally a good thing, even in areas you personally find boring. But perhaps not in the financial sense for Twitter, which is why stuff like this happens. It's not really just what was done, but *how* it was done that was most disappointing. And I bet you didn't have anything to do with that, so not much to say there. Actually, I suspect iTunes is a great analogy, even with the other apps you suggest. iTunes did destroy any competition in the primary music playback app market, and I believe (anecdotally though) that it dominates the lowest common denominator market -- also the largest part of the market. I'll be happy to buy you a drink when Spotify and and last.fm combined hit 50% of iTunes usage. They are the niche apps along the lines you suggest we should be making. -- Ed Finkler http://funkatron.com @funkatron AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.com On Apr 10, 12:20 am, Raffi Krikorian ra...@twitter.com wrote: the way that i usually explain twitter.com (the web site) is that it embodies one particular experience of twitter. twitter.com needs to implement almost every feature that twitter builds, and needs to implement it in a way that is easy to use for the* lowest common denominator of user*. this now also holds for the iphone. so, one possible answer for how to innovate and do potentially interesting/lucrative/creative things is to simply not target the lowest common denominator user anymore. find a particular need, and not the generic need, and blow it out of the water. what i am most interested in seeing is apps that break out of the mold and do things differently. ever since i joined the twitter platform, our team has built APIs that directly mirror the twitter.com experience -- 3rd party developers have taken those, and mimicked the twitter.com experience. for example, countless apps simply fetch timelines from the API and just render them. can we start to do more creative things? i don't have any great potentials off the top of my head (its midnight where i am now, and i flew in on a red-eye last night), but here are a few potential ones. i'm sure more creative application developers can come up with more. i want to see applications for people that: - don't have time to sit and watch twitter 24/7/365. while i love to scan through my timeline, frankly, that's a lot of content. can you summarize it for me? can you do something better than chronological sort? - want to understand what's going on around them. how do i discover people talking about the place i currently am? how do i know this restaurant is good? this involves user discovery, place discovery, content analysis, etc. - want to see what people are talking about a particular tv show, news article, or any piece of live-real-world content in real time. how can twitter be a second/third/fourth screen to the world? perhaps the OS X music playback app market is a poor example? sure itunes is a dominant app, but last.fm, spotify, etc., all exist and are doing things that itunes can't do. On Fri, Apr 9, 2010 at 7:26 PM, funkatron funkat...@gmail.com wrote: Twitter did this to BB clients too, today. You think this is the last platform they'll do an Official Client on? Take a look at the OS X music playback app market to see the future of Twitter clients. Here's the shirt for the Chirp keynote:http://spaz.spreadshirt.com/ Have fun in SF next week, everybody! -- Ed Finkler http://funkatron.com @funkatron AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.comxmpp%3afunkat...@gmail.com On Apr 9, 10:18 pm, Dewald Pretorius dpr...@gmail.com wrote: It's great for Loren. But, there's a problem, and I hope I'm not the only seeing it. Twitter has just kicked all the other developers of Twitter iPhone (and iPad) clients in the teeth. Big time. Now suddenly their products compete with a free product that carries the Twitter brand name, and that has potentially millions of dollars at its disposal for further development. It's really like they're saying, We picked the winner. Thanks for everything you've done in the past, but now, screw you. This would not have been such a huge deal if the developer ecosystem did not play such a huge role in propelling Twitter to where it is today. Please correct me if I'm wrong. On Apr 9, 10:41 pm, Tim Haines tmhai...@gmail.com wrote: Before
[twitter-dev] What Exactly is a Developer Advocate? (was Re: Opt-in beta of Popular Tweets for the Search API now available)
Taylor, I'm about to vent. Sorry about this. At some point did you plan on addressing any of the numerous complaints raised against making this anything other than opt-in? Several of us raised this, and you offered no response for 10 days. See http://groups.google.com/group/twitter-development-talk/ browse_thread/thread/983086ae9935d50c/d4a8e0fbc0fee5c0? lnk=gstq=popular+search#d4a8e0fbc0fee5c0 When you *did* post, you didn't actually address any concerns, or say hey, I spoke with the API team. This is why it's going like this. Like, say, an advocate of 3rd party developers would do. I'm not doing Twitter any favors; I realize that. I'm just the developer of a tiny, old open source client whose been hacking away on the API since spring of 2007. I'm not a strategic partner, and I don't bring Twitter any value. No VC funding will be coming my way, I'm afraid, and it doesn't make headlines on TechCrunch when I add a new feature (ping.fm? I supported that in 2007). But what I would like is to be treated with some respect. If you post something, and get significant pushback, I'd expect at *very* least some explanation about why doing it the way you guys want to do it is a great idea. If you are an advocate for 3rd party developers, as I interpreted your title, then doing us the courtesy of not simply ignoring/avoiding the concerns we voice seems like part of your job. It seems like you're doing a lot of selling of changes to *us*. That's not an advocate -- that's an evangelist. If your role there is an evangelist, then fine. You're doing a good job of ignoring the tougher questions and sticking to company lines. The point here is that I used to cut the API crew a lot of slack because I thought they at least weren't feeding us a line. I felt they actually were aiming for transparency, but were just overworked. If this is the way things are gonna go with someone who is, presumably, tasked with being *our* advocate, I think Twitter is losing the thread. Maybe it doesn't matter for you guys financially, and you'll go on and do Very Important Things and lots of people will continue to view Twitter as Game-Changing Technology, but it sure is a bummer for me. -- Ed Finkler http://funkatron.com @funkatron AIM: funka7ron / ICQ: 3922133 / XMPP:funkat...@gmail.com On Apr 1, 8:53 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Folks, As indicated a few weeks ago, we're launching our new *beta* enhancements to search.twitter.com and the Search API today -- it's currently rolling out to our servers. Thank you all for your feedback. *Key API Takeaways*: - During the current phase, receiving popular tweets in your API search results is *OPT-IN*. You will not see the new top results in search unless you specify the *result_typ**e* parameter on your search query string. - The result_type parameter takes one of three values: * *mixed* - receive both popular tweets and most recent tweets for the query. This is the equivalent of the future default behavior. * *popular* - receive only popular tweets for the query. * *recent* - receive only recent results for the query. This is the equivalent of the behavior you've come to expect until present - Each tweet in a search result will now contain a metadata node, with a field called 'result_type' that indicates whether the tweet is popular or recent. In the future, there may be other result_types. The metadata node will eventually contain other fields as well. - In addition to result_type, the metadata node may also include a 'recent_retweets' field indicating the number of retweets the tweet has received recently, rounded to a reasonable integer. - This metadata field will now appear in search results regardless of your OPT-IN status on the popular tweets feature. You don't have to do anything to receive this new metadata along with tweets in search results. In JSON, the metadata field is simply metadata. In XML, you'll see it expressed as twitter:metadata. *Continued Discussion*: To date, Twitter's real-time search has proven to be incredibly valuable. People, businesses and organizations have come to depend on finding out what's being discussed about a particular topic *right now*. We've been really impressed at the integrations many of you have developed using the Search API. Whether it's offering search columns in a Twitter client, mapping #hashtags to search, or deep analysis of trends and brand monitoring, you've shown us what's possible with Twitter search. With this new project, we want to make real-time search even more valuable by surfacing the best tweets about a particular topic, by considering recency, but also the interactions on a tweet. This means analyzing the author's profile, as well as the number times the tweet has been retweeted, favorited, replied, and more. It's an evolving algorithm that we'll be iterating on tuning until practically the end of time
[twitter-dev] Re: Most popular tweets in the search API
So this would change the default behavior of the search API, which is
currently to return recent results?
If so, I think that's a bad idea. Better to offer the option than to
change existing behavior when possible.
--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funkat...@gmail.com
On Mar 19, 10:37 am, Taylor Singletary taylorsinglet...@twitter.com
wrote:
Hi Developers!
The Search team is working on a beta project that returns the most popular
tweets for a query, rather than only the most recent tweets. This is a beta
project, but an important first step to surface the most popular tweets for
users searching Twitter.
You can expect many improvements as we tune and tweak our algorithms, but we
want to give everyone a heads up so we can go over the implications for
those consuming the search API.
--- New attribute in the payload ---
First of all there will be a new attribute in search result payloads. Since
some tweets are popular for a given query while others are simply the most
recent results that match the query, we are adding a metadata section to
specify the type of result that a given result represents.
So for a popular tweet the result_type in the metadata section will have
the value popular.
Example of a result with a popular tweet:
{
results:
[
{
profile_image_url:http://a1.twimg.com/profile_images/668144840/Elizabeth_Web_normal.jpg;,
created_at:Mon,15 Feb 2010 19:55:18 +,
from_user:Elizabeth,
to_user_id:null,
text:It's the Griswold family trip to Joshua Tree Park!
@rsarver @Devon @Jess @noradio @kevinweil,
id:9153622261,
from_user_id:106309,
geo:null,
iso_language_code:en,
source:lt;a href=quot;http://www.atebits.com/;
rel=quot;nofollowquot;gt;Tweetielt;/agt;,
metadata:
{
result_type: popular
}
}
/* etc ... */
}
Results that are not popular and represent simply recent query matches will
have the result_type in the metadata section with a value of recent.
Example of a recent result:
{
results:
[
{
profile_image_url:http://a3.twimg.com/profile_images/641350353/TimCheekFinger_normal.jpg;,
created_at:Mon, 15 Feb 2010 23:42:45 +,
from_user:timhaines,
to_user_id:97776,
text:@noradio Nice spot.,
id:9160218997,
from_user_id:159881,
to_user:noradio,
geo:null,
iso_language_code:it,
source:lt;a href=quot;http://www.atebits.com/;
rel=quot;nofollowquot;gt;Tweetielt;/agt;,
metadata:
{
result_type: recent
}
},
/* etc ... */
}
--- Results with popular tweets aren't ordered chronologically ---
Until the popular tweet feature all search results have been sorted
chronologically, most recent results at the top. If a search query has any
popular results, those will be returned at the top, even if they are older
than the other results.
Example of a non-chronologically ordered set of results including popular
results:
{
results:
[
{
profile_image_url:http://a1.twimg.com/profile_images/668144840/Elizabeth_Web_normal.jpg;,
created_at:Mon, 15 Feb 2010 19:55:18 +,
from_user:Elizabeth,
to_user_id:null,
text:It's the Griswold family trip to Joshua Tree Park!
@rsarver @Devon @Jess @noradio @kevinweil,
id:9153622261,
from_user_id:106309,
geo:null,
iso_language_code:en,
source:lt;a href=quot;http://www.atebits.com/;
rel=quot;nofollowquot;gt;Tweetielt;/agt;,
metadata:
{
result_type: popular
}
},
{
profile_image_url:http://a3.twimg.com/profile_images/641350353/TimCheekFinger_normal.jpg;,
created_at:Mon, 15 Feb 2010 23:42:45 +,
from_user:timhaines,
to_user_id:97776,
text:@noradio Nice spot.,
id:9160218997,
from_user_id:159881,
to_user:noradio,
geo:null,
iso_language_code:it,
source:lt;a href=quot;http://www.atebits.com/;
rel=quot;nofollowquot;gt;Tweetielt;/agt;,
metadata:
{
result_type: recent
}
}
/* etc ... */
}
--- Only getting popular results ---
If you *only* care about popular results for a given query term, you can
provide a result_type parameter with the value popular. Then only
popular results, if there are any, will be returned. By default, if
result_type isn't provided, all result types will be returned.
--- Never
[twitter-dev] Re: Most popular tweets in the search API
Your definition of time to adjust may not be ours. Twitter has, to be honest, a fairly crappy reputation for changing API behavior. While some of that was surely driven by performance concerns, I don't see how this could be. This doesn't help the rep. Please, do not enable this by default, *ever*. Don't change behavior unless it is necessary. Add a new API method, or make recent results the default and keep it that way. If you're advocating for developers, advocate for making us do less work to maintain current functionality, please. -- Ed Finkler http://funkatron.com Twitter:@funkatron AIM: funka7ron ICQ: 3922133 XMPP:funkat...@gmail.com On Mar 19, 1:09 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Your questions so far have been great and we're listening. I wanted to let everyone know that when we do roll this out, it will be such that developers will opt-in to receiving Top Tweets in their results for the first month or so of the feature rollout. After the trial transition period is complete, we'll enable this feature by default. You will have time to adjust. Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod On Fri, Mar 19, 2010 at 9:44 AM, Nick Arnett nick.arn...@gmail.com wrote: On Fri, Mar 19, 2010 at 7:37 AM, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Developers! The Search team is working on a beta project that returns the most popular tweets for a query, What is the definition of popular? Nick To unsubscribe from this group, send email to twitter-development-talk+ unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject. To unsubscribe from this group, send email to twitter-development-talk+unsubscribegooglegroups.com or reply to this email with the words REMOVE ME as the subject.
[twitter-dev] Re: What is the correct OAuth API endpoint
I'm surprised by this. Honestly, I think Twitter should not be allowing authenticated requests -- whether via signature or Basic Auth -- to happen over non- encrypted connections. Verifying the authenticity of the server is important, as a fair bit of trust is put in the data clients get back from Twitter. from http://tools.ietf.org/html/draft-hammer-oauth-10 4.3. Spoofing by Counterfeit Servers This protocol makes no attempt to verify the authenticity of the server. A hostile party could take advantage of this by intercepting the client's requests and returning misleading or otherwise incorrect responses. Service providers should consider such attacks when developing services using this protocol, and should require transport-layer security for any requests where the authenticity of the server or of request responses is an issue. In addition, if the consumer secret is discovered (which doesn't seem terribly difficult, especially with OSS apps), I do worry about the potential for session hijacking with plain text OAuth parameters. It's more challenging than some situations, but with enough motivation it seems doable. -- Ed Finkler http://funkatron.com Twitter:@funkatron AIM: funka7ron ICQ: 3922133 XMPP:funkat...@gmail.com On Mar 4, 12:15 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Good point. I'll considering encouraging it by default by presenting it that way. I certainly prefer it over https. A gating issue are design choices in many OAuth libraries where a base URL is utilized for both authorization steps and resource requests. If the base URL is https, then that bleeds to all resource requests, which often aren't necessary over HTTPs. I much prefer OAuth libraries that don't make any base URL considerations, requiring request_token, access_token, authorization, and resource requests all to be addressed by explicit URLs. Taylor On Thu, Mar 4, 2010 at 8:57 AM, Jaanus jaa...@gmail.com wrote: Is there a reason why the OAuth URL in the api wiki could not be HTTPS by default? Why would you want to recommend HTTP over HTTPS? (I know that OAuth was designed to be safe over HTTP, immune against man-in- the-middle and all, but HTTPS just gives me a warm and fuzzy feel. ;) rgds, Jaanus On Mar 4, 10:18 am, Thomas Woolway tswool...@gmail.com wrote: It's good to know that this is the recommended URI root for OAuth. Any chance of getting the docs ( http://apiwiki.twitter.com/Twitter-REST-API-Method:-oauth-access_toke...) updated to help out newcomers? Also, it might be worth adding a big NB that those resources aren't versioned - it's one of those things that is quite easy to miss. Cheers, Tom On Wed, Mar 3, 2010 at 3:26 PM, Scott Wilcox sc...@tig.gr wrote: Zhami, I'd go withhttps://api.twitter.com/1 Scott. On 3 Mar 2010, at 15:02, Zhami wrote: What is the correct API end-point for OAuth authenticated, *documented* API calls? http(s)://twitter.com http(s)://api.twitter.com http(s)://api.twitter.com/1
[twitter-dev] Re: Introduce yourself!
Hey Fellers! I'm Ed Finkler. I make stuff with JavaScript and PHP and related junk, and think about security from time to time. I've built stuff like this: * Spaz, a microblogging client that's older than you. Desktop and webOS http://getspaz.com * SpazCore, a component library for JavaScript that helps devs build web runtime applications. http://github.com/funkatron/spazcore * Twitter Source Stats, a simple web app that tracks and displays stats about how people are posting to Twitter http://funkatron.com/tss * The feature I'd like added to the API the most would be a social- graph-type method that included screen names -- Ed Finkler http://funkatron.com Twitter:@funkatron AIM: funka7ron ICQ: 3922133 XMPP:funkat...@gmail.com
[twitter-dev] Re: Application Suspended
Dude, really? Gestapo? Look, I don't think it's awesome or anything, but be *really* careful about attributing malice to something which could just be incompetence. Encourage fair play, for sure, but let's stick to the facts and avoid rhetoric. -- Ed Finkler http://funkatron.com Twitter:@funkatron AIM: funka7ron ICQ: 3922133 XMPP:funkat...@gmail.com On Feb 15, 4:51 pm, Dewald Pretorius dpr...@gmail.com wrote: Look, it is self-evident by now that this heavy-handed Gestapo-like action against applications is causing great anxiety in the developer community. We now have two very recent incidents, one of which was handled by Brian, who is part of the Platform team. For every person who has commented on this thread, there are numerous others who remain silent out of fear of incurring the wrath of the Platform team. I know, some of them have emailed me privately about this. Ryan, we need to hear from you, please. This is not a good situation, neither for you nor for us, and we cannot solve this. Only you can. On Feb 15, 4:16 pm, PJB pjbmancun...@gmail.com wrote: I thought Twitter didn't like bots? If so, why did they apparently have one send out suspension warnings? That's at least my conclusion given their non-response to questions, at least in that case. (As well, it seems as though the OAuth push is, at least in part, about app policing.) One would have thought that the Twitter police would be better aimed at enacting policies to deal with abuse by end-users, rather than such a heavy hand against apps. What's next? TweetDeck is going to be banned because they allow single-button duplicate tweets across multiple accounts? Some of us have built businesses and livelihoods around Twitter. It's scary to have those things threatened by the possibility of capricious enforcement handled by no questions please email demands. On Feb 15, 11:11 am, Abraham Williams 4bra...@gmail.com wrote: Sounds like Twitter dropped the ball with notifications. It appears that Twitter normally does send notifications before suspension as Refollow [1] got 2 warning. Although Rob had the issue of no response to clarifications. Abraham [1]http://refollow.tumblr.com/post/380619972/weve-been-suspended-by-twitter On Mon, Feb 15, 2010 at 10:34, PJB pjbmancun...@gmail.com wrote: Wow. What's really of concern is the capricious approach Twitter seems to have with app developers. Some apps are given a month to make a change, some are cut off immediately, some are sent legal letters, some are contacted beforehand, some aren't. Frankly, there should be no tracking code. If there is an issue, apart from extreme situations, Twitter should contact the app and, as they apparently did with socialtoo, give some reasonable period of time to remedy. On Feb 15, 10:02 am, Peter Denton petermden...@gmail.com wrote: Twitter should at least send a notification suspension, as well as a tracking code possibly, for both parties benefits, twitter and the app. *Reason*: My app was suspended, for something perfectly harmless, and was re-granted permission the next day, but it took a few communications with twitter to resolve. This is only going to continue to become more and more frequent. I would hate to envision a team of a few people having to follow up on app suspensions w/o reference. On Mon, Feb 15, 2010 at 6:15 AM, Dewald Pretorius dpr...@gmail.com wrote: The argument of, Clearly defining rules helps the spammers because then they know exactly how to stay just within the boundaries, holds _absolutely no_ water. Imagine you own an ice rink. You draw a circle with a radius of 2 meters on the ice, and make the rule that it's okay to skate inside the circle, and not okay to skate outside the circle. If someone skates right at the edge, at 1.999 meters, all the time, it _does not matter_ because you have decided that it is okay and acceptable to skate there. The same goes with Twitter rules. Make the rules very granular and very clear. Then, if someone skates just within the fringes, _it does not matter_ because they are still within what you deem acceptable. And, then _everyone_ knows where is the line between good and bad application behavior, because then it is a fence and not a broad gray smudge. Most app developers are _not_ the enemy and most app developers will be more than happy to not develop or to disable features that violate the rules. If only we can understand the rules. On Feb 15, 12:04 am, PJB pjbmancun...@gmail.com wrote: +1 to what Dewald says. We are purposely NOT developing certain features for fear that Twitter may suddenly change their rules once again
[twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
This isn't a zero-day vuln that hasn't been reported to the vendor, so
I think any suggestion that keeping it on the DL is not helpful. This
is a known issue with application of the OAuth spec. Educating the
developers who read this list, and maybe helping Twitter's engineering
team understand the problems better, should be top priority.
Pointing out what Flickr does is fine, but they're also in more of a
position to address possible abuses of their own API key as both the
consumer and the provider. App devs will have to hope that the API
support team responds quickly to these issues – and without and SLA or
support agreement in most cases, Twitter is under no obligation to
care. I hope it's *not* like that, but I think we've all seen cases
where feedback and response time wasn't what we'd like.
I agree that much of this seems like beating a dead horse, but I'd
also like to see more official response about it, even if it's just
hey, we know, and this is just the tradeoff we need to make.
Otherwise, I think we're providing feedback as requested on the API in
general, and authentication in particular.
--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funkat...@gmail.com
On Jan 31, 2:19 pm, Abraham Williams 4bra...@gmail.com wrote:
I would like to point out the official Flickr Uploadr application that is
OAuth and open source. If you download it as a user [1] it includes their
official API keys but if you download it as a developer [2] you implement
your own API keys.
Ironically all of these massive threads talking about impersonating
applications is probably just making more crackers aware that they can do
this. :-/
Abraham
[1]http://www.flickr.com/tools/uploadr/
[2]http://code.flickr.com/trac/browser/trunk/uploadr/README.osx#L76
On Sun, Jan 31, 2010 at 10:06, Josh Roesslein jroessl...@gmail.com wrote:
That's not all that secure, eventually it will be loaded into memory
and can be found by any hacker with some patience. As soon as you
distribute any sort of data it is no longer private. You're average
Joe might not be able to find it, but any skilled hacker will. And
after all the average Joe does not care anyways about OAuth tokens
(what's oauth?), but hackers do. So you're kind of blocking the
wrong person, it's the hacker you want to stop.
Josh
On Sun, Jan 31, 2010 at 2:28 AM, scott.a.herb...@googlemail.com wrote:
I 100% agree.
But another idea just struck me, why not put the OAuth part of your app
in a DLL (at lest the authentication and communication with twitter part)
and hard code it their.
You lose some of the open source nature of the app but it will be secure.
Sent using BlackBerry® from Orange
-Original Message-
From: Cameron Kaiser spec...@floodgap.com
Date: Sat, 30 Jan 2010 23:02:18
To: twitter-development-talk@googlegroups.com
Subject: Re: [twitter-dev] Re: a security problem puzzled me about using
oauth
in Desktop Client
OAuth as-is just wasn't designed for desktop apps, period. Square peg,
round hole. If Twitter is insisting on it, I'd rather this was
portrayed as a trade-off for increased user security, than a solvable
problem -- I don't think it is.
+1
--
personal:
http://www.cameronkaiser.com/--
Cameron Kaiser * Floodgap Systems *www.floodgap.com*
ckai...@floodgap.com
-- I'd love to go out with you, but I'm in perpetual denial.
--
Abraham Williams | Community Advocate |http://abrah.am
Project | Out Loud |http://outloud.labs.poseurtech.com
This email is: [ ] shareable [x] ask first [ ] private.
Sent from Seattle, WA, United States
[twitter-dev] Re: a security problem puzzled me about using oauth in Desktop Client
Not to be a complete pill, but that is a terrible, terrible initial experience for the average desktop app user. There is no way I would or could reasonably ask one of my users to register an app themselves, then fill in obscure hashes. The OAuth secret is simply impossible to use securely with open source, end-user-oriented applications. My only option with Spaz, when Twitter decides to take away basic auth, is to pray someone doesn't decide to steal my secret hash. Compiling does make getting the key more difficult, but assuming that desktop apps are compiled isn't a good idea -- Spaz isn't, for example. I could obscure the code for the end user, I suppose, but doing so seems contrary to open source philosophy, and probably just presents a challenge. OAuth as-is just wasn't designed for desktop apps, period. Square peg, round hole. If Twitter is insisting on it, I'd rather this was portrayed as a trade-off for increased user security, than a solvable problem -- I don't think it is. On Jan 30, 2:22 pm, Raffi Krikorian ra...@twitter.com wrote: what i would do is just make it clear to people who are using your open source client that they need to register their downloaded application with Twitter -- send them tohttp://twitter.com/apps/new, instruct them to fill out the form, and build a simple wizard that they can cut and paste the consumer token and secret into. On Sat, Jan 30, 2010 at 12:29 AM, ShellEx Well 5h3l...@gmail.com wrote: Some project (like dabr) put key and secret in config files. But I think it really suck for users who want to use my client with OAuth. Because they have to get a pair of key/secret and do configure themselves, and the this is not convenience for users. So I doubt that is it a good way to use OAuth in Desktop Client. On Jan 30, 1:35 am, Raffi Krikorian ra...@twitter.com wrote: the leak of a consumer secret will not result in the compromising of user accounts (the consumer secret is needed to get user secrets, but to get user secrets require the user's intervention). however - do not put the consumer key and secret in the source of your code and distribute it. instead, make it possible for your source to read the consumer key and secret from a configuration, and distribute, with your source code, a sample configuration file or a README that details how to create one. hope that helps. On Fri, Jan 29, 2010 at 7:57 AM, ShellEx Well 5h3l...@gmail.com wrote: if a twitter App's Consumer key and secret were leak out, is it possible to gain a user's access token without a user authentication process ? I am writing a opensource desktop client and has implemented OAuth for it. However, I don't know is it suitable to put my key and secret in the source? Are there any risks if i do that? Thx :) -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi
[twitter-dev] Re: Any iPhone Twitter apps with OAuth login ?
Just FWIW, this isn't really an iPhone-specific issue – there are a lot of rich mobile devices out there. One reason (excuse?) for not using OAuth in Spaz on webOS is the poor functionality on mobile. I'm really reluctant to move to OAuth until the flow for mobile is improved. The data from heypic.me is just what I was afraid of. -- Ed Finkler http://funkatron.com Twitter:@funkatron AIM: funka7ron ICQ: 3922133 XMPP:funkat...@gmail.com On Dec 6 2009, 3:08 am, Ram group...@cascadesoft.net wrote: As a followup to the mobile OAuth discussions from October (seehttp://groups.google.com/group/twitter-development-talk/browse_thread...) Does anyone know of any (publicly released) iPhone or other mobile Twitter apps that use OAuth ? I'm partly curious to know/confirm whether our app is the only iPhone (or mobile) app that uses Twitter OAuth login for posting tweets, but I also want to know what you think of the UI, if you've used Twitter OAuth login in any publicly released mobile app. Thanks Ram
[twitter-dev] Re: Platform announcements from LeWeb
Will this be posted to the dev announcement list as well? I missed this until now because it was not -- only caught it by chance in my friends timeline via ReadWriteWeb. -- Ed Finkler http://funkatron.com Twitter:@funkatron AIM: funka7ron ICQ: 3922133 XMPP:funkat...@gmail.com On Dec 28, 12:24 am, Ryan Sarver rsar...@twitter.com wrote: Hey all, Now that the dust has settled a bit and we are in the midst of the holidays I wanted to email everyone and provide some more details on the announcements we made a few weeks ago at LeWeb. *50,000 apps* We are continually amazed by all the incredible work the ecosystem does as a whole and we proud that developers have created over 50,000 applications that allow people to experience Twitter in so many different ways. We are really looking forward to what 2010 has in store as we put more emphasis on supporting the ecosystem better and maturing as a platform. We are humbled by and appreciative all the hard work you do. Please continue to give us feedback -- both good and bad -- on how we can support you better in your efforts to build awesome apps. *Auth announcements* With the recent launches of Retweet, Lists and Geotagging we have seen applications struggle to provide the experience they want for their users within the 150 req/hr limit. We are excited to open the skies up a bit and provide some more room for developers to work within. Starting in a few weeks all OAuth requests to api.twitter.com/1/ will be able to take advantage of a 10x rate limit increase. Basic Whitelisting still exists and is unchanged. We look forward to what this means in terms of the increased richness around the user experience in Twitter apps. *Developer Site* From the beginning we have used a disparate set of tools to help support the community -- from the apiwiki, to code.google.com for issues to this mailing group. It was a great way to get started quickly with fairly robust tools, but we need a place for developers to start from and help them find the right answers to their questions and help them solve their problems. We have announced a new Developer Site that begins to consolidate these communications channels and tools into a single place while adding some new, exciting tools to help developers. There will be new reference documentation, search, API console, API status dashboard (external monitoring service) and clearer documentation of policies. We are investing heavily in this area and will continue to improve the tools and content for the ecosystem to make sure that you have everything you need to get started and for continued support. We are really interested in getting your feedback on what will create a great site, so please let us know your wishlist of things that will help you be a more informed and more efficient developer. *Chirp - Twitter Developer Conference* Personally one of the most exciting announcements is that we will be throwing the first official Twitter Developer Conference which we are calling Chirp. It will be a two day event focused on equipping developers with all the tools they need to go forth and build great things. Day One will be filled with speakers from Twitter and the ecosystem talking about a broad range of topics like our roadmap, the Streaming API, how to develop desktop applications, sentiment analysis, user research and more. At the end of Day One we will kick off a 24-hour hack event with lots of great announcements and surprises already lined up. We'll also be filling Day Two with some workshops on specific topics for developers who want to dive deep in certain areas. There are lots of great surprises in store for the event and we hope to see lots of you there. *Firehose for everyone* Finally, the announcement that has garnered the most coverage and excitement. As I stated in the session at LeWeb we are committed to providing a framework for any company big or small, rich or poor to do a deal with us to get access to the Firehose in the same way we did deals with Google and Microsoft. We want everyone to have the opportunity -- terms will vary based on a number of variables but we want a two-person startup in a garage to have the same opportunity to build great things with the full feed that someone with a billion dollar market cap does. There are still a lot of details to be fleshed out and communicated, but this a top priority for us and we look forward to what types of companies and products get built on top of this unique and rich stream. Sorry for the long-winded email, but there is lots of really exciting stuff for us to be talking about. As always, we are very interested in getting your feedback on the announcements and more generally on how we can continue to improve how we work together. As I said a few times in the session, our success is dependent on your success so please let us know what we can do to help make you successful. Happy holidays, Ryan
[twitter-dev] Re: Security Best Practices
Might sorta work on webapps, or maybe desktop compiled code (assuming the config is compiled in at build time), but that doesn't help for desktop apps written in interpreted langs, where all source code and configs would be easily viewable (although I could imagine some initial setup stuff where it could get obscured). Not that I'm on either side of whatever this is. On Jul 1, 9:32 am, Andrew Badera and...@badera.us wrote: The secret should not reside in code. The secret should reside in a config file, or maybe even a machine datastore. Abstract it out, no one ever needs to see anything secret in your code. Thanks- - Andy Badera - and...@badera.us - Google me:http://www.google.com/search?q=andrew+badera - This email is: [ ] bloggable [x] ask first [ ] private On Wed, Jul 1, 2009 at 9:25 AM, DWRoelandsduane.roela...@gmail.com wrote: If you check out the OAuth Core Abstract, Section 4 (http://oauth.net/ core/1.0#anchor4) states it pretty plainly: Service Providers SHOULD NOT rely on the Consumer Secret as a method to verify the Consumer identity, unless the Consumer Secret is known to be inaccessible to anyone other than the Consumer and the Service Provider. This is exactly what Twitter has done with the Consumer Secret; they rely on it to verify the Consumer identity. This is a thorny dilemma for open source developers. There's no way to share the source code without compromising your application's security, because you've got to include the Consumer Key Secret in the source. You can obfuscate and encrypt, but a malicious actor with access to the source code can simply step through the code until the Consumer Secret is exposed in plain text. In any event, what's done is done, and Twitter certainly isn't going to abandon OAuth at this point. But opening the source of my Twitter client seems to be out of the question if I want to use OAuth. On Jul 1, 8:10 am, Philip Plante pplante@gmail.com wrote: I do not feel you've made a mountain out of a mole hill here. This topic has been on my mind since I first encountered oAuth. I haven't seen any open source apps use oAuth yet.
[twitter-dev] Re: API Changes for June 25, 2009
What's the word on a rate limit increase related to the issue 474 fix? -- Ed Finkler http://funkatron.com Twitter:@funkatron AIM: funka7ron ICQ: 3922133 XMPP:funkat...@gmail.com On Jun 25, 7:18 pm, Matt Sanford m...@twitter.com wrote: Two features and five fixes were deployed today, 2009-06-25: * Feature (REST): Added screen_name and user_id attributes to direct_messages/new for disambiguation - Issue:http://code.google.com/p/twitter-api/issues/detail?id=550 - Documentation:http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-direct_messages... * Feature (REST): Added new friendships/show method (issue 474, documentation) - Issue:http://code.google.com/p/twitter-api/issues/detail?id=474 - Documentation:http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-friendships-show * Fixed (REST): Partially fixed issue with tiling background images via the API - Issue:http://code.google.com/p/twitter-api/issues/detail?id=650 - Note: This was part one. There is a second part to complete the fix that is expected this week. The issue will be updated. * Fixed (OAuth): Added a more helpful error message when you try to use a request token in place of an access token. - Error Text: Request token must be exchanged for an access token before use * Fixed (OAuth): Improved error handling when invalid data is submitted in place of a token. - The generic HTTP 500 should now be replaced with a message that the token was not found * Fixed (REST): The JSON returned in maintenance mode now correctly contains null rather than NULL - Issue:http://code.google.com/p/twitter-api/issues/detail?id=703 * Fixed (Mail): Improved outbound email reliability (for apps parsing DM/friend emails) - Improved some retry logic related to transient errors such as timeouts. As always we've updated the change log athttp://apiwiki.twitter.com/REST-API-Changelog Thanks; – Matt Sanford / @mzsanford Twitter Dev
[twitter-dev] Re: Search API to require HTTP Referrer and/or User Agent
Indeed, some clearer criteria would be most appreciated. -- Ed Finkler http://funkatron.com Twitter:@funkatron AIM: funka7ron ICQ: 3922133 XMPP:funkat...@gmail.com On Jun 16, 12:51 pm, Justyn Howard justyn.how...@gmail.com wrote: Thanks Doug - Any additional info to help us know if we comply? My dev is out of the country on vacation and want to make sure we don¹t miss anything. On 6/16/09 11:33 AM, Doug Williams d...@twitter.com wrote: Hi all, The Search API will begin to require a valid HTTP Referrer, or at the very least, a meaningful and unique user agent with each request. Any request not including this information will be returned a 403 Forbidden response code by our web server. This change will be effective within the next few days, so please check your applications using the Search API and make any necessary code changes. Thanks, Doug
[twitter-dev] Re: Search API to require HTTP Referrer and/or User Agent
Totally understand the need. I asked for clearer criteria because in message one, you state you'll require a valid HTTP Referrer or a meaningful and unique user agent I can probably define a valid HTTP Referrer as containing a URL that exists, but a meaningful/unique user agent is somewhat in the eye of the beholder. In the second message, you say you'll require a valid HTTP Referrer and/or a User Agent I'm not sure how to define a valid user agent. That's why I'd like to see *your* definition for these things so we can meet your criteria. -- Ed Finkler http://funkatron.com Twitter:@funkatron AIM: funka7ron ICQ: 3922133 XMPP:funkat...@gmail.com On Jun 16, 12:56 pm, Doug Williams d...@twitter.com wrote: All we ask is that you include a valid HTTP Referrer and/or a User Agent with each request which is easy to do in almost every language. Both would be helpful but we only require one at this time. We simply want to be able to identify apps and have the ability to communicate with the authors. Thanks, Doug On Tue, Jun 16, 2009 at 9:51 AM, Justyn Howard justyn.how...@gmail.comwrote: Thanks Doug - Any additional info to help us know if we comply? My dev is out of the country on vacation and want to make sure we don’t miss anything. On 6/16/09 11:33 AM, Doug Williams d...@twitter.com wrote: Hi all, The Search API will begin to require a valid HTTP Referrer, or at the very least, a meaningful and unique user agent with each request. Any request not including this information will be returned a 403 Forbidden response code by our web server. This change will be effective within the next few days, so please check your applications using the Search API and make any necessary code changes. Thanks, Doug
[twitter-dev] Re: json parsing code not workin..urgent plzzz!!!!!
Are you running this from a browser? If so, perhaps a same-origin
policy error? You'll want to google it.
--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funkat...@gmail.com
On Jun 8, 8:01 am, grand_unifier jijodasgu...@gmail.com wrote:
$.ajax('http://twitter.com/friendships/exists.json?
user_a='+query1+'user_b='+query2,
function(data,textdata)
{
var public_tweets = JSON.parse(data);
if(public_tweets.text == 'true')
{
var newDiv = 'ptrue/p';
}
$('#content').append(newDiv);
});
},text);
even this doesnt seem to work...
On Jun 6, 12:33 pm, grand_unifier jijodasgu...@gmail.com wrote:
!-- this is the javascript json parser function --
script type=text/javascript src=../jquery-1.2.6.min.js
/script
script type=text/javascript
$(document).ready(function(){
$('form#search').bind(submit, function(e){
e.preventDefault();
$('#content').html('');
var query1 = urlencode($('input[name=user_a]').val
()); //userA
var query2 = urlencode($('input
[name=user_b]').val()); //userB
var rpp = 20; //number of tweets to retrieve out
$.getJSON('http://twitter.com/friendships/exists.json?
user_a='+query1+'user_b='+query2, function(data){
if(data == 'true'){
var newDiv = 'ptrue/p';}
$('#content').append(newDiv);
});
});
})
function urlencode(str) {
return escape(str).replace(/\+/g,'%2B').replace(/%20/g,
'+').replace(/\*/g, '%2A').replace(/\//g, '%2F').replace(/@/g, '%40');
}
})
/script
!-- javascript ends here --
this is a very basic code to check if two twitter users are friends or
not the json will return true or false in'it but it does seem
to work...its frustratin.
anyone got any idea why???
Re: OAuth Documentation Preview
I still maintain that this works fine for knowledgeable web dev folks (who seem to be the people who get excited about OAuth), but *will* confuse users who don't understand the tech involved, and/or aren't comfortable jumping between apps. In addition, the process becomes even more problematic with apps that don't run on a modern windowing platform (like CLIs, mobile devices, and the like). If you have hard numbers from usability studies that prove my suspicions unfounded, that would be *great*. I'd love to be wrong. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron On Feb 9, 4:12 pm, Blaine Cook bla...@twitter.com wrote: OAuth was designed with explicit desktop application support in mind. To see how it works in practice, try using a desktop Flickr Uploader or iMovie's YouTube integration. Normally your app will open a browser window (all modern environments do this seamlessly) and ask the user to authorize the application. Once they've done that, they should be told to go back to the application (close the browser window) and continue the setup process (usually by just clicking Continue or OK so that the desktop app knows that it's OK to exchange the request token for the access token). b.
Re: OAuth Documentation Preview
Those are all technical issues. I'm talking about usability issues for non-technical users. However, none of what I'd have to say is different than what I've already said on the topic, and I'm sure things will work out fine in time. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron On Feb 9, 5:11 pm, Nicholas Moline portal...@gmail.com wrote: Assuming Twitter keeps to a long/no expiration model for the OAuth tokens (as I understand it, it currently is set to not expire in the beta), or better yet, have a choice method for how long the token will last, for users accessing a site that accesses twitter, have a short expiration (an hour or a day), but have the option to create a token for client side applications that don't expire, then there shouldn't be a problem. You have your client program check to see if your token is valid, if it is not, spit out the url to get a new token, then you just paste your token back into your app's information and it's good for another 6 months or forever or whatever. It should even be possible to have your script get the token for you, for your own purposes if you store your login information, you can have your script access the url, get the token, and save it. There should be no real reason to save end user's login information, they should grant you access for the time periods that they access the site, it's much more secure that way overall, and if Twitter keeps to a long expiration model, saving those tokens to act for a period of time should be fine. On Mon, Feb 9, 2009 at 2:03 PM, funkatron funkat...@gmail.com wrote: I still maintain that this works fine for knowledgeable web dev folks (who seem to be the people who get excited about OAuth), but *will* confuse users who don't understand the tech involved, and/or aren't comfortable jumping between apps. In addition, the process becomes even more problematic with apps that don't run on a modern windowing platform (like CLIs, mobile devices, and the like). If you have hard numbers from usability studies that prove my suspicions unfounded, that would be *great*. I'd love to be wrong. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron On Feb 9, 4:12 pm, Blaine Cook bla...@twitter.com wrote: OAuth was designed with explicit desktop application support in mind. To see how it works in practice, try using a desktop Flickr Uploader or iMovie's YouTube integration. Normally your app will open a browser window (all modern environments do this seamlessly) and ask the user to authorize the application. Once they've done that, they should be told to go back to the application (close the browser window) and continue the setup process (usually by just clicking Continue or OK so that the desktop app knows that it's OK to exchange the request token for the access token). b.
Re: How API will works after OAuth?
On Feb 5, 10:38 pm, James Deville james.devi...@gmail.com wrote: Flickr doesn't seem to have a problem with the OAuth formula, so why are people thinking twitter will? I'm not sure people have said Twitter would have a problem. I've personally expressed some problems specific to applications I develop. Much of what I said would apply to desktop apps for Flickr too, but Flickr has never offered anything but OAuth (AFAIK). In addition, part of the concern I would have with Basic Auth is the plaintext password. Sure, it's Base64 encoded, but that's not encryption, that's just saving bandwidth. If twitter wanted to move to a different auth scheme, that might work. Or they could add ssl to the API front end, and use HTTPS, which is also expensive (either expensive SSL-offloading proxies, or you have to lock a session to a server). I don't think Twitter should keep a Basic Auth service. It just wouldn't be worth the risk to me. SSL has been available in the API for as long as I recall, and is in fact officially recommended, AFAIK. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron
Re: How API will works after OAuth?
Agreed. I do believe that the use of HTTP Basic Auth was key to the quick growth of the 3rd-party app community of Twitter, as the auth scheme is so well-understood and supported. This may or may not be as important at this point business-wise, as I suspect the Twitter userbase is large enough to overcome a fair bit of lazy user intertia. I wonder if we will see a lot less interesting API hacking (the good kind), though, and I think that would be a shame. While OAuth makes a ton of sense for website-based apps, it's kind of another kettle of fish for locally-hosted apps (desktop and mobile). Moving to OAuth-only is problematic for us for these reasons: 1. it complicates (and confuses) the process for users: instead of entering a username and password -- a well-understood, common process -- now the app has to push the user to a web site which hopefully explains what's going on decently. This works okay for web dorks like us, but I guarantee your avg user is going to find this confusing. Maybe not as confusing as OpenID, though. 2. updating locally-hosted apps to use a new authentication system is an issue of getting thousands (or higher orders) of users to upgrade. 6 months may not be enough, even for currently active applications. Stuff in development *cough*like mine*cough* now could find themselves having to toss out a ton of code they're knee-deep in right now. Yucky. My preference would be to *not* see HTTP Basic Auth go away in the foreseeable future. If that's not reasonable or possible, the 6-month window (even given that the countdown may not start for a few months) is pretty tight for comfort, and extending it would be much preferred. Note: One might wonder why I only mention these issues in the context of local apps rather than web apps. I think the expectations and user behavior tendencies are fairly different in the desktop and mobile app space, and there are a number of ways malware is detected and contained in this area. The web app space is a lot more open and easy to exploit, and likely will be unless the whole paradigm changes. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron On Feb 4, 10:03 pm, Cameron Kaiser spec...@floodgap.com wrote: I'm still (softly) repeating the hope that this will be extended, even if the Basic Auth API remains deprecated and static. An OAuth workflow is constrained for desktop apps, and for apps that aren't or can't use a web browser (in my case, text-mode twitter clients; other cases include all those little curl scripts posting monitoring information, task status, etc.), OAuth won't work at all. I fully support OAuth, but where appropriate. I think Ed Finkler said it best when he said the breadth of Twitter applications currently extant wouldn't exist were it not for a low barrier to entry. OAuth makes sense in many places, but it doesn't make sense everywhere, and I hope alternate methods of authentication remain possible even if they are intentionally limited to steer preferred traffic to an OAuth workflow. Otherwise I suspect the ecosystem outside the browser will be greatly reduced. -- personal:http://www.cameronkaiser.com/-- Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com -- Critics are the unpaid guardians of my soul. -- E. Stanley Jones ---
Re: verify_credentials response changed
Permanent. See posts on the list about a week ago, and issue in tracker. -- Ed Finkler http://funkatron.com AIM: funka7ron ICQ: 3922133 Skype: funka7ron On Dec 11, 11:20 am, JakeS [EMAIL PROTECTED] wrote: It used to be that callinghttp://twitter.com/account/verify_credentials.xml would return a simple authorizedtrue/authorized answer when given a correct username and password. Now it appears to be returning an entire serialized user object. This change has broken the authentication process for the existing releases of my application. Is this change permanent, or is it a temporary glitch?
