TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Twitter’s Shit Sandwich

219 点作者 berberich大约 14 年前

27 条评论

sriramk大约 14 年前
The common OAuth flow inside a mobile app is to show a web browser dialog which loads Webkit/IE/etc and show you the Twitter log-in UI. Frankly, I have no idea how to verify this page is actually Twitter's UI - there is no browser chrome, no SSL lock icon or any other trust indicators. It could as easily be just a random dialog constructed by the app author. I just don't see the value-add of OAuth in mobile app scenarios. Note that xAuth doesn't mean the app stores the passwords - you store a token like in OAuth. Of course, whether the app developer can be trusted to not store the username/password is a different story.<p>Btw, I have a popular WP7 app which uses xauth, primarily because Twitter's login screen is broken on the Windows Phone browser.
评论 #2562448 未加载
评论 #2564061 未加载
评论 #2562211 未加载
评论 #2562452 未加载
jrockway大约 14 年前
I'm OK with requiring OAuth. It's hard to trust third parties with data they collect themselves: see Sony and Gawker. It's even harder to trust them with data that belongs to someone else: they might one-way-hash their own passwords, of course, but they can't do that to your Twitter password. It's probably sitting in a database, cleartext, for every rogue employee or cracker to see.<p>Even if you don't care about someone having your credentials, you can't trust them not to intentionally or accidentally misuse your account. The only way to trust a third party is to give them an account that can only perform the actions that you specify, and that's exactly what OAuth does. Of course you have to use Twitter's site for that: that's where the trust comes from.<p>Anyway, I've used Android apps that pop open a web browser for the authentication part and then return you to the native app. It's, by definition, not seamless... but it's not confusing or slow or difficult or annoying. I imagine the experience is similar on iOS and Blackberry. So I don't see a problem here: all I see is the ability for users to have better protection over their personal information. That means they will be more willing to try your product, because the damage it can cause is limited. Less risk, more opportunity for innovation.<p>Hardly a "shit sandwich".
评论 #2562593 未加载
评论 #2562119 未加载
评论 #2562128 未加载
评论 #2562107 未加载
评论 #2562399 未加载
评论 #2562161 未加载
评论 #2562204 未加载
tolmasky大约 14 年前
Not sure if this would break some TOS or something but can't a native app just continue asking you for your username and password and just do this oath stuff in an offscreen webview, making it seem just like with xauth? It's almost disingenuous to show an in app browser with oath and confuse the user into thinking he has the same sort of "same origin" security as oath in the browser -- he doesn't, that webview is completely controlled by the app and thus offers no additional security over xauth whatsoever.
评论 #2562175 未加载
评论 #2562095 未加载
评论 #2562097 未加载
tlrobinson大约 14 年前
As many others have pointed out, OAuth is extremely susceptible to phishing or snooping of passwords on platforms where the OAuth flow is done in an embedded web view, which can be considered "untrusted", vs. your browser which could be considered "trusted" because you know the URL bar is accurate, and there's no mechanism for 3rd parties to scrape passwords (well, except for user scripts / extensions)<p>OAuth does also remove the burden of securely storing passwords, but so does xAuth.
评论 #2563134 未加载
ashbrahma大约 14 年前
"I can’t think of any reason why Twitter would force native apps through OAuth other than to create a hurdle that steers users toward Twitter’s own official native clients" &#62; I think this nails it.
evgen大约 14 年前
At what point is someone going to just say "fuck Twitter, Inc." and create a library of simple web-scrapers that emulates most of the API that twitter has been trying to claw back from the third-party dev community for the past year via the standard http interface? Such a library may be brittle, but it can't be much worse than the "yeah, we told you to do this a couple of months ago but now we changed our minds and you have two weeks to comply with our new policy" status that exists now?
neovive大约 14 年前
On a related note. Did anyone else notice today's removal of the "status" query string variable and the switch solely to "Web Intents"? <a href="http://dev.twitter.com/pages/intents" rel="nofollow">http://dev.twitter.com/pages/intents</a>. I believe many Twitter sharing buttons used the simpler query string approach over the full API with OAuth.
评论 #2565031 未加载
terhechte大约 14 年前
It's clear that Twitter wants to move innovation in their ecosystem away from native clients that duplicate their exiting functionality. Instead they seem to be keen to support projects that offer innovative ways of displaying, sorting, or working with Twitter's firehose.<p>Instagram does something similar. Their API terms of use read: "You cannot replicate the core user experience of Instagram.com" (<a href="http://instagram.com/developer/" rel="nofollow">http://instagram.com/developer/</a>)<p>I guess it is a matter of keeping potential future monetization options.
评论 #2562402 未加载
philfreo大约 14 年前
The flow of OAuth on mobile is not nearly as bad when the app opens Safari to the OAuth screen, and when the user hits accept/reject they get sent to a URI like myappname://oauth which the iPhone app can register to mean relaunch the app
评论 #2563814 未加载
guan大约 14 年前
Twitter has shown quite a lack of taste in recent months (e.g. dickbar). I wouldn’t be surprised if they simply hadn’t thought about these issues, and that it’s not a sinister plan to further encourage use of the official Twitter apps.
评论 #2562109 未加载
gcampbell大约 14 年前
The deadline has been pushed back two weeks to June 14: <a href="http://groups.google.com/group/twitter-development-talk/msg/dbe591c0088a4b18" rel="nofollow">http://groups.google.com/group/twitter-development-talk/msg/...</a>
buddydvd大约 14 年前
Browser-based OAuth flow (like Facebook's new iOS SDK -- the one that avoids using embedded webview) has two advantages:<p>1.) Single sign on. If you're already logged in to the site in the browser, you don't have to enter your user/password again. Also, if you don't trust the app invoking the web browser, you can always exit the app and pre-login to site with the web browser before running the app again.<p>2.) Optional interstitial pages. Sometimes, your account may be accessed from some questionable location. The OAuth flow enables challenging users with additional security questions before giving authorization to the app (e.g. Facebook's identify-your-friends'-faces challenge, enter-your-birthday challenge, etc.)
ak1394大约 14 年前
Wow. I guess I'll be shutting down my feature-phone twitter client because of it. It's been in life-support mode for about a year, but I guess that's the end of it.
评论 #2562231 未加载
nhangen大约 14 年前
Isn't Facebook doing the same thing? In fact, I just got an email from them today that they're forcing the issue and all devs must adopt oAuth by September.
zyb09大约 14 年前
Yes! I'm glad finally someone like Gruber shared his opinion on this. Integrating Twitter in native apps has been a huge pain for me and trying to explain clients why they can't have a native branded user/password dialog in the app (like "all" the other apps) is really tedious. For such a big player like Twitter they made it really cumbersome for 3rd partys to do simple tasks like posting a tweet.
daveman692大约 14 年前
This would become quite a bit simpler if they also moved to OAuth 2.0 (bearer tokens over SSL) instead of sticking with 1.1 (HMAC signatures).
评论 #2562192 未加载
joe_the_user大约 14 年前
Hey,<p>I'm designing a Twitter desktop client from the ground-up with Oauth. It is annoyingly over-complexified but doable. I suppose I can take a grim pleasure that others will have to suffer with me...
评论 #2562785 未加载
beerglass大约 14 年前
The biggest issue with Twitter oAuth sign-in that we have faced as developers is that the Twitter sign-in page does not work at all or is not optimized for feature phones with smaller screens and not running Webkit based browser. Always wished that Twitter provided a URL - twitter.com/appname that users could go to and assign all permissions and got a simple key + PIN that they could enter in our app to access their tweets.
ashbrahma大约 14 年前
Ryan Sarver (@rsarver) has posted a response with updates based on feedback:<p><a href="http://groups.google.com/group/twitter-development-talk/browse_thread/thread/e954fc0f8b5aa6ec/dbe591c0088a4b18" rel="nofollow">http://groups.google.com/group/twitter-development-talk/brow...</a>
tomkarlo大约 14 年前
What if Twitter decides to start putting ads for its own native clients on the OAuth screen? Given recent history, is there any reason this would be a surprise?
BlazingFrog大约 14 年前
&#62; "So long as you remain within the app, there’s no security advantage for OAuth in an embedded web view over xAuth"<p>Yes there is. I don't trust the developer enough to give her/him my user ID and password so OAuth works for me.
评论 #2562092 未加载
评论 #2562086 未加载
chopsueyar大约 14 年前
Your CSS fonts are tiny.
grandalf大约 14 年前
If Twitter were simply to implement Oauth2 this would not be an issue.
评论 #2562334 未加载
kqueue大约 14 年前
twitter xAuth is not secure. Why do you want me to hand over my username/password to a third party service?
drivebyacct2大约 14 年前
I'm not giving my username and password to my online accounts to random native or web apps when the service in online account in question provides oAuth.
评论 #2562103 未加载
leon_大约 14 年前
The last time I looked xAuth was not available for everyone. You had to request access to it and they often wouldn't give you the access.<p>I didn't get xAuth for my apps so I had to go the OAuth way. And I believe only a few popular apps got xAuth.
Rickasaurus大约 14 年前
Cry me a river of data mined tears.