Re: Chromium's support for CORS and UMP

I've been following this thread (and similar threads) with interest.
I've written a blog post about some of the challenges I see facing
developers who would like to use "HTML5" and the emerging
browser-based platform versus relying on, for example, Apple's App
Store, or, indeed, any native application development platform. The
post is here: http://blog.romeda.org/2010/05/three-simple-things-that-browser.html

While I think there are significant and [possibly] insurmountable
challenges to offering cross-domain HTTP requests from Javascript in
the context of a normal browser session (even accounting for
cookie-less XHR requests), and while I view CORS as a great resource
to provide a more robust alternative to JSONP, emerging "HTML5 Apps"
(closely aligned with the various widget specs) need a more robust
treatment of HTTP requests.

The alternative is clear – either run a proxy (thus compromising the
privacy of your users and incurring additional costs), convince every
site in the world that you expect to interact with to implement CORS,
or wrap your HTML5 App with PhoneGap, Titanium, Fluid, WRT, Opera
Widgets, or one of the many other browser-based native app wrappers.
The last solution is clearly the most viable, but also brings with it
the restrictions inherent to the Apple (and Android) App Store, as
well as being much more complex than a single unified approach to
cross-domain requests.

As the line becomes increasingly blurred between native apps and
web-based apps, this issue will come up more, not less. I'd love to
see a workable solution that gives users and developers alike a robust
set of tools that are based on HTML5. Perhaps this is a topic for
discussion at the upcoming W3C workshop on the Device API[1]? I'd be
happy to submit a position paper if there's interest.

b.

[1] http://www.w3.org/2010/api-privacy-ws/

On 12 May 2010 19:10, Nathan <nathan@webr3.org> wrote:
> Anne van Kesteren wrote:
>>
>> On Tue, 11 May 2010 07:10:59 +0200, Nathan <nathan@webr3.org> wrote:
>>>
>>> exactly, but the current set up stops xhr from getting resources that the
>>> could be retrieved from site A with wget - with an inverted model all the
>>> issues would disappear, leaving only one issue; namely informing sys admins
>>> that they must protected their resources that need protected - and this is
>>> their job after all.
>>
>> I'm sorry, but no, we cannot inform all sys admins all over the world and
>> hope they do the right thing. Inverting the model puts the user's data at
>> terrible risk. It is not going to happen.
>
> I'm going to suggest something that seems logical to me, but I'm probably
> way off target.
>
> It looks like a whole lot of work has gone in to the widgets specifications
> - and it looks like that caters for digital signing and has the Widget
> Access Request Policy, and for running js/html applications.
>
> So a couple of questions :)
>
> Do the major browser vendors plan to support widgets in the main UI window?
>
> How would CORS and WARP work together?
>
> and - is it a false path of hope for me to be thinking that I could make a
> JS/HTML5 application and have it run on the clients side, with no server
> dependencies, in all major browsers on all major platforms?
>
> Best,
>
> Nathan
>
>

Received on Wednesday, 12 May 2010 18:56:31 UTC