Breaches Twitter TOS (OAuth twitter authentication uses embedded browser)

This is not a duplicate of bug #627565 - more a bug in the current fix forbug #627565

If a new browser will be opened, secret and access token cannot be passed back to Gwibber. In this case, we have to use embedded browser.

Ah good, there's a bug now :)

After some quick research I ended up here: http://dev.twitter.com/pages/xauth

Has Gwibber already applied for xAuth privileges? Doesn't sound like it should be hard to obtain (and perhaps should've been requests a while ago if it hasn't been yet).

Oh, by the way, an alternative sign-in process for Facebook would also be desirable for the same reasons I outlined in the forum post.

The current process of gwibber is perfectly fine as far as I know. I don't know any twitter client that uses something different there. xauth privileges are only given to applications for the transition phase to oauth.

xAuth keys have special privileges and twitter said they would not give them to us. The current implementation is the simplest for users. If we opened a browser window, we rely on the user needing to copy and paste from the browser into gwibber. I don't really see a problem with embedding a browser into the accounts dialog, it is just a browser and a user can either allow or deny gwibber access. If they don't allow it, then nothing is passed back to gwibber.

The current implementation does not "replicate, frame, or mirror the Twitter website or its design." It is just a browser displaying the full page twitter provides, I see no way this could violate the TOS. I don't see anything that specifies which browsers are allowed, do you have a reference for that?

As far as I can tell, this isn't a breach. If any finds a reference otherwise, please re-open.

The current implementation does frame the Twitter website. The risk is a phishing risk: Gwibber could very well be pretending to display the Twitter website but not actually displaying it.

Anyway, I suppose if xAuth was not granted and Twitter is being such a PITA about it (which I'm glad Ryan Paul has commented on [1]), this method isn't worse than the previous one, and Gwibber can't really help it. Good to know it is being actively looked at, so that if Twitter was ever to fix its progress, Gwibber would adopt it (I suppose).

[1] http://arstechnica.com/security/guides/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong.ars/

It isn't actually framing the website, it is displaying the whole website, just another browser. Twitter's definition of framing is using an iframe, embedded in another page. Twitter is very focused on other web applications that use twitter, not really desktop clients. So they not only don't cater to our use case technically, their terminology is different too.

gwibber-accounts displays the full web page, just like any other browser. As far as phishing attacks go, the user has to tell twitter they are trusting gwibber/ubuntu as a client anyway, if they don't trust the application they wouldn't even get that far. It isn't like some random window that pops up when a user clicks on a link in a web page pretending to be something else. This is a desktop service, which the user has to choose to run, in doing so they are already trusting it.

Ken VanDine wrote on 2010-09-01: …“I don't really see a problem with embedding a browser into the accounts dialog, it is just a browser and a user can either allow or deny gwibber access.”
No it's not "just a browser": in a browser, I can check the URL and the protocal (I use https to log in to twitter). With this embedded browser, I can't check anything.
Oh, and the authorization page says that the application "Ubuntu" is requesting access to twitter. "Ubuntu"? Sorry, that doesn't look good to me.