Re: Impending web-arch issue?

Mark S. Miller wrote:
> 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.

Cheers Mark,

I'll be needing Access-Control-Allow-Methods as well tbh since not using 
only GET (and not using json/js either - it's for RDF/RDFa).

Also worth mentioning that I'm using mod_cern_meta [1] instead, as part 
of exposing Link headers for ACL on static resources, works rather well 
:) more on cern metafile semantics [2]

[1] http://httpd.apache.org/docs/2.0/mod/mod_cern_meta.html
[2] http://www.w3.org/Daemon/User/Config/General.html#MetaDir

Anne, all: I think I've come to the conclusion that after 5 years of 
CORS work in progress and widely implemented, it's not about to change 
soon (nor I guess, can it) - so will embrace and if others don't add the 
needed headers then so be it; I've passed the word on to most of the 
linked data community and each will decide for themselves :)

Best,

Nathan

Received on Tuesday, 11 May 2010 13:56:17 UTC