In regards to
(the previous mail was long enough) I think the answer is a very definite maybe.
The reasoning behind CORS was a security argument.
The browser security model (and I use that term very loosely) is based on domain security. The idea is that if you load a page from domain X then that page is assumed to be trusted by domain X and should be allowed to do anything it wants with domain X.
But what if the code from domain X wants to do something with domain Y?
Now today we already allow that but only for
(e.g. GET) and we don't let the requester see the response. E.g. if a page loaded from domain X makes a request to domain Y and the request is 'safe' then the browser will allow it but it won't let the code from domain X see the results of the
Now right away you should realize that the previous statement is a bald faced lie. And this lie has led to a lot of security holes. The browser doesn't just allow safe methods. It also allows domain X to make a request to domain Y using a very unsafe method,
Now, in theory, that cross-domain POST call is only allowed if it's a HTML FORM POST which in theory is detectable by the server and therefore servers should just know not to trust POST requests containing HTML FORMs unless there is an additional security mechanism
). But in theory this is considered a 'solved' problem and so is o.k.
But as XML HTTP Request (XHR) came on the scene this opened up a new channel of attack. Initially XHR handled this by just using the same domain policy. But this proved too restrictive in practice. There were lots of good reasons why a web page from domain
X would want to send an arbitrary HTTP request to domain Y and see the result (think mashups).
So this eventually led to CORS. It essentially lets the server say "I am o.k. with websites loaded from domains other than mine sending me requests". It actually allows finer grained security than that but the previous gives you the idea.
In theory so long as a server in domain Y says "HIt Me!" then domain X can send it whatever requests it wants. Presumably the server in domain Y has put in place the right protections to keep the endless list of browser attacks from working against
How does this affect Thali?
Oy. What a mess!
O.k. so first of all to the extent that we are running inside of a WebView we have to decide if we activate cross domain security. Most Web Views let you just turn it off. Since the Web View model is NOT a browser model but is an app model my strong preference
is that we just turn off cross domain security in the web view. I believe at that point XHR should 'just work' without any need for CORS.
But obviously this situation gets much more complicated when we think about a
. One thing I am sure of - the domain model makes zero sense for Thali. We are a peer to peer system. Who you got an app from means little or nothing. I suspect an intent/capabilities security model is what we need. Not a domain model. A Domain
model is inherently based on a centralized system. Thali is inherently decentralized.
My suspicion is that we will refuse to let cookies be used with Thali connections and from there we will let Thali requests skip the domain based security model.
But honestly this is a big complex area and I expect that eventually we'll have to spend a lot of time on it.
But not today.