Terri wrote: > There's a lot of small differences between our proposals,
And some big ones, if (for example) SSP ends up restricted to POST. > 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. True. SSP in its current form is not a mechanism for locking down all page communications. > (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. Are those page load time increases? It could just be the implementation mechanism you used, but I would suspect that either number would be unacceptable here. Even 1% is a big deal. The headers approach has the significant advantage of no page load increase just through deployment; the delay comes when you try and make a cross-domain POST. The restriction of SSP to POST also means that it wouldn't be useful to prevent "bandwidth stealing". Gerv _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
