Re: Why the restriction on unauthenticated GET in CORS?

[Henry Story]

On 18 Jul 2012, at 05:47, Ian Hickson wrote:

> On Wed, 18 Jul 2012, Henry Story wrote:
>> 
>> So my argument is that this restriction could be lifted since 
>> 
>> 1. GET is indempotent - and should not affect the resource fetched
>> 
>> 2. If there is no authentication, then the JS Agent could make the 
>> request via a CORS praxy of its choosing, and so get the content of the 
>> resource anyhow.
> 
> No, such a proxy can't get to intranet pages.
> 
> "Authentication" on the Internet can include many things, e.g. IP 
> addresses or mere connectivity, that are not actually included in the body 
> of an HTTP GET request. It's more than just cookies and HTTP auth headers.

Ah yes, quite right.  Tricky space...

Perhaps my question can be useful in your CORS design-decisions-faq .

Thanks,

Henry


> 
> -- 
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Social Web Architect
http://bblfish.net/

Re: Why the restriction on unauthenticated GET in CORS?

[Ian Hickson]

On Wed, 18 Jul 2012, Henry Story wrote:
> 
> So my argument is that this restriction could be lifted since 
> 
>  1. GET is indempotent - and should not affect the resource fetched
>
>  2. If there is no authentication, then the JS Agent could make the 
> request via a CORS praxy of its choosing, and so get the content of the 
> resource anyhow.

No, such a proxy can't get to intranet pages.

"Authentication" on the Internet can include many things, e.g. IP 
addresses or mere connectivity, that are not actually included in the body 
of an HTTP GET request. It's more than just cookies and HTTP auth headers.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Why the restriction on unauthenticated GET in CORS?

[Henry Story]

As I understand, a browser receiving even an unauthenticated GET request on a 
resource from a JavaScript Agent,  will pass the result on to the JS Agent only 
if the server adds the 

   Access-Control-Allow-Origin: http://hello-world.example

header to the response. 

I could not quite find it specified clearly in the spec that this has to be so, 
but it seems to flow from the example given in the introduction.

[[
If a resource author has a simple text resource residing at 
http://example.com/hello which contains the string "Hello World!" and would 
like http://hello-world.example to be able to access it, the response combined 
with a header introduced by this specification could look as follows:

Access-Control-Allow-Origin: http://hello-world.example

Hello World!
]]

And it is the experience of this being required that led me to build a CORS 
proxy [1] - (I am not the first to write one, I add quickly)

So my argument is that this restriction could be lifted since 

 1. GET is indempotent - and should not affect the resource fetched
 2. If there is no authentication, then the JS Agent could make the request via 
a CORS praxy of its choosing, and so get the content of the resource anyhow.
 3. One could still pass the Origin: header as a warning to sites who may be 
tracking people in unusual ways.

  Lifting this restriction would make a lot of public data available on the web 
for use by JS agents cleanly. Where requests require authentication or are 
non-indempotent CORS makes a lot of sense, and those are areas where data 
publishes would need to be aware of CORS anyway, and should implement it as 
part of a security review. But for people publishing open data, CORS should not 
be something they need to consider.

Henry


[1] 
https://github.com/read-write-web/rww-play/blob/master/app/org/w3/readwriteweb/play/CORSProxy.scala

Social Web Architect
http://bblfish.net/

Re: [Workers] Worker same-origin and usage in JS libraries...

[Bronislav Klučka]

On 18.7.2012 1:05, Ian Hickson wrote:

And if you want it to be defined in JS file itself, I'll suggest "use
strict" approach:

file> ---
"Access-Control-Allow-Origin: *";
(function(){
 "use strict";
   var x = 5;
})();
---
Whether it's a string or a comment seems like a detail. If we do do this,
I expect we'll find something that's somewhat language-agnostic (e.g.
allowing any leading and trailing punctuation on the first line, or
something to that effect).

