[twitter-dev] Re: A new permission level
Users do not need protection from their personal mobile Twitter clients any more than they do from their browsers. It's their app running on their device accessing their account at their direction. Requiring separate authentication for DMs for a mobile client app is like requiring separate cars keys for ignition, gas pedal, and breaks. Millions of mobile Twitter users are going to get really ticked off when they can no longer use their favorite apps. So let's be honest. When it comes to Twitter mobile clients, this isn't about user security. It's about pruning client competition from the market. Ron On May 19, 7:44 am, Damon Parker cartmet...@gmail.com wrote: In any security or permissions context the default should be the most secure and least amount of permissions to get the job done. That is Computer and Network Security 101. A user must explicitly configure more loose permissions on their own after understanding the implications. This is the way computer network security is and always has been done. This is part of the reason Linux/Unix et al is way more secure than Windows ever could be. Just because a user isn't sophisticated enough to configure more lax permissions to get their needs met isn't a reason to default to lower the security context. This is what FB did _completely_ wrong when they updated their permissions system. They defaulted everything to being completely open, accessible and public for purely selfish reasons. They wanted to keep more user data 100% public thus increasing the amount of public and free (as in $ to FB) user-generated content created every day. More pageviews, more pics, more comments equals more ad revenue for them. Even though it's a pain in the ass for developer's to rework their apps and re-auth it's the right thing to do for the end user and the overall safety of the community. I commend Twitter for doing the right (even if unpopular) thing in this case. Damon On Thursday, May 19, 2011 at 1:50 AM, janole wrote: Hi Matt, thanks for your feedback. I think the following paragraph can't be generalized, though: Why will you not grandfather existing applications into DM access? Grandfathering all existing read/write tokens assumes they all wanted access to DMs. The feedback we’ve had from users and developers tells us otherwise. We want to give users the opportunity to make an informed choice. -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
[twitter-dev] Re: Problems Loading Profile Images
Right now it all seems back to working normally again. I'll look at it again late this afternoon about the same time I saw the issue yesterday. Perhaps it's time related. If it occurs again, I'll take some captures and send them along. On Jul 22, 10:29 am, Taylor Singletary taylorsinglet...@twitter.com wrote: If possible, can you send along member ids or screen names, and if possible, an HTTP capture of the image download attempt? Thanks! Taylor On Wed, Jul 21, 2010 at 8:12 PM, Ron rbther...@gmail.com wrote: Same problem seems to be back - slow/no profile image downloads. On Jul 21, 3:14 pm, Ron rbther...@gmail.com wrote: Not seen it happen at all anymore since corrections were made. On Jul 21, 2:08 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Everyone, We had some issues with profile updates and image uploads last week and early this week. Some images uploaded in that time period resulted in incorrect image URLs, and while this should now be fixed for more recently updated/created images, those with avatars saved while in this state will likely remain in that state until they re-upload their image. What kind of percentages are you seeing in regards to missing/broken images? Taylor On Wed, Jul 21, 2010 at 5:35 AM, luisg luisfmgoncal...@gmail.com wrote: I'm having the same problem too... But just sometimes. Anyway, looks like Twitter is better now... At least is not so slow as was a couple of weeks ago. On Jul 21, 4:59 am, Ron rbther...@gmail.com wrote: Anyone noticing problems loading profile images (slow, no image returned, hanging...)? Seems to show up mostly on Public and Search endpoints.
[twitter-dev] Re: Problems Loading Profile Images
Hi Taylor, Tried again this afternoon and operation appears normal, except for an occasional profile image not loading. I find about 1 out of 200. An example is hiro07118. Ron On Jul 22, 10:42 am, Ron rbther...@gmail.com wrote: Right now it all seems back to working normally again. I'll look at it again late this afternoon about the same time I saw the issue yesterday. Perhaps it's time related. If it occurs again, I'll take some captures and send them along. On Jul 22, 10:29 am, Taylor Singletary taylorsinglet...@twitter.com wrote: If possible, can you send along member ids or screen names, and if possible, an HTTP capture of the image download attempt? Thanks! Taylor On Wed, Jul 21, 2010 at 8:12 PM, Ron rbther...@gmail.com wrote: Same problem seems to be back - slow/no profile image downloads. On Jul 21, 3:14 pm, Ron rbther...@gmail.com wrote: Not seen it happen at all anymore since corrections were made. On Jul 21, 2:08 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Everyone, We had some issues with profile updates and image uploads last week and early this week. Some images uploaded in that time period resulted in incorrect image URLs, and while this should now be fixed for more recently updated/created images, those with avatars saved while in this state will likely remain in that state until they re-upload their image. What kind of percentages are you seeing in regards to missing/broken images? Taylor On Wed, Jul 21, 2010 at 5:35 AM, luisg luisfmgoncal...@gmail.com wrote: I'm having the same problem too... But just sometimes. Anyway, looks like Twitter is better now... At least is not so slow as was a couple of weeks ago. On Jul 21, 4:59 am, Ron rbther...@gmail.com wrote: Anyone noticing problems loading profile images (slow, no image returned, hanging...)? Seems to show up mostly on Public and Search endpoints.
[twitter-dev] Re: Problems Loading Profile Images
So it looks like the problem is back, and perhaps time sensitive. Servers affected are a0, a1, and a3.twing.com. Problem is no response from server. URLs all look ok, but a few perhaps very long (i.e. http://a3.twimg.com/profile_images/598514017/l_58bce087ff00416383ca2b5595036c90_normal.jpg). On Jul 22, 6:36 pm, Ron rbther...@gmail.com wrote: Hi Taylor, Tried again this afternoon and operation appears normal, except for an occasional profile image not loading. I find about 1 out of 200. An example is hiro07118. Ron On Jul 22, 10:42 am, Ron rbther...@gmail.com wrote: Right now it all seems back to working normally again. I'll look at it again late this afternoon about the same time I saw the issue yesterday. Perhaps it's time related. If it occurs again, I'll take some captures and send them along. On Jul 22, 10:29 am, Taylor Singletary taylorsinglet...@twitter.com wrote: If possible, can you send along member ids or screen names, and if possible, an HTTP capture of the image download attempt? Thanks! Taylor On Wed, Jul 21, 2010 at 8:12 PM, Ron rbther...@gmail.com wrote: Same problem seems to be back - slow/no profile image downloads. On Jul 21, 3:14 pm, Ron rbther...@gmail.com wrote: Not seen it happen at all anymore since corrections were made. On Jul 21, 2:08 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Everyone, We had some issues with profile updates and image uploads last week and early this week. Some images uploaded in that time period resulted in incorrect image URLs, and while this should now be fixed for more recently updated/created images, those with avatars saved while in this state will likely remain in that state until they re-upload their image. What kind of percentages are you seeing in regards to missing/broken images? Taylor On Wed, Jul 21, 2010 at 5:35 AM, luisg luisfmgoncal...@gmail.com wrote: I'm having the same problem too... But just sometimes. Anyway, looks like Twitter is better now... At least is not so slow as was a couple of weeks ago. On Jul 21, 4:59 am, Ron rbther...@gmail.com wrote: Anyone noticing problems loading profile images (slow, no image returned, hanging...)? Seems to show up mostly on Public and Search endpoints.
[twitter-dev] Re: Problems Loading Profile Images
Same problem seems to be back - slow/no profile image downloads. On Jul 21, 3:14 pm, Ron rbther...@gmail.com wrote: Not seen it happen at all anymore since corrections were made. On Jul 21, 2:08 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Everyone, We had some issues with profile updates and image uploads last week and early this week. Some images uploaded in that time period resulted in incorrect image URLs, and while this should now be fixed for more recently updated/created images, those with avatars saved while in this state will likely remain in that state until they re-upload their image. What kind of percentages are you seeing in regards to missing/broken images? Taylor On Wed, Jul 21, 2010 at 5:35 AM, luisg luisfmgoncal...@gmail.com wrote: I'm having the same problem too... But just sometimes. Anyway, looks like Twitter is better now... At least is not so slow as was a couple of weeks ago. On Jul 21, 4:59 am, Ron rbther...@gmail.com wrote: Anyone noticing problems loading profile images (slow, no image returned, hanging...)? Seems to show up mostly on Public and Search endpoints.
[twitter-dev] Problems Loading Profile Images
Anyone noticing problems loading profile images (slow, no image returned, hanging...)? Seems to show up mostly on Public and Search endpoints.
[twitter-dev] Re: User Photo Loading Issues
Actually, my user's can even log-in on Twitter's webpage. Has Twitter gone belly up? On Jul 16, 10:18 pm, Ron rbther...@gmail.com wrote: Anyone having trouble loading user avatar photos for their tweets? I seem to be getting very long delays with many photos not being returned at all. Doesn't appear to be anything on the issue on the Twitter Status page...
[twitter-dev] Re: User Photo Loading Issues
Looks like a3.twimg.com is down. On Jul 16, 11:07 pm, Ron rbther...@gmail.com wrote: Actually, my user's can even log-in on Twitter's webpage. Has Twitter gone belly up? On Jul 16, 10:18 pm, Ron rbther...@gmail.com wrote: Anyone having trouble loading user avatar photos for their tweets? I seem to be getting very long delays with many photos not being returned at all. Doesn't appear to be anything on the issue on the Twitter Status page...
[twitter-dev] Followers Timeline
Anyone know of any reason why an identical API call to the followers timeline (api.twitter.com/1/statuses/followers.json) from two different clients would return different results? I'm specifying cursor=-1 for both, but in one client I get both the next and prev cursor objects plus an array of user statuses, while in the other I only get an array of user statuses. Both requests are for the same user account, which as only a handful of followers. Anyone have any ideas? Ron
[twitter-dev] Re: Previous_Cursor Not Working
Anyone, please. This is still a problem. Previous_Cursor_Str is returning an empty object when trying to return from pages 2 or 3. This is affecting all my apps. Does anyone have any idea what's gone wrong and what if anything I can do about it? On Jul 5, 9:15 am, Ron rbther...@gmail.com wrote: This is still not working. Previous_Cursor_Str for current page less than 4 returns an empty object on either Followers or Friends API calls. Nothing showing up on Twitter Status about this. Does anyone at Twitter care to comment? On Jul 5, 6:38 am, CWorster cwors...@schlimmer.com wrote: Same problem here. I'm using previous_cursor_str and next_cursor_str. previous_cursor_str stopped working. next_cursor_str works as expected. 2010/7/5 Ron rbther...@gmail.com: Anyone else seeing a problem on Followers or Friends with Previous_Cursor not working (returning a blank response)?
[twitter-dev] Re: Previous_Cursor Not Working
This is still not working. Previous_Cursor_Str for current page less than 4 returns an empty object on either Followers or Friends API calls. Nothing showing up on Twitter Status about this. Does anyone at Twitter care to comment? On Jul 5, 6:38 am, CWorster cwors...@schlimmer.com wrote: Same problem here. I'm using previous_cursor_str and next_cursor_str. previous_cursor_str stopped working. next_cursor_str works as expected. 2010/7/5 Ron rbther...@gmail.com: Anyone else seeing a problem on Followers or Friends with Previous_Cursor not working (returning a blank response)?
[twitter-dev] Previous_Cursor Not Working
Anyone else seeing a problem on Followers or Friends with Previous_Cursor not working (returning a blank response)?
[twitter-dev] why i can not connect to api.twitter.com??
yeap, yesterday night i found that i can not connect to the api host.. anyone has any idea??? i implement oauth protocol by myself in symbian. then, one more question: what can i do when i got the PIN code? set as parammeter 'oauth_verifier' in basestring before signature? if i do so, just made a authorization request like reques_token, and send it to http://api.twitter.com/oauth/access_token, then i got a 500 err from api server... can someone tell me what'wrong about it? thx very much.
[twitter-dev] Fail Whale
Anybody else noticing that Twitter appears to be down hard at the moment (actually for about 20 mins now)?
[twitter-dev] Re: Fail Whale
Thanks! On Jun 14, 11:46 pm, John Kalucki j...@twitter.com wrote: Check the status blog for this sorts of things. http://status.twitter.com -John Kaluckihttp://twitter.com/jkalucki Infrastructure, Twitter Inc. On Mon, Jun 14, 2010 at 9:45 PM, Rajiv Verma™ rajiv@gmail.com wrote: Yes!! Here too... I am from India FYI On Tue, Jun 15, 2010 at 10:13 AM, Ron B rbtheron...@gmail.com wrote: Anybody else noticing that Twitter appears to be down hard at the moment (actually for about 20 mins now)? -- Thanks Regards Rajiv Verma Bangalore E-Mail: rajiv@gmail.com Ph: +91-92430-12766 Go Green, Use minimum natural resources!
[twitter-dev] Re: t.co mixed messages
Hi Taylor, So is it correct to assume that my users will no longer be able to advertise their webpage links through a direct appearance of that link in their tweets (i.e. http://www.mygreatwebsite.com), because this new initiative will always obfuscate the link within a t.co wrapper? In fact, is it true that the only way the original link would be displayed in a tweet is if the client Twitter app viewing the tweet took advantage of the entities information provided with the tweet and converted the t.co link back to the original link prior to displaying the tweet (something my app has no control over)? Just my opinion, but I don't think Twitter should alter the content of their clients' tweets. How can Twitter know for sure that the alteration will be harmless to the original intended meaning of the tweet? What if, as a joke, a user wanted to include in their tweet the phrase www.whatthehell.com? Twitter would convert that into a t.co wrapper that goes no where, and destroy the meaning of the tweet in the process? I can appreciate why Twitter wants to be in the click loop for embedded URLs, but can you think about it some more and perhaps come up with a less intrusive way of do it? Ron On Jun 10, 9:44 am, Taylor Singletary taylorsinglet...@twitter.com wrote: While it's true that some details are still being worked out, the following is the intention: a) You post the linkhttp://f.ws/tcowithin a tweet b) Within the published, text component of the tweet, you'll see the t.coURL c) within the entities of the tweet, you'll see yourhttp://f.ws/tcolink d) It's up to clients on how they want to render the link. They might want to render it as a t.co link. They might want to reference the annotation and render the URL there (which would be an f.ws link, not the ultimate destination). They might want to do something else with how they display the URL, or interpret the URL referenced in the entity by some other means. Taylor On Wed, Jun 9, 2010 at 9:06 PM, TJ Luoma luo...@gmail.com wrote: On the list we were told: our current plan is that no user will see a t.co URL on twitter.com but we still have some details to work through. the links will still be displayed as they were sent in, but the target of the link will be the t.co link instead. and, we want to provide the same ability to display original links to developers. we're going to use the entities attribute to make this possible. On the website, (http://blog.twitter.com/2010/06/links-and-twitter-length-shouldnt.html) Twitter said: When this is rolled out more broadly to users this summer, all links shared on Twitter.com or third-party apps will be wrapped with a t.co URL. A really long link such as http://www.amazon.com/Delivering-Happiness-Profits-Passion-Purpose/dp...be wrapped as http://t.co/DRo0trjfor display on SMS, but it could be displayed to web or application users as amazon.com/Delivering- or as the whole URL or page title. Ultimately, we want to display links in a way that removes the obscurity of shortened link and lets you know where a link will take you. Reading that last sentence, it makes it sound like you are going to auto-expand shortened URLs, which would effectively kill all other URL shortening services. Can someone clarify this? I searched through the list archive but didn't see an answer. If I post http://ƒ.ws/tco http://xn--3ha.ws/tco to Twitter (which is a redirect to http://blog.twitter.com/2010/06/links-and-twitter-length-shouldnt.html), will the user see http://ƒ.ws/tco http://xn--3ha.ws/tco and if the user clicks on http://ƒ.ws/tco http://xn--3ha.ws/tco will it actually go through (for analytics, etc)? Thanks! TjL
[twitter-dev] Re: link wrapping on the API
Users are accustomed to the fact that use of *free* services is entirely *as is* and at their own risk, so none of us should feel we have to protect their privacy or their security beyond this original expectation. If they don't like the performance, security, or privacy implications of this change, they'll leave Twitter, just like they left Facebook. But that is ultimately Twitter's responsibility to control and react to. Our responsibility is to keep rowing collectively in the same direction, or get off the boat. :) On Jun 9, 10:17 am, Harshad RJ harshad...@gmail.com wrote: On Wed, Jun 9, 2010 at 6:48 PM, Dewald Pretorius dpr...@gmail.com wrote: I don't buy the click tracking privacy argument. Twitter will have no more insight into clicks than what bit.ly or any other shortening service has, The difference being that the user who clicks the links in Twitter will have most probably logged into Twitter. Thus, Twitter can directly associate a click with a user. When clicking on bit.ly shortened URLs it is very very unlikely that the user is logged into bit.ly. That is because only people who shorten URLs need a bit.ly account (which is a very small percentage). -- Harshad RJhttp://hrj.wikidot.com
[twitter-dev] Twitter Fail Whale All Morning
Is anyone else hearing complaints about Twitter Fail Whale popping up practically continuously all morning?
[twitter-dev] Re: link wrapping on the API
I just had one of those *rough edges* brought to my attention that I think may also have already been alluded to on this thread. Some users use long URLs as a portion or even their entire tweet. This tweet technique is being used significantly in tweets about the Gulf oil spill crisis, for example. (i.e. http://www.grist.org/aritcle/2010-06-08-does-obama-need-more-not-fewer-oilmen-in-his-administration). The author of such a tweet fully expects that this message will be conveyed in the tweet itself, by virtue of the message conveyed by the long URL - not just the URL destination's content. It doesn't sound like this interesting and useful melding of tweet text and tweet attachments will be possible any longer after the t.co wrapper initiative is implemented. That would be a real shame... Good point Ed, about staying in the game. Fortunately, we can row and talk at the same time. :) On Jun 9, 11:47 am, M. Edward (Ed) Borasky zn...@borasky- research.net wrote: Quoting Ron B rbtheron...@gmail.com: Users are accustomed to the fact that use of *free* services is entirely *as is* and at their own risk, so none of us should feel we have to protect their privacy or their security beyond this original expectation. If they don't like the performance, security, or privacy implications of this change, they'll leave Twitter, just like they left Facebook. Ah, but they *aren't* leaving Facebook! They're continuing to join and share. Facebook and its hundreds of millions of users are continuing to co-evolve. And *when* - not *if* - the FUD brigade realizes it can't take Facebook out, it will turn its energies on Twitter. I hope as a community / ecosystem / whatever, we're ready for that. But that is ultimately Twitter's responsibility to control and react to. Our responsibility is to keep rowing collectively in the same direction, or get off the boat. :) Well, to the extent that it's possible, sure. But groupthink can kill a product / service too. There are clearly some *technical* rough edges on link wrapping that need to be discussed / debated.
[twitter-dev] Re: Clock Ticking on Basic Authpocalypse
Thanks for the reply. Yes, I did see your earlier post. I was hoping someone from Twitter would have greater insight into which media hosting services they were working with (assuming Twitter would most likely be involved at a corporate level with these other companies), and what features may be lost in the conversion. As I mentioned, I have already tested TwitPic and yFrog. But both no longer support Upload Post. Do the others you mentioned also lose that functionality? Img.ly is supposedly in the works. Is anything going on with Posterous? Is the loss of Upload Post a systemic OAuth issue for the time being? It's not easy for some of us to submit app revisions in rapid succession, and not including functionality in the first place is always better than taking it away later. Any help anyone can provide to help us get it (more right) the first time would be deeply appreciated by all. On May 31, 4:54 am, Rich rhyl...@gmail.com wrote: I posted such a list a week or so back I have successfully integrated: Twitpic Yfrog (they only allow the XML version of verify_credentials rather than json) Twitgoo Mobypicture Twitvid I believe pikchur also supports it but I haven't had the chance to test it yet On May 31, 1:30 am, Ron meerkat...@gmail.com wrote: With the clock ticking on Basic Authpocalypse (T-30 days and counting), what is the state of media hosting providers with regards to OAuth Echo compliance? Those of us developing mobile client apps need about two weeks to get our revised apps through the relevant approval processes, so we're down to about two weeks left before needing to submit something or risk our apps not working anymore. I have successfully tested with TwitPic and yFrog, but both seem to have lost Upload Post functionality when moving to OAuth Echo. Img.ly said they're still working on their implementation. Posterous is still a ? Can anyone share a list of providers ready to begin testing their new OAuth Echo functionality, along with a heads-up about any lost functionality resulting from the move? It's becoming increasingly important to find out who's going to be on the playing field with what functionality so we can revise our apps accordingly in advance of the approaching deadline.
[twitter-dev] Clock Ticking on Basic Authpocalypse
With the clock ticking on Basic Authpocalypse (T-30 days and counting), what is the state of media hosting providers with regards to OAuth Echo compliance? Those of us developing mobile client apps need about two weeks to get our revised apps through the relevant approval processes, so we're down to about two weeks left before needing to submit something or risk our apps not working anymore. I have successfully tested with TwitPic and yFrog, but both seem to have lost Upload Post functionality when moving to OAuth Echo. Img.ly said they're still working on their implementation. Posterous is still a ? Can anyone share a list of providers ready to begin testing their new OAuth Echo functionality, along with a heads-up about any lost functionality resulting from the move? It's becoming increasingly important to find out who's going to be on the playing field with what functionality so we can revise our apps accordingly in advance of the approaching deadline.
[twitter-dev] Re: How long does it take to get approved with xAuth?
XAuth is is the right choice for an end-user client app and satisfactorily resolves the UX issues in client applications that OAuth creates. Unfortunately, many web-app developers simply don't know enough about end-user client app development to understand these UX issues, or why end-user client application trust is neither an issue that needs addressing nor one that OAuth can (nor even attempts to) address. It shouldn't take more than a week or two to get your authorization from Twitter to use XAuth if you're applying for a client app. On May 30, 1:40 pm, Bernd Stramm bernd.str...@gmail.com wrote: On Sun, 30 May 2010 11:14:54 -0700 Abraham Williams 4bra...@gmail.com wrote: On Sun, May 30, 2010 at 11:01, Bernd Stramm bernd.str...@gmail.com wrote: The user does trust the app, otherwise they would not be using it. The problem with the scheme of using the app *and* a browser is that the user has to trust *both* of them. And if they don't trust the app, why are they using it to post their tweets? Trust is not a boolean value. There are levels of it. I trust my mobile browser to not take over my Twitter account but I only trust random new Twitter client to not post spam. If the Twitter client breaks my trust it is easy to revoke access to it. Is it easy for most users? The authentication token doesn't expire, so an application (any application, not just desktop/mobile client) can do what it wants for quite a while. You should be careful with trusting browsers, mobile or otherwise. They are very leaky. And my point remains, when using a browser *and* a standalone client, the user trusts both of them. From the point of view of the honest application developer, I do not want to assume that another application (the browser) which is completely unknown to me, is trustworthy. Hence I prefer the solution with the small integrated webview in my application. But also, what do people to with their twitter account that needs protecting, other than posting messages and media content? And of course giving away great data to the data miners. A lot of this authentication business misses the easiest intrusion vector anyway. People will steal your phone, and have access to everything you store on it. Including any authentication for serious business. Nevermind trusting the standalone app or the browser, the entire system is easily compromised if its stolen. -- Bernd Stramm bernd.str...@gmail.com
[twitter-dev] Source param in Lists timelines
The source param in Lists timelines seems to be hardwired to web. Is this on purpose, or is something wrong? i.e. http://api.twitter.com/1/user/lists/list_id/statuses.format, yields sourceweb/source.
[twitter-dev] Re: Source param in Lists timelines
Hi Taylor, Thanks for getting back to me so quickly. You're right, this was cockpit error on my part. I apologize for taking up your time unnecessarily. On another note, I've have an xAuth access request in for over a week now. Can you help expedite it. It's for registration ID: 135852. I'm pretty much dead-in-the-water with further testing on my app until this approval goes through. Thanks again! Ron On May 11, 12:48 pm, Taylor Singletary taylorsinglet...@twitter.com wrote: Hi Ron, I'm not able to reproduce this problem -- when I fetch a group of statuses from a list, I'm seeing unique source tags corresponding to the origin of the updates. Is it possible that the tweets you're evaluating in your list were all, in fact, posted via web? Taylor Singletary Developer Advocate, Twitterhttp://twitter.com/episod On Tue, May 11, 2010 at 9:23 AM, Ron B rbther...@gmail.com wrote: The source param in Lists timelines seems to be hardwired to web. Is this on purpose, or is something wrong? i.e.http://api.twitter.com/1/user/lists/list_id/statuses.format, yields sourceweb/source.
[twitter-dev] Re: Schedule for API call rate increases with oAuth?
Some of you talk about an app as if it were a person. Sure, apps could be malicious, but that includes every app on your computer - doesn't it? Why should you assume some of the apps handling your credentials can be more trustworthy than others? Any app that is on your computer while you type your username/password can potentially obtain that information. And what about the app at the far end of the Internet that may be pretending to be Twitter's authorization page? Frankly, I think the whole argument about malicious apps is a little over the top for an OAuth discussion. Why would you believe that basic auth developers are required to store passwords in plain-text...? I'm a basic auth developer, and I have always stored username/passwords encrypted in a access protected keychain file. I do not know of a single developer of any platform that would be so irresponsible as to store username/passwords in plain text - well until now. :) Twitter's only interest in OAuth (like any other platform provider) is to control access to their platform at an application level, and to allow other platform providers access to their users' data. This altruistic nonsense about Twitter being more interested in your personal password protection than your bank, your online stock trading company, or the IRS, is just that - nonsense. There's nothing wrong with Twitter's decision to implement OAuth. I makes perfect sense. I'd do it, if I were in their shoes. Why are so many of you rushing to their defense with these manufactured alternative reasons for why they are implementing it? On Apr 27, 5:52 am, glenn gillen gl...@rubypond.com wrote: Anytime you enter your credentials, regardless of where, you open yourself to being snooped. I believe that is far less likely when communicating with YOUR app on YOUR computer, than it is via a browser over the open Internet to a 3rd party that may or may not be who you think it is... Supporting this option though Twitter is dependent on the security procedures of every 3rd party to maintain the integrity of an account. WithOAuthat least should an individual 3rd party have their security breached then access to just that 3rd party can be terminated. Also with basic auth developers are required to store passwords in plain-text (or at least in some retrievable form) and as someone else has already pointed out with the propensity for users to use the same password on many services this exposes them to undue risk from a breach of a 3rd party or via a malicious developer. I'd sleep much easier at night if I didn't know anybody else's password, I'm sure the Twitter team would prefer if only a user knew their own password too. -- Glennhttp://glenngillen.com/ -- Subscription settings:http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
[twitter-dev] Re: Schedule for API call rate increases with oAuth?
Hi Raffi, Didn't mean to sound like lambasting. I have read the history on OAuth, which is why I commented as I did. I agree with both of your points. Both are very good reasons to implement OAuth. I just don't believe protecting users against their own app is a fundamental reason to implement OAuth, nor is safeguarding user credential databases against hacker attacks. The suggestion that these were some of the primary benefits of implementing OAuth sounded like spin to me, so I said so. I've implemented OAuth some time ago, with no real issues. For the environment Twitter is in, I think it makes perfect sense. My BS sensors went off at some of the comments I saw circulating as to what OAuth's principal benefits are. But if you'd rather not see any dissenting opinions expressed on this forum, I can happily keep my thoughts to myself. Ron On Apr 27, 11:29 am, Raffi Krikorian ra...@twitter.com wrote: hi ron. i'm just seeing you respond to every message in this thread lambasting oauth, so i figured it may be time to say something. i suggest you read up on the history of oauth? there are two reasons, that i care about, that oauth is important: 1. *minimizing the exposure of user's usernames and passwords*: in the base case, no - i don't trust random applications to have access to user's passwords. this is similar to the argument i made in this blog post: http://mehack.com/xauth-and-perhaps-the-need-for-socializing-ap. there are a few applications i trust more than i trust other apps: mail.app on my mac, for example, safari and chrome, for example. sure, its possible to attack those applications -- but, i believe, the probability of somebody managing an attack on those applications is significantly greater than the probability of an application, malicious or not, exposing a password. the password could be exposed for malicious means, or simply a bug. mail.app, safari, chrome, etc. have massive corporations who are very much incentivized to patch/update them if there is a security problem. random-twitter-app? not so much. (a different argument on this theme, however, is whether users care about this) 2. *providing differing levels of access*: twitter implements read and read/write as access profiles on applications. it is possible to give an application only read access to your account, which means that it cannot post a status update -- only read your timeline and such. this is not possible in a world where you are handing out your password. if a user's password is giving to a third party application, then all the permissions of a user is exposed. sure - i also have interests regarding visibility into the platform (if an application has a bug, we can trivially figure out which application it is; if a user is curious which app is reading my DMs we will be able to tell them, etc.). but i also really do care about the security of users. Some of you talk about an app as if it were a person. Sure, apps could be malicious, but that includes every app on your computer - doesn't it? Why should you assume some of the apps handling your credentials can be more trustworthy than others? Any app that is on your computer while you type your username/password can potentially obtain that information. And what about the app at the far end of the Internet that may be pretending to be Twitter's authorization page? Frankly, I think the whole argument about malicious apps is a little over the top for an OAuth discussion. Why would you believe that basic auth developers are required to store passwords in plain-text...? I'm a basic auth developer, and I have always stored username/passwords encrypted in a access protected keychain file. I do not know of a single developer of any platform that would be so irresponsible as to store username/passwords in plain text - well until now. :) Twitter's only interest in OAuth (like any other platform provider) is to control access to their platform at an application level, and to allow other platform providers access to their users' data. This altruistic nonsense about Twitter being more interested in your personal password protection than your bank, your online stock trading company, or the IRS, is just that - nonsense. There's nothing wrong with Twitter's decision to implement OAuth. I makes perfect sense. I'd do it, if I were in their shoes. Why are so many of you rushing to their defense with these manufactured alternative reasons for why they are implementing it? On Apr 27, 5:52 am, glenn gillen gl...@rubypond.com wrote: Anytime you enter your credentials, regardless of where, you open yourself to being snooped. I believe that is far less likely when communicating with YOUR app on YOUR computer, than it is via a browser over the open Internet to a 3rd party that may or may
[twitter-dev] Re: Schedule for API call rate increases with oAuth?
Where end-user credentials are stored is entirely up to the end-user, as is who they choose to share the information with. OAuth does not and cannot address this, as it shouldn't - and neither should Twitter When a user types their username/password on the Twitter authorization screen, they are using someone's browser on someone's computer either of which could harbor malicious software that could capture what was typed, and are communicating these credentials over the open Internet using at best nothing more than the https basic auth uses. In addition, training users to become accustomed to providing their user credentials outside of their apps to requests made over the open Internet makes them a lot more susceptible to phishing attacks. How exactly is this then better security than basic auth? The only real advantage to using OAuth is more application access control and protected shared user access between application platforms. There are no real tangible advantages for the end-user. With basic auth, all an end-user had to do was tell the app their user credentials. With OAuth, they have to leave their app to tell Twitter, wait for Twitter to tell their app, and then return to their app to continue the process. At least with XAuth, the user can continue to tell their app their user credentials and have all this OAuth stuff handled behind the curtain for them. I understand the very compelling reasons why Twitter wants to convert to universal OAuth access. But let's quit spinning OAuth as this great new security enhancement technology that will benefit end- users It's not. It wasn't even meant to be. It was just meant to help the Twitters of the world communicate end-user information among each other without having to share their end-users' credentials. On Apr 26, 7:08 pm, Raffi Krikorian ra...@twitter.com wrote: What's the latest schedule for increasing the allowed API call rate for oAuth users? That seems to have been lost in the shuffle. unclear - we're actively working with our infrastructure and operations teams on capacity planning specifically so we can increase the rate limits. Also, is there any advantage to xAuth over the desktop PIN oAuth scheme (for a desktop application)? I'm putting together a proposal and can't see any real advantage to it on the desktop, especially since I have the oAuth code done, thanks to Marc Mims' Net::Twitter. ;-) personally, i would -love it-, if everybody just used the oauth web workflow so that none of you even see a user's username/password. that would make the web more secure. i'm even soliciting suggestions on what we could do to make the web workflow better. i understand, however, that the PIN workflow can be off putting for some users. so, implementing oAuth instead of xAuth would make me happy - but i doubt that's a motivation for most developers. -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- Subscription settings:http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
[twitter-dev] Re: Schedule for API call rate increases with oAuth?
So the more correct response would be that neither OAuth or Basic Auth can take over a user's account, since it is the API functionality that is the gating factor. So then you have to ask yourself, do you believe your user credentials are more secure when only you, your app, and Twitter will ever see them outside of a secure https connection, or do you believe they are more secure when you, your browser, the open Internet, and something that looks like a Twitter authorization page will see them - and a separate set of credentials (access token and token secret) will also allow access to the same account? On Apr 26, 8:30 pm, Abraham Williams 4bra...@gmail.com wrote: You used to be able to change an accounts email address through the API but it looks like Twitter removed that feature so no. An OAuth application can not take over a users account. Abraham On Mon, Apr 26, 2010 at 17:49, philip crawford philipha...@gmail.comwrote: With a users twitter password, I can take over their account by changing email password. Can I do that with OAuth credentials? On Mon, Apr 26, 2010 at 7:43 PM, Ron B rbther...@gmail.com wrote: Where end-user credentials are stored is entirely up to the end-user, as is who they choose to share the information with. OAuth does not and cannot address this, as it shouldn't - and neither should Twitter When a user types their username/password on the Twitter authorization screen, they are using someone's browser on someone's computer either of which could harbor malicious software that could capture what was typed, and are communicating these credentials over the open Internet using at best nothing more than the https basic auth uses. In addition, training users to become accustomed to providing their user credentials outside of their apps to requests made over the open Internet makes them a lot more susceptible to phishing attacks. How exactly is this then better security than basic auth? The only real advantage to using OAuth is more application access control and protected shared user access between application platforms. There are no real tangible advantages for the end-user. With basic auth, all an end-user had to do was tell the app their user credentials. With OAuth, they have to leave their app to tell Twitter, wait for Twitter to tell their app, and then return to their app to continue the process. At least with XAuth, the user can continue to tell their app their user credentials and have all this OAuth stuff handled behind the curtain for them. I understand the very compelling reasons why Twitter wants to convert to universal OAuth access. But let's quit spinning OAuth as this great new security enhancement technology that will benefit end- users It's not. It wasn't even meant to be. It was just meant to help the Twitters of the world communicate end-user information among each other without having to share their end-users' credentials. On Apr 26, 7:08 pm, Raffi Krikorian ra...@twitter.com wrote: What's the latest schedule for increasing the allowed API call rate for oAuth users? That seems to have been lost in the shuffle. unclear - we're actively working with our infrastructure and operations teams on capacity planning specifically so we can increase the rate limits. Also, is there any advantage to xAuth over the desktop PIN oAuth scheme (for a desktop application)? I'm putting together a proposal and can't see any real advantage to it on the desktop, especially since I have the oAuth code done, thanks to Marc Mims' Net::Twitter. ;-) personally, i would -love it-, if everybody just used the oauth web workflow so that none of you even see a user's username/password. that would make the web more secure. i'm even soliciting suggestions on what we could do to make the web workflow better. i understand, however, that the PIN workflow can be off putting for some users. so, implementing oAuth instead of xAuth would make me happy - but i doubt that's a motivation for most developers. -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en -- imby - in my back yard An Experiment in Local Professional Networking http://madison.imby.info/p/Philip.Crawford -- Abraham Williams | Developer for hire |http://abrah.am @abraham |http://projects.abrah.am|http://blog.abrah.am This email is: [ ] shareable [x] ask first [ ] private.
[twitter-dev] Re: Schedule for API call rate increases with oAuth?
Unless I'm wrong (it happens), I believe you can do everything the API offers with OAuth that you can currently do with basic auth. But even if that isn't true, preventing basic auth from allowing username/ password changes is a much more direct solution (and easier) than forcing an OAuth implementation to solve that issue. Anytime you enter your credentials, regardless of where, you open yourself to being snooped. I believe that is far less likely when communicating with YOUR app on YOUR computer, than it is via a browser over the open Internet to a 3rd party that may or may not be who you think it is... On Apr 26, 7:49 pm, philip crawford philipha...@gmail.com wrote: With a users twitter password, I can take over their account by changing email password. Can I do that with OAuth credentials? On Mon, Apr 26, 2010 at 7:43 PM, Ron B rbther...@gmail.com wrote: Where end-user credentials are stored is entirely up to the end-user, as is who they choose to share the information with. OAuth does not and cannot address this, as it shouldn't - and neither should Twitter When a user types their username/password on the Twitter authorization screen, they are using someone's browser on someone's computer either of which could harbor malicious software that could capture what was typed, and are communicating these credentials over the open Internet using at best nothing more than the https basic auth uses. In addition, training users to become accustomed to providing their user credentials outside of their apps to requests made over the open Internet makes them a lot more susceptible to phishing attacks. How exactly is this then better security than basic auth? The only real advantage to using OAuth is more application access control and protected shared user access between application platforms. There are no real tangible advantages for the end-user. With basic auth, all an end-user had to do was tell the app their user credentials. With OAuth, they have to leave their app to tell Twitter, wait for Twitter to tell their app, and then return to their app to continue the process. At least with XAuth, the user can continue to tell their app their user credentials and have all this OAuth stuff handled behind the curtain for them. I understand the very compelling reasons why Twitter wants to convert to universal OAuth access. But let's quit spinning OAuth as this great new security enhancement technology that will benefit end- users It's not. It wasn't even meant to be. It was just meant to help the Twitters of the world communicate end-user information among each other without having to share their end-users' credentials. On Apr 26, 7:08 pm, Raffi Krikorian ra...@twitter.com wrote: What's the latest schedule for increasing the allowed API call rate for oAuth users? That seems to have been lost in the shuffle. unclear - we're actively working with our infrastructure and operations teams on capacity planning specifically so we can increase the rate limits. Also, is there any advantage to xAuth over the desktop PIN oAuth scheme (for a desktop application)? I'm putting together a proposal and can't see any real advantage to it on the desktop, especially since I have the oAuth code done, thanks to Marc Mims' Net::Twitter. ;-) personally, i would -love it-, if everybody just used the oauth web workflow so that none of you even see a user's username/password. that would make the web more secure. i'm even soliciting suggestions on what we could do to make the web workflow better. i understand, however, that the PIN workflow can be off putting for some users. so, implementing oAuth instead of xAuth would make me happy - but i doubt that's a motivation for most developers. -- Raffi Krikorian Twitter Platform Teamhttp://twitter.com/raffi -- Subscription settings:http://groups.google.com/group/twitter-development-talk/subscribe?hl=en -- imby - in my back yard An Experiment in Local Professional Networkinghttp://madison.imby.info/p/Philip.Crawford
[twitter-dev] Re: countdown to OAuth / basic auth removal / OAuthcalypse
China's policy didn't just recently change, Twitter's did. So it is Twitter telling us that we may not be able to support China and other firewall blocked countries any longer. It is, after all, within Twitter's power to continue to support Basic Auth. It is their conscious decision not to, despite the significant negative ramifications being brought to their attention. In an earlier comment from Twitter: twitter.com is trying to drive people to understand and discover what's going on in the world. No one in the world needs to understand and discover what's going on more than the people of these communist-block countries that otherwise see only what their governments allow them to see. It is unfortunate that Twitter plans to turn their back on them. Then again, what's a billion people here or there?... On Apr 25, 9:04 pm, Abraham Williams 4bra...@gmail.com wrote: It is not twitter telling you it is China. -- Little androids dreaming of Nexus Ones compiled this text. On Apr 25, 2010 6:53 PM, Dewald Pretorius dpr...@gmail.com wrote: Raffi, We really need a resolution for this issue before Basic Auth is deprecated. It sounds as if Twitter is telling developers of web apps that they cannot provide service to Chinese users, and other users behind firewalls that block access to twitter.com. But that can't be right, can it? On Apr 25, 4:49 am, jaronbarends jaronbare...@gmail.com wrote: I moved my web based app from ba... This issue has discussed in this group before here: https://groups.google.com/group/twitter-development-talk/browse_threa... Being a frontend developer, I may have misunderstood the outcome of that discussion (I certain... -- Subscription settings:http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
[twitter-dev] Tweets are not showing up in search results, have not been since Thursday
I have noticed that tweets from my twitter account @thumbfight suddenly stopped appearing in the Twitter search results starting on Thursday. Anyone else have this problem? I submitted a Twitter support request, which was closed by an automated program they have regarding new Twitter accounts. This account is not new, and up until Wednesday evening all was working well. Anyone else experiencing, or have experienced in the past, this kind of problem? Ron Evans @deadprogram
