[EMAIL PROTECTED] wrote: > I've updated the proposal to make this aspect a bit more clear: > http://people.mozilla.org/~bsterne/site-security-policy/details.html
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. The allow/deny priority system: is that the same as used by e.g. .htaccess? If not, should it be? You didn't include the feature of a special value for the local domain. Can we abuse localdomain and localhost, or would those be supposed to refer to the user's computer rather than the server? X-SSP-Script-Source: allow *.localdomain X-SSP-Script-Source: allow localhost I note that in Content-Restrictions, I used "this": X-SSP-Script-Source: allow this 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. X-SSP-Script-Source: allow head; allow *.example.com; deny public.example.com 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. (You need to include a note that, presumably, the restrictions are combined for script - the script access has to be allowed by both if both are present.) As the words Source and Target can be ambiguous, I would therefore suggest: SSP-Script-Host SSP-Request-Origin SSP-Request-Host SSP-Report-URI We do need to continue to think about the performance impact of Request-Source/Request-Origin. 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. Again, perhaps a middle ground. > One interesting proposal I have been sent via private email was from > Amit Klein, who suggests potentially allowing authors to include a > single, zero-parameter function within event-handling attributes, > which could be defined in an external file. Hmm... 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... Gerv _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