Well not exactly a detail... we already have comment processing in HTML 
and JS... (IE). Script minifiers can have issues with that, JS engines 
would have to start parse end somehow execute comments to look for 
something suspicious in a text without recognizable syntax and semantics 
(garbage)
Maybe some specific object, as a property on window / worker scope would 
be inline with language and requiremenets (=to define script properties)

(this|self).ScriptProperties = {
   DisableCrossOriginExecution = false, //to disable CO script sharing, 
since current default is true
   AllowCrossOriginWorkerExecution = true //to enable CO in workers, 
since current default is false

}

it would also allow any future extensions

BK

Re: [Workers] Worker same-origin and usage in JS libraries...

[Ian Hickson]

On Wed, 18 Jul 2012, Bronislav Klu�~Mka wrote:
> 
> Since script is loaded using HTTP, why not use already defined CORS headers on
> server side while serving those scripts?

CORS is the wrong semantic. It's not "origin A is allowed to read content 
from origin B", it's "origin A is allowed to cause origin B to run code", 
which is a very different threat model. It would be quite bad for us to 
say that any file that you can read from another origin, you can cause to 
be executed as script in that origin.


> And if you want it to be defined in JS file itself, I'll suggest "use 
> strict" approach:
> 
> file> ---
> "Access-Control-Allow-Origin: *";
> (function(){
> "use strict";
>   var x = 5;
> })();
> ---http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [Workers] Worker same-origin and usage in JS libraries...

[Bronislav Klučka]

  
  

On 17.7.2012 23:53, Ian Hickson wrote:


  My plan is to make it so that cross-origin URLs start cross-origin
  workers. The main unresolved question is how to do this in an
  opt-in manner. The best idea I've come up with so far is having
  scripts that want to opt-in to being run in such a way start with
  a line line: // Cross-Origin Worker for: http://example.net
  ...or (for multiple domains): // Cross-Origin Worker for:
  http://example.com https://example.org
  ...or (for any domain): // Cross-Origin Worker for all origins
  ...but that doesn't seem super neat.


Since script is loaded using HTTP, why not use already defined CORS
headers on server side while serving those scripts?
And if you want it to be defined in JS file itself, I'll suggest
"use strict" approach:

file>
---
"Access-Control-Allow-Origin: *";
(function(){
    "use strict";
  var x = 5;
})();
---

and define CORS headers as a string (maybe with the restriction that
those headers must be first executable/runnable code in JS file - so
there may be comments and whitespaces before)

B.

-- 
  
  
s pozdravem
 Bronislav Klučka




http://www.bauglir.com
bronislav.klu...@bauglir.com

  * webové aplikace
  * software na zakázku


  



  

Re: CORS proxy - was: CORS security hole?

[Eric Rescorla]

I'm not going to debate this with you.

Yes, the items you are raising have some relationship to the kind of
work WebAppSec is
doing, but they are not in fact in scope for this WG. Please take it elsewhere.

-Ekr


