----- Original Message ----- > > I'd love the health-report web page to suggest remediations for > performance-sucking issues. But I'm afraid of allowing remote content > (albeit 'secured' using HTTPS) to actually trigger this behaviour. > I'm much more confident in the pattern that the code stays in the > browser in contrast to being highly volatile.
I think that the recent work on OCSP that David Keeler has been doing and the CA pinning that Camilo Viecco has been working on go a long way towards making HTTPS secure, instead of merely "secure." I also think that the range of threats that a browser support API mitigates is far greater than the network attacks that render HTTPS merely secure-ish, and that we should do it even if the pinning is not ready yet. > A one-shot "optimize performance" button that calls a list of hard-coded > procedures (e.g. disable_known_performance_killers(), > reset_experimental_settings_that_are_for_power_users_only(), ...) would > be pretty cool though :) Firefox reset does most of this: https://support.mozilla.org/en-US/kb/reset-firefox-easily-fix-most-problems But it's not very well known, and I am guessing since you didn't mention it you might not have known about it either :) Having APIs that get around the discoverability problem makes this feature much more useful. Thanks, Monica _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
