We've been doing some very similar work here in the Carleton Computer Security Lab over the past year, and we put out a tech report in April that I think would be really helpful:
http://www.scs.carleton.ca/research/tech_reports/index.php?Abstract=tr-08-07_0007&Year=2008 For one, we did a bunch of analysis of the security and performance of our system that will be interesting to you and possibly some of the numbers will also apply to SSP. There's a lot of small differences between our proposals, and I'd like to point out some differences between our "soma-approval" and your "request-source" that are important: (1) Because the request-source query involves getting the headers for the resource, it can still be used as a security leak to get information out of the browser by placing it in the URI. (2) Request-source is on a per-resource basis. Soma-approval is done on a per-site basis. We have some estimated performance numbers that might be very interesting to you here, because we clocked in around 13% overhead without caching (6% with an estimated caching rate). These were overestimations based on average load times per site, but there's some prelim numbers for the Gervase, who asked about them. My colleagues and I would really love to see this sort of policy implemented in browsers, and it would be great if we could help produce a specification that is workable and secure. There's all sorts of little things I'd like to discuss, but I think it makes more sense to let you read our report first. _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