On Tue, Jul 17, 2012 at 2:50 PM, Henry Story  wrote:
>
> On 17 Jul 2012, at 23:16, Eric Rescorla wrote:
>
>> This all seems out of scope for the work WebAppSec is chartered for.
>
> All of it? Really?
>
> Let me look at the charter of the working group. Areas of scope for this 
> working group include:
>
> [[
> Secure Mashups: Several mechanisms for secure resource sharing and messaging 
> across origins exist or are being specified, but several common and desirable 
> use cases are not covered by existing work, such as: allowing child IFRAMEs 
> to protect themselves from "clickjacking" or specify what characteristics a 
> parent window must allow. The WG will design mechanisms and coordinate with 
> existing and ongoing work in other forums to allow secure mashups.
> ]]
>
> 1.  Linked Data is all about mashups. It's about taking information from 
> different sites and using semantic technology building a merge of different 
> points of view. In Linked Data space we are having trouble with
> merging data in JS tools ( WebApps ) because of limitations of where we can 
> get information from. CORS helps, but perhaps it can be improved without harm 
> to security?
>
> I pointed out that unnecessary restrictions in CORS with 
> GET-requests-without-authentication is forcing one to put up CORS proxies.
>
> 2. CORS restrictions are based on very weak identity of the Origin JS. This 
> means that a lot less mashups can happen that would otherwise be possible if 
> JS were signed and more precisely identified.
>
> 3. I proposed a minimal improvement to build trust in Origin JS, that could 
> make mashups more easy, by allowing users to specify through their WebID 
> profile (which they use for TLS authentication) which Origins they trust. At 
> least as a thought experiment.
>
>> Henry, can you please raise this in another venue.
>
> Well I was just reporting here, in answer to a question by one of your 
> members, that I had brought this up in another W3C WG that might want to look 
> at how Apps and Linked Data can work together. Indeed I even pointed to an 
> e-mail where this was brought up
>
>http://lists.w3.org/Archives/Public/public-ldp-wg/2012Jul/0041.html
>
> Therefore my intervention even fit the section  "The WG will design 
> mechanisms and coordinate with existing and ongoing work in other forums to 
> allow secure mashups."
>
>
> I hope that helps you see how this ties in with this groups Eric. We can all 
> be mistaken. Indeed, I thought at the start of the thread that I had found a 
> security in CORS. I then quickly excused myself as soon as I saw that I was 
> wrong.
>
> All the best,
>
> Henry
>
>
>> -Ekr
>>
>> [As WG Chair]
>>
>> On Tue, Jul 17, 2012 at 1:15 PM, Henry Story  wrote:
>>>
>>> On 17 Jul 2012, at 21:32, Dirk Pranke wrote:
>>>
 On Mon, Jul 16, 2012 at 11:22 PM, Henry Story  
 wrote:
> Ok, I don't really have a browser to hack on. On the other hand a few of 
> us
> are working on building a CORS
> proxy at the read-write-web community group to enable javascript linked 
> data
> agents to build up in the browser views of data distributed on the web.
> There may be some interesting results this brings up that we can discuss 
> at
> TPAC in Lyon... :-)

 Building a CORS proxy for any reason other than to prototype something
 sounds (at first blush) like a bad idea; as Adam says, you're
 basically changing the security policies the web is supposed to be
 using. It seems like if you're having to do this you're solving the
 wrong problem, and maybe there's something else that should be
 changed?
>>>
>>> Well I have proposed to the Linked Data Profile WG today that it may be 
>>> useful for them add  a use case that would take WebApps into account so as 
>>> to look at some of the issues that are brought up in this space when 
>>> WebApps interact with LinkedData. See the mail here:
>>>
>>>   http://lists.w3.org/Archives/Public/public-ldp-wg/2012Jul/0041.html
>>>
>>> A lot of Linked Data providers do not support CORS (it's too new for them 
>>> to have noticed, and too far from their use cases) yet we would like to 
>>> build apps that use that data. As a result one cannot have a javascript 
>>> application as described in that e-mail do a GET on such resources using 
>>> CORS alone. One needs a proxy to get such resources.
>>>
>>>   What I am not so clear about is whether there is any need for CORS to put 
>>> any restrictions at all on resources that are fetched with GET - since GET 
>>> is indempotent - especially when the GET request is done without any access 
>>> control at all. That would at least make a lot of public linked data 
>>> browseable without the need for a proxy using javascript

Re: [Workers] Worker same-origin and usage in JS libraries...

[Ian Hickson]

