W3C home > Mailing lists > Public > www-tag@w3.org > May 2010

Re: Impending web-arch issue?

From: Nathan <nathan@webr3.org>
Date: Tue, 11 May 2010 09:32:44 +0100
Message-ID: <4BE9162C.8090606@webr3.org>
To: Anne van Kesteren <annevk@opera.com>
CC: "www-tag@w3.org" <www-tag@w3.org>
Anne van Kesteren wrote:
> On Mon, 10 May 2010 12:10:05 +0200, Nathan <nathan@webr3.org> wrote:
>> Knowing me I'm being overly bold and out of place, but maybe it's 
>> better to start looking at the options and try and get something in 
>> place before the.. well you know.
> Doesn't really seem bold or out of place to me, but so far we have not 
> been able to come up with anything. And given the constraints I don't 
> think we will. (Asking the user or "inverting the model" as you put it 
> are not really options as explained on public-webapps@w3.org.)

Fair enough, and I do understand the safety issue, so is this correct:

If you allow all xhr interaction on resources by default, then this 
leaves the web open to phishing and worse as the user agent can be used 
as a proxy between any two sites (both intranet sites behind a firewall 
and the web at large).

If you deny all xhr interaction on resources by default, then this 
leaves the web closed to the eyes of xhr.

At the minute we're already in the closed web state (I make it sound so 
bad!), so it's as safe as it can get should CORS as it stands progress 
through to recommendation.

In light of all that's been discussed, would you agree that neither 
approach is ideal, and that the current closed xhr web approach (whilst 
it keeps things safe in the interim) isn't a long-term fix that 
addresses both issues?

As noted the same issue(s) will arise again with browser extensions in 
the near future. Thus, can we open CORS+same origin policy for XHR up to 
a round of suggestions that keep the web both safe and open at the same 
time? - or at least make it a bit easier to open up by adding default 
CORS settings for an entire domain in a .well-known place or suchlike.

IMHO universal browser based client side applications running over a web 
of data is a huge thing for the web to loose, and something I wouldn't 
like to see given up, especially with the advent of HTML5+JS APIs - all 
the pieces are in place, the web is shifting in this direction - and 
afaict this issue is the only thing blocking us from progressing.


Received on Tuesday, 11 May 2010 08:40:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:34 UTC