On 21 Jul 2012, at 15:02, Eric Rescorla wrote:
> Henry,
>
> In my opinion as Chair, there has been broad consensus in the
> WebAppSec WG that one of the basic design constraints of
> CORS is that introducing CORS features into browsers not create
> new security vulnerabilities for existing netwo
Henry,
In my opinion as Chair, there has been broad consensus in the
WebAppSec WG that one of the basic design constraints of
CORS is that introducing CORS features into browsers not create
new security vulnerabilities for existing network deployments.
What you are proposing would have that result
On 21 Jul 2012, at 05:39, Jonas Sicking wrote:
> On Fri, Jul 20, 2012 at 11:58 AM, Henry Story wrote:
>>
>> On 20 Jul 2012, at 18:59, Adam Barth wrote:
>>
>>> On Fri, Jul 20, 2012 at 9:55 AM, Cameron Jones wrote:
On Fri, Jul 20, 2012 at 4:50 PM, Adam Barth wrote:
> On Fri, Jul 20, 2
On Fri, Jul 20, 2012 at 11:58 AM, Henry Story wrote:
>
> On 20 Jul 2012, at 18:59, Adam Barth wrote:
>
>> On Fri, Jul 20, 2012 at 9:55 AM, Cameron Jones wrote:
>>> On Fri, Jul 20, 2012 at 4:50 PM, Adam Barth wrote:
On Fri, Jul 20, 2012 at 4:37 AM, Cameron Jones wrote:
> So, this is a n
On Fri, 20 Jul 2012, Henry Story wrote:
>
> How many of those would use ip addresses that are not standard private
> ip addresses? (Because if they do, then they would not be affected). Of
> those that do not, would IPV6 offer them a scheme where they could
> easily use standard private ip addr
On 20 Jul 2012, at 21:02, Tab Atkins Jr. wrote:
> On Fri, Jul 20, 2012 at 11:58 AM, Henry Story wrote:
>> Of course, but you seem to want to support hidden legacy systems, that is
>> systems none of us know about or can see. It is still a worth while inquiry
>> to find out how many systems the
On Fri, Jul 20, 2012 at 11:58 AM, Henry Story wrote:
> Of course, but you seem to want to support hidden legacy systems, that is
> systems none of us know about or can see. It is still a worth while inquiry
> to find out how many systems there are for which this is a problem, if any.
> That is:
On 20 Jul 2012, at 18:59, Adam Barth wrote:
> On Fri, Jul 20, 2012 at 9:55 AM, Cameron Jones wrote:
>> On Fri, Jul 20, 2012 at 4:50 PM, Adam Barth wrote:
>>> On Fri, Jul 20, 2012 at 4:37 AM, Cameron Jones wrote:
So, this is a non-starter. Thanks for all the fish.
>>>
>>> That's why we ha
On Fri, Jul 20, 2012 at 9:55 AM, Cameron Jones wrote:
> On Fri, Jul 20, 2012 at 4:50 PM, Adam Barth wrote:
>> On Fri, Jul 20, 2012 at 4:37 AM, Cameron Jones wrote:
>>> So, this is a non-starter. Thanks for all the fish.
>>
>> That's why we have the current design.
>
> Yes, i note the use of the
On Fri, Jul 20, 2012 at 4:50 PM, Adam Barth wrote:
> On Fri, Jul 20, 2012 at 4:37 AM, Cameron Jones wrote:
>> So, this is a non-starter. Thanks for all the fish.
>
> That's why we have the current design.
Yes, i note the use of the word "current" and not "final".
Ethics are a starting point for
On Fri, Jul 20, 2012 at 4:37 AM, Cameron Jones wrote:
> On Fri, Jul 20, 2012 at 8:29 AM, Adam Barth wrote:
>> On Thu, Jul 19, 2012 at 7:50 AM, Cameron Jones wrote:
>>> On Thu, Jul 19, 2012 at 3:19 PM, Anne van Kesteren wrote:
On Thu, Jul 19, 2012 at 4:10 PM, Cameron Jones wrote:
> Isn
On Fri, Jul 20, 2012 at 8:29 AM, Adam Barth wrote:
> On Thu, Jul 19, 2012 at 7:50 AM, Cameron Jones wrote:
>> On Thu, Jul 19, 2012 at 3:19 PM, Anne van Kesteren wrote:
>>> On Thu, Jul 19, 2012 at 4:10 PM, Cameron Jones wrote:
Isn't this mitigated by the Origin header?
>>>
>>> No.
>>
>> Cou
On Thu, Jul 19, 2012 at 7:50 AM, Cameron Jones wrote:
> On Thu, Jul 19, 2012 at 3:19 PM, Anne van Kesteren wrote:
>> On Thu, Jul 19, 2012 at 4:10 PM, Cameron Jones wrote:
>>> Isn't this mitigated by the Origin header?
>>
>> No.
>
> Could you expand on this response, please?
>
> My understanding
On Thu, Jul 19, 2012 at 3:19 PM, Anne van Kesteren wrote:
> On Thu, Jul 19, 2012 at 4:10 PM, Cameron Jones wrote:
>> Isn't this mitigated by the Origin header?
>
> No.
>
>
Could you expand on this response, please?
My understanding is that requests generate from XHR will have Origin
applied. Th
On Thu, Jul 19, 2012 at 3:06 PM, Eric Rescorla wrote:
> On Thu, Jul 19, 2012 at 6:54 AM, Anne van Kesteren wrote:
>> On Thu, Jul 19, 2012 at 2:43 PM, Henry Story wrote:
>>> If a mechanism can be found to apply restrictions for private IP ranges
>>> then that
>>> should be used in preference to
On Thu, Jul 19, 2012 at 4:10 PM, Cameron Jones wrote:
> Isn't this mitigated by the Origin header?
No.
> Also, what about the point that this is unethically pushing the costs
> of securing private resources onto public access providers?
It is far more unethical to expose a user's private data.
On Thu, Jul 19, 2012 at 2:54 PM, Anne van Kesteren wrote:
> On Thu, Jul 19, 2012 at 2:43 PM, Henry Story wrote:
>> If a mechanism can be found to apply restrictions for private IP ranges then
>> that
>> should be used in preference to forcing the rest of the web to implement CORS
>> restrictions
On Thu, Jul 19, 2012 at 6:54 AM, Anne van Kesteren wrote:
> On Thu, Jul 19, 2012 at 2:43 PM, Henry Story wrote:
>> If a mechanism can be found to apply restrictions for private IP ranges then
>> that
>> should be used in preference to forcing the rest of the web to implement CORS
>> restrictions
On Thu, Jul 19, 2012 at 2:43 PM, Henry Story wrote:
> If a mechanism can be found to apply restrictions for private IP ranges then
> that
> should be used in preference to forcing the rest of the web to implement CORS
> restrictions on public data. And indeed the firewall servers use private ip
>> On Wed, Jul 18, 2012 at 4:41 AM, Henry Story wrote:
>>
>>> 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.
>>
>> Yes, the restriction on performing an unauthenticated GET only s
On 19 Jul 2012, at 14:07, Cameron Jones wrote:
> On Wed, Jul 18, 2012 at 4:41 AM, Henry Story wrote:
>> 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)
>
> Yes, the Origin and unauthenticated CORS restr
On Wed, Jul 18, 2012 at 4:41 AM, Henry Story wrote:
> 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)
Yes, the Origin and unauthenticated CORS restrictions are trivially
circumvented by a simple proxy.
>
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 m
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, a
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 sp
25 matches
Mail list logo