On Tue, 6 Dec 2011, Jonas Sicking wrote:
> On Tue, Dec 6, 2011 at 5:05 PM, Travis Leithead
>  wrote:
> > A new scenario just came to my attention that I thought I might
> > pose to the list. Given the current same-origin restrictions on
> > new Worker(), it is problematic for Worker usage by any JS
> > libraries on a CDN.
> >
> > A site using a CDN simply provides an absolute URL reference to
> > the library, and it is subsequently downloaded and executed in
> > the context of the current page's domain. Relative URLs to a
> > worker script will resolve according to the domain of the hosting
> > page:
> >
> > // http://cdn.net/dowork.js which was included from http://test.com/home.htm
> > var w = new Worker("lib/workers/w1.js");
> > // Tries to open http://test.com/lib/workers/w1.js
> >
> > and absolute URLs will fail due to the cross-origin restrictions
> > on the new Worker constructor:
> >
> > // same setup as before
> > var w = new Worker("http://cdn.net/lib/workers/w1.js";);
> > // Cross-origin failure from http://test.com/home.htm
> >
> > I looked back through the list and at the original worker proposals
> > to try and discover why the same-origin restrictions is in place.
> >
> > The root of the issue seems to be the expectation that WorkerGlobalScope
> > runs and executes everything according to its own location.URL.
> > Thus, allowing http://cdn.net/lib/workers/w1.js to load in the
> > previous example, would allow http://test.com/home.htm to potentially
> > modify any data associated with cdn.net's domain (like through
> > Indexed DB, or XHR, etc).
> >
> > One way to allow the CDN scenario to work would be to provide an explicit
> > way to tell a worker to run in the host context, rather than the context
> > that the Worker is loaded from (which is what 

Re: CORS proxy - was: CORS security hole?

[Henry Story]

On 17 Jul 2012, at 23:16, Eric Rescorla wrote:

> This all seems out of scope for the work WebAppSec is chartered for.

All of it? Really?

Let me look at the charter of the working group. Areas of scope for this 
working group include:

[[
Secure Mashups: Several mechanisms for secure resource sharing and messaging 
across origins exist or are being specified, but several common and desirable 
use cases are not covered by existing work, such as: allowing child IFRAMEs to 
protect themselves from "clickjacking" or specify what characteristics a parent 
window must allow. The WG will design mechanisms and coordinate with existing 
and ongoing work in other forums to allow secure mashups.
]]

1.  Linked Data is all about mashups. It's about taking information from 
different sites and using semantic technology building a merge of different 
points of view. In Linked Data space we are having trouble with
merging data in JS tools ( WebApps ) because of limitations of where we can get 
information from. CORS helps, but perhaps it can be improved without harm to 
security?

I pointed out that unnecessary restrictions in CORS with 
GET-requests-without-authentication is forcing one to put up CORS proxies. 

2. CORS restrictions are based on very weak identity of the Origin JS. This 
means that a lot less mashups can happen that would otherwise be possible if JS 
were signed and more precisely identified. 

3. I proposed a minimal improvement to build trust in Origin JS, that could 
make mashups more easy, by allowing users to specify through their WebID 
profile (which they use for TLS authentication) which Origins they trust. At 
least as a thought experiment.

> Henry, can you please raise this in another venue.

Well I was just reporting here, in answer to a question by one of your members, 
that I had brought this up in another W3C WG that might want to look at how 
Apps and Linked Data can work together. Indeed I even pointed to an e-mail 
where this was brought up 

   http://lists.w3.org/Archives/Public/public-ldp-wg/2012Jul/0041.html

Therefore my intervention even fit the section  "The WG will design mechanisms 
and coordinate with existing and ongoing work in other forums to allow secure 
mashups."


I hope that helps you see how this ties in with this groups Eric. We can all be 
mistaken. Indeed, I thought at the start of the thread that I had found a 
security in CORS. I then quickly excused myself as soon as I saw that I was 
wrong. 

All the best,

Henry


> -Ekr
> 
> [As WG Chair]
> 
> On Tue, Jul 17, 2012 at 1:15 PM, Henry Story  wrote:
>> 
>> On 17 Jul 2012, at 21:32, Dirk Pranke wrote:
>> 
>>> On Mon, Jul 16, 2012 at 11:22 PM, Henry Story  
>>> wrote:
 Ok, I don't really have a browser to hack on. On the other hand a few of us
 are working on building a CORS
 proxy at the read-write-web community group to enable javascript linked 
 data
 agents to build up in the browser views of data distributed on the web.
 There may be some interesting results this brings up that we can discuss at
 TPAC in Lyon... :-)
