RE: iphone urls

Pownce, a similar application to Twitter, uses the pownce:// scheme on the iphone to move back and forth between their application and their web site. This is particularly useful in their login flow which uses OAuth. OAuth requires sending users (using a browse) to their service provider for authorization (it's a delegation protocol) and are then redirected back to the calling site (to notify it can continue). In case of an desktop or mobile application, normal http callbacks would require opening a listening socket (and potentially a firewall configuration). Instead, the Pownce application asks the service provider to redirect the user back to a pownce:// url which on the iphone brings up the Pownce application. The result is a seamless integration of the application and browser.

The technical problem with this flow is that many service providers will block such urls from being used for callbacks because they have no way to verify where they will lead and if they hold security risks for the user. Since it is the remote service provider who is redirecting the user, and since the user usually have a higher trust relationship with the service provider, the user is more likely to allow that redirect to go through. Yahoo's OAuth implementation does not allow such url schemes used, or even any unverified http urls (something people have complained about).

The key is how the browser handles launching applications from a security standpoint. Content types do not offer sufficient control over the user flow, and make it more difficult to share a common content type (like an XML config schema) without opening another dialog for the user to select from. One suggestion I have seen was to use an application scheme like application://pownce/some_path. It doesn't solve any of the above concerns but at least indicates to the service provider what the intention really is.

Either way, there is a real need here and without any better (and complete) solution, people are happy to use what works.

EHL

> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf
> Of Stefan Eissing
> Sent: Thursday, October 02, 2008 3:34 AM
> To: Alan Ruttenberg
> Cc: Mark Nottingham; W3C TAG; HTTP Group Working
> Subject: Re: iphone urls
>
>
>
> Am 02.10.2008 um 11:35 schrieb Alan Ruttenberg:
>
> > The alternative in this case would be better IPC on the iphone. My
> > read is that the twitterific "scheme" isn't something one would use
> > to publish on the web. Rather it's a way to hook things on the
> > iphone so that one application can easily call a service that
> > another application publishes. The "other" application creates an
> > openURL handler, part of it's own application, which apparently
> > makes the "scheme"  globally accessible.
>
> That is the current use there, yes. But with things like ical: and
> itunes: uri schemes in OSX already, I hold any bet that we will soon
> see app uri schemes spreading from the iPhone apps to the OSX apps.
> And then someone will build support into FF?
>
> I think application uri schemes result from something lacking in URI
> dispatching and maybe web arch. Taking the simple "ical:" uri scheme
> on OS X, designers of web pages wanted something to say "click here to
> add this to your calendar". While that is a fair use case, the design
> with ical: uri schemes is a poor approach.
>
> Instead imagine the web page to offer additionally "click here to
> remove this from your calendar". Clearly, neither the ical: uri
> scheme, nor the w3c endorsed content-type based dispatching can
> perform the task. Would something like
>
>    <a href="http://example.org/event.ics" rel="calendar.add">Add this
> event to your calendar</a>
>    <a href="http://example.org/event.ics"
> rel="calendar.remove">Remove this event to your calendar</a>
>
> be desirable? Of course this needs some browser infrastructure.
>
> The alternative approach is to embedd
>
>    <a href="http://example.org/event.ics" type="text/calendar">An
> interesting event for you!</a>
>
> in a page and let the user choose actions from a context menu. But
> that makes a very poor user interface.
>
> //Stefan
>
>
> --
> <green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany Amtsgericht
> Münster: HRB5782
>
>
>
>


> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf
> Of Stefan Eissing
> Sent: Thursday, October 02, 2008 3:34 AM
> To: Alan Ruttenberg
> Cc: Mark Nottingham; W3C TAG; HTTP Group Working
> Subject: Re: iphone urls
>
>
>
> Am 02.10.2008 um 11:35 schrieb Alan Ruttenberg:
>
> > The alternative in this case would be better IPC on the iphone. My
> > read is that the twitterific "scheme" isn't something one would use
> > to publish on the web. Rather it's a way to hook things on the
> > iphone so that one application can easily call a service that
> > another application publishes. The "other" application creates an
> > openURL handler, part of it's own application, which apparently
> > makes the "scheme"  globally accessible.
>
> That is the current use there, yes. But with things like ical: and
> itunes: uri schemes in OSX already, I hold any bet that we will soon
> see app uri schemes spreading from the iPhone apps to the OSX apps.
> And then someone will build support into FF?
>
> I think application uri schemes result from something lacking in URI
> dispatching and maybe web arch. Taking the simple "ical:" uri scheme
> on OS X, designers of web pages wanted something to say "click here
> to add this to your calendar". While that is a fair use case, the
> design with ical: uri schemes is a poor approach.
>
> Instead imagine the web page to offer additionally "click here to
> remove this from your calendar". Clearly, neither the ical: uri
> scheme, nor the w3c endorsed content-type based dispatching can
> perform the task. Would something like
>
>    <a href="http://example.org/event.ics" rel="calendar.add">Add this
> event to your calendar</a>
>    <a href="http://example.org/event.ics"
> rel="calendar.remove">Remove this event to your calendar</a>
>
> be desirable? Of course this needs some browser infrastructure.
>
> The alternative approach is to embedd
>
>    <a href="http://example.org/event.ics" type="text/calendar">An
> interesting event for you!</a>
>
> in a page and let the user choose actions from a context menu. But
> that makes a very poor user interface.
>
> //Stefan
>
>
> --
> <green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
> Amtsgericht Münster: HRB5782
>
>
>
>

Received on Thursday, 2 October 2008 14:34:48 UTC