On Jun 12, 7:07 am, Gervase Markham <[EMAIL PROTECTED]> wrote: >True. SSP in its current form is not a mechanism for locking down all >page communications
Shouldn't it be? Site admins will already have to provide all the necessary information in order to be SSP compliant, so it makes sense to me to give them extra protection. The only reason I can think of not to do this is if the implementation turns out to have a huge overhead, but although I was disappointed with our estimated numbers, I'm confident we can reduce those in practice. (see below.) > > 13% overhead without caching (6% with an estimated caching rate). > > These were overestimations based on average load times per site, > 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. Those are estimations of round-trip times, once per cross-domain, to get a policy file. They did not come from our implementation at all. They are because of network delay, not processing time. I'd say that these are very inflated numbers because we used the average request time for a given site, even though most of the files loaded from a given site would be much bigger than any policy file. They can probably be treated as a maximum load increase. Note: our test cases included some sites with very high latency, which probably brought that 6% average increase up even higher than it would be if you weren't, say, getting info from a very laggy site in France as we were. With smaller policy files (or headers), the cost should be fairly minimal, but I would say we should do some tests before assuming that it's going to be negligible, especially if you're talking about adding headers to everything. If we restricted our proposal to POST requests, as proposed for SSP, then we end up with very similar estimated performance numbers. > The restriction of SSP to POST also means that it wouldn't be useful to > prevent "bandwidth stealing". It also means that it wouldn't be that useful to prevent cross site request forgery (realistically, "safe" operations aren't unless your web programmers abide by them, and I would venture that many don't). _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