>>> 
>>> Building a CORS proxy for any reason other than to prototype something
>>> sounds (at first blush) like a bad idea; as Adam says, you're
>>> basically changing the security policies the web is supposed to be
>>> using. It seems like if you're having to do this you're solving the
>>> wrong problem, and maybe there's something else that should be
>>> changed?
>> 
>> Well I have proposed to the Linked Data Profile WG today that it may be 
>> useful for them add  a use case that would take WebApps into account so as 
>> to look at some of the issues that are brought up in this space when WebApps 
>> interact with LinkedData. See the mail here:
>> 
>>   http://lists.w3.org/Archives/Public/public-ldp-wg/2012Jul/0041.html
>> 
>> A lot of Linked Data providers do not support CORS (it's too new for them to 
>> have noticed, and too far from their use cases) yet we would like to build 
>> apps that use that data. As a result one cannot have a javascript 
>> application as described in that e-mail do a GET on such resources using 
>> CORS alone. One needs a proxy to get such resources.
>> 
>>   What I am not so clear about is whether there is any need for CORS to put 
>> any restrictions at all on resources that are fetched with GET - since GET 
>> is indempotent - especially when the GET request is done without any access 
>> control at all. That would at least make a lot of public linked data 
>> browseable without the need for a proxy using javascript. Furthermore a 
>> proxy is so easy to build, any such public data can be found anyway, so the 
>> CORS restriction on GET have no real effect, other than getting people to 
>> write CORS proxies
>> 
>> Next since I mentioned this in the e-mail to the LDP WG, let me mention this 
>> here. I have an interesting suggestion for you on how to make it easier to 
>> work out when one could trust a JS Origin. So w

Re: CORS proxy - was: CORS security hole?

[Eric Rescorla]

This all seems out of scope for the work WebAppSec is chartered for.

Henry, can you please raise this in another venue.

-Ekr

[As WG Chair]

On Tue, Jul 17, 2012 at 1:15 PM, Henry Story  wrote:
>
> On 17 Jul 2012, at 21:32, Dirk Pranke wrote:
>
>> On Mon, Jul 16, 2012 at 11:22 PM, Henry Story  
>> wrote:
>>> Ok, I don't really have a browser to hack on. On the other hand a few of us
>>> are working on building a CORS
>>> proxy at the read-write-web community group to enable javascript linked data
>>> agents to build up in the browser views of data distributed on the web.
>>> There may be some interesting results this brings up that we can discuss at
>>> TPAC in Lyon... :-)
>>
>> Building a CORS proxy for any reason other than to prototype something
>> sounds (at first blush) like a bad idea; as Adam says, you're
>> basically changing the security policies the web is supposed to be
>> using. It seems like if you're having to do this you're solving the
>> wrong problem, and maybe there's something else that should be
>> changed?
>
> Well I have proposed to the Linked Data Profile WG today that it may be 
> useful for them add  a use case that would take WebApps into account so as to 
> look at some of the issues that are brought up in this space when WebApps 
> interact with LinkedData. See the mail here:
>
>http://lists.w3.org/Archives/Public/public-ldp-wg/2012Jul/0041.html
>
> A lot of Linked Data providers do not support CORS (it's too new for them to 
> have noticed, and too far from their use cases) yet we would like to build 
> apps that use that data. As a result one cannot have a javascript application 
> as described in that e-mail do a GET on such resources using CORS alone. One 
> needs a proxy to get such resources.
>
>What I am not so clear about is whether there is any need for CORS to put 
> any restrictions at all on resources that are fetched with GET - since GET is 
> indempotent - especially when the GET request is done without any access 
> control at all. That would at least make a lot of public linked data 
> browseable without the need for a proxy using javascript. Furthermore a proxy 
> is so easy to build, any such public data can be found anyway, so the CORS 
> restriction on GET have no real effect, other than getting people to write 
> CORS proxies
>
>  Next since I mentioned this in the e-mail to the LDP WG, let me mention this 
> here. I have an interesting suggestion for you on how to make it easier to 
> work out when one could trust a JS Origin. So what is the issue? Currently 
> there is a bit of a problem with the Origin header because the site receiving 
> a request with an Origin header may not know anything about that Origin site 
> at all. Currently that means it has to close the connection. But what if I 
> the user who logged in really trust the origin site JS? (say because it is 
> hosted on my FreedomBox). So lets say I have some JS on my FBox and that JS 
> goes to the site of a friend of mine. How can that Friend know that I trust 
> the JS coming from my FBox, and not trust say the JS from some other random 
> site? Well if I log in with WebID and the WebID Profile is hosted on my FBox, 
> then that seems like a good indicator that my friend should trust requests 
> that come from JS that has the Origin of my FBox. One could even make this 
> explicit with a relation in my profile such as
>
>
>:me trustsOrigin  .
>
>
> Then my friends server could have confirmation from my profile that the 
> origin is trustworthy.
>
> Of course if the JS, was signed then things could be even more easy, because 
> that would allow me to place signed JS on my site that I trust and we would 
> not have the trouble of someone maliciously uploading JS in a blog post of 
> mine also getting rights at the same time. That is why I thought JS signing 
> would be a pretty useful feature to have.
>
> Henry
>
>>
>> -- Dirk
>
> Social Web Architect
> http://bblfish.net/
>
>

