On Jun 25, 5:22 am, Gervase Markham <[EMAIL PROTECTED]> wrote: > The documentation for Request-Source is now more complete, but it's a > bit jumbled. I would make bullet 4 into bullet 2, and remove the second > sentence because it's repeated in (new) bullet 3.
Good points. I'll make these changes. > You didn't include the feature of a special value for the local domain. > I note that in Content-Restrictions, I used "this": Another good point. I prefer the use of "this" over the other suggestion of "localhost" since the latter could create ambiguity between the server the content came from and the user's local machine. I'll add "this" to the proposal as well. > We might also consider a special value for Script-Source of "head", if > we are looking for ways to make it more palatable and > easily-implementable for web authors. I agree that it may be more palatable for authors, but it may come at the expense of 1) security: while it is far less likely to find an injection point in the <head> of a document, it is still possible, and 2) clarity of the new model: telling people to "move all your scripts to external JS files" is a fairly large change to make, but it is clear that anything remaining will not be executed. It also fits nicely with the philosophy of separating behavior from content structure. Telling people to "move all your scripts to external JS files or the <head> of your document", while satisfying the behavior- content separation, may potentially confuse people as to _why_ they are separating their scripts. I am open to this, though, if others feel it might be valuable. > You may want to consider rethinking the names of the headers. At the > moment, you would expect Script-Source and Request-Source to be > parallel, but in fact Script-Source does something very similar to > Request-Target, but just for script. Agreed. I have been talking with Dan Veditz about this topic, and there are some substantive changes and additions that need to be made to the header names. I will likely follow-up with a separate post on that topic since it could become rather lengthy. > We do need to continue to think about the performance impact of > Request-Source/Request-Origin. True, and I'm hoping we can leverage some wisdom from the Access Control specification regarding how to minimize performance overhead. I know that spec is still in flux, though, and I'm paying attention to the mailing list to track their progress. > One option would be to have the site able > to return a policy file in the body of the response to a HEAD request, > which would define policy for that request and the entire site as well. > This avoids the "well-known URL" problem, and gives the option of both > page-specific responses and a general response. I like the idea of being able to send "meta-policy" for a set of resources larger than 1 to cut down on round-trips, etc. Is your suggestion that the policy query return the meta-policy in the response itself, or that it return a URL to a meta-policy file? I think I would tend to favor the latter. > It's not quite that simple. See the quirksMode.org page on inline event > handlers:http://www.quirksmode.org/js/events_early.html > > If you want to permit suppression of the default action using an inline > style, you may need to allow at least "return functionWithNoParams()". > There are other ways to prevent the default action, but this one is > quite familiar to people. > > Also, people often want to pass "this" or "event" to their event > handlers so they know which item was clicked on or have access to event > properties. More info on the latter > here:http://www.quirksmode.org/js/events_access.html > > It's beginning to look like this might not fly... All good points. Calling only zero-parameter functions appears to be less useful than I originally thought. We will have to probably scrap that idea. As I mentioned, I have a set of changes that I need to make to the proposal which I'll work on over the weekend and will follow up with another post when I've collected my thoughts a bit more. Regards, Brandon _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
