Re: Impending web-arch issue?

On Tue, May 11, 2010 at 1:32 AM, Nathan <nathan@webr3.org> wrote:

> 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.
>

Given an apache compatible web server, you could add

    <FilesMatch "\.js$">
      Header set Access-Control-Allow-Origin "*"
    </FilesMatch>

in a root .htaccess file. Adding this header is a good idea for all
resources that parse as JavaScript anyway, as should be the case for all
*.js files and for all JSONP services, since these resources are already not
protected by the Same Origin Policy. For these resources, adding this header
*cannot* result in any loss of security.



>
> 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.
>
> Best,
>
> Nathan
>
>


-- 
    Cheers,
    --MarkM