CORS proxy - was: CORS security hole?

[Henry Story]

On 17 Jul 2012, at 21:32, Dirk Pranke wrote:

> On Mon, Jul 16, 2012 at 11:22 PM, Henry Story  wrote:
>> Ok, I don't really have a browser to hack on. On the other hand a few of us
>> are working on building a CORS
>> proxy at the read-write-web community group to enable javascript linked data
>> agents to build up in the browser views of data distributed on the web.
>> There may be some interesting results this brings up that we can discuss at
>> TPAC in Lyon... :-)
> 
> Building a CORS proxy for any reason other than to prototype something
> sounds (at first blush) like a bad idea; as Adam says, you're
> basically changing the security policies the web is supposed to be
> using. It seems like if you're having to do this you're solving the
> wrong problem, and maybe there's something else that should be
> changed?

Well I have proposed to the Linked Data Profile WG today that it may be useful 
for them add  a use case that would take WebApps into account so as to look at 
some of the issues that are brought up in this space when WebApps interact with 
LinkedData. See the mail here:

   http://lists.w3.org/Archives/Public/public-ldp-wg/2012Jul/0041.html

A lot of Linked Data providers do not support CORS (it's too new for them to 
have noticed, and too far from their use cases) yet we would like to build apps 
that use that data. As a result one cannot have a javascript application as 
described in that e-mail do a GET on such resources using CORS alone. One needs 
a proxy to get such resources.

   What I am not so clear about is whether there is any need for CORS to put 
any restrictions at all on resources that are fetched with GET - since GET is 
indempotent - especially when the GET request is done without any access 
control at all. That would at least make a lot of public linked data browseable 
without the need for a proxy using javascript. Furthermore a proxy is so easy 
to build, any such public data can be found anyway, so the CORS restriction on 
GET have no real effect, other than getting people to write CORS proxies

 Next since I mentioned this in the e-mail to the LDP WG, let me mention this 
here. I have an interesting suggestion for you on how to make it easier to work 
out when one could trust a JS Origin. So what is the issue? Currently there is 
a bit of a problem with the Origin header because the site receiving a request 
with an Origin header may not know anything about that Origin site at all. 
Currently that means it has to close the connection. But what if I the user who 
logged in really trust the origin site JS? (say because it is hosted on my 
FreedomBox). So lets say I have some JS on my FBox and that JS goes to the site 
of a friend of mine. How can that Friend know that I trust the JS coming from 
my FBox, and not trust say the JS from some other random site? Well if I log in 
with WebID and the WebID Profile is hosted on my FBox, then that seems like a 
good indicator that my friend should trust requests that come from JS that has 
the Origin of my FBox. One could even make this explicit with a relation in my 
profile such as 


   :me trustsOrigin  .
   

