Account Options

  1. Sign in
The old Google Groups will be going away soon.
Switch to the new Google Groups.
Google Groups Home
« Groups Home
Message from discussion Content Security Policy Spec questions and feedback
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Brandon Sterne  
View profile  
 More options Jul 13 2009, 5:48 pm
Newsgroups: mozilla.dev.security
From: Brandon Sterne <bste...@mozilla.com>
Date: Mon, 13 Jul 2009 14:48:26 -0700
Local: Mon, Jul 13 2009 5:48 pm
Subject: Re: Content Security Policy Spec questions and feedback
On 07/09/2009 03:05 PM, EricLaw wrote:

>>> It seems natural that a subdownload should be able to say e.g.
>>> Content- Security-Policy: callers <originlist>
>> That's not too far off from what frame-ancestors does (which was
>> also a scope-creep). Could they be combined in some way?

>> I'd like something like that, but won't concerned sites want to
>> enforce it server-side? A reliable Referer, or the Origin/Sec-From
>> header would seem more useful there.

> Some might, but that basically requires the server to send Vary:
> Origin or Vary: Sec-From for all resources returned.  This seems like
>  it could potentially impair performance for otherwise cacheable
> resources.

I don't see why servers need to send Vary: Sec-From for all resources
returned. Can't they just send it for the resources that they don't want
cached?

You mentioned that there are legacy IE bugs that would be problematic
for sending Vary: Sec-From. In the article you posted it says:

> Internet Explorer 6 will treat a response with a Vary header as
> completely uncacheable...

This seems like a problem of underutilizing browser caching but it
doesn't seem to break the Sec-From model where each request is validated
by the server using the context supplied in Sec-From.  If an extra
request is generated, it will be validated by the server in the same way
as the original request.  Plus, this is assuming that Microsoft even
plans to implement Sec-From in IE 6/7.

Are there other problems that you see in the Sec-From model?  It
addresses both CSRF and the bandwidth-stealing issue you raised.  I'm
personally a strong supporter.

Cheers,
Brandon


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.