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
 |
Newsgroups: mozilla.dev.security
From: Sid Stamm <s...@mozilla.com>
Date: Mon, 06 Jul 2009 10:14:44 -0700
Local: Mon, Jul 6 2009 1:14 pm
Subject: Re: Content Security Policy Spec questions and feedback
Hi Eric, Gerv... thanks for getting this thread started. My replies are
inline due to the diverse range of discussions going on in this thread. :) I also cut some stuff not relevant to my responses out to shrink the size of this message. On 7/6/09 7:46 AM, EricLaw wrote: > On Jul 6, 3:02 am, Gervase Markham <g...@mozilla.org> wrote: Right. The goal with frame-ancestors is to be able to specify what >> On 06/07/09 01:28, EricLaw wrote:> Server CSP Versioning >>> frame-ancestors >>> In addition to IFRAMEs/FRAME tags, this should also restrict OBJECT >>> tags that point to HTML pages, correct? >> I guess so :-) sites can embed a protected page in any sort of framing context, no matter the tag. If an HTML/XHTML/etc document has a CSP, then any ancestor frame or embedding entity is verified against the policy. So I guess if a protected HTML document is embedded using OBJECT, then whatever content set the OBJECT tag must be checked. The only time this really gets broken is when plug-ins are involved. For >>> Are relative URIs valid for the report-URI/policy-URI? (Seems like I believe this is an implementation issue... a relative URI eventually >>> this would be a good thing to support). However, if so, is there any >>> interaction/relationship with the BASE tag, which is supposed to also >>> appear early in the head? >> Very good question. gets turned into an absolute URI before being requested. It is at that point (when it has been 'absolutified' or whatever I should call it) when CSP checks are done. Whether or not a BASE tag is present, the UA has to figure out what host to request the content from and over what scheme and port to request it; at this level, relative and absolute URIs should appear the same. I'll try to make this more obvious in the Spec. >>> Doesn t make sense to me, because self is defined to include the I worry about a changed meaning of the keyword based on context, because >>> scheme. This suggests that we need a "selfhost" directive, which >>> includes the hostname only. >> Or we make the same word serve two purposes, doing the "obvious" thing. that can lead to bugs. :) Fears aside, using self in the host position with any additional information (scheme://self or self:port) isn't such a bad idea, and makes sense to me. >>> If the Fail closed model is used, is there any way for the user to The spec states that we put errors in the error/debug console (so an >>> know why the site is broken? Isn t this going to create a problem, >>> where, say, a FF4 user will downgrade to a browser that doesn t >>> support CSP (say, Opera 9) because the site works properly there ? >>> Everyone loses. >> This is a problem with a "tighten when the header is used, and then use >> directives to loosen" approach. Content Restrictions had the opposite >> approach - it started with loose (i.e. the situation as it is without CR >> support) and tightened using directives. This avoided this problem. Of >> course, both directions have pros and cons. > Oh, I think Fail Closed is a fine model, but unless there's some way advanced user can see exactly what's going on. Maybe we need to figure out a "CSP Broken" icon to pop up next to the lock icon in the status bar? I hate to clutter up the UI unless >>> Agreeing with Sacolcor, I think the spec should explicitly note that I wholeheartedly agree. >>> CSP isn t intended to apply to User-Scripts, although I think the >>> Greasemonkey guys might find it hard to implement their current >>> feature-set considering where CSP is likely to be implemented in the >>> browser stacks. >> We need to avoid breaking Greasemonkey/GreasemonkIE. > I think there's a very I agree with this, but I subscribe to the "UA provided context for HTTP > legitimate case to be made for the potential security value in > preventing unexpected cross-domain data reads. requests" school of thought. I think the UA should provide some info about where requests came from to the server (render context like stylesheet or image, and source origin) -- then the Server can decide whether or not to serve the content. Cheers, 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.
| |||||||||||||