Then my friends server could have confirmation from my profile that the origin 
is trustworthy. 

Of course if the JS, was signed then things could be even more easy, because 
that would allow me to place signed JS on my site that I trust and we would not 
have the trouble of someone maliciously uploading JS in a blog post of mine 
also getting rights at the same time. That is why I thought JS signing would be 
a pretty useful feature to have.

Henry

> 
> -- Dirk

Social Web Architect
http://bblfish.net/

Re: CORS security hole?

[Dirk Pranke]

On Mon, Jul 16, 2012 at 11:22 PM, Henry Story  wrote:
>
> On 17 Jul 2012, at 08:10, Adam Barth wrote:
>
>
>
> On Mon, Jul 16, 2012 at 11:01 PM, Henry Story 
> wrote:
>>
>> I first posted this to public-webapps, and was then told the security
>> discussions were taking
>> place on public-webappsec, so I reposted there.
>>
>> On 17 Jul 2012, at 00:39, Adam Barth wrote:
>>
>> As I wrote when you first posted this to public-webapps:
>>
>> [[
>> I'm not sure I fully understand the issue you're worried about, but if I
>> understand it correctly, you've installed an HTTP proxy that forcibly adds
>> CORS headers to every response.  Such a proxy will indeed lead to security
>> problems.  You and I can debate whether the blame for those security problem
>> lies with the proxy or with CORS, but I think reasonable people would agree
>> that forcibly injecting a security policy into the responses of other
>> servers without their consent is a bad practice.
>> ]]
>>
>>
>> Hmm, I think I just understood where the mistake in my reasoning is: When
>> making a request on the CORS proxy (
>> http://proxy.com/cors?url=http://bank.com/joe/statement on a resource
>> intended for bank.com, the browser will not send the bank.com credentials to
>> the proxy - since bank.com and proxy.com are different domains.  So the
>> attack I was imagining won't work, since the proxy won't just be able to use
>> those to pass itself for the browser user.
>>
>> Installing an HTTP proxy locally would of course be a trojan horse attack,
>> and then all bets are off.
>>
>> The danger might rather be the inverse, namely that if a CORS proxy is
>> hosted by a web site used by the browser user for other authenticated
>> purposes ( say a social web server running on a freedom box ) that the
>> browser pass the authentication information to the proxy in the form of
>> cookies, and that this proxy then pass those to any site the initial script
>> was connected to.
>>
>> Here using only client side certificate authentication helps, as that is
>> an authentication mechanism that cannot be forged or accidentally passed on.
>>
>> ---
>>
>> Having said that, are there plans to get to a point where JavaScript
>> agents could be identified in a more fine grained manner?
>
>
> No.
>
>>
>> Cryptographically perhaps with a WebID?
>
>
> That's unlikely to happen soon.
>
>> Then the Origin header could be a WebID and it would be possible for a
>> user to specify in his foaf profile his trust for a number of such agents?
>> But perhaps I should start that discussion in another thread
>
>
> I'd recommend getting some implementor interest in your proposals before
> starting such a thread.  A standard without implementations is like a fish
> without water.
>
>
> Ok, I don't really have a browser to hack on. On the other hand a few of us
> are working on building a CORS
> proxy at the read-write-web community group to enable javascript linked data
> agents to build up in the browser views of data distributed on the web.
> There may be some interesting results this brings up that we can discuss at
> TPAC in Lyon... :-)
>

Building a CORS proxy for any reason other than to prototype something
sounds (at first blush) like a bad idea; as Adam says, you're
basically changing the security policies the web is supposed to be
using. It seems like if you're having to do this you're solving the
wrong problem, and maybe there's something else that should be
changed?

-- Dirk

Re: [Server-Sent Events] Network connection clarification

[Odin Hørthe Omdal]

On Wed, 11 Jul 2012 00:52:06 +0200, Ian Hickson  wrote:

