Abraham,

I am not in the least interested in arguing, my point being that our differing 
subjective
interpretations are meaningless.

Since this isn't a statute, we needn't spend endless hours teasing the intent 
out of it,
we can just ask the guys who wrote it what they meant.  As we have now done.



On 19 May 2011, at 16:35, Abraham Williams wrote:

> 
> 
> On Thu, May 19, 2011 at 08:18, hax0rsteve <hax0rc...@btinternet.com> wrote:
> 
> 1) it isn't
> 
> Ask users if they know that JavaScript can be inserted into UIWebViews that 
> can read their password and I think you will find most of them will be 
> surprised.
>  
> C) it doesn't
> 
> 
> Twitter.com is being framed within the application.
>  
> Of course, it depends how you read it.  But what really matters is what 
> Twitter intended
> when they wrote it.
> 
> +1 for an official twitter comment please.
> 
> 
> 
> 
> Abraham
> -------------
> Abraham Williams | InboxQ | abrah.am
> @abraham | github.com/abraham | blog.abrah.am
> This email is: [ ] shareable [x] ask first [ ] private.
> 
>  
> 
> 
> On 19 May 2011, at 16:13, Tom van der Woerdt wrote:
> 
>> http://dev.twitter.com/pages/api_terms -> II. Principles -> 1. Don't 
>> surprise users -> C. Your application should not: -> replicate, frame, or 
>> mirror the Twitter website or its design.
>> 
>> Tom
>> 
>> 
>> On 5/19/11 5:10 PM, hax0rsteve wrote:
>>> 
>>> 
>>> Tom,
>>> 
>>> Could you clarify :
>>> 
>>> If using a web view is against the ToS, could you state which section ?
>>> 
>>> And if "it soon will be" (which conflicts with the above), what makes you 
>>> think so ?
>>> 
>>> Did I miss something ?
>>> 
>>> Also, if someone from the Twitter team could confirm either of these, this 
>>> would be much 
>>> more helpful.
>>> 
>>> 
>>> 
>>> 
>>> On 19 May 2011, at 16:00, Tom van der Woerdt wrote:
>>> 
>>>> Like I mentioned in my post - use the actual browser which includes an 
>>>> address bar (that's what it's about - without the address bar the user 
>>>> doesn't know it's actually twitter.com and you might just as well use 
>>>> xAuth, lol). Use a callback URL which includes a custom scheme 
>>>> (myapp://oauth_redirect, for example) and catch this URL in your code.
>>>> 
>>>> Tom
>>>> 
>>>> 
>>>> On 5/19/11 4:58 PM, Adriaan Pelzer wrote:
>>>>> 
>>>>> If using a UIWebView is against the TOS, how should app developers 
>>>>> (standalone apps, that is)               authenticate without xauth, in 
>>>>> the light of yesterday's announcements?
>>>>> 
>>>>> Adriaan Pelzer
>>>>> 
>>>>>  //))//\\//\\||//
>>>>> //\\//7//7///\\
>>>>> 
>>>>> putting you in touch with your crowds
>>>>> http://www.wewillraakyou.com
>>>>> twitter: http://www.twitter.com/adriaan_pelzer
>>>>> linkedIn: http://uk.linkedin.com/pub/adriaan-pelzer/4/874/860/
>>>>> skype: adriaan_pelzer
>>>>> +4478 7978 1743
>>>>> 
>>>>> 
>>>>> 
>>>>> On Thu, May 19, 2011 at 3:53 PM, Tom van der Woerdt <i...@tvdw.eu> wrote:
>>>>> 1. Yep
>>>>> 2. NO. There's no difference in oauth/authorize and oauth/authenticate, 
>>>>> except that authenticate will simply pass the "accept/deny" screen if the 
>>>>> user has already accepted the app. Also, don't display it in a WebView, 
>>>>> use the normal browser instead and use a callback URL with a custom 
>>>>> scheme - for example myapp://. Let the browser redirect this URL back to 
>>>>> the app. Again, do NOT use a UIWebView - I'm pretty sure that that's 
>>>>> against the TOS, and if it's not, it soon will be.
>>>>> 3. Yep
>>>>> 4. Yes, you will need to store the consumer token and secret in the code, 
>>>>> and store the user's token and secret in the keychain (or somewhere else, 
>>>>> secure).
>>>>> 
>>>>> The OAuth flow is no different for mobile devices than for desktops.
>>>>> 
>>>>> Tom
>>>>> 
>>>>> 
>>>>> 
>>>>> On 5/19/11 4:45 PM, Andrew W. Donoho wrote:
>>>>>> 
>>>>>> Gentle Twitter Support Folks,
>>>>>> 
>>>>>>  There is an ambiguity in the OAuth flow for mobile devices. As I now 
>>>>>> have little time to move from xAuth to OAuth, I would appreciate it if 
>>>>>> Twitter Support would confirm the following OAuth flow which uses your 
>>>>>> routes.
>>>>>> 
>>>>>> 1) Use "POST oauth/request_token" to get the access token needed for the 
>>>>>> user web dialog.
>>>>>> 
>>>>>> 2) Upon receiving the request token, open a web view using "GET 
>>>>>> oauth/authorize". This is the ambiguous path for mobile devices. It is 
>>>>>> specified that this path must be used for desktop devices. As a mobile 
>>>>>> device is really a wireless desktop device, I believe Twitter wants me 
>>>>>> to use this route in lieu of "GET oauth/authenticate". Other vendors 
>>>>>> also allow the specification of whether this is a mobile device. They 
>>>>>> then provide a web authorization dialog appropriate for a narrow screen. 
>>>>>> It does not appear that Twitter offers this functionality. Could you 
>>>>>> please confirm this? Finally, as my app runs on an iPad, what is the 
>>>>>> preferred web view width? (To support both portrait and landscape 
>>>>>> orientations, it needs to be less than 768 pixels. 600 pixels is a 
>>>>>> common, Apple suggested, width.) Could you please enlighten me to what 
>>>>>> is Twitter's preferred authorization web view width?
>>>>>> 
>>>>>> 3) Use "GET oauth/authenticate" to acquire the access token and access 
>>>>>> secret.
>>>>>> 
>>>>>> 4) As I haven't yet requested my new consumer key and, hence, do not 
>>>>>> know some things, will I also be maintaining a consumer secret for my 
>>>>>> OAuth signature mechanism?
>>>>>> 
>>>>>>  Thank you for your support.
>>>>>>  
>>>>>> 
>>>>>> Anon,
>>>>>> Andrew
>>>>>> 
>>>>>> 
>>>>>> P.S. Thank you for the two week extension for our xAuth to OAuth 
>>>>>> transition. Because Apple                                                
>>>>>>            may still reject my app for unrelated to Twitter issues, four 
>>>>>> weeks is still a totally inadequate period to ensure a zero downtime 
>>>>>> transition. Please recognize both the risks to our business              
>>>>>>                                              and the hardship you are 
>>>>>> imposing on small organizations. Furthermore, Apple's WWDC conference 
>>>>>> occurs in the middle of your current conversion schedule, this only 
>>>>>> allows me, in effect, 3 weeks to make this change. You can really hurt 
>>>>>> us with your imposed schedule. While I doubt that is your intent, it is, 
>>>>>> nonetheless, a likely outcome. Please double, at least, your conversion 
>>>>>> period to 8 weeks. 
>>>>>> 
>>>>>> ____________________________________
>>>>>> Andrew W. Donoho
>>>>>> Donoho Design Group, L.L.C.
>>>>>> a...@ddg.com, +1 (512) 750-7596, twitter.com/adonoho
>>>>>> 
>>>>>> "When you can't imagine how things are going to change, 
>>>>>>     that doesn't mean that nothing will change.
>>>>>>         It means that things will change in ways that are unimaginable."
>>>>>>             Bruce Sterling, January 02, 2009
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> 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 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 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 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 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 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 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 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 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

Reply via email to