Exponential back-off isn't at all necessarily the right solution. In
particular, consider mobile devices, where network connectivity goes in
and out as the user moves. Most of the time, you want to be trying to
connect as soon as you have connectivity. Similarly with laptops on wifi
where the connection is only briefly hurt by an obstacle -- you want to
keep trying every few seconds until the obstacle is gone. Exponential
backoff if a terrible thing in those kinds of situations.

You can distinguish local network difficulties from server load
difficulties in a variety of ways, e.g. having a dedicated ping server on
the same network as the "real" server, which doesn't suffer from the same
load concerns, and which you try to contact and only switch to  
exponential

backoff if it responds but the main server isn't. And so on. UAs can do
that kind of thing.


Exactly. I'm a bit unsure about why you wrote this which is a support for  
the "let the UA do the reconnecting because it is smart" case, but still  
is hesitant about changing the spec to follow implementations there.



SSE is mostly a convenience API (advanced authors can use streaming XHR
or WebSockets to achieve the same result the hard way), so lack of
convenience in error recovery feels like an omission in this API.


If it's something we do want to eventually support, I think it's be
something to consider for v2.


I think we should fix this now. As said, for Opera's part I think we can  
follow spec (we're the closest to it now anyway :P) but I actually like  
the «UA handles reconnects» case better. However, it should really have  
some sort of state and event notifying about what it is doing.


So if you are prone to DoS-ing, and don't trust the user agent's  
implementation, you can actually do:


es.onreconnecting = function(e) {
// es.readyState is EventSource.RECONNECTING

// We don't want the default behaviour
es.close();
do_custom_reconnecting_logic();
};


I agree with Chaals and Kornel Lesiński, and actually most of the posters  
on this topic. I don't we're far from a good solution.


The core issue is, at least as I see it, is that implementations differ  
pretty starkly from what the spec says - so something has to change  
somewhere :-)


--
Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com

[Server-sent Events] Status of 26-April-2012 LC comments

[Arthur Barstow]

Hi All,

The comment deadline for the April 26 SSE LC [LC] ended May 17. Since 
the LC was published, I noted 2 comments, 1 bug report (see below) and 5 
ED updates (see below).


The comments are:

1. 17-Apr-2012; Odin Hørthe Omdal (Opera); 
http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0226.html 
; [Server-Sent Events] Infinite reconnection clarification.


Odin Hørthe, Hixie, All, - I don't see a clear conclusion/consensus and 
no bug was filed. As such, please indicate - via a reply to the 
_original_ thread - your take on this comment and please file a bug if 
applicable.


2. 29-Apr-2012; Neil Jenkins (Opera); [Server-Sent Events] Network 
connection clarification ; 10-July-2012 Hixie suggests error handling 
could be supported for v2 
. 
Additionally, Chaals indicated in 
 this 
could be considered a v1 bug.


Neil, Hixie, Chaals, All, - I don't see a clear conclusion/consensus and 
no bug was filed. As such, please indicate - via a reply to the 
_original_ thread - your take on this comment and please file a bug if 
applicable.


(If these two comments do not require substantive changes for v1, it 
appears the spec is ready for a CfC to publish as a Candidate 
Recommendation.)


-Thanks, Art

[LC] http://www.w3.org/TR/2012/WD-eventsource-20120426/

= Bug report: only 16866 
; 26-Apr-2012 
filed by ann...@opera.com; FIXED on 10-July-2012 ; Fix: 
. 
I consider this a non-substantive change


= ED Updates (the LC was based on 1.215)

* 216 
. 
Non-substantive (stylesheet update)


* 217 
. 
Non-substantive(change "event name" to "event type")


* 218 
. 
Non-substantive (one additional change of "event name" to "event type")


* 219 
.Non-substantive 
(remove "[TreatNonCallableAsNull]" WebIDL qualifier from attributes)


* 220 
. 
Non-substantive (fixes bug 16866)


= Bugs Open when CfC for LC was started: 14900, 15495, 16070, hence an 
indication the group does not consider them mandatory for v1